MABEA/arbeitskacheln/00_index.md

# 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.
5. ✅ **UNKNOWN-Readiness-Zustand (READY-002) — erledigt (2026-09-05):** war offen, wurde
   noch am selben Tag live gefixt. Nie kontrollierte Objekte zählen jetzt als `unbekannt`
   statt fälschlich als „einsatzbereit". Siehe `13_readiness.md`.

## Subagenten je Epic

Sieben Subagenten aus dem Subagenten-Repo sind für dieses Projekt bereits installiert
(siehe Memory `reference-subagents-repo`), plus `fastapi-expert`/`python-expert` passend
zum Techstack. Bei der tatsächlichen UMSETZUNG einer Kachel (nicht bei der Planung hier)
sollen die folgenden Subagenten bevorzugt herangezogen werden — als Standard-Zuordnung je
Epic, einzelne Kacheln können abweichen:

| Epic | Empfohlene Subagenten |
|---|---|
| 01 Foundation | fastapi-expert, postgres-expert, jwt-expert, docker-expert, openapi-expert |
| 02 Identity | postgres-expert (Eindeutigkeits-Constraints), owasp-top10-expert (Path-Traversal bei Codes/Labels) |
| 03 Digital File | fastapi-expert (Aggregations-Endpunkt), sql-expert (Joins über viele Tabellen) |
| 04 Assets | postgres-expert, sql-expert |
| 05 Fleet | fastapi-expert |
| 06 Inventory | postgres-expert, sql-expert (Mengen-/Chargenlogik) |
| 07 Warehouse | postgres-expert (Hierarchie-Queries, Transaktionen bei Umlagerung) |
| 08 Loadout | fastapi-expert, sql-expert |
| 09 Inspections | python-expert (Berechnungslogik Intervalle/Ampel) |
| 10 Maintenance | python-expert, postgres-expert |
| 11 Defects | fastapi-expert |
| 12 Personnel | jwt-expert/oauth-oidc-expert (bei PERS-002 Auth-Bezug), owasp-top10-expert |
| 13 Readiness | python-expert (Regel-Engine-Logik) |
| 14 Documents | owasp-top10-expert (Upload-Sicherheit/MIME-Whitelist, bereits Thema bei DOC-001), fastapi-expert |
| 15 Mobile | kein Backend-Subagent zentral (Frontend/PWA-lastig) |
| 16 Operations | noch offen, erst bei Angehen des Epics zuordnen |
| 17 Zuständigkeit | postgres-expert (n:m-Vererbungslogik) |
| 18 Notifications | fastapi-expert, owasp-top10-expert (E-Mail-Injection bei Trigger-Inhalten) |
| 19 Satelliten-Server | postgres-expert, sql-expert (Sync Insert/Upsert), docker-expert |

**Wie einbeziehen:** vor Implementierungsbeginn einer Kachel kurz prüfen, ob einer der
zugeordneten Subagenten als Review-Instanz (nach Fertigstellung) oder als Umsetzungs-
Delegation sinnvoll ist — nicht zwingend für jede einzelne Kachel, aber als Standardpfad
für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) Themen.

## 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 |
| 17 Zuständigkeit | Verantwortliche flexibel Standorten/Objekten zuordnen | P0 |
| 18 Notifications | Benachrichtigung + Eskalation bei Fehlbestand | P1 |
| 19 Satelliten-Server | Autarker Betrieb bei Verbindungsverlust (zurückgestellt) | P3 |

## Stand 2026-09-08: Code-Abgleich

Jede Kachel unten wurde gegen den tatsächlichen Code-Stand geprüft (Backend-Endpunkte in
`backend/app/api/v1/endpoints/*.py`, Models in `backend/app/models/*.py`, Migrations-
Historie `backend/alembic/versions/0001…0025`, Frontend-Seiten/Komponenten in
`frontend/src/pages/**` und `frontend/src/components/**`). Status-Werte: ✅ erledigt (im
Code klar nachweisbar), 🔶 teilweise (Grundgerüst da, aber Lücke), ⬜ offen (kein
Code-Nachweis). Bei vager Beschreibung ohne eindeutigen Code-Fund wurde konservativ ⬜
vergeben statt geraten.

**Gesamt: 111 Kacheln — 79 ✅ / 11 🔶 / 21 ⬜.**

