docs: Arbeitskacheln-Backlog als Dateien angelegt (arbeitskacheln/)

Master-Prompt-Ergebnis vom 2026-09-05 (Epic-Übersicht, vollständige Kachel- Liste, Abhängigkeitsgraph, MVP-Abgrenzung, Details zu den ersten 20 Kacheln) aus dem Chat in Dateien überführt statt nur im Gespräch zu bleiben. 00_index.md: Decisions Required, Epic-Übersicht, vollständige Kachel-Tabelle, Abhängigkeitsgraph, MVP-Abgrenzung. 01_foundation.md / 02_identity.md / 03_digital_file.md: Detailspezifikation je Kachel (Ziel/Beschreibung/Datenmodell/Rechte/Akzeptanzkriterien/Tests/DoD), jeweils mit Abgleich gegen den aktuellen MABEA-Ist-Stand. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KC8HYvv6UkCVYheYiTw9DD
2026-09-05 15:16:14 +02:00
parent 95e04b521b
commit 5524ef9ce9
4 changed files with 682 additions and 0 deletions
@@ -0,0 +1,212 @@
 # Arbeitskacheln-Backlog — KatS-/BOS-Ressourcenplattform
 Master-Prompt-Ergebnis (2026-09-05), Phase 1: Epic-Übersicht, vollständige Kachel-Liste,
 Abhängigkeitsgraph, Priorisierung, MVP-Abgrenzung. Details je Kachel liegen in den
 epic-eigenen Dateien (`01_foundation.md`, `02_identity.md`, ...), fortlaufend ergänzt.
 Kachel-Template und Nutzer-Vorgaben zur Methodik: siehe Memory
 `feedback_arbeitskacheln_methodik.md`.
 ## DECISION REQUIRED
 1. **Verhältnis zu MABEA:** Dieses Backlog beschreibt großteils, was in MABEA (dieses Repo)
   bereits gebaut ist. Entscheidung: **(a) MABEA-Code weiterverwenden**, Kacheln als
   nachträgliche Strukturierung/Lückenfüller — nicht (b) Neustart. Begründung: vermeidet
   Doppelarbeit.
 2. **Techstack:** FastAPI/PostgreSQL/React-PWA beibehalten (bereits entschieden, funktioniert,
   self-hosted-tauglich) statt Resgrid-(.NET)/OpenFleet-(Node) Stack zu übernehmen.
 3. **QR-Code-Inhalt-Schema:** **entschieden — URL-Pfad** (`/akte/{ressourcentyp}/{id}`), kein
   signierter Token, keine Volldaten im QR.
 4. **Person/Benutzer-Trennung (PERS-001/002):** MABEA hat aktuell nur `Benutzer` (Login=Person
   verschmolzen). Echte Trennung ist ein Datenmodell-Bruch — Umfang vorher separat abschätzen,
   bevor verbindlich eingeplant.
 ## Epic-Übersicht
 | Epic | Ziel | Priorität |
 |---|---|---|
 | 01 Foundation | Technisches Fundament (Repo/DB/Auth/API/Logging/CI) | P0 |
 | 02 Identity | Objekt-ID/Inventarnummer/Seriennummer/QR/Barcode | P0 |
 | 03 Digital File | Akte als Aggregations-Entität über alle Teilbereiche | P0 |
 | 04 Assets | Generisches Ressourcenmodell (Kategorie/Typ/Instanz/Set) | P0 |
 | 05 Fleet | Fahrzeug-Spezialfelder | P1 |
 | 06 Inventory | Material (Einzelgerät/Verbrauchsmaterial/Chargen) | P1 |
 | 07 Warehouse | Lagerplätze, Bestand, Bewegungen | P1 |
 | 08 Loadout | Soll/Ist-Beladung, Kontrolle | P1 |
 | 09 Inspections | Prüfungen generisch | P1 |
 | 10 Maintenance | Wartung | P2 |
 | 11 Defects | Mängel-Ticket | P1 |
 | 12 Personnel | Person/Benutzer/Qualifikation | P1 |
 | 13 Readiness | Zentrale Einsatzbereitschafts-Engine | P1 |
 | 14 Documents | Dokumentenverwaltung | P2 |
 | 15 Mobile | QR-Scan-Workflow, PWA | P1 |
 | 16 Operations | Einsatzverwaltung (Ausblick) | P3 |
 ## Vollständige Kachel-Liste
 | ID | Modul | Kachel | Prio | Aufwand | Risiko | Abhängigkeiten |
 |---|---|---|---|---|---|---|
 | FOUND-001 | Foundation | Repo & Projektstruktur | P0 | S | LOW | — |
 | FOUND-002 | Foundation | DB-Grundgerüst + Migrationen | P0 | S | LOW | FOUND-001 |
 | FOUND-003 | Foundation | Authentication | P0 | M | MEDIUM | FOUND-002 |
 | FOUND-004 | Foundation | Authorization-Grundgerüst | P0 | M | MEDIUM | FOUND-003 |
 | FOUND-005 | Foundation | API-Grundgerüst/Konventionen | P0 | S | LOW | FOUND-002 |
 | FOUND-006 | Foundation | Logging & Audit-Grundgerüst | P0 | S | LOW | FOUND-002 |
 | FOUND-007 | Foundation | Konfigurationsmanagement | P0 | XS | LOW | FOUND-001 |
 | FOUND-008 | Foundation | Docker/Compose-Setup | P0 | M | MEDIUM | FOUND-001 |
 | FOUND-009 | Foundation | CI/CD-Grundgerüst | P0 | S | LOW | FOUND-008 |
 | FOUND-010 | Foundation | Backup-Strategie | P1 | S | MEDIUM | FOUND-002 |
 | FOUND-011 | Foundation | Test-Grundgerüst | P0 | M | LOW | FOUND-002 |
 | FOUND-012 | Foundation | Dokumentationsgerüst | P1 | XS | LOW | FOUND-001 |
 | IDENT-001 | Identity | Objekt-ID-Schema | P0 | S | LOW | FOUND-002 |
 | IDENT-002 | Identity | Inventarnummer manuell | P0 | S | LOW | IDENT-001 |
 | IDENT-003 | Identity | Inventarnummer-Nummernschemata | P1 | M | MEDIUM | IDENT-002 |
 | IDENT-004 | Identity | Seriennummer + Eindeutigkeitsprüfung | P0 | S | LOW | IDENT-001 |
 | IDENT-005 | Identity | Hersteller/Modell-Stammdaten | P1 | S | LOW | IDENT-004 |
 | IDENT-006 | Identity | QR-Code-Erzeugung | P0 | S | LOW | IDENT-001 |
 | IDENT-007 | Identity | QR-Code-Druck (Label) | P0 | S | LOW | IDENT-006 |
 | IDENT-008 | Identity | QR-Scan → Akte öffnen | P0 | M | MEDIUM | IDENT-006, FILE-006 |
 | IDENT-009 | Identity | QR-Neuvergabe & -Historie | P2 | S | LOW | IDENT-006 |
 | IDENT-010 | Identity | Barcode/GTIN | P3 | S | LOW | IDENT-001 |
 | FILE-001 | Digital File | Akte-Grundgerüst | P0 | M | MEDIUM | IDENT-001 |
 | FILE-002 | Digital File | Akte-Stammdatenbereich | P0 | S | LOW | FILE-001 |
 | FILE-003 | Digital File | Akte-Standortbereich | P0 | S | LOW | FILE-001, WH-001 |
 | FILE-004 | Digital File | Akte-Verantwortlichkeit | P1 | S | LOW | FILE-001, PERS-003 |
 | FILE-005 | Digital File | Akte-Historienbereich | P0 | M | MEDIUM | FILE-001, FOUND-006 |
 | FILE-006 | Digital File | Akte-Übersichtsseite (UI) | P0 | M | LOW | FILE-002..005 |
 | FILE-007 | Digital File | Akte-Audit-Anbindung | P1 | S | LOW | FILE-005 |
 | ASSET-001 | Assets | AssetCategory | P0 | XS | LOW | FOUND-002 |
 | ASSET-002 | Assets | AssetType | P0 | S | LOW | ASSET-001 |
 | ASSET-003 | Assets | Asset/AssetInstance | P0 | M | MEDIUM | ASSET-002, IDENT-001/002/004 |
 | ASSET-004 | Assets | Asset-Status-Modell | P0 | S | LOW | ASSET-003 |
 | ASSET-005 | Assets | Asset-Suche & Liste | P1 | S | LOW | ASSET-003 |
 | ASSET-006 | Assets | Asset-Bewegungshistorie | P1 | S | LOW | ASSET-003, WH-001 |
 | ASSET-007 | Assets | AssetSet | P2 | M | MEDIUM | ASSET-003 |
 | ASSET-008 | Assets | Consumable | P1 | M | MEDIUM | ASSET-002 |
 | FLEET-001 | Fleet | Fahrzeugtypen | P1 | XS | LOW | ASSET-002 |
 | FLEET-002 | Fleet | Fahrzeuge (Kennzeichen/Funkrufname) | P1 | S | LOW | ASSET-003, FLEET-001 |
 | FLEET-003 | Fleet | Kilometer/Betriebsstunden | P1 | XS | LOW | FLEET-002 |
 | FLEET-004 | Fleet | Fahrzeugstatus (5-stufig) | P1 | S | LOW | FLEET-002, READY-002 |
 | FLEET-005 | Fleet | Fahrzeug-Dokumente | P2 | XS | LOW | FLEET-002, DOC-001 |
 | FLEET-006 | Fleet | Fahrzeug-Einsatzhistorie (Platzhalter) | P3 | S | MEDIUM | FLEET-002, OPS-002 |
 | INV-001 | Inventory | Materialarten/Kategorien | P1 | XS | LOW | ASSET-001 |
 | INV-002 | Inventory | Einzelgeräte (SN-pflichtig) | P1 | S | LOW | ASSET-003, IDENT-004 |
 | INV-003 | Inventory | Verbrauchsmaterial (Mengen) | P1 | S | LOW | ASSET-008 |
 | INV-004 | Inventory | Chargenverwaltung | P1 | S | MEDIUM | INV-003 |
 | INV-005 | Inventory | Ablaufdaten & Warnschwellen | P1 | S | LOW | INV-004 |
 | INV-006 | Inventory | Mindestbestände & Fehlbestand | P1 | M | MEDIUM | INV-003, LOAD-001 |
 | INV-007 | Inventory | Ausgabe/Rückgabe | P2 | M | MEDIUM | INV-003 |
 | WH-001 | Warehouse | Lager-Stammdaten (Hierarchie) | P1 | S | LOW | FOUND-002 |
 | WH-002 | Warehouse | Lagerplätze | P1 | S | LOW | WH-001 |
 | WH-003 | Warehouse | Bestand je Lagerplatz | P1 | M | MEDIUM | WH-002, INV-003 |
 | WH-004 | Warehouse | Einlagerung/Auslagerung | P1 | M | MEDIUM | WH-003 |
 | WH-005 | Warehouse | Umlagerung | P1 | S | LOW | WH-004 |
 | WH-006 | Warehouse | Inventur & Bestandskorrektur | P2 | M | MEDIUM | WH-003 |
 | WH-007 | Warehouse | Materialbewegungsprotokoll | P1 | S | LOW | WH-004, FOUND-006 |
 | LOAD-001 | Loadout | Soll-Beladung/Beladungsplan | P1 | M | MEDIUM | ASSET-003, INV-002/003 |
 | LOAD-002 | Loadout | Ist-Beladung | P1 | S | LOW | LOAD-001 |
 | LOAD-003 | Loadout | Abweichungserkennung | P1 | S | MEDIUM | LOAD-002 |
 | LOAD-004 | Loadout | Digitale Beladungskontrolle | P1 | M | MEDIUM | LOAD-003 |
 | LOAD-005 | Loadout | Kontrollhistorie | P1 | S | LOW | LOAD-004, FOUND-006 |
 | LOAD-006 | Loadout | Readiness-Kopplung | P1 | S | MEDIUM | LOAD-003, READY-001 |
 | INSP-001 | Inspections | Prüfarten-Stammdaten | P1 | S | LOW | ASSET-002 |
 | INSP-002 | Inspections | Prüfintervalle | P1 | S | LOW | INSP-001 |
 | INSP-003 | Inspections | Prüfdurchführung/-ergebnis | P1 | M | MEDIUM | INSP-002 |
 | INSP-004 | Inspections | Status-Ampel (VALID/DUE_SOON/OVERDUE/FAILED) | P1 | S | LOW | INSP-003 |
 | INSP-005 | Inspections | Prüfdokument-Anbindung | P2 | XS | LOW | INSP-003, DOC-001 |
 | INSP-006 | Inspections | Prüftermin-Übersicht | P1 | S | LOW | INSP-004 |
 | MAINT-001 | Maintenance | Wartungspläne | P2 | S | LOW | ASSET-002 |
 | MAINT-002 | Maintenance | Wartungsintervalle | P2 | S | MEDIUM | MAINT-001 |
 | MAINT-003 | Maintenance | Wartungsauftrag | P2 | M | MEDIUM | MAINT-002 |
 | MAINT-004 | Maintenance | Wartungshistorie | P2 | S | LOW | MAINT-003, FOUND-006 |
 | MAINT-005 | Maintenance | Ersatzteile/Kosten | P3 | M | MEDIUM | MAINT-003 |
 | MAINT-006 | Maintenance | Wartungsdokument-Anbindung | P2 | XS | LOW | MAINT-003, DOC-001 |
 | DEFECT-001 | Defects | Mangelmeldung + Foto | P1 | M | LOW | ASSET-003, DOC-001 |
 | DEFECT-002 | Defects | Priorität & Status-Workflow | P1 | S | LOW | DEFECT-001 |
 | DEFECT-003 | Defects | Verantwortlicher & Reparaturzuordnung | P1 | S | LOW | DEFECT-002, PERS-002 |
 | DEFECT-004 | Defects | Abschluss & Dokumentation | P1 | S | LOW | DEFECT-003 |
 | DEFECT-005 | Defects | Readiness-Einfluss (kritisch) | P1 | S | MEDIUM | DEFECT-002, READY-001 |
 | PERS-001 | Personnel | Person (fachlich) | P1 | M | HIGH | FOUND-002 |
 | PERS-002 | Personnel | Benutzer (technisch, verknüpft) | P0 | M | HIGH | PERS-001, FOUND-003 |
 | PERS-003 | Personnel | Einheiten/Organisationsstruktur | P1 | S | LOW | PERS-001 |
 | PERS-004 | Personnel | Funktionen/Rollen im Einsatzkontext | P2 | S | LOW | PERS-003 |
 | PERS-005 | Personnel | Qualifikationen/Lehrgänge | P1 | S | LOW | PERS-001 |
 | PERS-006 | Personnel | Führerscheine/Berechtigungen mit Gültigkeit | P1 | M | MEDIUM | PERS-005, ASSET-002 |
 | PERS-007 | Personnel | Qualifikationsablauf-Warnungen | P1 | S | LOW | PERS-006 |
 | READY-001 | Readiness | Regel-Engine (Grundgerüst) | P1 | M | HIGH | ASSET-004 |
 | READY-002 | Readiness | Zustände READY/LIMITED/NOT_READY/UNKNOWN | P1 | S | MEDIUM | READY-001 |
 | READY-003 | Readiness | Regel-Kopplung (Prüfung/Wartung/Mangel/Beladung) | P1 | L | HIGH | READY-002, INSP-004, DEFECT-005, LOAD-006 |
 | READY-004 | Readiness | Readiness-Dashboard | P1 | S | LOW | READY-003 |
 | READY-005 | Readiness | Regel-Konfiguration-UI | P2 | M | MEDIUM | READY-003 |
 | DOC-001 | Documents | Dokument-Grundgerüst (Upload) | P1 | M | MEDIUM | FILE-001 |
 | DOC-002 | Documents | Dokumenttypen | P2 | XS | LOW | DOC-001 |
 | DOC-003 | Documents | Versionierung | P2 | M | MEDIUM | DOC-001 |
 | DOC-004 | Documents | Original-vs-Kopie-Kennzeichnung | P2 | S | LOW | DOC-001 |
 | DOC-005 | Documents | Zugriffsrechte je Dokument | P2 | S | MEDIUM | DOC-001, FOUND-004 |
 | MOBILE-001 | Mobile | PWA-Grundgerüst | P1 | M | MEDIUM | FOUND-005 |
 | MOBILE-002 | Mobile | QR-Scan-Workflow (Kernablauf) | P1 | M | MEDIUM | MOBILE-001, IDENT-008 |
 | MOBILE-003 | Mobile | Offline-Grundgerüst | P2 | L | HIGH | MOBILE-001 |
 | MOBILE-004 | Mobile | Mobile Mangelmeldung + Foto | P1 | S | LOW | MOBILE-002, DEFECT-001 |
 | MOBILE-005 | Mobile | Mobile Beladungskontrolle | P1 | S | MEDIUM | MOBILE-002, LOAD-004 |
 | OPS-001 | Operations | Einsatzverwaltung (Platzhalter) | P3 | L | HIGH | FILE-001 |
 | OPS-002 | Operations | Einsatzmittel-Verknüpfung | P3 | M | MEDIUM | OPS-001, ASSET-003 |
 | OPS-003 | Operations | Einsatznachbereitung (Platzhalter) | P3 | L | HIGH | OPS-001 |
 ## Abhängigkeitsgraph (Epic-Ebene)
 ```
 FOUNDATION
    ↓
 IDENTITY ──────────────┐
    ↓                   │
 DIGITAL FILE ←──────────┤ (Akte referenziert Identity direkt)
    ↓                   │
 ASSETS ←────────────────┘
    ↓         ↓          ↓
 FLEET   INVENTORY    PERSONNEL
    ↓         ↓          │
    │    WAREHOUSE       │
    │         ↓          │
    │      LOADOUT       │
    ↓         ↓          ↓
 INSPECTIONS  DEFECTS   (Qualifikation → Readiness)
    ↓         ↓
 MAINTENANCE   │
    ↓         ↓
     READINESS ←── (bündelt Inspections+Maintenance+Defects+Loadout)
         ↓
     DOCUMENTS (läuft quer durch alle Epics ab FILE-001)
         ↓
     MOBILE
         ↓
     OPERATIONS (Ausblick, P3)
 ```
 ## MVP-Abgrenzung (P0 + P1)
 **P0 (zwingend, Foundation):** FOUND-001…011, IDENT-001/002/004/006/007/008,
 FILE-001/002/003/005/006, ASSET-001…004, PERS-002.
 **P1 (MVP-Funktionsumfang):** Fleet (komplett), Inventory (komplett), Warehouse (komplett),
 Loadout (komplett), Inspections (komplett), Defects (komplett), Personnel (bis auf PERS-004),
 Readiness (bis auf READY-005), Mobile (bis auf MOBILE-003), DOC-001 (nur Grundgerüst,
 Rest P2).
 **Bewusst außerhalb MVP:** Maintenance (P2, außer Kern optional), Documents-Feinschliff
 (Versionierung/Zugriffsrechte, P2), Operations komplett (P3).
 Deckt sich das MVP praktisch mit dem, was in MABEA schon existiert — Lücken laut diesem
 Backlog gegenüber MABEA-Ist-Stand: **PERS-001 (Person getrennt von Benutzer)**,
 **AssetSet/Consumable als eigenständige Konzepte (ASSET-007/008)**, **Readiness als
 konfigurierbare Regel-Engine statt fest verdrahteter Logik (READY-001/005)**, **Wartung als
 eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
 ## Detaillierungsstand
 | Datei | Enthält Details für |
 |---|---|
 | `01_foundation.md` | FOUND-001 … FOUND-006 |
 | `02_identity.md` | IDENT-001, 002, 004, 005 … 010 |
 | `03_digital_file.md` | FILE-001 … FILE-005 |
 Restliche Kacheln: nur Zeile in der Tabelle oben, Details folgen nach Freigabe.
