# Epic 16 — Operations

Details zu OPS-001 … OPS-003. **Bewusst nur als Platzhalter ausgearbeitet** — die
Ursprungs-Anforderung sagt explizit: „Einsatzverwaltung/Einsatzdisposition noch nicht
implementieren, aber bei der Architektur berücksichtigen." Diese Datei erfüllt genau das:
genug Grundgerüst, damit FLEET-006 und andere Epics wissen, worauf sie sich später beziehen
— keine vollständige Fachspezifikation, da kein konkreter Bedarf vorliegt.

---

## OPS-001 — Einsatzverwaltung (Platzhalter)

- **Ziel:** Grundgerüst für eine künftige Einsatzverwaltung, das keine Änderung an
  bereits gebauten Epics erzwingt.
- **Beschreibung:** minimales Platzhalter-Datenmodell (Einsatz-Entität mit ID,
  Zeitstempel, Status) — Rest folgt erst, wenn das Epic tatsächlich angegangen wird.
- **Benutzerwert:** TBD — noch keine konkrete Anforderung geäußert.
- **Abhängigkeiten:** FILE-001
- **Datenmodell:** `einsatz` (id, bezeichnung, alarmiert_am, status) — Platzhalter, nicht
  endgültig
- **Backend/Frontend/Mobile:** TBD
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** künftig eigener „Einsatz"-Akte-Typ denkbar (Ressourcen-Akte und Einsatz-Akte
  sind unterschiedliche Konzepte)
- **Rechte/Audit:** TBD
- **Akzeptanzkriterien/Tests:** TBD
- **DoD:** **DECISION REQUIRED:** dieses Epic explizit NICHT umsetzen, bevor ein echter
  Bedarf konkret geäußert wird. Der Platzhalter dient nur dazu, dass FLEET-006/OPS-002
  wissen, worauf sie sich später beziehen. Aufwand/Risiko/Priorität sind ohne echte
  Anforderung nicht sinnvoll schätzbar.

## OPS-002 — Einsatzmittel-Verknüpfung

- **Ziel:** Ressourcen (Assets) einem Einsatz zuordnen (welches Fahrzeug/Material war bei
  Einsatz X im Einsatz).
- **Beschreibung:** M:N Einsatz↔Asset, Zeitraum der Zuordnung.
- **Benutzerwert:** Nutzungsnachweis, Grundlage für FLEET-006 (Fahrzeug-Einsatzhistorie).
- **Abhängigkeiten:** OPS-001, ASSET-003
- **Datenmodell:** `einsatz_ressource` (einsatz_id, asset_id, von, bis) — Platzhalter
- **Backend/Frontend/Mobile:** TBD
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Ressourcen-Akte könnte „Einsatzhistorie" als zusätzlichen Bereich bekommen
  (siehe FLEET-006)
- **Rechte/Audit:** TBD
- **Akzeptanzkriterien/Tests:** TBD
- **DoD:** abhängig von OPS-001, gleiche Einschränkung — nicht umsetzen ohne konkreten
  Bedarf.

## OPS-003 — Einsatznachbereitung (Platzhalter)

- **Ziel:** Nach einem Einsatz Rückschau/Auswertung (Verbrauchsmaterial-Nachbestellung,
  Debriefing-Notizen).
- **Beschreibung:** bewusst nicht spezifiziert.
- **Benutzerwert:** TBD
- **Abhängigkeiten:** OPS-001
- **Datenmodell/Backend/Frontend/Mobile/QR/SN/Inv/Akte/Rechte/Audit:** TBD
- **Akzeptanzkriterien/Tests:** TBD
- **DoD:** **DECISION REQUIRED**, wie OPS-001 — reiner Platzhalter, absichtlich nicht
  weiter ausgearbeitet gemäß Ursprungs-Anforderung.

---

**MABEA-Ist-Stand-Abgleich:** entfällt — dieses Epic ist im gesamten Backlog das einzige,
das bewusst nicht gegen einen Ist-Stand abgeglichen wird, weil weder MABEA noch die
Ursprungs-Anforderung dafür eine konkrete Zielvorstellung liefern. Sollte dieses Epic
später tatsächlich angegangen werden, sollte der erste Schritt eine eigene, echte
Anforderungsklärung mit dem Nutzer sein (analog zum Ablauf, der zu diesem gesamten Backlog
geführt hat) — nicht ein direkter Sprung in die Umsetzung.

---

## Abschluss der Backlog-Detaillierungsphase

Mit diesem Epic sind **alle 16 Epics des Backlogs** (siehe `00_index.md`) mindestens einmal
durchgegangen — 13 davon vollständig fachlich spezifiziert (Foundation bis Mobile), dieses
letzte bewusst nur als Platzhalter. Insgesamt wurden im Zuge dieser Detaillierung
**zwei echte Bugs in MABEA gefunden und noch am selben Tag live gefixt** (Betriebsstunden
fälschlich fahrzeug-only geplant → generischer Zähler ASSET-009 + Funkkenner-Feld ergänzt;
UNKNOWN-Readiness-Zustand fehlte → nie kontrollierte Objekte galten fälschlich als
einsatzbereit). Die verbleibenden offenen Punkte sind in `00_index.md` unter „Decisions
Required" gesammelt.