Initiale fachliche Konzeption MABEA (Prompts 01-23, Arbeitskarten 01-13)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L85hmKbvX7Cqkq47KnQhFt

ergebnisse/17_mobile_offline.md

@@ -0,0 +1,44 @@
+# Prompt 17 – Mobile und Offline-Nutzung
+
+Bezug: [[11_kontroll_ui]], Karte [[06_geraet_pc_mobil]]. Rein fachliches Konzept, keine Technologiewahl (folgt Prompt 19).
+
+## 1. Ausgangslage
+Rettungsdienst/KatS-Umfeld: wechselnde Fahrzeuge/Wachen, Netzabdeckung nicht durchgängig gesichert (Annahme aus Prompt 01). Kontrolle darf nicht an fehlendem Netz scheitern.
+
+## 2. Bewertung: braucht V1 echtes Offline?
+- Voll-Offline (mehrstündig, mit späterer Synchronisierung inkl. Konfliktlösung) ist komplex und erhöht MVP-Umfang erheblich (Grundprinzip: V1 klein halten).
+- Praxisrelevanter Fall ist eher **kurzzeitiger Netzausfall/-lücke während einer laufenden Kontrolle**, nicht stundenlange Komplett-Offline-Nutzung ganzer Wachen.
+- Entscheidung: V1 unterstützt **robuste Kurzzeit-Unterbrechung** (siehe 3.), aber KEIN vollwertiges Offline-Konzept mit Mehrgeräte-Konfliktlösung. Vollwertiges Offline = Roadmap (Prompt 24).
+
+## 3. Konzept für V1 (Kurzzeit-Netzausfall)
+- Eingaben in der Kontroll-UI (Prompt 11) werden lokal im Gerät zwischengespeichert, sobald eingegeben – nicht erst bei Übertragung an Server verworfen, wenn Verbindung kurz fehlt.
+- Bei wiederhergestellter Verbindung: automatische Übertragung der zwischengespeicherten Eingaben, ohne dass Mitarbeiter erneut eintippen muss.
+- Deutliche Statusanzeige in der UI: „nicht gespeichert/wird übertragen" vs. „gespeichert" je Position, damit Mitarbeiter erkennt, ob Eintrag schon serverseitig gesichert ist.
+- Kontrolle kann nicht abgeschlossen werden (Prompt 16), solange nicht alle Positionen serverseitig bestätigt gespeichert sind – Abschluss-Button wartet/blockiert mit Hinweis, statt fälschlich „abgeschlossen" bei unvollständiger Übertragung zu melden.
+
+## 4. Was V1 NICHT leisten muss
+- Mehrstündige Offline-Nutzung ohne jede Verbindung.
+- Bearbeitung derselben Kontrolle durch mehrere Geräte gleichzeitig mit Konfliktauflösung (ohnehin in Prompt 02 ausgeschlossen: eine Kontrolle = eine Person zu einem Zeitpunkt).
+- Vollständige lokale Kopie des Materialstamms/aller Objekte für Offline-Betrieb.
+
+## 5. Kennzeichnung nicht synchronisierter Daten
+- Solange lokale Zwischenspeicherung nicht bestätigt an Server übertragen ist: eindeutiges visuelles Merkmal (z. B. Uhr-Symbol) an betroffenen Positionen/Kontrolle in der UI.
+- Kein „stiller" Datenverlust: Verbindungsabbruch mitten in Eingabe darf Eingabe nicht kommentarlos verwerfen.
+
+## 6. Roadmap-Erweiterung (Prompt 24)
+- Echtes Offline-Modell (z. B. ganze Schicht ohne Netz arbeiten, spätere Synchronisierung mehrerer Geräte, Konfliktbehandlung bei parallelen Änderungen) als spätere Ausbaustufe, sobald reale Nutzung zeigt, ob Bedarf über Kurzzeit-Unterbrechung hinausgeht.
+- Technisch möglicher Weg dahin (unverbindliche Notiz, Entscheidung erst Prompt 19): App (native oder PWA mit Service Worker) mit lokaler Datenhaltung auf dem Gerät, Synchronisierung bei wiederhergestellter Verbindung. Erfordert lokale Kopie relevanter Stammdaten (Materialstamm/Objekte des Nutzers) sowie Konfliktlösung bei paralleler Bearbeitung.
+
+## 7. Erweiterung: Satelliten-Server bei längerem/vollständigem Internetausfall (Karte 13, Nutzerentscheidung)
+Über die reine Kurzzeit-Unterbrechung (Punkt 3) hinaus wurde eine zweite, unabhängige Lösung für **längere oder vollständige Trennung vom Hauptserver** entschieden – relevant vor allem für KatS-Einsatzlagen (Zeltlager/Einsatzort ohne Internet) und Wachen mit dauerhaft schlechter Anbindung.
+
+- **Ansatz:** Kein Client-seitiges Offline-Caching für diesen Fall, sondern ein **Satelliten-Server** – ein vollwertiger, kleiner Klon des Hauptservers (gleiche Software/API/Datenbank), der lokal am Einsatzort/an der Wache läuft.
+- **Autark-Dauer:** bewusst nicht zeitlich begrenzt (kann Stunden bis mehrere Tage/unbestimmt sein) – kein System-Zwang zur Rücksynchronisation nach fester Frist.
+- **Mehrbenutzerfähigkeit:** mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten, da dieser funktional wie ein eigener Hauptserver arbeitet (keine reine Cache-Lösung).
+- **Konfliktvermeidung statt Konfliktlösung:** jedes Objekt ist während der Trennung exakt einem Server (Haupt- oder Satellit) fest zugeordnet und am jeweils anderen für Schreibzugriffe gesperrt. Dadurch entstehen strukturell keine Synchronisationskonflikte.
+- Details, offene Punkte (Auslagerungs-Auslöser, Stammdaten-Vorbereitung des Satelliten, Hardware) siehe [[13_satelliten_server]].
+- Abgrenzung zu Punkt 3: Kurzzeit-Pufferung im Browser bleibt für kurze Netzlücken während einer einzelnen Kontrolle; Satelliten-Server ist die Lösung für ganze Standorte/Einsatzorte über längere Zeiträume.
+
+## Referenzen
+Bezug: [[11_kontroll_ui]]
+Arbeitskarten: [[06_geraet_pc_mobil]], [[13_satelliten_server]]