| Epic | ✅ | 🔶 | ⬜ | Gesamt | Einschätzung |
|---|---|---|---|---|---|
| 01 Foundation | 7 | 1 | 4 | 12 | Kern (Repo/DB/Auth/API/Config/Tests) fertig, DevOps-Rand (Docker/CI/Backup/Doku) offen |
| 02 Identity | 6 | 1 | 3 | 10 | QR/Seriennummer/Inventarnummer fertig, Nummernschemata/Hersteller-Stammdaten/Neuvergabe offen |
| 03 Digital File | 7 | 0 | 0 | 7 | vollständig fertig |
| 04 Assets | 7 | 1 | 1 | 9 | Kernmodell fertig, AssetSet als eigenes Konzept fehlt |
| 05 Fleet | 4 | 1 | 1 | 6 | Kernfelder da, 5-stufiger Status teilweise, Einsatzhistorie offen |
| 06 Inventory | 7 | 0 | 0 | 7 | vollständig fertig |
| 07 Warehouse | 6 | 1 | 0 | 7 | praktisch komplett, nur eigener Inventur-Workflow fehlt |
| 08 Loadout | 6 | 0 | 0 | 6 | vollständig fertig |
| 09 Inspections | 2 | 3 | 1 | 6 | kein eigenständiges Prüfarten-Modul, nur Intervall/Termin am Gerät |
| 10 Maintenance | 5 | 0 | 1 | 6 | fast vollständig (eigenes Wartungsmodul existiert), nur Ersatzteile/Kosten offen |
| 11 Defects | 5 | 0 | 0 | 5 | vollständig fertig |
| 12 Personnel | 5 | 0 | 2 | 7 | Qualifikationen/Einheiten da, Person/Benutzer-Trennung + Einsatzfunktionen offen |
| 13 Readiness | 3 | 1 | 1 | 5 | Zustände/Dashboard/Regel-Kopplung da, aber feste Logik statt konfigurierbarer Regel-Engine |
| 14 Documents | 1 | 0 | 4 | 5 | nur Grundgerüst+Hash, Typen/Versionierung/Kopie-Kennzeichen/Rechte offen |
| 15 Mobile | 4 | 1 | 0 | 5 | PWA/QR/Kontroll-Flow da, vollständiges Offline-Grundgerüst nur teilweise |
| 16 Operations | 0 | 0 | 3 | 3 | bewusst Platzhalter |
| 17 Zuständigkeit | 2 | 0 | 0 | 2 | vollständig fertig |
| 18 Notifications | 2 | 0 | 0 | 2 | vollständig fertig |
| 19 Satelliten-Server | 0 | 1 | 0 | 1 | nur Datenmodell-Stub (`Systemknoten`), keine Sync-Logik |

## Vollständige Kachel-Liste

