docs: nächste 10 Arbeitskacheln (FILE-006/007, ASSET-001..008)

Digital-File-Epic damit vollständig (FILE-001..007), neues Assets-Epic
(04_assets.md) komplett detailliert. MABEA-Ist-Stand-Abgleich je Epic:
Digital File fehlt komplett (Aggregations-Akte existiert nirgends, obwohl
alle Einzelbausteine schon da sind), Assets ist bis auf AssetSet/Consumable
als eigenständige Konzepte bereits abgedeckt (Bereich/Kategorie/Objekttyp/
Objekt/Lagerbewegung).

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

arbeitskacheln/04_assets.md

@@ -0,0 +1,180 @@
+# Epic 04 — Assets
+
+Details zu ASSET-001 … ASSET-008 (vollständig).
+
+---
+
+## ASSET-001 — AssetCategory
+
+- **Ziel:** Oberste Gliederungsebene für Ressourcentypen.
+- **Beschreibung:** Kategorie-Stammdaten (z.B. „Medizin", „Fahrzeuge", „Funk").
+- **Benutzerwert:** Navigierbare Struktur beim Anlegen/Suchen.
+- **Abhängigkeiten:** FOUND-002
+- **Datenmodell:** `asset_category` (id, name)
+- **Backend:** CRUD
+- **Frontend:** Verwaltung Kategorie
+- **Mobile:** nur Anzeige/Filter
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** nein direkt
+- **Rechte:** Administrator
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Kategorie anlegen/umbenennen/löschen (nur wenn unbenutzt).
+- **Tests:** CRUD-Test, Löschschutz-Test bei Verwendung.
+- **DoD:** mind. 3 Beispielkategorien angelegt.
+
+## ASSET-002 — AssetType
+
+- **Ziel:** Konkreter Typ innerhalb einer Kategorie (z.B. „AED Philips FRx").
+- **Beschreibung:** Typ-Stammdaten, verweist auf Kategorie + Hersteller/Modell (IDENT-005).
+- **Benutzerwert:** Wiederverwendbare Vorlage für alle Exemplare dieses Typs.
+- **Abhängigkeiten:** ASSET-001
+- **Datenmodell:** `asset_type` (id, category_id, name, hersteller_id, modell)
+- **Backend:** CRUD
+- **Frontend:** Verwaltung
+- **Mobile:** Anzeige
+- **QR-Code/Seriennummer/Inventarnummer:** nein direkt
+- **Akte:** Stammdatenbereich referenziert den Typ
+- **Rechte:** Materialwart/Administrator
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Typ anlegen mit Kategorie- und Hersteller-Verknüpfung.
+- **Tests:** CRUD- + Verknüpfungstest.
+- **DoD:** mind. ein Typ je Kategorie angelegt.
+
+## ASSET-003 — Asset/AssetInstance
+
+- **Ziel:** Das konkrete Einzelobjekt (physische Ressource) — Kernentität der Plattform.
+- **Beschreibung:** Instanz eines AssetType mit eigener Objekt-ID, Inventarnummer,
+  Seriennummer.
+- **Benutzerwert:** „Ein Ding, ein Datensatz" — Grundlage für praktisch alle anderen Epics.
+- **Abhängigkeiten:** ASSET-002, IDENT-001/002/004
+- **Datenmodell:** `asset` (id, asset_type_id, inventarnummer, seriennummer, status, ...)
+- **Backend:** CRUD
+- **Frontend:** Anlegen-Formular, Liste
+- **Mobile:** Anzeige/Anlage im Feld
+- **QR-Code:** wird für diese Instanz erzeugt (IDENT-006)
+- **Seriennummer/Inventarnummer:** hier verortet
+- **Akte:** 1:1 Grundlage der Akte
+- **Rechte:** Materialwart/Administrator schreibt, alle lesen
+- **Audit:** Anlage/Änderung geloggt
+- **Akzeptanzkriterien:** Asset anlegen mit Typ-Referenz, Inventarnummer/SN eindeutig im
+  jeweiligen Scope.
+- **Tests:** CRUD-Test, Eindeutigkeits-Constraint-Test.
+- **DoD:** durchgängig mit IDENT-001/002/004 verzahnt getestet.
+
+## ASSET-004 — Asset-Status-Modell
+
+- **Ziel:** Genereller Lebenszyklus-Status, den alle Ressourcentypen teilen.
+- **Beschreibung:** Enum z.B. AKTIV/IN_WARTUNG/AUSSER_DIENST — Erweiterungspunkt für
+  Readiness; spezifische Module wie Fleet dürfen feiner erweitern (FLEET-004).
+- **Benutzerwert:** Einheitliche Sprache über alle Ressourcentypen hinweg.
+- **Abhängigkeiten:** ASSET-003
+- **Datenmodell:** `asset.status` (enum)
+- **Backend:** Statuswechsel-Endpoint
+- **Frontend:** Status-Dropdown
+- **Mobile:** Anzeige/Änderung
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Stammdatenbereich (Status-Badge)
+- **Rechte:** Materialwart/Administrator
+- **Audit:** Statuswechsel geloggt
+- **Akzeptanzkriterien:** Statuswechsel möglich, ungültige Übergänge (falls modelliert)
+  abgelehnt.
+- **Tests:** Statuswechsel-Test.
+- **DoD:** Status fließt sichtbar in FILE-002 ein.
+
+## ASSET-005 — Asset-Suche & Liste
+
+- **Ziel:** Ressourcen wiederfinden, ohne ihre Akte-ID einzeln zu kennen.
+- **Beschreibung:** Liste mit Filter (Kategorie/Typ/Status) + Volltextsuche
+  (Name/Inventarnummer/SN).
+- **Benutzerwert:** Alltagswerkzeug für Materialwart/Helfer.
+- **Abhängigkeiten:** ASSET-003
+- **Datenmodell:** keins neu
+- **Backend:** Such-/Filter-Query-Parameter am Listen-Endpunkt
+- **Frontend:** Listen-Seite mit Suchfeld/Filtern
+- **Mobile:** kompakte Listenansicht
+- **QR-Code:** nein
+- **Seriennummer/Inventarnummer:** Suchfelder
+- **Akte:** Sprungziel je Zeile
+- **Rechte:** wie Lese-Recht
+- **Audit:** nein
+- **Akzeptanzkriterien:** Suche nach Inventarnummer/SN/Name liefert korrekte Treffer.
+- **Tests:** Suchtest mit kombinierten Kriterien.
+- **DoD:** Performance akzeptabel bei realistischer Datenmenge (Index statt
+  Volltabellen-Scan).
+
+## ASSET-006 — Asset-Bewegungshistorie
+
+- **Ziel:** Generisches Standortwechsel-Protokoll für jedes Asset, nicht nur
+  fahrzeug-/warehouse-spezifisch.
+- **Beschreibung:** Bewegung(asset_id, von, nach, wer, wann, warum) — Basis für
+  WH-007/FILE-003.
+- **Benutzerwert:** Nachvollziehbarkeit „wo war das Ding wann".
+- **Abhängigkeiten:** ASSET-003, WH-001
+- **Datenmodell:** `asset_bewegung`
+- **Backend:** Bewegung erzeugen bei Standortwechsel
+- **Frontend:** Verschieben-Aktion
+- **Mobile:** ggf. später (P2)
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Standort- und Historienbereich
+- **Rechte:** Materialwart+
+- **Audit:** eigenständiges Fach-Protokoll (nicht generisches Audit-JSON, da Von/Nach-Felder
+  strukturiert gebraucht werden — bewusst getrennt von FOUND-006)
+- **Akzeptanzkriterien:** Standortwechsel erzeugt Bewegungseintrag korrekt.
+- **Tests:** Bewegungstest.
+- **DoD:** funktional deckungsgleich mit dem in MABEA bereits existierenden
+  Lagerbewegung-Modell (dient hier als Vorbild/Referenzimplementierung).
+
+## ASSET-007 — AssetSet
+
+- **Ziel:** Mehrere Assets als ein handhabbares Bündel (Materialset) verwalten.
+- **Beschreibung:** Set-Entität mit Mitgliedsliste (Assets oder Consumables in bestimmter
+  Menge).
+- **Benutzerwert:** z.B. „Verbandsset" als eine Ausgabeeinheit statt Einzelteile einzeln zu
+  handhaben.
+- **Abhängigkeiten:** ASSET-003
+- **Datenmodell:** `asset_set`, `asset_set_mitglied`
+- **Backend:** CRUD Set + Mitglieder
+- **Frontend:** Set-Zusammenstellung
+- **Mobile:** Anzeige
+- **QR-Code:** Set kann eigene Identität/eigenen QR bekommen (IDENT-001 anwendbar)
+- **Seriennummer/Inventarnummer:** Set selbst kann eigene Inventarnummer haben
+- **Akte:** eigene Akte für das Set
+- **Rechte:** Materialwart+
+- **Audit:** Änderung der Mitgliederliste geloggt
+- **Akzeptanzkriterien:** Set anlegen, Mitglieder hinzufügen/entfernen.
+- **Tests:** CRUD-Test.
+- **DoD:** mind. ein Set mit 2+ Mitgliedern funktionsfähig. **Lücke gegenüber MABEA:**
+  Beladungsvorlage ist konzeptionell ähnlich, aber fest ans Objekt gebunden — kein
+  eigenständiges, wiederverwendbares Set-Konzept.
+
+## ASSET-008 — Consumable
+
+- **Ziel:** Verbrauchsmaterial als eigenes Konzept vom Einzelgerät abgrenzen.
+- **Beschreibung:** Consumable-Typ mit Mengenführung statt Einzelinstanz-pro-Objekt-ID.
+- **Benutzerwert:** Verbandsmaterial/Medikamente etc. sinnvoll ohne künstliche Einzel-IDs je
+  Stück verwalten.
+- **Abhängigkeiten:** ASSET-002
+- **Datenmodell:** `consumable` (asset_type_id, ...) — im Unterschied zu Asset keine 1:1
+  Objekt-ID pro Stück, sondern Menge an einem Ort (Ausbau folgt in INV-003)
+- **Backend:** Grundmodell
+- **Frontend:** Unterscheidung im AssetType-Formular („ist Verbrauchsmaterial")
+- **Mobile:** Anzeige
+- **QR-Code/Seriennummer:** Consumables i.d.R. ohne SN, ggf. Charge (INV-004)
+- **Inventarnummer:** i.d.R. nicht je Stück, ggf. je Charge
+- **Akte:** vereinfachte Akte (Bestandsverlauf statt Einzelverlauf)
+- **Rechte:** Materialwart+
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Consumable-Typ anlegen, unterscheidet sich klar von Asset im
+  Datenmodell (keine Einzel-Instanzen entstehen).
+- **Tests:** Abgrenzungstest.
+- **DoD:** Grundlage für INV-003 gelegt.
+
+---
+
+**MABEA-Ist-Stand-Abgleich:** ASSET-001…004 entsprechen `Bereich`/`Kategorie`,
+`Objekttyp`, `Objekt`, `ObjektStatus` — vollständig vorhanden, inkl. des 5-stufigen
+Fahrzeug-Status als Beispiel für ASSET-004-Erweiterung. ASSET-005 (Suche/Filter) vorhanden
+in ObjektListPage/ObjektSection. ASSET-006 (Bewegungshistorie) vorhanden als
+`Lagerbewegung` (diente hier sogar als Vorbild). **ASSET-007 (AssetSet) und ASSET-008
+(Consumable als eigenständiges Konzept) fehlen** — echte Lücken, wie schon in der
+Gap-Analyse vorher notiert.