@@ -0,0 +1,138 @@
 # Epic 01 — Foundation
 Details zu FOUND-001 … FOUND-006. Übersichtstabelle mit allen FOUND-Kacheln (auch die noch
 nicht detaillierten) siehe `00_index.md`.
 ---
 ## FOUND-001 — Repo & Projektstruktur
 - **Modul:** Foundation
 - **Ziel:** Einheitliche, nachvollziehbare Code-Basis, auf der alle weiteren Kacheln aufbauen.
 - **Beschreibung:** Verzeichnisstruktur Backend/Frontend, Namenskonventionen,
  Formatierungs-/Lint-Regeln, Basis-README.
 - **Benutzerwert:** Keiner direkt (Entwickler-Infrastruktur), aber Voraussetzung für alles.
 - **Abhängigkeiten:** keine
 - **Datenmodell:** keins
 - **Backend:** Grundgerüst (App-Einstiegspunkt, Router-Registrierung leer)
 - **Frontend:** Grundgerüst (Build-Tooling, leere Startseite)
 - **Mobile:** noch nicht relevant
 - **QR-Code:** nein
 - **Seriennummer:** nein
 - **Inventarnummer:** nein
 - **Akte:** nein
 - **Rechte:** keine (noch kein Auth)
 - **Audit:** nein
 - **Akzeptanzkriterien:** Repo klont sich, Backend startet, Frontend baut, Lint läuft ohne
  Fehler.
 - **Tests:** Smoke-Test „App startet"
 - **DoD:** lauffähiges leeres Grundgerüst, dokumentiert im README.
 ## FOUND-002 — DB-Grundgerüst + Migrationen
 - **Ziel:** Versionierte, reproduzierbare Datenbankstruktur.
 - **Beschreibung:** PostgreSQL-Anbindung, Migrationstool (z.B. Alembic), erste leere Migration.
 - **Benutzerwert:** indirekt (Datenintegrität/Nachvollziehbarkeit für alle Module).
 - **Abhängigkeiten:** FOUND-001
 - **Datenmodell:** Migrations-Metatabelle (vom Tool selbst verwaltet)
 - **Backend:** DB-Session-Handling, Connection-Pool
 - **Frontend:** —
 - **Mobile:** —
 - **QR-Code / Seriennummer / Inventarnummer / Akte:** nein
 - **Rechte:** keine
 - **Audit:** nein
 - **Akzeptanzkriterien:** Migration lässt sich anwenden und zurückrollen, DB-Verbindung aus
  App funktioniert.
 - **Tests:** Migrations-Up/Down-Test gegen Testdatenbank.
 - **DoD:** Migration reproduzierbar auf frischer DB, CI führt sie aus.
 ## FOUND-003 — Authentication
 - **Ziel:** Sichere Anmeldung als Basis für jede weitere Rechteprüfung.
 - **Beschreibung:** Login mit Passwort (gehashed), Token-Ausgabe (JWT o.ä.),
  Token-Validierung.
 - **Benutzerwert:** Jeder Nutzer kann sich anmelden — Grundvoraussetzung für alles Weitere.
 - **Abhängigkeiten:** FOUND-002
 - **Datenmodell:** `benutzer` (login, passwort_hash, aktiv)
 - **Backend:** POST /auth/login, Token-Decode-Dependency
 - **Frontend:** Login-Seite
 - **Mobile:** gleicher Login-Flow
 - **QR-Code/Seriennummer/Inventarnummer:** nein
 - **Akte:** nein
 - **Rechte:** noch keine Rollen, nur „angemeldet/nicht angemeldet"
 - **Audit:** Login-Fehlversuche protokollieren (Brute-Force-Erkennung, optional P2)
 - **Akzeptanzkriterien:** korrektes Passwort → Token; falsches Passwort → 401; abgelaufener
  Token → 401.
 - **Tests:** Login erfolgreich/fehlgeschlagen, Token-Ablauf.
 - **DoD:** Login funktioniert clientseitig und serverseitig, Passwort niemals im Klartext
  gespeichert/geloggt.
 ## FOUND-004 — Authorization-Grundgerüst
 - **Ziel:** Zentrale Stelle, an der jeder Endpunkt Rechte prüfen kann.
 - **Beschreibung:** Rollen-Modell (fest, kein granulares System — das kommt erst in
  Personnel/Readiness-Phase oder eigener späterer Kachel), Dependency/Middleware für
  Rollenprüfung.
 - **Benutzerwert:** Schützt sensible Aktionen (z.B. nur Materialwart darf Material anlegen).
 - **Abhängigkeiten:** FOUND-003
 - **Datenmodell:** `rolle`, `benutzer_rolle`
 - **Backend:** require_roles()-Dependency
 - **Frontend:** Rollenbasiertes Ein-/Ausblenden von UI-Elementen
 - **Mobile:** gleiches Prinzip
 - **Akte/QR/SN/Inv:** nein
 - **Rechte:** dies IST das Rechte-Grundgerüst
 - **Audit:** Rollenänderungen protokollieren
 - **Akzeptanzkriterien:** Endpunkt ohne passende Rolle → 403; mit passender Rolle → 200.
 - **Tests:** je Rolle ein Zugriffstest.
 - **DoD:** mind. 2 Rollen (z.B. Administrator, Helfer) funktionieren nachweisbar
  unterschiedlich.
 ## FOUND-005 — API-Grundgerüst
 - **Ziel:** Konsistente API für alle künftigen Module.
 - **Beschreibung:** Einheitliches Fehlerformat, Versionierungs-Präfix (`/api/v1`),
  OpenAPI-Dokumentation automatisch.
 - **Benutzerwert:** indirekt — konsistente, vorhersehbare API für Frontend/Mobile/
  Drittsysteme.
 - **Abhängigkeiten:** FOUND-002
 - **Datenmodell:** keins
 - **Backend:** Fehler-Handler, Health-Endpoint
 - **Frontend:** generischer API-Client mit einheitlicher Fehlerbehandlung
 - **Mobile:** gleicher Client
 - **Akte/QR/SN/Inv:** nein
 - **Rechte:** keine (Health-Endpoint öffentlich)
 - **Audit:** nein
 - **Akzeptanzkriterien:** `/health` antwortet 200, ein absichtlich provozierter Fehler
  liefert einheitliches JSON-Fehlerformat.
 - **Tests:** Health-Check-Test, Fehlerformat-Test.
 - **DoD:** OpenAPI-Doku ist unter `/docs` erreichbar.
 ## FOUND-006 — Logging & Audit-Grundgerüst
 - **Ziel:** Jede sicherheits-/fachlich relevante Aktion muss später nachvollziehbar sein.
 - **Beschreibung:** Zentrale Audit-Tabelle (append-only), generische Log-Funktion
  (wer/wann/was/alter Wert/neuer Wert).
 - **Benutzerwert:** Nachvollziehbarkeit für Zugführer/Administrator, Vertrauenswürdigkeit
  des Systems.
 - **Abhängigkeiten:** FOUND-002
 - **Datenmodell:** `audit_log` (id, zeitpunkt, benutzer_id, ereignistyp, entitaet_typ,
  entitaet_id, alter_wert, neuer_wert)
 - **Backend:** log()-Service-Funktion, von anderen Modulen aufrufbar
 - **Frontend:** Änderungslog-Ansicht (rudimentär, volle UI evtl. später eigene Kachel)
 - **Mobile:** —
 - **Akte/QR/SN/Inv:** nein direkt, aber Grundlage für FILE-005/007
 - **Rechte:** Lesen nur privilegierte Rollen
 - **Audit:** ist selbst das Audit-System
 - **Akzeptanzkriterien:** eine Testaktion erzeugt einen Log-Eintrag mit korrektem
  Vorher/Nachher-Wert.
 - **Tests:** Log-Eintrag wird bei simulierter Aktion erzeugt und ist abrufbar.
 - **DoD:** mind. ein reales Ereignis (z.B. Login) wird bereits geloggt.
 ---
 **MABEA-Ist-Stand-Abgleich:** FOUND-001…006 sind in MABEA vollständig vorhanden
 (FastAPI-Grundgerüst, Alembic-Migrationen, JWT-Login, `require_roles()`-Dependency,
 einheitliches Fehlerformat + `/docs`, `historie`-Tabelle als Audit-Log). FOUND-007…012
 (Konfiguration/Docker/CI/Backup/Tests/Doku) ebenfalls größtenteils vorhanden
 (`app_settings.py`, `.env`, Gitea-CI `ci.yml`, `pytest`, README/DEVLOG) — kein Nachholbedarf
 in diesem Epic.
