Sprint 7: React-PWA-Frontend (Offline-Härtung) + Flutter-Android-Grundgerüst

React/Vite-PWA (frontend/):
- Login, Objektliste (Prompt 11 Screen 1), Kontroll-Screen (Screens 2-6 kompakt:
  Start/Objekt-Sperre-Übernahme, Positionserfassung, Abschluss/Abbruch)
- Offline-Härtung (Prompt 17): IndexedDB-Queue (src/offline/queue.ts) puffert
  Positions-PUTs lokal, automatische Übertragung bei Reconnect + periodischem
  Sync-Versuch, Statusanzeige je Position (nicht gespeichert/wird übertragen/
  gespeichert/Fehler), Abschluss-Button bleibt gesperrt bis alles gespeichert
- Nutzt aus, dass PUT /kontrollen/{id}/positionen/{material_id} backend-seitig
  idempotent ist (Upsert) - Queue kann beliebig oft retryen ohne Duplikate
- Service Worker via vite-plugin-pwa für App-Shell-Caching (Start im Feld ohne
  Cold-Load); PWA-Icons als TODO vermerkt (noch keine echten Bilddateien)
- Client-Fehler (4xx) werden nicht automatisch wiederholt, nur Netzwerkfehler

Flutter-Android-Grundgerüst (flutter_app/), auf Nutzerwunsch parallel begonnen:
- Gleiche API als zweiter Client (Prompt 19 API-first), Login/Objektliste/
  Kontroll-Screen als Dart-Äquivalent zur PWA
- Bewusst OHNE Offline-Queue in dieser ersten Fassung (siehe flutter_app/README.md)
- Plattform-Ordner (android/, ios/) nicht von Hand erzeugt - müssen auf dem
  Zielsystem per `flutter create .` nachgezogen werden, sonst zu fehleranfällig
  ohne Testlauf

Offen: Playwright-E2E (Testphase 4), Praktiker-Session, PWA-Icons, Flutter-
Offline-Queue - brauchen laufendes Deployment bzw. sind kein reiner Code-Schritt.

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

frontend/README.md

@@ -0,0 +1,44 @@
+# MABEA Frontend – Sprint 7
+
+React + Vite PWA. Deckt Prompt 11 Screens 1-6 (kompakt zusammengefasst: Objektliste,
+Kontrolle mit Positionserfassung, Abschluss/Abbruch) und Prompt 17 (Offline-Härtung:
+IndexedDB-Queue, Statusanzeige je Position, Abschluss blockiert bis alles gespeichert) ab.
+
+## Setup (auf dem Zielsystem, nicht lokal)
+
+```bash
+npm install
+cp example.env .env
+# .env: VITE_API_BASE_URL auf die Backend-URL setzen
+npm run build
+```
+
+`npm run build` erzeugt `dist/` inkl. Service Worker (vite-plugin-pwa) - dieser Ordner
+wird vom Reverse-Proxy (nginx) ausgeliefert, siehe `deploy/`.
+
+## Fehlende Assets vor Produktivbetrieb
+
+- `public/icon-192.png`, `public/icon-512.png` (PWA-Manifest-Icons) müssen noch ergänzt
+  werden - aktuell nur in `vite.config.ts` referenziert, keine echten Bilddateien vorhanden.
+
+## Architektur-Entscheidungen (Sprint 7)
+
+- **Offline-Queue** (`src/offline/queue.ts`): IndexedDB statt reinem Service-Worker-Cache,
+  weil tatsächliche Formulardaten (Ist-Mengen) über Reload/Absturz hinweg erhalten bleiben
+  müssen. Der Service Worker selbst cached nur den App-Shell (Assets), keine API-Requests.
+- **Idempotenz**: `PUT /kontrollen/{id}/positionen/{material_id}` ist backend-seitig ein
+  Upsert (siehe `backend/app/services/kontrolle.py`) - die Queue kann denselben Eintrag
+  beliebig oft erneut senden, ohne doppelte Kontrollpositionen/Fehlbestände zu erzeugen.
+- **Statusanzeige**: jede Position zeigt "nicht gespeichert" / "wird übertragen…" /
+  "gespeichert" / "Fehler" - kein stiller Datenverlust bei Verbindungsabbruch (Prompt 17.5).
+- **Abschluss-Sperre**: der Abschließen-Button ist deaktiviert, solange auch nur eine
+  Position nicht bestätigt gespeichert ist.
+- Client-Fehler (4xx, z. B. Objekt-Sperre durch Übernahme) werden NICHT automatisch
+  wiederholt - der Mitarbeiter sieht den Fehler und muss bewusst reagieren.
+
+## Noch nicht umgesetzt (bewusst außerhalb Sprint 7)
+
+- QR-/Barcode-Kamera-Scan (Karte 10, Roadmap) - Objektsuche ist vorbereitet (Textfeld
+  akzeptiert auch einen gescannten Code), aber kein Kamera-Zugriff verdrahtet.
+- Playwright-E2E-Tests und Praktiker-Explorations-Session (Testphase 4) - dafür wird ein
+  laufendes Test-Deployment gebraucht, kein reiner Code-Schritt.