# 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.de` vorhanden, 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_URL` bleibt für die PWA unverändert relativ (`/api/v1`, CLAUDE.md-Regel), die Flutter-App nutzt stattdessen `https://mabea.perlbach-edv.de/api/v1` als 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/health` tatsächlich 200 liefert (nicht mehr den aktuell beobachteten Redirect-Loop), bevor die App-Basis-URL festgelegt wird. - **DECISION REQUIRED — App-Identität:** Package-Name (z.B. `de..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`).