patrickandClaude Sonnet 5
9c6426190e
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
3.8 KiB
Epic 23 — Flutter-Begleit-App (Sondierung, P3)
Bewusst nur als Sondierungs-Prototyp geplant, keine Grundsatzentscheidung.
Motivation: PWA (Epic 15 Mobile) deckt den Tablet-Feldeinsatz bereits weitgehend ab
(MOBILE-001/002/004/005 fertig). Offen ist, ob native Kamera-API für den QR-Scan
spürbar zuverlässiger ist als Browser-getUserMedia/@zxing/browser — das soll ein
einzelner Prototyp-Screen klären, bevor irgendeine Grundsatzentscheidung
(Ergänzung vs. Ablösung der PWA) fällt.
Build-Umgebung: separater Server 192.168.1.236 (Hostname aicontrol), Flutter+
Android-SDK bereits installiert, unabhängig von MABEA-Infrastruktur — reiner
Build-Host, kein Dauerbetrieb der App dort (App läuft auf Endgeräten).
FLUT-001 — QR-Scan-Prototyp gegen MABEA-Backend (P3, Sondierung)
- Ziel: Klären, ob native Kamera-API (Flutter, z.B.
mobile_scanner-Paket) den QR-Scan-Workflow spürbar zuverlässiger/schneller macht als die PWA-Lösung — KEIN Ersatz für MOBILE-002, nur Vergleichsdatenpunkt. - Scope (bewusst minimal): Login-Screen (JWT gegen
/api/v1/auth/login) + EIN Screen QR-Scan → Objekt-Identifikation anzeigen. Kein voller Kontroll-Workflow, keine Offline-Fähigkeit, kein Produktionsanspruch. - Abhängigkeiten: MABEA-Backend-API (bestehend, unverändert nutzbar — FastAPI/ REST ist stack-agnostisch, kein Rückbau nötig)
- TLS/Zertifikat — entschieden 2026-09-10: Option 1 (echte Domain + Let's
Encrypt). Domain
mabea.perlbach-edv.devorhanden, DNS zeigt bereits auf die öffentliche WAN-IP, gültiges Let's-Encrypt-Zertifikat existiert bereits (CN=mabea.perlbach-edv.de, Issuer Let's Encrypt) — läuft aber noch über einen vorgelagerten Reverse-Proxy (openresty, vermutlich Nginx Proxy Manager im Heimnetz des Nutzers), der aktuell nur auf sich selbst redirected statt auf MABEA (192.168.1.238) durchzuleiten. Nutzer kümmert sich selbst um den Proxy-Host-Eintrag (mabea.perlbach-edv.de→192.168.1.238) — liegt außerhalb des MABEA-Server-Zugriffs. Sobald das steht:VITE_API_BASE_URLbleibt für die PWA unverändert relativ (/api/v1, CLAUDE.md-Regel), die Flutter-App nutzt stattdessenhttps://mabea.perlbach-edv.de/api/v1als fest hinterlegte absolute Basis-URL — kein selbstsigniertes Zertifikat, kein Cert-Pinning, kein Sonderweg mehr nötig.- Prüfschritt vor Implementierungsstart: verifizieren, dass
https://mabea.perlbach-edv.de/api/v1/healthtatsächlich 200 liefert (nicht mehr den aktuell beobachteten Redirect-Loop), bevor die App-Basis-URL festgelegt wird.
- Prüfschritt vor Implementierungsstart: verifizieren, dass
- DECISION REQUIRED — App-Identität: Package-Name (z.B.
de.<org>.mabea), Anzeigename, Icon — noch nicht festgelegt, nicht kritisch für den Prototyp (Platzhalter-Werte reichen), aber nötig vor einem echten Android-Build. - DECISION REQUIRED — Test-Instanz: gegen Prod-Backend (192.168.1.238) direkt testen, oder separater Test-Zugang? Für einen reinen Kamera-Vergleichstest spricht wenig gegen Prod (nur Lesezugriff: Login + QR-Scan-Anzeige, keine Schreibaktionen im Scope).
- Nicht-Ziele: kein Ersatz für die PWA, keine Offline-Fähigkeit, kein vollständiger Kontroll-Workflow, keine Store-Veröffentlichung (Sideload/interner Test-Build reicht für die Sondierung).
- DoD: offen, P3 — reine Sondierung, kein MVP-Bestandteil. Ergebnis dieses Prototyps entscheidet, ob ein Folge-Epic (voller Kontroll-Workflow) überhaupt sinnvoll ist — nicht vorher committen.
Referenzen
Chat 2026-09-10: Motivation/Trade-offs erstmals besprochen (Offline-Fähigkeit,
native Hardware-Zugriffe, App-Store-Distribution als Nachteil für internes
BOS-Tool). Nutzer-Entscheidung: MABEA-Begleit-App, nur Build-Server, kein
Dauerbetrieb auf 192.168.1.236. TLS-Blocker entdeckt bei Server-Check
192.168.1.238 (/etc/nginx/sites-enabled/mabea.conf).