scripte/MABEA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1e8d66f63614b25650072560cecaea12cdf9ecbd
MABEA/arbeitskacheln/15_mobile.md
T
patrickandClaude Sonnet 5 9c6426190e docs(arbeitskacheln): Open-Source-/HiOrg-Vergleich ausgewertet, 14 neue Kacheln ausgearbeitet 
Vergleich mit InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS,
HiOrg-Server ergibt neue Kacheln (ASSET-010 Custody, FILE-008 Hash-Audit-Journal,
FILE-009 Notizen, NOTIF-003, MAINT-007 Tankbuch, ZUST-003 Standort-Scoping,
FOUND-007 Import/Export, FOUND-008 Fristen-Dienst, READY-006 Statistik-Dashboard,
UI2-006..010) sowie Referenz-Ergänzungen bei bestehenden Lücken. Alle Design-
Entscheidungen (Datenmodell, Sicherheitsanforderungen bei ASSET-010) geklärt.

Neues Epic 23 (Flutter-Begleit-App, Sondierungs-Prototyp FLUT-001) inkl. geklärtem
TLS-Blocker (Domain mabea.perlbach-edv.de mit Let's-Encrypt-Zertifikat statt
selbstsigniertem Server-Zertifikat).

Alle Kacheln bleiben offen/ungeplant, nur ausgearbeitet, keine Implementierung.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
2026-09-10 00:49:32 +02:00

6.5 KiB
Raw Blame History

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 1:1 mit MABEA — Scan routet seit 2026-09-06 zur Akte (/akte/objekt/{id}), von dort Kurzweg-Button "Kontrolle starten".

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.
  • Referenz (Open-Source-Vergleich 2026-09-09): KP Front (feuerwehr-oberwil/kp-front, identischer Stack FastAPI/PostgreSQL/React-Vite-PWA, AGPL-3.0-or-later — nur Muster, keine Codeübernahme) löst das nicht als globale Offline-Queue, sondern als Draft-first-Erfassung: jede Eingabe (captureDraft.ts-Muster) wird sofort lokal als Entwurf mit eigenem Sync-Status gespeichert (statt nur bei Verbindungsverlust in eine Warteschlange zu fallen) — der Nutzer sieht pro Datensatz „lokal/synchronisiert" statt nur eines globalen Online-Banners. Für MABEA relevant, weil Kontrollen/Mängelmeldungen (MOBILE-004/005) so auch bei instabiler statt komplett fehlender Verbindung robust bleiben, nicht nur im reinen Offline-Fall. Empfehlung: MOBILE-003 auf dieses Muster hin konkretisieren statt generischer „Offline-Queue".

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 (Akte existiert jetzt, aber ohne eingebetteten Melde-Kurzweg).

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 (aktualisiert 2026-09-05): 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 jetzt nur noch ein kleiner Nachzug — die Akte existiert seit dem Digital-File-Epic (/akte/objekt/{id}), der Scan routet aber weiterhin zur Kontrolle statt zur Akte; Umstellung des Scan-Ziels ist kein Neubau mehr. MOBILE-003 (Offline-Fähigkeit) fehlt weiterhin komplett — bewusst P2/HIGH RISK, da technisch das anspruchsvollste Thema im Mobile-Epic.

Reference in New Issue View Git Blame Copy Permalink