MABEA/arbeitskacheln/13_readiness.md

Epic 13 — Readiness

Details zu READY-001 … READY-005 (vollständig).

---

READY-001 — Regel-Engine (Grundgerüst)

• Ziel: Konfigurierbarer Mechanismus statt fest verdrahteter if/else-Logik, um zu bestimmen, ob ein Asset einsatzbereit ist.
• Beschreibung: Regelkatalog (welche Faktoren zählen: Fehlbestand/Prüfung/Wartung/ Mangel/Beladung), pro Regel an-/abschaltbar, evtl. Gewichtung.
• Benutzerwert: Verschiedene Organisationen haben unterschiedliche Kriterien für „einsatzbereit" — konfigurierbar statt Code-Änderung nötig.
• Abhängigkeiten: ASSET-004
• Datenmodell: readiness_regel (id, schluessel, aktiv, beschreibung)
• Backend: Regel-Auswertungs-Engine (iteriert aktive Regeln, sammelt Gründe)
• Frontend: keins in dieser Kachel (Konfiguration folgt READY-005)
• Mobile: keins
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Grundlage für Readiness-Anzeige
• Rechte: keine neuen (Auswertung ist lesend)
• Audit: nein
• Akzeptanzkriterien: Regeln iterierbar, Ergebnis = Liste erfüllter/nicht erfüllter Kriterien.
• Tests: Regel-Iterations-Test.
• DoD: HIGH RISK (größte technische Unsicherheit im gesamten Backlog) — MABEA hat stattdessen eine fest verdrahtete Funktion (einsatzbereitschaft() mit hartcodierten Kriterien Fehlbestand/Ablauf/Prüfung/Sperre/Mangel/in_wartung/HU-UVV). Umbau zu einer echten Regel-Engine ist ein substanzieller Umbau, kein Nachzug — vor Umsetzung klären, ob der Konfigurierbarkeits-Bedarf real ist (bisher nur eine Organisation im Einsatz, ein fester Kriterienkatalog reicht evtl. aus).

READY-002 — Zustände READY/LIMITED/NOT_READY/UNKNOWN

• Ziel: Einheitliche Zustands-Terminologie.
• Beschreibung: Enum mit vier Werten, UNKNOWN für Assets ohne ausreichende Datenbasis (z.B. noch nie kontrolliert).
• Benutzerwert: Klare Ampel statt Zahlenwerk.
• Abhängigkeiten: READY-001
• Datenmodell: keins neu (Enum-Rückgabewert der Engine)
• Backend: Mapping Regel-Ergebnisse → einer der vier Zustände
• Frontend: Badge/Farbe je Zustand
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Stammdatenbereich
• Rechte: wie Lese-Recht
• Audit: nein
• Akzeptanzkriterien: alle vier Zustände erreichbar, UNKNOWN korrekt für „noch nie kontrolliert".
• Tests: Zustandstest je Fall.
• DoD: DECISION REQUIRED (fachlich, nicht nur technisch): MABEA kennt nur drei Zustände (einsatzbereit/eingeschränkt/nicht_einsatzbereit). UNKNOWN fehlt bisher — ein noch nie kontrolliertes Objekt wird aktuell als „einsatzbereit" gezählt, weil keine Kriterien verletzt sind. Das ist fachlich fragwürdig: „nie geprüft" sollte vermutlich nicht dasselbe bedeuten wie „geprüft und in Ordnung". Vor Umsetzung mit dem Nutzer klären, ob das der gewünschte aktuelle Zustand ist oder korrigiert werden soll.

READY-003 — Regel-Kopplung (Prüfung/Wartung/Mangel/Beladung)

• Ziel: Tatsächliche Verzahnung der Regel-Engine mit den anderen Epics.
• Beschreibung: Jede Regel liest den relevanten Zustand aus INSP/MAINT/DEFECT/LOAD.
• Benutzerwert: Gesamtbild statt Einzelmodule, die nichts voneinander wissen.
• Abhängigkeiten: READY-002, INSP-004, DEFECT-005, LOAD-006, MAINT (falls Wartung ebenfalls einfließen soll)
• Datenmodell: keins neu
• Backend: Regel-Implementierungen je Faktor
• Frontend: Gründe-Liste in der Readiness-Anzeige
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Stammdatenbereich
• Rechte: wie Lese-Recht
• Audit: nein zusätzlich
• Akzeptanzkriterien: jeder Faktor einzeln testbar, Kombination mehrerer Faktoren korrekt (mehrere Gründe gleichzeitig möglich).
• Tests: Faktor-Einzeltests + Kombinationstest.
• DoD: deckt sich weitgehend mit MABEA (dashboard.einsatzbereitschaft() hat bereits Fehlbestand/Ablauf/Prüfung/Sperre/Mangel/in_wartung/HU-UVV kombiniert) — Wartung (MAINT) kann noch nicht einfließen, da das Wartungs-Epic in MABEA nicht existiert.

READY-004 — Readiness-Dashboard

• Ziel: Zentrale Übersicht „wie viele Assets sind einsatzbereit".
• Beschreibung: Kachel mit Zahlen je Zustand + aufklappbare Detailliste mit Gründen.
• Benutzerwert: Leitungsverantwortliche sehen auf einen Blick den Gesamtzustand.
• Abhängigkeiten: READY-003
• Datenmodell: keins neu
• Backend: Aggregations-Endpunkt
• Frontend: Dashboard-Kachel
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: nein (übergreifende Sicht)
• Rechte: Verantwortliche
• Audit: nein
• Akzeptanzkriterien: Zahlen stimmen mit Summe der Einzel-Assets überein.
• Tests: Konsistenztest (Summe Detail = Summe Kachel).
• DoD: deckt sich 1:1 mit MABEA (Kachel „Einsatzbereites Material", bereits umgesetzt inkl. aufklappbarer Detailliste).

READY-005 — Regel-Konfiguration-UI

• Ziel: Administrator kann Regeln an-/abschalten ohne Code-Änderung.
• Beschreibung: UI zum Umschalten der READY-001-Regeln.
• Benutzerwert: Organisationsspezifische Anpassung ohne Entwicklerbeteiligung.
• Abhängigkeiten: READY-003
• Datenmodell: keins neu (nutzt readiness_regel.aktiv)
• Backend: PATCH-Endpunkt
• Frontend: Einstellungsseite
• Mobile: keins
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: nein
• Rechte: Administrator
• Audit: Änderung geloggt
• Akzeptanzkriterien: Regel abschalten entfernt sie sichtbar aus der Bewertung.
• Tests: Ein-/Ausschalt-Test.
• DoD: P2, abhängig von READY-001 (ob die Regel-Engine überhaupt gebaut wird) — kann komplett entfallen, wenn READY-001 zurückgestellt bleibt und ein fester Kriterienkatalog ausreicht.

---

MABEA-Ist-Stand-Abgleich: Funktional ist Readiness in MABEA bereits gut abgedeckt (dashboard.einsatzbereitschaft() kombiniert mehr Faktoren als in dieser Kachel-Spezifikation ursprünglich vorgesehen — sogar Fahrzeug-HU/UVV und Mangel-Priorität fließen schon ein). Die konzeptionelle Lücke ist die fehlende Konfigurierbarkeit (READY-001/005: alles ist fest im Code verdrahtet statt als an-/abschaltbare Regeln) und der fehlende UNKNOWN-Zustand (READY-002 — ein nie kontrolliertes Objekt gilt fälschlich als einsatzbereit). Letzteres ist die wichtigste fachliche Nachfrage aus diesem Epic, nicht nur eine technische Fleißaufgabe.