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

arbeitskacheln/23_flutter_begleitapp.md

@@ -0,0 +1,64 @@
+# 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.<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`).