| ID | Modul | Kachel | Prio | Aufwand | Risiko | Abhängigkeiten | Status |
|---|---|---|---|---|---|---|---|
| FOUND-001 | Foundation | Repo & Projektstruktur | P0 | S | LOW | — | ✅ |
| FOUND-002 | Foundation | DB-Grundgerüst + Migrationen | P0 | S | LOW | FOUND-001 | ✅ (Alembic, 25 Migrationen) |
| FOUND-003 | Foundation | Authentication | P0 | M | MEDIUM | FOUND-002 | ✅ (`auth.py` Login/JWT, `core/security.py`) |
| FOUND-004 | Foundation | Authorization-Grundgerüst | P0 | M | MEDIUM | FOUND-003 | ✅ (`permission.py` Rollen/Berechtigungen) |
| FOUND-005 | Foundation | API-Grundgerüst/Konventionen | P0 | S | LOW | FOUND-002 | ✅ (`api/v1/api.py` Router-Sammlung) |
| FOUND-006 | Foundation | Logging & Audit-Grundgerüst | P0 | S | LOW | FOUND-002 | 🔶 (Historie-Modell/Audit-Trail vorhanden, kein strukturiertes Logging-Framework gefunden) |
| FOUND-007 | Foundation | Konfigurationsmanagement | P0 | XS | LOW | FOUND-001 | ✅ (`core/app_settings.py`, BaseSettings) |
| FOUND-008 | Foundation | Docker/Compose-Setup | P0 | M | MEDIUM | FOUND-001 | ⬜ (kein Dockerfile/docker-compose im Repo gefunden) |
| FOUND-009 | Foundation | CI/CD-Grundgerüst | P0 | S | LOW | FOUND-008 | ✅ (`.gitea/workflows/ci.yml` - Backend-Tests + Frontend-Build/Tests, vorheriger Abgleich hat nur `.github/` geprüft) |
| FOUND-010 | Foundation | Backup-Strategie | P1 | S | MEDIUM | FOUND-002 | ⬜ (kein Backup-Skript/-Dokumentation gefunden) |
| FOUND-011 | Foundation | Test-Grundgerüst | P0 | M | LOW | FOUND-002 | ✅ (`backend/pytest.ini`+`backend/tests/`, seit 2026-09-08 auch `frontend/vitest.config.ts`+`src/**/*.test.ts(x)`, beide in CI) |
| FOUND-012 | Foundation | Dokumentationsgerüst | P1 | XS | LOW | FOUND-001 | ⬜ (kein README im Projektwurzelverzeichnis gefunden) |
| IDENT-001 | Identity | Objekt-ID-Schema | P0 | S | LOW | FOUND-002 | ✅ (Objekt-Code-Vergabe, `/objekte/naechster-code`) |
| IDENT-002 | Identity | Inventarnummer manuell | P0 | S | LOW | IDENT-001 | ✅ (Objektposition-Code, `objektposition.py`) |
| IDENT-003 | Identity | Inventarnummer-Nummernschemata | P1 | M | MEDIUM | IDENT-002 | ⬜ (kein konfigurierbares Schema gefunden, nur fester Code-Zähler) |
| IDENT-004 | Identity | Seriennummer + Eindeutigkeitsprüfung | P0 | S | LOW | IDENT-001 | ✅ (`geraet_instanz.py` Seriennummer-Feld/Unique) |
| IDENT-005 | Identity | Hersteller/Modell-Stammdaten | P1 | S | LOW | IDENT-004 | ⬜ (kein eigenes Hersteller/Modell-Stammdatenmodell gefunden) |
| IDENT-006 | Identity | QR-Code-Erzeugung | P0 | S | LOW | IDENT-001 | ✅ (`label.pdf`-Endpunkte für Objekt/Objektposition) |
| IDENT-007 | Identity | QR-Code-Druck (Label) | P0 | S | LOW | IDENT-006 | ✅ (`/objekte/{id}/label.pdf`, `/objektpositionen/{id}/label.pdf`) |
| IDENT-008 | Identity | QR-Scan → Akte öffnen | P0 | M | MEDIUM | IDENT-006, FILE-006 | ✅ (`BarcodeScanner.tsx`, Akte-Route `/akte/objekt/{id}`) |
| IDENT-009 | Identity | QR-Neuvergabe & -Historie | P2 | S | LOW | IDENT-006 | ⬜ (kein Nachweis für Neuvergabe-Workflow) |
| IDENT-010 | Identity | Barcode/GTIN | P3 | S | LOW | IDENT-001 | 🔶 (`BarcodeScanner.tsx` existiert, GTIN-Materialabgleich nicht nachweisbar) |
| FILE-001 | Digital File | Akte-Grundgerüst | P0 | M | MEDIUM | IDENT-001 | ✅ (`akte.py`, `services/akte.py`, docstring referenziert FILE-001) |
| FILE-002 | Digital File | Akte-Stammdatenbereich | P0 | S | LOW | FILE-001 | ✅ (Teil des Akte-Aggregats) |
| FILE-003 | Digital File | Akte-Standortbereich | P0 | S | LOW | FILE-001, WH-001 | ✅ (`admin/StandortSection.tsx`, Akte-Standortdaten) |
| FILE-004 | Digital File | Akte-Verantwortlichkeit | P1 | S | LOW | FILE-001, PERS-003 | ✅ (Zuständigkeit im Akte-Aggregat, `zustaendigkeit.py`) |
| FILE-005 | Digital File | Akte-Historienbereich | P0 | M | MEDIUM | FILE-001, FOUND-006 | ✅ (`historie.py`, `admin/HistorieSection.tsx`) |
| FILE-006 | Digital File | Akte-Übersichtsseite (UI) | P0 | M | LOW | FILE-002..005 | ✅ (`AktePage.tsx`) |
| FILE-007 | Digital File | Akte-Audit-Anbindung | P1 | S | LOW | FILE-005 | ✅ (Historie durchgängig in Akte eingebunden) |
| ASSET-001 | Assets | AssetCategory | P0 | XS | LOW | FOUND-002 | ✅ (`Kategorie` in `stammdaten.py`) |
| ASSET-002 | Assets | AssetType | P0 | S | LOW | ASSET-001 | ✅ (`Objekttyp` in `stammdaten.py`) |
| ASSET-003 | Assets | Asset/AssetInstance | P0 | M | MEDIUM | ASSET-002, IDENT-001/002/004 | ✅ (`objekt.py`, `objektposition.py`, `geraet_instanz.py`) |
| ASSET-004 | Assets | Asset-Status-Modell | P0 | S | LOW | ASSET-003 | ✅ (`ObjektStatus`, `GeraetStatus`, `ObjektpositionStatus` Enums) |
| ASSET-005 | Assets | Asset-Suche & Liste | P1 | S | LOW | ASSET-003 | ✅ (`ObjektListPage.tsx`, `suche.py` Endpunkt) |
| ASSET-006 | Assets | Asset-Bewegungshistorie | P1 | S | LOW | ASSET-003, WH-001 | ✅ (`lagerbewegung.py`, `historie.py`) |
| ASSET-007 | Assets | AssetSet | P2 | M | MEDIUM | ASSET-003 | ⬜ (kein eigenständiges Set-Konzept über Objekt/Objektposition hinaus gefunden) |
| ASSET-008 | Assets | Consumable | P1 | M | MEDIUM | ASSET-002 | 🔶 (Verbrauchsmaterial über `MaterialTyp`/Mengenlogik abgebildet, kein eigenes Consumable-Modell) |
| ASSET-009 | Assets | Nutzungszähler (Kilometer/Betriebsstunden generisch) | P1 | S | LOW | ASSET-003 | ✅ (`fahrzeugdetails.py` Kilometerstand, MAINT-002 nutzt es) |
| FLEET-001 | Fleet | Fahrzeugtypen | P1 | XS | LOW | ASSET-002 | ✅ (Objekttyp deckt Fahrzeugtypen ab) |
| FLEET-002 | Fleet | Fahrzeuge (Kennzeichen/Funkrufname) | P1 | S | LOW | ASSET-003, FLEET-001 | ✅ (`fahrzeugdetails.py`: Kennzeichen, Funkrufname, OPTA/Funkkennung) |
| FLEET-003 | Fleet | Kilometerstand (Anwendung von ASSET-009) | P1 | XS | LOW | FLEET-002, ASSET-009 | ✅ (Kilometerstand-Feld + Wartungsintervall-Kopplung) |
| FLEET-004 | Fleet | Fahrzeugstatus (5-stufig) | P1 | S | LOW | FLEET-002, READY-002 | 🔶 (`ObjektStatus` hat nur 3 Werte, Einsatzbereitschaft wird separat mit 4 Zuständen berechnet — keine 5-stufige Enum gefunden) |
| FLEET-005 | Fleet | Fahrzeug-Dokumente | P2 | XS | LOW | FLEET-002, DOC-001 | ✅ (`Dokument` polymorph, `entitaet_typ` deckt Fahrzeug/Objekt ab) |
| FLEET-006 | Fleet | Fahrzeug-Einsatzhistorie (Platzhalter) | P3 | S | MEDIUM | FLEET-002, OPS-002 | ⬜ (kein Einsatz-Modell vorhanden, Operations-Epic ist Platzhalter) |
| INV-001 | Inventory | Materialarten/Kategorien | P1 | XS | LOW | ASSET-001 | ✅ (`MaterialTyp`, `Kategorie` in `stammdaten.py`) |
| INV-002 | Inventory | Einzelgeräte (SN-pflichtig) | P1 | S | LOW | ASSET-003, IDENT-004 | ✅ (`geraet_instanz.py`) |
| INV-003 | Inventory | Verbrauchsmaterial (Mengen) | P1 | S | LOW | ASSET-008 | ✅ (Objektposition Soll-/Istmenge, `Material`) |
| INV-004 | Inventory | Chargenverwaltung | P1 | S | MEDIUM | INV-003 | ✅ (`chargennummer` in `objektposition.py`) |
| INV-005 | Inventory | Ablaufdaten & Warnschwellen | P1 | S | LOW | INV-004 | ✅ (`ablauf_charge`-Grund, Dashboard-Tile `AblaufdatenTile.tsx`) |
| INV-006 | Inventory | Mindestbestände & Fehlbestand | P1 | M | MEDIUM | INV-003, LOAD-001 | ✅ (`fehlbestand.py`, `mindermenge.py`, `fehlbestaende.py`-Endpunkt) |
| INV-007 | Inventory | Ausgabe/Rückgabe | P2 | M | MEDIUM | INV-003 | ✅ (`ausgabe.py` Model+Endpunkt, Migration 0021 referenziert INV-007) |
| WH-001 | Warehouse | Lager-Stammdaten (Hierarchie) | P1 | S | LOW | FOUND-002 | ✅ (`Lagerort`, Migration 0019/Modell referenziert WH-001) |
| WH-002 | Warehouse | Lagerplätze | P1 | S | LOW | WH-001 | ✅ (`Lagerplatz` referenziert WH-002) |
| WH-003 | Warehouse | Bestand je Lagerplatz | P1 | M | MEDIUM | WH-002, INV-003 | ✅ (`Bestand`-Modell referenziert WH-003) |
| WH-004 | Warehouse | Einlagerung/Auslagerung | P1 | M | MEDIUM | WH-003 | ✅ (`services/lager.py` Ein-/Auslagerungsfunktionen referenzieren WH-004) |
| WH-005 | Warehouse | Umlagerung | P1 | S | LOW | WH-004 | ✅ (`/lagerplaetze/.../umlagerung`-Endpunkt referenziert WH-005) |
| WH-006 | Warehouse | Inventur & Bestandskorrektur | P2 | M | MEDIUM | WH-003 | 🔶 (Bestandskorrektur über Ein-/Auslagerung möglich, kein eigener Inventur-Workflow/Zählliste gefunden) |
| WH-007 | Warehouse | Materialbewegungsprotokoll | P1 | S | LOW | WH-004, FOUND-006 | ✅ (`Materialbewegung`, `lagerbewegung.py`, referenziert WH-007) |
| LOAD-001 | Loadout | Soll-Beladung/Beladungsplan | P1 | M | MEDIUM | ASSET-003, INV-002/003 | ✅ (`vorlage.py` Beladungsvorlage, `BeladungsplanerBoard.tsx`) |
| LOAD-002 | Loadout | Ist-Beladung | P1 | S | LOW | LOAD-001 | ✅ (Objektposition-Istmenge, `GeraeteInstanzenListe.tsx`) |
| LOAD-003 | Loadout | Abweichungserkennung | P1 | S | MEDIUM | LOAD-002 | ✅ (Fehlbestand-Erkennung bei Ist<Soll, `fehlbestand.py`) |
| LOAD-004 | Loadout | Digitale Beladungskontrolle | P1 | M | MEDIUM | LOAD-003 | ✅ (`kontrollen.py`, `KontrollPage.tsx`) |
| LOAD-005 | Loadout | Kontrollhistorie | P1 | S | LOW | LOAD-004, FOUND-006 | ✅ (`Kontrolle`-Modell append-only, Historie-Anbindung) |
| LOAD-006 | Loadout | Readiness-Kopplung | P1 | S | MEDIUM | LOAD-003, READY-001 | ✅ (Fehlbestand fließt in `einsatzbereitschaft()`-Berechnung ein) |
| INSP-001 | Inspections | Prüfarten-Stammdaten | P1 | S | LOW | ASSET-002 | ⬜ (kein eigenständiges Prüfart-Stammdatenmodell gefunden) |
| INSP-002 | Inspections | Prüfintervalle | P1 | S | LOW | INSP-001 | 🔶 (`pruefintervall_monate` an Objektposition, aber nicht generisch je Prüfart) |
| INSP-003 | Inspections | Prüfdurchführung/-ergebnis | P1 | M | MEDIUM | INSP-002 | 🔶 (Statuswechsel an Geräteinstanz inkl. `naechste_pruefung`, kein separates Prüfergebnis-Protokoll) |
| INSP-004 | Inspections | Status-Ampel (VALID/DUE_SOON/OVERDUE/FAILED) | P1 | S | LOW | INSP-003 | 🔶 (Prüftermine im Dashboard, aber keine 4-stufige Ampel-Enum gefunden) |
| INSP-005 | Inspections | Prüfdokument-Anbindung | P2 | XS | LOW | INSP-003, DOC-001 | ✅ (Dokument polymorph, `entitaet_typ` deckt Geräteinstanz ab) |
| INSP-006 | Inspections | Prüftermin-Übersicht | P1 | S | LOW | INSP-004 | ✅ (`PrueftermineTile.tsx`, `/dashboard/prueftermine`) |
| MAINT-001 | Maintenance | Wartungspläne | P2 | S | LOW | ASSET-002 | ✅ (`Wartungsplan`, Migration 0022 referenziert MAINT-001) |
| MAINT-002 | Maintenance | Wartungsintervalle | P2 | S | MEDIUM | MAINT-001, ASSET-009 | ✅ (`services/wartung.py` referenziert MAINT-002, Zeit-/km-/Betriebsstunden-Intervalle) |
| MAINT-003 | Maintenance | Wartungsauftrag | P2 | M | MEDIUM | MAINT-002 | ✅ (`Wartungsauftrag`, `wartungsauftraege`-Endpunkte) |
| MAINT-004 | Maintenance | Wartungshistorie | P2 | S | LOW | MAINT-003, FOUND-006 | ✅ (Wartungsauftrag-Status/Erledigen-Verlauf, `WartungsplanSection.tsx`) |
| MAINT-005 | Maintenance | Ersatzteile/Kosten | P3 | M | MEDIUM | MAINT-003 | ⬜ (kein Ersatzteil-/Kosten-Feld gefunden) |
| MAINT-006 | Maintenance | Wartungsdokument-Anbindung | P2 | XS | LOW | MAINT-003, DOC-001 | ✅ (Dokument polymorph, deckt Wartungsauftrag ab) |
| DEFECT-001 | Defects | Mangelmeldung + Foto | P1 | M | LOW | ASSET-003, DOC-001 | ✅ (`mangel.py`, `MangelListePage.tsx`, Dokument-Anhang möglich) |
| DEFECT-002 | Defects | Priorität & Status-Workflow | P1 | S | LOW | DEFECT-001 | ✅ (`MangelStatus`, `MangelPrioritaet` Enums) |
| DEFECT-003 | Defects | Verantwortlicher & Reparaturzuordnung | P1 | S | LOW | DEFECT-002, PERS-002 | ✅ (Zustaendigkeit/Kontrollverantwortung koppelt an Mangel-Objekt) |
| DEFECT-004 | Defects | Abschluss & Dokumentation | P1 | S | LOW | DEFECT-003 | ✅ (`PATCH /maengel/{id}` Statuswechsel inkl. Abschluss) |
| DEFECT-005 | Defects | Readiness-Einfluss (kritisch) | P1 | S | MEDIUM | DEFECT-002, READY-001 | ✅ (`services/mangel.py`: Priorität "hoch" macht Objekt "nicht einsatzbereit") |
| PERS-001 | Personnel | Person (fachlich) | P1 | M | HIGH | FOUND-002 | ⬜ (laut DECISION-Abschnitt der Datei selbst nicht getrennt, nur `Benutzer`) |
| PERS-002 | Personnel | Benutzer (technisch, verknüpft) | P0 | M | HIGH | PERS-001, FOUND-003 | ✅ (`Benutzer`-Modell, `benutzer.py`-Endpunkt) |
| PERS-003 | Personnel | Einheiten/Organisationsstruktur | P1 | S | LOW | PERS-001 | ✅ (`Einheit`-Modell, hierarchisch, `einheiten`-Endpunkt) |
| PERS-004 | Personnel | Funktionen/Rollen im Einsatzkontext | P2 | S | LOW | PERS-003 | ⬜ (nur technische Rollen `RolleTyp` gefunden, keine Einsatzfunktionen) |
| PERS-005 | Personnel | Qualifikationen/Lehrgänge | P1 | S | LOW | PERS-001 | ✅ (`Qualifikationstyp`, `BenutzerQualifikation`) |
| PERS-006 | Personnel | Führerscheine/Berechtigungen mit Gültigkeit | P1 | M | MEDIUM | PERS-005, ASSET-002 | ✅ (`Qualifikationskategorie.fuehrerschein`, `ObjekttypQualifikationsanforderung`) |
| PERS-007 | Personnel | Qualifikationsablauf-Warnungen | P1 | S | LOW | PERS-006 | ✅ (`QualifikationTile.tsx`, `/dashboard/qualifikationsablaeufe`) |
| READY-001 | Readiness | Regel-Engine (Grundgerüst) | P1 | M | HIGH | ASSET-004 | 🔶 (Logik existiert in `services/dashboard.py`/`services/akte.py`, aber fest verdrahtet statt konfigurierbare Engine) |
| READY-002 | Readiness | Zustände READY/LIMITED/NOT_READY/UNKNOWN | P1 | S | MEDIUM | READY-001 | ✅ (bereit/eingeschränkt/unbekannt/nicht_einsatzbereit in `services/dashboard.py`, laut DECISION-Abschnitt am 2026-09-05 live gefixt) |
| READY-003 | Readiness | Regel-Kopplung (Prüfung/Wartung/Mangel/Beladung) | P1 | L | HIGH | READY-002, INSP-004, DEFECT-005, LOAD-006 | ✅ (`einsatzbereitschaft()` zieht Fehlbestand/Mangel/Gerätestatus zusammen) |
| READY-004 | Readiness | Readiness-Dashboard | P1 | S | LOW | READY-003 | ✅ (`EinsatzbereitschaftTile.tsx`, `/dashboard/einsatzbereitschaft`) |
| READY-005 | Readiness | Regel-Konfiguration-UI | P2 | M | MEDIUM | READY-003 | ⬜ (keine UI zur Regel-Konfiguration gefunden, Regeln sind Code) |
| DOC-001 | Documents | Dokument-Grundgerüst (Upload) | P1 | M | MEDIUM | FILE-001 | ✅ (`dokument.py` Model+Endpunkt, inkl. SHA-256-Duplikaterkennung, Migration 0024/0016 referenzieren DOC-001) |
| DOC-002 | Documents | Dokumenttypen | P2 | XS | LOW | DOC-001 | ⬜ (kein `dokumenttyp`-Feld im Modell gefunden) |
| DOC-003 | Documents | Versionierung | P2 | M | MEDIUM | DOC-001 | ⬜ (kein Versionsfeld/-verweis im Dokument-Modell) |
| DOC-004 | Documents | Original-vs-Kopie-Kennzeichnung | P2 | S | LOW | DOC-001 | ⬜ (kein entsprechendes Feld gefunden) |
| DOC-005 | Documents | Zugriffsrechte je Dokument | P2 | S | MEDIUM | DOC-001, FOUND-004 | ⬜ (kein dokumentspezifisches Berechtigungsmodell gefunden, nur allgemeine Rollen) |
| MOBILE-001 | Mobile | PWA-Grundgerüst | P1 | M | MEDIUM | FOUND-005 | ✅ (Vite-PWA-Build erzeugt `manifest.webmanifest`/`sw.js`, `vite-plugin-pwa` in package.json) |
| MOBILE-002 | Mobile | QR-Scan-Workflow (Kernablauf) | P1 | M | MEDIUM | MOBILE-001, IDENT-008 | ✅ (`BarcodeScanner.tsx` verdrahtet in `ObjektListPage.tsx`) |
| MOBILE-003 | Mobile | Offline-Grundgerüst | P2 | L | HIGH | MOBILE-001 | 🔶 (`offline/queue.ts`, `useOnlineStatus.ts`, `SyncStatus.tsx` vorhanden — Warteschlange für Kontrollen, kein vollständiges Offline-App-Grundgerüst über alle Module) |
| MOBILE-004 | Mobile | Mobile Mangelmeldung + Foto | P1 | S | LOW | MOBILE-002, DEFECT-001 | ✅ (Mangel-Erfassung inkl. Foto/Dokument-Anhang, in Kontroll-Flow verdrahtet) |
| MOBILE-005 | Mobile | Mobile Beladungskontrolle | P1 | S | MEDIUM | MOBILE-002, LOAD-004 | ✅ (`KontrollPage.tsx` mit Fach-Gruppierung, mobil-optimiert laut Memory-Feedback) |
| OPS-001 | Operations | Einsatzverwaltung (Platzhalter) | P3 | L | HIGH | FILE-001 | ⬜ (kein Einsatz-Modell im Code, bewusst Platzhalter) |
| OPS-002 | Operations | Einsatzmittel-Verknüpfung | P3 | M | MEDIUM | OPS-001, ASSET-003 | ⬜ (kein Nachweis) |
| OPS-003 | Operations | Einsatznachbereitung (Platzhalter) | P3 | L | HIGH | OPS-001 | ⬜ (kein Nachweis) |
| ZUST-001 | Zuständigkeit | Objekt/Standort ↔ Verantwortlicher | P0 | S | LOW | FOUND-002, ASSET-003 | ✅ (`Zustaendigkeit`-Modell, `zustaendigkeit.py`-Endpunkt) |
| ZUST-002 | Zuständigkeit | Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung) | P1 | S | LOW | ZUST-001, PERS-003 | ✅ (`Kontrollverantwortung`-Modell, `KontrollverantwortungSection.tsx`) |
| NOTIF-001 | Notifications | Benachrichtigung bei neuem Fehlbestand | P1 | S | LOW | INV-006 | ✅ (`services/benachrichtigung.py`: `benachrichtige_neuer_fehlbestand`, E-Mail-Versand) |
| NOTIF-002 | Notifications | Eskalation lange offener Fehlbestände | P1 | M | MEDIUM | INV-006, NOTIF-001 | ✅ (`eskalation.py` Endpunkt+Konfiguration, `EskalationSection.tsx`) |
| SAT-001 | Satelliten-Server | Hauptserver mit Satelliten-Servern | P3 | L | HIGH | FOUND-002, ASSET-003, MOBILE-003 | 🔶 (`Systemknoten`-Modell mit `KnotenTyp.haupt/satellit` existiert, Docstring vermerkt aber "V1 nutzt ausschließlich den Hauptserver" — keine Sync-Logik implementiert) |

