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

arbeitskacheln/00_index.md

@@ -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.

arbeitskacheln/01_foundation.md

@@ -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.

arbeitskacheln/02_identity.md

@@ -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.

arbeitskacheln/03_digital_file.md

@@ -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.