docs: Fehler korrigiert - Betriebsstunden fälschlich fahrzeug-only geplant

Nutzer-Fund: FLEET-003 (Kilometerstand/Betriebsstunden) war fälschlich als
fahrzeug-gebundenes Datenmodell geplant, obwohl die Ursprungs-Anforderung
explizit auch Stromerzeuger/Pumpen mit betriebsstundenabhängiger Wartung
nennt (Modul 14). Neue generische Kachel ASSET-009 (Nutzungszähler)
eingeführt, FLEET-003 zur bloßen Fahrzeug-Anwendung davon reduziert.

MABEA-Abgleich korrigiert: echte Lücke ist jetzt doppelt - kein generischer
Zähler für Nicht-Fahrzeug-Geräte UND keine Rückwärtslauf-Validierung am
bestehenden Fahrzeug-Kilometerstand.

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

arbeitskacheln/04_assets.md

@@ -169,6 +169,39 @@ Details zu ASSET-001 … ASSET-008 (vollständig).
 - **Tests:** Abgrenzungstest.
 - **DoD:** Grundlage für INV-003 gelegt.
 
+## ASSET-009 — Nutzungszähler (Kilometer/Betriebsstunden generisch)
+
+- **Nachtrag (Nutzer-Fund):** ursprünglich fälschlich als FLEET-003 fahrzeug-gebunden
+  geplant. Betriebsstunden brauchen aber auch Stromerzeuger, Pumpen und andere Geräte
+  (explizit in der Ursprungs-Anforderung Modul 14 „Wartung": „kilometerabhängige UND
+  betriebsstundenabhängige Wartung" — nicht auf Fahrzeuge beschränkt). Generischer
+  Nutzungszähler gehört daher ins Assets-Epic, nicht ins Fleet-Epic.
+- **Ziel:** Nutzungsgrad JEDES Assets erfassen, das einen Zähler hat (Kilometer ODER
+  Betriebsstunden ODER beides) — Basis für zähler-abhängige Wartungsintervalle (MAINT-002).
+- **Beschreibung:** generisches Zählerfeld je Asset (Typ: km/Betriebsstunden/keins),
+  Erfassungsverlauf (nicht nur aktueller Wert, sondern Verlauf der Meldungen).
+- **Benutzerwert:** Fahrzeuge (km), aber auch Stromerzeuger/Pumpen/Kompressoren
+  (Betriebsstunden) bekommen dieselbe Wartungslogik, ohne dass jedes Modul sein eigenes
+  Zählerfeld neu erfindet.
+- **Abhängigkeiten:** ASSET-003
+- **Datenmodell:** `asset.zaehler_typ` (enum: keiner/kilometer/betriebsstunden),
+  `asset.zaehlerstand` (aktuell), optional `zaehlerstand_historie`
+- **Backend:** Update-Endpoint mit Plausibilitätsprüfung (nur steigend, Override nur
+  Administrator)
+- **Frontend:** Eingabefeld bei Kontrolle/Rückkehr bzw. nach Nutzung
+- **Mobile:** Eingabe im Feld
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Stammdatenbereich
+- **Rechte:** jeder Nutzer darf melden, Korrektur nur Administrator
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Wert kann nur steigen (Validierung gegen Rückwärtslauf, außer
+  Admin-Override); funktioniert gleichermaßen für ein Fahrzeug (km) und ein Gerät
+  (Betriebsstunden).
+- **Tests:** Validierungstest je Zählertyp, Test mit einem Nicht-Fahrzeug-Asset
+  (z.B. Stromerzeuger).
+- **DoD:** mind. ein Fahrzeug UND ein Gerät (z.B. Stromerzeuger) nutzen denselben
+  Mechanismus nachweisbar.
+
 ---
 
 **MABEA-Ist-Stand-Abgleich:** ASSET-001…004 entsprechen `Bereich`/`Kategorie`,
@@ -177,4 +210,8 @@ Fahrzeug-Status als Beispiel für ASSET-004-Erweiterung. ASSET-005 (Suche/Filter
 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.
+Gap-Analyse vorher notiert. **ASSET-009 (generischer Nutzungszähler) fehlt ebenfalls:**
+MABEA hat Kilometerstand/Betriebsstunden nur an `fahrzeugdetails` (1:1 zu Objekt mit
+`ist_zugfahrzeug`), Geräte wie Stromerzeuger/Pumpen (`GeraetInstanz`) haben aktuell KEIN
+Betriebsstunden-Feld — echte Lücke, wenn Wartung künftig betriebsstundenabhängig geplant
+werden soll (MAINT-002, Wartungs-Epic in MABEA ohnehin noch komplett offen).