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.