# 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]]