docs: nächste 10 Arbeitskacheln (FLEET-001..006, INV-001..004)

Fleet-Epic vollständig, Inventory-Epic begonnen (INV-005..007 folgen). Zwei
konkrete Funde beim MABEA-Abgleich: FLEET-003 (Kilometerstand) hat in MABEA
keine Rückwärtslauf-Validierung; INV-004 (Chargenverwaltung) wäre in MABEA
kein Nachzug sondern ein struktureller Umbau (Objektposition führt aktuell
nur eine Charge/Ablaufdatum, nicht mehrere gleichzeitig).

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

arbeitskacheln/00_index.md

@@ -209,6 +209,8 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
 | `02_identity.md` | IDENT-001, 002, 004, 005 … 010 |
 | `03_digital_file.md` | FILE-001 … FILE-007 (vollständig) |
 | `04_assets.md` | ASSET-001 … ASSET-008 (vollständig) |
+| `05_fleet.md` | FLEET-001 … FLEET-006 (vollständig) |
+| `06_inventory.md` | INV-001 … INV-004 |
 
-Restliche Kacheln (FLEET, INV, WH, LOAD, INSP, MAINT, DEFECT, PERS, READY, DOC, MOBILE,
+Restliche Kacheln (INV-005…007, WH, LOAD, INSP, MAINT, DEFECT, PERS, READY, DOC, MOBILE,
 OPS): nur Zeile in der Tabelle oben, Details folgen nach Freigabe.

arbeitskacheln/05_fleet.md

@@ -0,0 +1,136 @@
+# Epic 05 — Fleet
+
+Details zu FLEET-001 … FLEET-006 (vollständig).
+
+---
+
+## FLEET-001 — Fahrzeugtypen
+
+- **Ziel:** Fahrzeugspezifische Typebene oberhalb AssetType.
+- **Beschreibung:** Fahrzeugtyp-Stammdaten (z.B. „GW-San", „MTW"), verweist auf AssetType.
+- **Benutzerwert:** Vorlage für Fahrzeug-Anlage, ähnliche Fahrzeuge gruppiert.
+- **Abhängigkeiten:** ASSET-002
+- **Datenmodell:** `fahrzeugtyp` (id, asset_type_id, ...) oder Erweiterungsfelder an
+  `asset_type`
+- **Backend:** CRUD
+- **Frontend:** Verwaltung
+- **Mobile:** Anzeige
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Stammdatenbereich
+- **Rechte:** Materialwart/Administrator
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Fahrzeugtyp anlegen, Verknüpfung zu AssetType.
+- **Tests:** CRUD-Test.
+- **DoD:** mind. ein Fahrzeugtyp angelegt.
+
+## FLEET-002 — Fahrzeuge (Kennzeichen/Funkrufname)
+
+- **Ziel:** Fahrzeug-Spezialfelder am Asset.
+- **Beschreibung:** Kennzeichen, Fahrgestellnummer, Funkrufname als 1:1-Erweiterungstabelle
+  zu Asset.
+- **Benutzerwert:** Fahrzeuge sind die wichtigste Ressourcenklasse im Rettungsdienst — eigene
+  Kennfelder sind Pflicht.
+- **Abhängigkeiten:** ASSET-003, FLEET-001
+- **Datenmodell:** `fahrzeugdetails` (asset_id, kennzeichen, fahrgestellnummer,
+  funkrufname)
+- **Backend:** CRUD/Upsert
+- **Frontend:** Formular
+- **Mobile:** Anzeige
+- **QR-Code:** Kennzeichen kann Klartext-Fallback auf dem Label sein
+- **Seriennummer/Inventarnummer:** ergänzend, siehe Asset-Kernfelder
+- **Akte:** Fahrzeug-spezifischer Stammdatenbereich
+- **Rechte:** Materialwart/Administrator
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Felder setzen/anzeigen funktioniert.
+- **Tests:** CRUD-Test.
+- **DoD:** deckt sich mit MABEA `fahrzeugdetails` (bereits umgesetzt, diente hier als
+  Vorbild).
+
+## FLEET-003 — Kilometerstand/Betriebsstunden
+
+- **Ziel:** Nutzungsgrad des Fahrzeugs erfassen (Basis für km-/std-abhängige
+  Wartungsintervalle, MAINT-002).
+- **Beschreibung:** Felder + Erfassungsverlauf (nicht nur aktueller Wert, sondern Verlauf
+  der Meldungen).
+- **Benutzerwert:** Grundlage für Wartungsplanung.
+- **Abhängigkeiten:** FLEET-002
+- **Datenmodell:** `fahrzeugdetails.kilometerstand`/`betriebsstunden` (aktuell) +
+  optional `km_stand_historie`
+- **Backend:** Update-Endpoint mit Plausibilitätsprüfung
+- **Frontend:** Eingabefeld bei Kontrolle/Rückkehr
+- **Mobile:** Eingabe im Feld (nach Fahrt)
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Stammdatenbereich
+- **Rechte:** jeder Fahrzeugnutzer darf melden (breiter als reine Materialwart-Rechte),
+  Korrektur nur Administrator
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Wert kann nur steigen (Validierung gegen Rückwärtslauf, außer
+  Admin-Korrektur-Override).
+- **Tests:** Validierungstest (Rückwärtslauf abgelehnt, Override funktioniert).
+- **DoD:** funktioniert, Validierung greift nachweisbar.
+
+## FLEET-004 — Fahrzeugstatus (5-stufig)
+
+- **Ziel:** Fahrzeug-spezifische Verfeinerung von ASSET-004.
+- **Beschreibung:** einsatzbereit/eingeschränkt/nicht einsatzbereit/in Wartung/außer Dienst
+  — die ersten drei rechnerisch aus der Readiness-Engine (READY-002), die letzten zwei
+  manuell gesetzt.
+- **Benutzerwert:** Differenziertere Aussage als der generische Asset-Status.
+- **Abhängigkeiten:** FLEET-002, READY-002
+- **Datenmodell:** kein Extra-Feld nötig, wenn ASSET-004 generisch genug +
+  Readiness-Overlay reicht — sonst eigenes Statusfeld
+- **Backend:** Statuswechsel + Readiness-Kopplung
+- **Frontend:** Status-Anzeige/-Dropdown
+- **Mobile:** Anzeige
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Stammdatenbereich
+- **Rechte:** manuelle Zustände (Wartung/außer Dienst) nur Materialwart/Administrator
+- **Audit:** Statuswechsel geloggt
+- **Akzeptanzkriterien:** 5 Zustände korrekt unterscheidbar, rechnerischer vs. manueller
+  Anteil klar getrennt.
+- **Tests:** Statustest je Zustand.
+- **DoD:** deckt sich vollständig mit MABEA (bereits umgesetzt: `ObjektStatus` inkl.
+  `in_wartung` + Readiness-Berechnung im Dashboard).
+
+## FLEET-005 — Fahrzeug-Dokumente
+
+- **Ziel:** Fahrzeugpapiere/Zulassung digital anhängen.
+- **Beschreibung:** Nutzt DOC-001 generisch, hier nur die Fach-Kopplung/Anzeige in der
+  Fahrzeug-Akte.
+- **Benutzerwert:** Zulassungsbescheinigung/Versicherungsnachweis griffbereit.
+- **Abhängigkeiten:** FLEET-002, DOC-001
+- **Datenmodell:** keins neu (nutzt Dokument-Polymorphie)
+- **Backend:** keins zusätzlich
+- **Frontend:** Dokumente-Panel in der Fahrzeug-Akte
+- **Mobile:** Anzeige
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Dokumentenbereich
+- **Rechte:** wie DOC-001
+- **Audit:** wie DOC-001
+- **Akzeptanzkriterien:** Dokument an Fahrzeug hochladen/anzeigen.
+- **Tests:** Integrationstest mit DOC-001.
+- **DoD:** entspricht MABEA (DokumentePanel bereits generisch wiederverwendbar,
+  funktioniert unverändert für Fahrzeuge).
+
+## FLEET-006 — Fahrzeug-Einsatzhistorie (Platzhalter, P3)
+
+- **Ziel:** Welche Einsätze ein Fahrzeug gefahren ist.
+- **Beschreibung:** Platzhalter-Kachel — echte Umsetzung hängt vom noch nicht entworfenen
+  Operations-Epic ab.
+- **Benutzerwert:** Nutzungsnachweis/Auslastungsstatistik.
+- **Abhängigkeiten:** FLEET-002, OPS-002
+- **Datenmodell / Backend / Frontend / Mobile / QR / SN / Inv / Akte / Rechte / Audit:**
+  TBD — nicht sinnvoll spezifizierbar vor OPS-001/002.
+- **Akzeptanzkriterien:** TBD.
+- **Tests:** TBD.
+- **DoD:** **DECISION REQUIRED:** diese Kachel bleibt bewusst Platzhalter, erst bei
+  tatsächlichem Angehen des Operations-Epics neu aufsetzen statt jetzt blind zu spezifizieren.
+
+---
+
+**MABEA-Ist-Stand-Abgleich:** FLEET-001…005 sind praktisch 1:1 in MABEA vorhanden
+(Objekttyp mit `ist_zugfahrzeug`, `fahrzeugdetails`-Tabelle, 5-stufiger `ObjektStatus`,
+generisches DokumentePanel). Einzige offene Lücke: FLEET-003s Plausibilitätsprüfung
+(„Kilometerstand darf nicht sinken") ist in MABEA **nicht** validiert — reiner
+Zahlen-Input ohne Rückwärtslauf-Schutz. Kleine, konkrete Nachbesserung, keine neue Kachel
+nötig. FLEET-006 ist in MABEA (noch) nicht relevant, da kein Operations-Epic existiert.

arbeitskacheln/06_inventory.md

@@ -0,0 +1,102 @@
+# Epic 06 — Inventory
+
+Details zu INV-001 … INV-004. INV-005…007 noch nicht detailliert, siehe
+`00_index.md`-Tabelle.
+
+---
+
+## INV-001 — Materialarten/Kategorien
+
+- **Ziel:** Grobe Materialarten-Gliederung innerhalb Inventory.
+- **Beschreibung:** Unterscheidet sich von ASSET-001 durch Fachlichkeit (Medizin/
+  Sanitätsmaterial/Funk/Strom/...) statt technischer Asset-Kategorie — **Entscheidung:
+  ASSET-001 wiederverwenden**, keine Doppelstruktur.
+- **Benutzerwert:** Konsistente Kategorien app-weit statt zwei parallele Systeme.
+- **Abhängigkeiten:** ASSET-001
+- **Datenmodell:** keins neu (Wiederverwendung von `asset_category`)
+- **Backend/Frontend/Mobile:** keins zusätzlich
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** nein direkt
+- **Rechte:** wie ASSET-001
+- **Audit:** wie ASSET-001
+- **Akzeptanzkriterien:** keine doppelte Kategorie-Verwaltung im UI.
+- **Tests:** keine zusätzlichen.
+- **DoD:** Entscheidung dokumentiert (kein neuer Code nötig) — MABEA macht das bereits so
+  (Material nutzt dieselbe Kategorie/Bereich-Struktur wie Objekte).
+
+## INV-002 — Einzelgeräte (SN-pflichtig)
+
+- **Ziel:** Materialtyp, der als Asset (nicht Consumable) geführt wird, mit Pflicht-SN.
+- **Beschreibung:** Kennzeichnung am AssetType („materialtyp=geraet_sn"), erzwingt
+  SN-Erfassung bei Instanzanlage.
+- **Benutzerwert:** Geräte wie Pulsoxymeter/Defibrillator korrekt als Einzelstücke mit
+  Prüfhistorie führen.
+- **Abhängigkeiten:** ASSET-003, IDENT-004
+- **Datenmodell:** `asset_type.materialtyp` (enum: standard/ablauf_charge/geraet_sn)
+- **Backend:** Validierung SN-Pflicht bei diesem Typ
+- **Frontend:** Formular passt sich Materialtyp an
+- **Mobile:** Erfassung im Feld
+- **QR-Code:** eigener QR je Instanz (IDENT-006)
+- **Seriennummer:** hier Pflichtfeld
+- **Inventarnummer:** ergänzend
+- **Akte:** Stammdatenbereich
+- **Rechte:** Materialwart+
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Anlage ohne SN bei diesem Typ wird abgelehnt.
+- **Tests:** Validierungstest.
+- **DoD:** deckt sich mit MABEA `materialtyp=geraet_sn` + `GeraetInstanz` (bereits
+  umgesetzt).
+
+## INV-003 — Verbrauchsmaterial (Mengen)
+
+- **Ziel:** Mengenbasierte Führung statt Einzel-Instanz.
+- **Beschreibung:** Consumable-Bestand als Zahl+Einheit statt Liste von Objekten.
+- **Benutzerwert:** Verbandsmaterial/Medikamente ohne unnötigen Verwaltungsaufwand pro
+  Stück.
+- **Abhängigkeiten:** ASSET-008
+- **Datenmodell:** `bestand` (consumable_id, standort_id, menge, einheit)
+- **Backend:** Mengenanpassung (Zu-/Abgang)
+- **Frontend:** Mengenfeld statt Instanzliste
+- **Mobile:** Mengenerfassung bei Kontrolle
+- **QR-Code:** nein direkt
+- **Seriennummer:** entfällt
+- **Inventarnummer:** ggf. je Charge (INV-004), nicht je Stück
+- **Akte:** vereinfachte Bestandsansicht
+- **Rechte:** Mitarbeiter darf melden, Materialwart verwaltet Struktur
+- **Audit:** Mengenänderung geloggt
+- **Akzeptanzkriterien:** Menge erhöhen/verringern, negative Menge unmöglich.
+- **Tests:** Grenzwerttest (0, negativ abgelehnt).
+- **DoD:** deckt sich mit MABEA `Objektposition.istmenge`
+  (materialtyp=standard/ablauf_charge).
+
+## INV-004 — Chargenverwaltung
+
+- **Ziel:** Mehrere Chargen desselben Verbrauchsmaterials unterscheidbar führen.
+- **Beschreibung:** Chargennummer + Ablaufdatum je Teilbestand statt nur am Gesamtbestand.
+- **Benutzerwert:** Rückrufaktionen chargen-genau möglich, unterschiedliche Ablaufdaten pro
+  Charge korrekt abgebildet.
+- **Abhängigkeiten:** INV-003
+- **Datenmodell:** `charge` (consumable_bestand_id, chargennummer, ablaufdatum, menge)
+- **Backend:** CRUD je Charge
+- **Frontend:** Chargen-Liste je Verbrauchsmaterial
+- **Mobile:** Erfassung bei Wareneingang
+- **QR-Code:** nein
+- **Seriennummer:** entfällt
+- **Inventarnummer:** Chargennummer ist eine Art Sub-Identität
+- **Akte:** Bestandsverlauf-Detailebene
+- **Rechte:** Materialwart+
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** mehrere Chargen mit unterschiedlichem Ablaufdatum gleichzeitig
+  führbar.
+- **Tests:** Mehrfach-Chargen-Test.
+- **DoD:** **echte MABEA-Lücke:** MABEA führt `chargennummer`+`ablaufdatum` nur EINFACH je
+  Objektposition (ein Wert, keine Liste) — mehrere Chargen gleichzeitig an derselben Position
+  sind aktuell NICHT abbildbar. Diese Kachel wäre in MABEA kein reiner Nachzug, sondern ein
+  Datenmodell-Umbau (1:1 → 1:n).
+
+---
+
+**MABEA-Ist-Stand-Abgleich:** INV-001…003 vollständig vorhanden. **INV-004 ist die erste
+Kachel in diesem Backlog, die einen echten strukturellen Umbau in MABEA bedeuten würde**
+(Mehrfach-Chargen je Position), nicht nur eine Ergänzung — vor Umsetzung separat einschätzen
+lassen, ob das fachlich überhaupt gebraucht wird (bisher kein Nutzer-Bedarf dafür geäußert).