Decision Required #5 und READY-002 als behoben markiert, da noch am selben
Tag live gefixt (siehe Commit fab3a06).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KC8HYvv6UkCVYheYiTw9DD
128 lines
6.2 KiB
Markdown
128 lines
6.2 KiB
Markdown
# 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:** ✅ **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.
|
|
|
|
---
|
|
|
|
**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).
|