Archiv-Verbund

Der geteilte Unterbau für fünf Apps, die alle dasselbe tun: etwas fotografieren, Angaben dazuschreiben, später am PC wiederfinden.

App	Bereich im Archiv	Stand
Ausstellungen	ausstellungen	live — auf der Schale gebaut
Wein	wein	live
Dunkelkammer	dunkelkammer	live
Fundus	fundus	live — von Anfang an auf der Schale
Motive	motive	live seit App 1.6.0 — nur der Weg ans Archiv, nicht auf der Schale
Tickets	—	Sonderfall, bleibt draußen (E2E-verschlüsselt)

Motive ist dabei der eine Sonderfall, der zeigt, dass das hier kein Alles-oder-nichts ist: die App bleibt am Telefon, wie sie war, und nimmt aus der Schale nur ArchivClient und automatik.js. Sie liefert ans selbe Archiv, ohne eine Schalen-App zu sein — der Umzug auf SchalenActivity bliebe ein eigenes Vorhaben.

Geteilt wird die Infrastruktur, nicht die Fachlichkeit. Jede App bleibt eine eigene APK mit eigenem Namen und Icon; am Telefon werden sie ausdrücklich nicht zusammengefasst. Was sie teilen, liegt hier.

Was hier liegt

server/	ein Archiv-Server mit Bereichen: ein Container, ein Vhost, eine Anmeldung
schale/	die gemeinsame Android-Schale — ein Gradle-Modul, als Submodul in jeder App
web/	die gemeinsame Web-Schale — ES-Module ohne Bauschritt, vom Server und aus den App-Assets ladbar

.env braucht ARCHIV_BENUTZER und ARCHIV_PASSWORT, sonst sagt die Weboberfläche „kein Konto eingerichtet" (Vorlage: .env.beispiel).

Die beiden neuen Apps (Wein, Dunkelkammer) folgen nach dem Plan.

Warum getrennte Repos

Die Apps behalten ihre eigenen Repos. Hier liegt nur, was mehr als eine App braucht. Eingebunden wird als Submodul unter Archive/ — wie, steht in schale/README.md (Android) und web/README.md (Seite).

Stand der Etappen

	Etappe
✅	0	Repo eingerichtet
✅	1	Der Server wird bereichsfähig — server/
✅	2	Ausgerollt
✅	3	Weboberfläche, lesend, mit Anmeldung
✅	4	Bearbeiten, Suche, index.html
✅	5	Android-Schale herausziehen — schale/
✅	6	Web-Schale, Kern und Betrachter — web/
⬜	7–11	Wein, dann Dunkelkammer
⬜	12	Motive nachziehen (bei Gelegenheit)