patrickandClaude Sonnet 5
15fb8dbb16
Neue Tabelle fahrzeugdetails (1:1 zu Objekt, additiv/optional): Kennzeichen, Funkrufname, Baujahr, Kilometerstand, Betriebsstunden, nächste HU/UVV. objekt_status um 'in_wartung' erweitert (Nutzer-Vorgabe: einsatzbereit/ eingeschränkt/nicht einsatzbereit/in Wartung/außer Dienst - die ersten drei bleiben weiterhin rein rechnerisch über dashboard.einsatzbereitschaft(), in_wartung/ausser_dienst sind die beiden manuell gesetzten Zustände). dashboard.einsatzbereitschaft(): ausser_dienst-Objekte zählen nicht mehr mit, in_wartung und überfällige HU/UVV sind neue Gründe für "nicht einsatzbereit". dashboard.bevorstehende_prueftermine() (Kachel 2) zeigt jetzt Geräte- UND Fahrzeugprüfungen (HU/UVV) in einer Liste (Nutzer-Vorgabe: ein Konzept für "welche Prüfungen bald fällig sind") - Schema dafür verallgemeinert (typ/bezeichnung/faelligkeitsdatum statt geräte-spezifischer Felder). Frontend: Status-Dropdown + Fahrzeugdetails-Formular in ObjektSection (nur für Objekttypen mit ist_zugfahrzeug=True), Dashboard-Kachel 2 zeigt gemischte Liste. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KC8HYvv6UkCVYheYiTw9DD
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)
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 invite.config.tsreferenziert, 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 (siehebackend/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)
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.