MABEA/arbeitskacheln/05_fleet.md

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.