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/12_personnel.md

@@ -23,10 +23,9 @@ Details zu PERS-001 … PERS-007 (vollständig).
 - **Audit:** Änderung geloggt
 - **Akzeptanzkriterien:** Person ohne Benutzerkonto anlegbar.
 - **Tests:** CRUD-Test, Test „Person ohne Benutzer funktioniert".
-- **DoD:** **HIGH RISK** (siehe Decision Required #4 in `00_index.md`) — größter Umbau
-  des gesamten Personal-Bereichs, da MABEA Person=Benutzer verschmolzen hat. Vor
-  Umsetzung: echten Bedarf klären (gibt es in der Praxis tatsächlich Personen ohne
-  Login-Bedarf, die trotzdem im System geführt werden müssen?).
+- **DoD:** ✅ umgesetzt (2026-09-08) — echter Bedarf via AskUserQuestion bestätigt,
+  danach live deployed. `Person`-Modell (Migration 0034 mit Backfill bestehender
+  Benutzer), `/personen`-CRUD, Admin-UI `PersonSection.tsx`.
 
 ## PERS-002 — Benutzer (technisch, verknüpft)
 
@@ -47,10 +46,10 @@ Details zu PERS-001 … PERS-007 (vollständig).
 - **Akzeptanzkriterien:** bestehende Benutzer funktionieren nach Migration unverändert.
 - **Tests:** Migrationstest (keine Datenverluste), Regressionstest bestehender
   Auth-Flows.
-- **DoD:** **DECISION REQUIRED** — das ist der eigentliche Bruch. Lohnt sich das, wenn
-  aktuell niemand Personen ohne Login braucht? Empfehlung: zurückstellen bis konkreter
-  Bedarf auftritt (z.B. Jugendgruppen-Verwaltung), dann als eigenes fokussiertes Vorhaben
-  angehen, nicht „nebenbei" im Rahmen einer anderen Kachel.
+- **DoD:** ✅ umgesetzt (2026-09-08) — `Benutzer.person_id` FK (nullable), `/benutzer`
+  verknüpft bestehende Person oder legt automatisch neue Person an, wenn keine
+  `person_id` angegeben wird (Backward-Kompatibilität). Backfill bestehender Benutzer
+  via `ROW_NUMBER()`-1:1-Positionsmatch statt Name-Join (Namenskollisionen vermieden).
 
 ## PERS-003 — Einheiten/Organisationsstruktur
 
@@ -160,10 +159,10 @@ Details zu PERS-001 … PERS-007 (vollständig).
 
 ---
 
-**MABEA-Ist-Stand-Abgleich:** PERS-003, 005, 006, 007 sind vollständig in MABEA
-umgesetzt und größtenteils sogar schon live getestet. **PERS-001/002 (Person↔Benutzer-
-Trennung) bleiben der einzige echte offene Architekturentscheid im gesamten Backlog** —
-bewusst nicht einfach umgesetzt, sondern als Decision Required markiert, da der Nutzen
-(Personen ohne Login) bisher nicht als konkreter Bedarf geäußert wurde. **PERS-004
+**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** PERS-001…003, 005, 006, 007
+sind vollständig in MABEA umgesetzt und live deployed. PERS-001/002 (Person↔Benutzer-
+Trennung) waren der größte offene Architekturentscheid im gesamten Backlog — echter
+Bedarf wurde am 2026-09-08 bestätigt, danach umgesetzt und deployed (Details siehe
+PERS-001/002 oben). **PERS-004
 (fachliche Funktion innerhalb einer Einheit, z.B. „Zugführer") fehlt komplett** — leicht
 zu verwechseln mit den bestehenden System-Rollen, ist aber ein eigenständiges Konzept.