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