@@ -0,0 +1,209 @@
 # Epic 02 — Identity
 Details zu IDENT-001, 002, 004, 005–010. IDENT-003 (Nummernschemata) noch nicht detailliert,
 siehe `00_index.md`-Tabelle.
 ---
 ## IDENT-001 — Objekt-ID-Schema
 - **Ziel:** Jede Ressource ist technisch eindeutig identifizierbar, unabhängig von
  Fachfeldern.
 - **Beschreibung:** Primärschlüssel-Strategie für alle Ressourcentypen festlegen (UUID vs.
  fortlaufende ID je Tabelle), Konvention dokumentieren.
 - **Benutzerwert:** Grundlage für QR-Code/Verknüpfungen — ohne stabile ID keine verlässliche
  digitale Identität.
 - **Abhängigkeiten:** FOUND-002
 - **Datenmodell:** Konvention (kein neues Feld, sondern Festlegung für alle künftigen
  Tabellen)
 - **Backend/Frontend/Mobile:** —
 - **QR-Code:** Grundlage für spätere QR-Kacheln
 - **Seriennummer/Inventarnummer:** getrennt davon, siehe IDENT-002/004
 - **Akte:** die ID ist der Aufhänger der Akte
 - **Rechte:** keine
 - **Audit:** nein
 - **Akzeptanzkriterien:** dokumentierte Entscheidung (ADR), mind. ein Beispiel-Modell nutzt
  sie.
 - **Tests:** keine (reine Konvention)
 - **DoD:** ADR verabschiedet, in FOUND-002-Migrationsvorlage verankert.
 ## IDENT-002 — Inventarnummer (manuell)
 - **Ziel:** Organisationseigene, menschenlesbare Kennzeichnung neben der technischen ID.
 - **Beschreibung:** Freitextfeld, Eindeutigkeit je Organisation erzwingen.
 - **Benutzerwert:** Materialwart kann Ressourcen anhand vertrauter Nummern wiederfinden
  (Etiketten, Inventarlisten).
 - **Abhängigkeiten:** IDENT-001
 - **Datenmodell:** `inventarnummer` (Textfeld, UNIQUE je Organisation) an Asset-Tabelle
  (folgt ab ASSET-003)
 - **Backend:** Validierung Eindeutigkeit bei Anlage/Änderung
 - **Frontend:** Eingabefeld bei Ressourcenanlage
 - **Mobile:** Anzeige in der Akte
 - **QR-Code:** kann Teil des gedruckten Labels sein (Klartext-Fallback)
 - **Seriennummer:** getrennt, siehe IDENT-004
 - **Akte:** Kernfeld der Identität
 - **Rechte:** Ändern nur Materialwart/Administrator
 - **Audit:** Änderung der Inventarnummer wird geloggt
 - **Akzeptanzkriterien:** doppelte Inventarnummer wird abgelehnt (409), Änderung wird
  protokolliert.
 - **Tests:** Konflikt-Test, Erfolgstest.
 - **DoD:** funktioniert für mind. einen Ressourcentyp (Vorgriff auf ASSET-003, kann testweise
  an Dummy-Tabelle validiert werden).
 ## IDENT-004 — Seriennummer + Eindeutigkeitsprüfung
 - **Ziel:** Herstellerseitige eindeutige Kennzeichnung erfassen.
 - **Beschreibung:** Seriennummernfeld, Eindeutigkeit optional je Materialtyp konfigurierbar
  (manche Ressourcen brauchen keine SN-Eindeutigkeit global, sondern nur je Objektposition
  — Lehre aus MABEA: SN ist nur innerhalb einer Position eindeutig, nicht global).
 - **Benutzerwert:** Rückverfolgbarkeit bei Rückrufaktionen/Garantiefällen/Diebstahl.
 - **Abhängigkeiten:** IDENT-001
 - **Datenmodell:** `seriennummer` (Text) an Asset-Instanz
 - **Backend:** Eindeutigkeitsprüfung im konfigurierten Scope
 - **Frontend:** Eingabefeld, ggf. Scan-Unterstützung (Kamera, spätere Mobile-Kachel)
 - **Mobile:** Anzeige/Erfassung
 - **QR-Code:** SN kann im gedruckten Label als Klartext stehen, nicht im QR-Inhalt selbst
 - **Inventarnummer:** getrennt, siehe IDENT-002
 - **Akte:** Kernfeld
 - **Rechte:** Ändern nur Materialwart/Administrator
 - **Audit:** Änderung wird geloggt
 - **Akzeptanzkriterien:** doppelte SN im gleichen Scope wird abgelehnt, in unterschiedlichem
  Scope erlaubt.
 - **Tests:** beide Fälle abgedeckt.
 - **DoD:** wie IDENT-002, funktioniert an Dummy-/Vorgriffs-Tabelle.
 ## IDENT-005 — Hersteller/Modell-Stammdaten
 - **Ziel:** Herstellerangaben strukturiert statt als Freitext im Namen.
 - **Beschreibung:** Stammdatentabelle Hersteller, Modellfeld am AssetType, Verknüpfung.
 - **Benutzerwert:** Ersatzteilsuche/Rückrufabgleich nach Hersteller möglich, saubere
  Filterung.
 - **Abhängigkeiten:** IDENT-004
 - **Datenmodell:** `hersteller` (id, name), `asset_type.hersteller_id`, `asset_type.modell`
 - **Backend:** CRUD Hersteller, Modellfeld in AssetType-Endpunkten
 - **Frontend:** Herstellerauswahl im AssetType-Formular
 - **Mobile:** Anzeige in Akte
 - **QR-Code:** nein
 - **Seriennummer/Inventarnummer:** nein
 - **Akte:** Stammdatenbereich
 - **Rechte:** Ändern nur Materialwart/Administrator
 - **Audit:** Änderung wird geloggt
 - **Akzeptanzkriterien:** Hersteller anlegen, AssetType damit verknüpfen, Anzeige in Akte
  korrekt.
 - **Tests:** CRUD-Test, Verknüpfungstest.
 - **DoD:** funktioniert für mind. einen AssetType.
 ## IDENT-006 — QR-Code-Erzeugung
 - **Ziel:** Jede Ressource bekommt einen QR-Code, der auf ihre Identität verweist.
 - **Beschreibung:** QR-Inhalt = URL-Pfad (`/akte/{ressourcentyp}/{id}`), nicht Volldaten
  (Decision Required #3 in `00_index.md` — entschieden: URL-Pfad).
 - **Benutzerwert:** Grundlage für schnelles Scannen statt manueller Suche.
 - **Abhängigkeiten:** IDENT-001
 - **Datenmodell:** kein neues Feld — QR wird aus der Objekt-ID zur Laufzeit generiert, nicht
  gespeichert
 - **Backend:** Funktion/Endpoint, das QR-Payload (PNG/SVG) für eine ID liefert
 - **Frontend:** QR-Vorschau-Komponente
 - **Mobile:** gleiche Erzeugung
 - **QR-Code:** ist diese Kachel
 - **Seriennummer/Inventarnummer:** stehen NICHT im QR-Inhalt (nur Klartext-Fallback auf dem
  Label, siehe IDENT-007)
 - **Akte:** Ziel des QR-Verweises
 - **Rechte:** Erzeugen wie Lese-Recht der Ressource
 - **Audit:** nein (reine Generierung, kein Datenzustand)
 - **Akzeptanzkriterien:** QR-Code für existierende ID erzeugt, für unbekannte ID Fehler.
 - **Tests:** Erzeugungstest, Dekodier-Test (Payload ergibt korrekte URL).
 - **DoD:** QR-Bild lässt sich mit Standard-Scanner lesen und ergibt korrekten Pfad.
 ## IDENT-007 — QR-Code-Druck (Label)
 - **Ziel:** Druckfertiges Etikett mit QR + Klartext-Fallback.
 - **Beschreibung:** PDF-Label-Generierung (Vektor, skaliert verlustfrei), Klartext = Name +
  Inventarnummer/Seriennummer.
 - **Benutzerwert:** Materialwart kann Etiketten für neue Ressourcen direkt drucken.
 - **Abhängigkeiten:** IDENT-006
 - **Datenmodell:** keins
 - **Backend:** GET-Endpoint liefert PDF
 - **Frontend:** Druckbutton in der Akte/Ressourcenliste
 - **Mobile:** eher Desktop-Funktion (Etikettendrucker), Mobile nur Anzeige
 - **QR-Code:** wird hier eingebettet
 - **Seriennummer/Inventarnummer:** als Klartext auf dem Label
 - **Akte:** Aktion aus der Akte heraus auslösbar
 - **Rechte:** wie Lese-Recht
 - **Audit:** nein
 - **Akzeptanzkriterien:** PDF enthält scanbaren QR + korrekten Klartext.
 - **Tests:** Label-Erzeugungstest (Snapshot/Struktur, nicht Pixel).
 - **DoD:** auf echtem Etikettendrucker test-gedruckt und scanbar.
 ## IDENT-008 — QR-Scan → Akte öffnen
 - **Ziel:** Zentraler Einstiegspunkt „scannen → sofort alle Infos sehen".
 - **Beschreibung:** Frontend-Route, die den QR-Pfad auflöst und direkt FILE-006 lädt.
 - **Benutzerwert:** Kernnutzen des ganzen Identity-Konzepts — ohne das bleibt QR nur Deko.
 - **Abhängigkeiten:** IDENT-006, FILE-006
 - **Datenmodell:** keins
 - **Backend:** keins zusätzlich (nutzt FILE-001-Aggregations-Endpoint)
 - **Frontend:** Scan-Route + Kamera-Komponente
 - **Mobile:** zentraler mobiler Workflow-Einstieg (siehe MOBILE-002)
 - **QR-Code:** ist diese Kachel
 - **Seriennummer/Inventarnummer:** nur Anzeige
 - **Akte:** Zielseite
 - **Rechte:** wie Akte-Lese-Recht, 404 falls Ressourcen-ID unbekannt/kein Zugriff
 - **Audit:** nein
 - **Akzeptanzkriterien:** Scan eines gültigen QR öffnet korrekt die Akte; ungültiger Code
  zeigt Fehlermeldung, keinen Absturz.
 - **Tests:** Routing-Test mit gültiger/ungültiger ID.
 - **DoD:** funktioniert auf echtem Smartphone im Feldtest.
 ## IDENT-009 — QR-Neuvergabe & QR-Historie
 - **Ziel:** Verlorenes/beschädigtes Etikett ersetzen, ohne die Ressourcen-ID zu verlieren.
 - **Beschreibung:** Da QR nur die ID referenziert (IDENT-006), ist „neu vergeben" technisch
  nur ein neuer Druck — Kachel deckt aber den Sonderfall ab, dass zwischenzeitlich ALTE
  gedruckte Etiketten im Umlauf sein können und das nachvollziehbar bleiben muss.
 - **Benutzerwert:** Klarheit, welches physische Etikett aktuell gültig ist.
 - **Abhängigkeiten:** IDENT-006
 - **Datenmodell:** `qr_druck_ereignis` (ressourcen_id, zeitpunkt, benutzer_id) — nur
  Protokoll, kein Zustand am Objekt selbst
 - **Backend:** Log-Eintrag bei jedem Label-Druck (Kopplung an IDENT-007)
 - **Frontend:** „zuletzt gedruckt am" in der Akte anzeigen
 - **Mobile:** nur Anzeige
 - **QR-Code:** Kernthema
 - **Seriennummer/Inventarnummer:** nein
 - **Akte:** Historienbereich
 - **Rechte:** wie Lese-Recht
 - **Audit:** ist selbst ein Audit-Protokoll
 - **Akzeptanzkriterien:** jeder Druckvorgang erzeugt einen Eintrag, in der Akte sichtbar.
 - **Tests:** Protokoll-Test bei Druckaufruf.
 - **DoD:** funktioniert an mind. einer Ressource nachweisbar.
 ## IDENT-010 — Barcode/GTIN (optional, P3)
 - **Ziel:** Handelsübliche Verbrauchsgüter über Hersteller-Barcode statt eigener Nummer
  erfassen.
 - **Beschreibung:** Zusatzfeld GTIN/EAN, optionale Barcode-Scan-Unterstützung neben QR.
 - **Benutzerwert:** Schnellere Ersterfassung bei Standard-Verbrauchsmaterial (z.B.
  Verbandsmaterial mit Herstellerbarcode).
 - **Abhängigkeiten:** IDENT-001
 - **Datenmodell:** `gtin` (Text, optional) an Asset/Consumable
 - **Backend:** Validierung Format (EAN-13/GTIN-Prüfsumme)
 - **Frontend:** Barcode-Scan-Eingabehilfe
 - **Mobile:** Scan-Unterstützung
 - **QR-Code:** eigenständig daneben, kein Ersatz
 - **Seriennummer/Inventarnummer:** ergänzend, nicht Ersatz
 - **Akte:** Stammdatenbereich
 - **Rechte:** wie Materialwart-Schreibrecht
 - **Audit:** Änderung wird geloggt
 - **Akzeptanzkriterien:** gültige GTIN wird angenommen, ungültige abgelehnt.
 - **Tests:** Prüfsummen-Test.
 - **DoD:** funktioniert für mind. ein Verbrauchsmaterial-Beispiel. Priorität P3 — kann
  grundsätzlich zurückgestellt werden.
 ---
 **MABEA-Ist-Stand-Abgleich:** IDENT-001 (Code/UUID), 002/003 (`objekt.code`/
 `objektposition.code`, Nummernschema mit Präfix), 004 (Seriennummer je Objektposition/
 GeraetInstanz, Eindeutigkeit korrekt scope-begrenzt), 006/007/008 (Code128-Label + PDF +
 Scan→Kontrolle-Route) sind vorhanden, allerdings Code128 statt QR und ohne
 Digital-File-Zielseite (die gibt es noch nicht, siehe FILE-Epic). IDENT-005
 (Hersteller/Modell), IDENT-009 (QR-Historie), IDENT-010 (Barcode/GTIN) fehlen komplett.
@@ -0,0 +1,123 @@
 # Epic 03 — Digital File (Akte)
 Details zu FILE-001 … FILE-005. FILE-006 (Übersichtsseite) und FILE-007
 (Audit-Anbindung) noch nicht detailliert, siehe `00_index.md`-Tabelle.
 ---
 ## FILE-001 — Akte-Grundgerüst
 - **Ziel:** Zentrale Entität, die alle Teilbereiche einer Ressource bündelt.
 - **Beschreibung:** Konzeptionelle „Akte" muss keine eigene Tabelle sein, sondern eine
  Aggregations-Sicht (View/Backend-Endpunkt), der Stammdaten+Standort+Historie+Dokumente+
  Prüfungen+Wartungen+Mängel für eine gegebene Ressourcen-ID zusammenführt.
 - **Benutzerwert:** Ein Helfer/Prüfer sieht auf einen Blick alles zu einer Ressource, ohne
  mehrere Screens durchklicken zu müssen.
 - **Abhängigkeiten:** IDENT-001
 - **Datenmodell:** kein neues Datenmodell — Aggregations-Logik über bestehende Tabellen (die
  zum Zeitpunkt dieser Kachel z.T. noch nicht existieren, daher zunächst nur
  Stammdaten+Historie als Platzhalter, Rest wird nachgezogen sobald die jeweiligen Module
  existieren)
 - **Backend:** GET /akte/{ressourcen_id} (aggregiert)
 - **Frontend/Mobile:** —
 - **QR-Code:** Ziel des QR-Scans (IDENT-008)
 - **Seriennummer/Inventarnummer:** werden hier nur angezeigt, nicht neu verwaltet
 - **Akte:** ist diese Kachel selbst
 - **Rechte:** Lesen wie Ressourcen-Leserecht
 - **Audit:** Akte-Aufruf selbst wird NICHT geloggt (zu granular/kein Mehrwert), nur
  Änderungen an den Teilbereichen
 - **Akzeptanzkriterien:** Endpunkt liefert für eine existierende Ressourcen-ID ein
  zusammengesetztes JSON, für unbekannte ID 404.
 - **Tests:** Aggregations-Test mit Dummy-Daten in mind. zwei Teilbereichen.
 - **DoD:** Grundgerüst erweiterbar, ohne bestehende Endpunkt-Konsumenten zu brechen, wenn
  neue Teilbereiche dazukommen.
 ## FILE-002 — Akte-Stammdatenbereich
 - **Ziel:** Feste, immer sichtbare Kopfzeile jeder Akte.
 - **Beschreibung:** Name, Kategorie/Typ, Inventarnummer, Seriennummer, Hersteller/Modell,
  Status-Badge gebündelt.
 - **Benutzerwert:** Sofortige Grundorientierung ohne Scrollen.
 - **Abhängigkeiten:** FILE-001, IDENT-002/004/005, ASSET-004
 - **Datenmodell:** keins neu, reine Aggregation
 - **Backend:** Teil des FILE-001-Aggregations-Endpunkts
 - **Frontend:** Kopfzeilen-Komponente
 - **Mobile:** kompakte Variante (Karte statt Tabellenzeile)
 - **QR-Code:** Druckbutton hier verankert (IDENT-007)
 - **Seriennummer/Inventarnummer:** zentrale Anzeige hier
 - **Akte:** ist dieser Bereich selbst
 - **Rechte:** wie Lese-Recht
 - **Audit:** nein (nur Anzeige)
 - **Akzeptanzkriterien:** alle Kernfelder korrekt angezeigt, Status-Badge farbcodiert.
 - **Tests:** Rendering-Test mit Beispieldaten.
 - **DoD:** an mind. zwei unterschiedlichen Ressourcentypen (z.B. Fahrzeug + Gerät) getestet.
 ## FILE-003 — Akte-Standortbereich
 - **Ziel:** Aktueller Standort direkt sichtbar, mit Sprung zur vollständigen
  Standorthistorie.
 - **Beschreibung:** Anzeige aktueller Standort (Lagerplatz/Fahrzeug/Person), Link zu
  WH-Modul für Details.
 - **Benutzerwert:** „Wo ist das Ding gerade" ist die häufigste Frage im Alltag.
 - **Abhängigkeiten:** FILE-001, WH-001 (zumindest Platzhalter-Standortfeld, bevor
  Warehouse-Epic fertig ist)
 - **Datenmodell:** Referenz auf aktuellen Standort (Feld existiert ggf. schon am Asset,
  hier nur Anzeige)
 - **Backend:** Teil des Aggregations-Endpunkts
 - **Frontend:** Standort-Kachel in der Akte
 - **Mobile:** gleiche Anzeige, kompakt
 - **QR-Code/Seriennummer/Inventarnummer:** nein
 - **Akte:** ist dieser Bereich
 - **Rechte:** wie Lese-Recht
 - **Audit:** nein (Standortänderung selbst wird in WH-Modul geloggt, hier nur Anzeige)
 - **Akzeptanzkriterien:** aktueller Standort korrekt, Link funktioniert.
 - **Tests:** Rendering-Test.
 - **DoD:** funktioniert, sobald WH-001 minimal existiert (auch als Platzhalter-Freitextfeld
  vor vollem Warehouse-Modul akzeptabel).
 ## FILE-004 — Akte-Verantwortlichkeitsbereich
 - **Ziel:** Klar erkennbar, wer für eine Ressource zuständig ist.
 - **Beschreibung:** Anzeige zuständige Person/Einheit (aus Personnel-Epic).
 - **Benutzerwert:** Ansprechpartner bei Fragen/Problemen sofort ersichtlich.
 - **Abhängigkeiten:** FILE-001, PERS-003 (zumindest Einheiten-Grundgerüst)
 - **Datenmodell:** Referenz auf zuständige Einheit/Person
 - **Backend:** Teil des Aggregations-Endpunkts
 - **Frontend:** Verantwortlichkeits-Kachel
 - **Mobile:** gleiche Anzeige
 - **QR-Code/Seriennummer/Inventarnummer:** nein
 - **Akte:** ist dieser Bereich
 - **Rechte:** wie Lese-Recht; Ändern nur Administrator/Zugführer
 - **Audit:** Änderung wird geloggt
 - **Akzeptanzkriterien:** Zuständigkeit anzeigen/ändern funktioniert, Änderung geloggt.
 - **Tests:** Anzeige- und Änderungstest.
 - **DoD:** funktioniert mit mind. einer Einheit.
 ## FILE-005 — Akte-Historienbereich
 - **Ziel:** Chronologische Ereignisliste je Ressource, direkt in der Akte statt in einem
  separaten globalen Log.
 - **Beschreibung:** Gefilterte Sicht auf FOUND-006 (Audit-Log), gefiltert nach
  `entitaet_id`.
 - **Benutzerwert:** „Was ist mit diesem Gerät in letzter Zeit passiert" auf einen Blick.
 - **Abhängigkeiten:** FILE-001, FOUND-006
 - **Datenmodell:** keins neu
 - **Backend:** Filter-Query auf Audit-Log nach Ressourcen-ID
 - **Frontend:** Zeitleisten-Komponente in der Akte
 - **Mobile:** kompakte Liste
 - **QR-Code/Seriennummer/Inventarnummer:** nein
 - **Akte:** ist dieser Bereich
 - **Rechte:** wie Lese-Recht (evtl. eingeschränkter als Vollzugriff auf globales Audit-Log)
 - **Audit:** zeigt Audit-Daten, erzeugt selbst keine
 - **Akzeptanzkriterien:** Ereignisse chronologisch, korrekt gefiltert auf die Ressource.
 - **Tests:** Filter-Test mit mehreren Ressourcen (keine Vermischung).
 - **DoD:** mind. drei unterschiedliche Ereignistypen sichtbar getestet.
 ---
 **MABEA-Ist-Stand-Abgleich:** Das gesamte Digital-File-Epic **fehlt in MABEA komplett** —
 es gibt keine gebündelte Akte-Ansicht, nur Einzelseiten (Objektliste, Historie-Filter,
 Dokumente-Panel je Ressource getrennt aufrufbar). Größte konkrete Lücke aus diesem Backlog
 gegenüber dem MABEA-Ist-Stand, obwohl alle Bausteine (Stammdaten, Standort, Historie,
 Dokumente, Prüfungen, Mängel) einzeln bereits existieren — es fehlt nur die
 Aggregations-Seite/der Aggregations-Endpunkt, der sie bündelt.