docs: Readiness-Epic komplettiert (READY-001..005)

Funktional gut abgedeckt (einsatzbereitschaft() kombiniert schon mehr
Faktoren als ursprünglich spezifiziert). Zwei echte Lücken: keine
Konfigurierbarkeit (alles fest im Code, READY-001/005), und fachlich
wichtiger - fehlender UNKNOWN-Zustand: ein nie kontrolliertes Objekt gilt
aktuell fälschlich als einsatzbereit. Als neue Decision Required #5
aufgenommen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KC8HYvv6UkCVYheYiTw9DD

arbeitskacheln/00_index.md

@@ -20,6 +20,9 @@ Kachel-Template und Nutzer-Vorgaben zur Methodik: siehe Memory
 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):** MABEA zählt ein nie kontrolliertes Objekt aktuell
+   als „einsatzbereit" (keine Kriterien verletzt, aber auch nie geprüft). Fachlich zu klären,
+   ob das gewollt ist oder ein eigener UNKNOWN-Zustand eingeführt werden soll.
 
 ## Epic-Übersicht
 
@@ -218,6 +221,7 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
 | `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) |
 
-Restliche Kacheln (READY, DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen
-nach Freigabe.
+Restliche Kacheln (DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen nach
+Freigabe.

arbeitskacheln/13_readiness.md

@@ -0,0 +1,128 @@
+# 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.