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

## E2E-Tests (Playwright)

```bash
npm install
npx playwright install chromium
npm run test:e2e
```

Läuft komplett gegen einen gemockten Backend (`e2e/mockApi.ts`, `page.route`) - kein
echtes Backend/DB nötig, `playwright.config.ts` startet `npm run dev` automatisch.
Deckt Login, Objekt-Sperre/Übernahme, Fortschrittsanzeige und die Offline-Queue
(Reconnect-Verhalten) ab. Reale Integrationstests gegen ein echtes Backend sowie die
Praktiker-Explorations-Session (Testphase 4) sind ein separater, späterer Schritt -
dafür wird ein laufendes Test-Deployment gebraucht, kein reiner Code-Schritt.