patrickandClaude Sonnet 5
8f9816b639
MOBILE-001/004/005 solide umgesetzt (Kontroll-UI gilt als Vorbild-Muster), MOBILE-002 nur teilweise (Scan-Ziel ist Kontrolle statt vollständiger Akte, hängt am Digital-File-Epic), MOBILE-003 (Offline) fehlt komplett, bewusst P2/HIGH RISK. Nutzer-Vorgabe: installierte Subagenten (postgres/sql/jwt/oauth-oidc/owasp/ docker/openapi/fastapi/python-expert) in die Kachel-Umsetzung einbeziehen - zentrale Epic->Subagent-Zuordnungstabelle in 00_index.md statt Rework aller 11 Detail-Dateien. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KC8HYvv6UkCVYheYiTw9DD
5.7 KiB
5.7 KiB
Epic 15 — Mobile
Details zu MOBILE-001 … MOBILE-005 (vollständig).
MOBILE-001 — PWA-Grundgerüst
- Ziel: Mobile Nutzung ohne native App — PWA installierbar, Grundgerüst für spätere Offline-Fähigkeit.
- Beschreibung: Web-App-Manifest, Service-Worker-Registrierung, Icons, responsives Base-Layout.
- Benutzerwert: Helfer installieren die Anwendung wie eine App aufs Smartphone, ohne App-Store.
- Abhängigkeiten: FOUND-005
- Datenmodell: keins
- Backend: keins zusätzlich
- Frontend: Manifest, Service-Worker-Grundgerüst
- Mobile: ist diese Kachel selbst
- QR-Code/Seriennummer/Inventarnummer: nein
- Akte: nein
- Rechte: keine neuen
- Audit: nein
- Akzeptanzkriterien: App lässt sich auf dem Smartphone „zum Homescreen hinzufügen", startet standalone.
- Tests: Manifest-Validierungstest.
- DoD: deckt sich mit MABEA (Vite-PWA-Plugin bereits eingerichtet, Manifest/Icons/ Service-Worker vorhanden).
MOBILE-002 — QR-Scan-Workflow (Kernablauf)
- Ziel: Scan → Akte öffnen → Status/Prüfung/Mangel/Foto → Speichern mit möglichst wenig Klicks.
- Beschreibung: Kamera-Zugriff, QR-Dekodierung, Routing zur Akte (IDENT-008), von dort direkte Kurzwege zu häufigen Aktionen.
- Benutzerwert: Kernversprechen des ganzen Identity-Konzepts — ohne diesen Ablauf ist QR nur Deko.
- Abhängigkeiten: MOBILE-001, IDENT-008
- Datenmodell: keins neu
- Backend: keins zusätzlich
- Frontend: Scanner-Komponente + Routing
- Mobile: ist diese Kachel selbst
- QR-Code: zentral
- Seriennummer/Inventarnummer: nein
- Akte: Zielseite
- Rechte: wie Akte-Leserecht
- Audit: nein zusätzlich
- Akzeptanzkriterien: Scan bis Akte offen in wenigen Sekunden, Fehlerfall (kein QR erkannt/ungültiger Code) klar kommuniziert.
- Tests: Scan-Erfolgs-/Fehlertest.
- DoD: deckt sich mit MABEA (
BarcodeScanner-Komponente + Scan-Route bereits vorhanden) — aber das aktuelle Scan-Ziel ist die Kontrolle, nicht eine vollständige Akte (existiert noch nicht, siehe Digital-File-Epic — größte Lücke im Backlog).
MOBILE-003 — Offline-Grundgerüst (P2)
- Ziel: Grundfunktionen auch ohne Netzverbindung nutzbar (z.B. im Keller/ Fahrzeughalle ohne Empfang).
- Beschreibung: Service-Worker-Caching-Strategie, Offline-Queue für Schreibaktionen, Sync bei Wiederverbindung.
- Benutzerwert: Arbeiten in Funklöchern ohne Datenverlust.
- Abhängigkeiten: MOBILE-001
- Datenmodell: keins (clientseitig)
- Backend: keins zusätzlich (muss idempotente/nachträgliche Verarbeitung vertragen)
- Frontend: Offline-Queue, Sync-Logik, Konfliktbehandlung
- Mobile: ist diese Kachel selbst
- QR-Code/Seriennummer/Inventarnummer: nein
- Akte: nein
- Rechte: keine neuen
- Audit: nachträglich synchronisierte Aktionen müssen korrekten Zeitstempel/Nutzer behalten
- Akzeptanzkriterien: Aktion offline ausführen, nach Wiederverbindung korrekt übernommen.
- Tests: Offline-Simulationstest.
- DoD: HIGH RISK, P2 — komplexestes Mobile-Thema. MABEA hat KEINE Offline-Fähigkeit (nur PWA-Shell-Caching via Vite-PWA-Plugin, keine Offline-Queue für Schreibvorgänge) — bei Netzausfall schlägt jede Aktion einfach fehl.
MOBILE-004 — Mobile Mangelmeldung + Foto
- Ziel: Schaden direkt im Feld melden, mit Foto vom Kamera-Sensor.
- Beschreibung: Nutzt DEFECT-001 + DOC-001, mobil-optimiertes Formular (große Buttons, wenig Tipparbeit).
- Benutzerwert: Zentrales Alltagswerkzeug für Helfer.
- Abhängigkeiten: MOBILE-002, DEFECT-001
- Datenmodell: keins neu
- Backend: keins zusätzlich
- Frontend: mobil-optimiertes Meldeformular
- Mobile: ist diese Kachel selbst
- QR-Code: Scan startet Meldung direkt am richtigen Asset
- Seriennummer/Inventarnummer: nein
- Akte: Mängelbereich
- Rechte: wie DEFECT-001
- Audit: wie DEFECT-001
- Akzeptanzkriterien: Meldung inkl. Foto in unter 30 Sekunden möglich.
- Tests: Bedienbarkeitstest (informell, kein reiner Unit-Test).
- DoD: deckt sich mit MABEA (
MangelListePage+DokumentePanelbereits responsive nutzbar) — direkter QR-Start der Meldung fehlt noch, da keine Akte/QR-Route existiert (Digital-File-Epic-Abhängigkeit).
MOBILE-005 — Mobile Beladungskontrolle
- Ziel: Kontroll-Ablauf (LOAD-004) mobil-optimiert.
- Beschreibung: Große Eingabefelder, Fach-Gruppierung, Signatur am Ende.
- Benutzerwert: Zentraler täglicher Arbeitsablauf für Helfer.
- Abhängigkeiten: MOBILE-002, LOAD-004
- Datenmodell: keins neu
- Backend: keins zusätzlich
- Frontend: mobile Kontroll-UI
- Mobile: ist diese Kachel selbst
- QR-Code: Scan startet Kontrolle direkt
- Seriennummer/Inventarnummer: Erfassung je Position
- Akte: Beladungsbereich
- Rechte: wie LOAD-004
- Audit: wie LOAD-004
- Akzeptanzkriterien: kompletter Kontrollablauf mobil ohne Zoom-/Scroll-Frust durchführbar.
- Tests: Bedienbarkeitstest.
- DoD: deckt sich 1:1 mit MABEA — explizit als gutes Muster festgehalten (Fach-Gruppierung in der Kontroll-UI kam gut an, Präzedenz für weitere mobile Screens), bereits produktiv und vom Nutzer geschätzt.
MABEA-Ist-Stand-Abgleich: MOBILE-001, 004, 005 sind solide umgesetzt (PWA läuft, die Kontroll-UI gilt sogar als vorbildliches Muster für künftige mobile Screens). MOBILE-002 ist nur teilweise erreicht — der Scan führt aktuell zur Kontrolle, nicht zu einer vollständigen Akte, weil diese noch nicht existiert (hängt am Digital-File-Epic, der größten offenen Lücke im gesamten Backlog). MOBILE-003 (Offline-Fähigkeit) fehlt komplett — bewusst P2/HIGH RISK, da technisch das anspruchsvollste Thema im Mobile-Epic.