docs: Mobile-Epic komplettiert + Subagenten-Zuordnung je Epic ergänzt

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

arbeitskacheln/00_index.md

@@ -24,6 +24,38 @@ Kachel-Template und Nutzer-Vorgaben zur Methodik: siehe Memory
    noch am selben Tag live gefixt. Nie kontrollierte Objekte zählen jetzt als `unbekannt`
    statt fälschlich als „einsatzbereit". Siehe `13_readiness.md`.
 
+## Subagenten je Epic
+
+Sieben Subagenten aus dem Subagenten-Repo sind für dieses Projekt bereits installiert
+(siehe Memory `reference-subagents-repo`), plus `fastapi-expert`/`python-expert` passend
+zum Techstack. Bei der tatsächlichen UMSETZUNG einer Kachel (nicht bei der Planung hier)
+sollen die folgenden Subagenten bevorzugt herangezogen werden — als Standard-Zuordnung je
+Epic, einzelne Kacheln können abweichen:
+
+| Epic | Empfohlene Subagenten |
+|---|---|
+| 01 Foundation | fastapi-expert, postgres-expert, jwt-expert, docker-expert, openapi-expert |
+| 02 Identity | postgres-expert (Eindeutigkeits-Constraints), owasp-top10-expert (Path-Traversal bei Codes/Labels) |
+| 03 Digital File | fastapi-expert (Aggregations-Endpunkt), sql-expert (Joins über viele Tabellen) |
+| 04 Assets | postgres-expert, sql-expert |
+| 05 Fleet | fastapi-expert |
+| 06 Inventory | postgres-expert, sql-expert (Mengen-/Chargenlogik) |
+| 07 Warehouse | postgres-expert (Hierarchie-Queries, Transaktionen bei Umlagerung) |
+| 08 Loadout | fastapi-expert, sql-expert |
+| 09 Inspections | python-expert (Berechnungslogik Intervalle/Ampel) |
+| 10 Maintenance | python-expert, postgres-expert |
+| 11 Defects | fastapi-expert |
+| 12 Personnel | jwt-expert/oauth-oidc-expert (bei PERS-002 Auth-Bezug), owasp-top10-expert |
+| 13 Readiness | python-expert (Regel-Engine-Logik) |
+| 14 Documents | owasp-top10-expert (Upload-Sicherheit/MIME-Whitelist, bereits Thema bei DOC-001), fastapi-expert |
+| 15 Mobile | kein Backend-Subagent zentral (Frontend/PWA-lastig) |
+| 16 Operations | noch offen, erst bei Angehen des Epics zuordnen |
+
+**Wie einbeziehen:** vor Implementierungsbeginn einer Kachel kurz prüfen, ob einer der
+zugeordneten Subagenten als Review-Instanz (nach Fertigstellung) oder als Umsetzungs-
+Delegation sinnvoll ist — nicht zwingend für jede einzelne Kachel, aber als Standardpfad
+für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) Themen.
+
 ## Epic-Übersicht
 
 | Epic | Ziel | Priorität |
@@ -223,6 +255,6 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
 | `12_personnel.md` | PERS-001 … PERS-007 (vollständig) |
 | `13_readiness.md` | READY-001 … READY-005 (vollständig) |
 | `14_documents.md` | DOC-001 … DOC-005 (vollständig) |
+| `15_mobile.md` | MOBILE-001 … MOBILE-005 (vollständig) |
 
-Restliche Kacheln (MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen nach
-Freigabe.
+Restliche Kacheln (OPS): nur Zeile in der Tabelle oben, Details folgen nach Freigabe.

arbeitskacheln/15_mobile.md

@@ -0,0 +1,130 @@
+# 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` + `DokumentePanel` bereits 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.