## 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, ZUST-001.

**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), ZUST-002, Notifications (komplett).

**Bewusst außerhalb MVP:** Maintenance (P2, außer Kern optional), Documents-Feinschliff
(Versionierung/Zugriffsrechte, P2), Operations komplett (P3), Satelliten-Server komplett
(P3, bewusst zurückgestellt).

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-007 (vollständig) |
| `04_assets.md` | ASSET-001 … ASSET-009 (vollständig, ASSET-009 nachträglich ergänzt) |
| `05_fleet.md` | FLEET-001 … FLEET-006 (vollständig) |
| `06_inventory.md` | INV-001 … INV-007 (vollständig) |
| `07_warehouse.md` | WH-001 … WH-007 (vollständig) |
| `08_loadout.md` | LOAD-001 … LOAD-006 (vollständig) |
| `09_inspections.md` | INSP-001 … INSP-006 (vollständig) |
| `10_maintenance.md` | MAINT-001 … MAINT-006 (vollständig) |
| `11_defects.md` | DEFECT-001 … DEFECT-005 (vollständig) |
| `12_personnel.md` | PERS-001 … PERS-007 (vollständig) |
| `13_readiness.md` | READY-001 … READY-005 (vollständig) |
| `14_documents.md` | DOC-001 … DOC-005 (vollständig) |
| `15_mobile.md` | MOBILE-001 … MOBILE-005 (vollständig) |
| `16_operations.md` | OPS-001 … OPS-003 (bewusst nur Platzhalter, siehe Datei) |
| `17_zustaendigkeit.md` | ZUST-001 … ZUST-002 (vollständig, nachträglich ergänzt) |
| `18_notifications.md` | NOTIF-001 … NOTIF-002 (vollständig, nachträglich ergänzt) |
| `19_satelliten_server.md` | SAT-001 (Platzhalter, nachträglich ergänzt, bewusst zurückgestellt) |
| `20_ui_redesign.md` | UI-001 … UI-008 (vollständig umgesetzt, 2026-09-06) |

