MABEA/arbeitskacheln/13_readiness.md

Epic 13 — Readiness

Details zu READY-001 … READY-006. READY-001-005 vollständig, READY-006 ergänzt am 2026-09-09 aus HiOrg-Server-Vergleich, offen/ungeplant.

---

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: ✅ behoben (2026-09-05, noch am selben Tag wie dieser Backlog-Eintrag): MABEA kannte bisher nur drei Zustände. Ein noch nie kontrolliertes Objekt wurde fälschlich als „einsatzbereit" gezählt. Vierter Zustand unbekannt live ergänzt (dashboard.einsatzbereitschaft(), Grund noch_nie_kontrolliert), Dashboard-Kachel und Tests entsprechend angepasst.

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.

READY-006 — Statistik-/Reporting-Dashboard-Kachel (P2, neu)

• Ziel: Kennzahlen über Zeit statt nur Momentaufnahme des aktuellen Zustands.
• Beschreibung: Neue Dashboard-Kachel mit Verlaufs-Kennzahlen: Bereitschaftsquote über Zeit (Anteil READY/LIMITED/NOT_READY/UNKNOWN je Zeitpunkt), Mängelquote je Standort, Anzahl offener Wartungen. Nutzt bereits vorhandene Daten (Einsatzbereitschaft, Mängel, Wartungsaufträge), aggregiert sie nur zeitlich/ gruppiert statt nur aktuellen Stand zu zeigen.
• Benutzerwert: Trends erkennbar („wird die Bereitschaft besser/schlechter") statt nur Snapshot — Grundlage für Leitungsentscheidungen (z.B. wo Ressourcen fehlen).
• Abhängigkeiten: READY-004, Mangel-Modell, MAINT-003
• Datenmodell (entschieden 2026-09-10): täglicher Snapshot, nicht Live-Berechnung — readiness_snapshot (Zeitpunkt, Standort, Zustand, Anzahl). Begründung: Live-Berechnung würde bedeuten, die READY-003-Regel-Logik rückwirkend auf jeden historischen Zeitpunkt anzuwenden (zeitpunktbezogener Nachbau der Ampel-Logik) — deutlich fehleranfälliger als ein simpler täglicher Snapshot. Tägliche Auflösung reicht für Trend-Reporting.
• Backend: Aggregations-Endpunkt(e), periodischer Snapshot-Job via systemd-Timer (mabea-readiness-snapshot.timer, gleiches Muster wie mabea-eskalation.timer bei NOTIF-002) — Zeitplan über OnCalendar in der Timer-Unit auf dem Server jederzeit ohne Codeänderung/Deploy anpassbar (systemctl edit + daemon-reload), reine Betriebskonfiguration. Standard- Anzeigezeitraum im Frontend: letzte 90 Tage, mit Filter für längere Zeiträume.
• Frontend: neue Dashboard-Kachel (react-grid-layout, wie bestehende Tiles), einfache Zeitreihen-Darstellung
• Mobile: Anzeige, kein Erfassungsbedarf
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte (ergänzt 2026-09-10): zusätzlich zum globalen Dashboard bekommt jedes einzelne Objekt einen Verlaufs-Abschnitt in seiner Akte (FILE-005-Bereich) — „Bereitschaftshistorie dieses Objekts" (z.B. „in den letzten 6 Monaten X Tage nicht einsatzbereit"). Nutzt dieselbe zugrundeliegende Datenquelle wie das globale Dashboard, nur gefiltert auf ein Objekt statt aggregiert über alle — andere Abfrage-Granularität, kein zweiter Datenspeicher nötig.
• Rechte: Leitungsverantwortliche/Administration
• Audit: nein (reine Auswertung)
• Akzeptanzkriterien: mind. eine Kennzahl (z.B. Bereitschaftsquote) über mehrere Zeitpunkte hinweg korrekt dargestellt.
• Tests: Aggregations-Test mit synthetischen Daten über mehrere Zeitpunkte.
• DoD: offen — Design vollständig geklärt (2026-09-10), bereit für Implementierung. Referenz (HiOrg-Server-Vergleich 2026-09-09): HiOrg bietet dedizierte Statistiken über Dienste/Kurse — MABEA hat vergleichbare Rohdaten (Einsatzbereitschaft, Mängel, Wartung), aber keine Verlaufs-/Trend-Ansicht, nur den aktuellen Zustand (READY-004).

---

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). Der UNKNOWN-Zustand (READY-002) war die wichtigste fachliche Nachfrage aus diesem Epic — wurde direkt im Zuge dieses Backlog-Durchgangs live gefixt, nicht nur dokumentiert (siehe READY-002 oben).