**Alle 20 Epics durchgegangen** (16 ursprüngliche + 17 Zuständigkeit/18 Notifications/19
Satelliten-Server/20 UI-Redesign, nachträglich ergänzt). Detaillierungsphase
abgeschlossen (2026-09-05), UI-Redesign-Epic ergänzt (2026-09-06).

## Nachtrag: Externe Roadmap-Bewertung Shelf/Resgrid/Emergency Mgmt (2026-09-05)

Nutzer brachte eine extern erstellte Roadmap ein, basierend auf einem Vergleich mit den
Open-Source-Projekten Shelf, Resgrid, Emergency Management (sowie geprüft und verworfen:
Sahana Eden, InvenTree). Abgleich gegen diesen Backlog + tatsächlichen MABEA-Ist-Stand:

- **Veraltet/schon erledigt:** "Phase 0" (CI-Fix, Fahrzeug-Feldnamen-Bug, Vorlagen-Snapshot-
  Prinzip) ist zu 100% bereits umgesetzt — das dort vorgeschlagene Snapshot-Prinzip ("Sollmenge
  fest in objektposition kopieren, Versionierung entfernen") ist exakt das, was am
  2026-09-05 in dieser Session umgesetzt wurde. "Phase 2" (FLEET-001/002/004,
  PERS-001/002-Inhalte) deckt sich mit FLEET-001/002/004/005 und PERS-005/006/007, die laut
  Backlog bereits live sind.
- **Widerspruch in der externen Roadmap, geklärt (2026-09-05):** Phase 4 schlug eine
  Dispatch-Karte (Fahrzeug-Position/-Status auf Karte, Echtzeit) vor, während derselbe
  Vorschlag unter "was nicht übernommen wird" explizit "Dispatch/Alarmierung - MABEA
  braucht es nicht" ausschließt. Nutzer-Entscheidung: **keine Dispatch-Karte**, bleibt
  außerhalb des Backlogs, deckt sich mit dem bestehenden Einsatz-Ausschluss (Operations-
  Epic 16 bleibt Platzhalter).
- **Echte neue Punkte, noch nicht im Backlog:** visuelle Beladungsplanung (Drag&Drop von
  Material auf Objekt/Fach, inspiriert von Shelf) - Nachzug zu LOAD-001; Multi-Organisationen-
  Konzept (mehrere Träger wie ASB/DRK/THW mit eigenen Standorten/Objekten/Benutzern) und
  Materialanforderung zwischen Organisationen - beides bisher nirgends spezifiziert, würde
  am ehesten als neues Epic oder Erweiterung von FOUND-004 (Authorization) einzuordnen sein.
- **Bereits rejected, deckt sich mit bestehender Entscheidung:** GPS-Tracking, Sahana Eden,
  InvenTree als Vorbild - keine Änderung nötig, Operations-Epic (16) bleibt bewusst
  Platzhalter (siehe `16_operations.md`).

Noch nicht als eigene Epic-Datei ausgearbeitet - reine Protokollierung des Abgleichs, damit
die externe Roadmap nicht als eigenständiger, widersprüchlicher Plan neben diesem Backlog
weiterlebt.

**Leitlinie (Nutzer-Vorgabe 2026-09-05): MABEA positiv weiterentwickeln — gute Inhalte aus
den Vergleichsprojekten übernehmen, schlechte/unpassende bewusst klein halten.**

Übernehmen (fachlich gut, passt zu MABEAs Material-First-Fokus):
- Visuelle Beladungsplanung (Drag&Drop, Shelf) — Nachzug zu LOAD-001.
- Lagerplatz-/Bestandsdenken (Shelf) — Kern bereits umgesetzt (Warehouse-Epic).
- Qualifikationsmatrix "wer darf was bedienen" (Resgrid) — bereits umgesetzt (PERS-005/006).
- Multi-Organisationen-Konzept (Emergency Mgmt) — noch offen, siehe oben, sinnvoll für
  spätere Mandantenfähigkeit, aber kein aktueller Bedarf.

Bewusst klein halten/nicht übernehmen (passt nicht zu MABEAs Scope, Material- statt
Einsatz-First):
- Dispatch/Alarmierung, GPS-Tracking, Dispatch-Karte (Resgrid) — explizit abgelehnt.
- Einsatzdokumentation/Einsatzführung (Resgrid/Emergency Mgmt) — Operations-Epic (16)
  bleibt bewusst Platzhalter, kein Ausbau ohne konkreten Bedarf.
- Sahana-Eden-Komplexität (zu viel KatS-Spezifisches, das MABEA nicht braucht) und
  InvenTree-Techniklastigkeit (zu wenig fachlicher Fokus) — beide nur als Ideen-Fundus,
  nicht als Vorbild für Architektur/Scope.

## Nachtrag: Abgleich mit alten Arbeitskarten (2026-09-05)

Alle 14 `arbeitskarten/*.md` (Karte 01–14, Vorgänger-Planungsstand) gegen dieses Backlog
geprüft und danach gelöscht — der komplette Ordner ist damit aufgelöst, `arbeitskarten/`
enthält nur noch den auf "aufgelöst" aktualisierten Index. Sieben Karten waren inhaltlich
vollständig abgedeckt (Karte 02, 03, 06, 09, 10, 11, 14 — jeweils in FOUND-003/004,
LOAD-001/002, MOBILE-001, IDENT-\*, ASSET-Grundprämisse bzw. INSP-Epic aufgegangen). Sechs
Karten enthielten Inhalte, die in keinem der 16 Epics vorkamen — daraus wurden drei neue
Epics (17 Zuständigkeit, 18 Notifications, 19 Satelliten-Server) sowie zwei Ergänzungen an
INV-006 (Sofort-Nachfüllung, Mindermengen-Gültigkeit). Quell-Karten: 01, 04, 05, 07, 08,
12, 13 — ihr Inhalt lebt jetzt in den genannten Epic-Dateien weiter.