|
|
|
@@ -228,15 +228,24 @@ Generator/Upsampler und Hardwarewriter werden als getrennte Stufen mit kleinem, |
|
|
|
- Frame-Klonierung pro Chunk erhöht Heap-Pressure; spätere Workstreams sollten Pooling / Zero-Copy prüfen.
|
|
|
|
|
|
|
|
### WS-01-T3 — Supervisor-Schicht einführen
|
|
|
|
- **Status:** TODO
|
|
|
|
- **Owner:** offen
|
|
|
|
- **Status:** IN PROGRESS
|
|
|
|
- **Owner:** Lead Coderaffe
|
|
|
|
- **Code-Orte:**
|
|
|
|
- `internal/app/engine.go`
|
|
|
|
- **Ziel:**
|
|
|
|
Queue-Füllstand, Late-Rate und Fehlerhäufigkeit überwachen und in Runtime-Zustände überführen.
|
|
|
|
Queue-Füllstand, Late-Rate und Fehlerhäufigkeit überwachen und in explizite Runtime-Zustände überführen,
|
|
|
|
sodass ein degradierter Queue-Health-Pfad automatisch auf `degraded`, `muted` oder `faulted` zeigt.
|
|
|
|
- **Akzeptanzpunkte:**
|
|
|
|
- State-Entscheidungen sind explizit
|
|
|
|
- kein implizites Weiterwursteln bei Schieflage
|
|
|
|
- Alle Runtime-Entscheidungen laufen über `evaluateRuntimeState`, nicht stillschweigend weiter auf `running`.
|
|
|
|
- Queue-Health, Late-Buffers und Fault-Events treiben gezielt `degraded` → `muted` → `faulted`, damit Operatoren wissen, wann Blockaden vorliegen.
|
|
|
|
- `EngineStats` und `/runtime` bringen `runtimeIndicator`, `queue`, `faultHistory`, `transitionHistory` und das `runtimeState`-Label, so Telemetrie und UI dieselben Signale sehen.
|
|
|
|
- **Nachweis:**
|
|
|
|
- `internal/app/engine.go` (Generator-/Writer-Loops) ruft `evaluateRuntimeState` auf und protokolliert Fault-Events, Transition-Historien und Counters.
|
|
|
|
- `txBridge.TXStats` (`cmd/fmrtx/main.go`) leitet die Runtime-Infos an `/status` und `/runtime`, damit die API-Layer aktuelle Fault-Zustände spiegeln.
|
|
|
|
- `internal/app/runtime_state_test.go` plus `go test ./...` sichern die erwarteten Transition-Reihenfolgen und Fault-Counter.
|
|
|
|
- **Restrisiken:**
|
|
|
|
- Queue-Schwellen für `critical`/`lateBuffers` brauchen noch Feldvalidierung und ggf. Konfiguration.
|
|
|
|
- Fault-Reset/Operator-Interaktion ist im Control-Plane-UI noch zu finalisieren.
|
|
|
|
|
|
|
|
## Offene Architekturfragen
|
|
|
|
- Ist `capacity_frames = 3` ein guter Startwert oder nur Konzept-Default?
|
|
|
|
@@ -298,31 +307,50 @@ Einführen eines klaren Betriebsmodells mit Fault-, Recovery- und Muted-Zuständ |
|
|
|
## Aufgaben
|
|
|
|
|
|
|
|
### WS-02-T1 — Fault-Klassifikation definieren
|
|
|
|
- **Status:** TODO
|
|
|
|
- **Owner:** offen
|
|
|
|
- **Status:** IN PROGRESS
|
|
|
|
- **Owner:** Lead Coderaffe
|
|
|
|
- **Beispiele:**
|
|
|
|
- Treiberfehler
|
|
|
|
- Write-Time-Budget überschritten
|
|
|
|
- Queue leer
|
|
|
|
- Queue dauerhaft kritisch
|
|
|
|
- Selbsttest fehlgeschlagen
|
|
|
|
- unerlaubtes Live-Update
|
|
|
|
- `queueCritical`
|
|
|
|
- `lateBuffers`
|
|
|
|
- `writeTimeout` (z. B. Driver-Timeouts)
|
|
|
|
- `queueEmpty`
|
|
|
|
- `unknown` (Catch-all für unvorhergesehene Runtime-Zustände)
|
|
|
|
- **Ziel:**
|
|
|
|
Alle relevanten Fehlertypen als `FaultReason`/`FaultSeverity` codieren, damit sie später eindeutig auf Telemetrie und Logs abgebildet werden können.
|
|
|
|
- **Nachweis:**
|
|
|
|
- `internal/app/fault.go` definiert Reasons (`queueCritical`, `lateBuffers`, `writeTimeout`, `queueEmpty`, `unknown`) und Severity-Stufen (`warn`, `degraded`, `muted`, `faulted`).
|
|
|
|
- `internal/app/engine.go` ruft `recordFault` im Queue- und Late-Buffer-Prozess auf, so dass jede Reason vom Fault-Historien-Log erfasst wird.
|
|
|
|
- `internal/app/runtime_state_test.go` und `internal/app/fault_test.go` prüfen, dass die Reason/Severity-Kombinationen korrekt geloggt und ausgewertet werden.
|
|
|
|
- **Restrisiken:**
|
|
|
|
Weitere Driver-/Hardware-Faults (z. B. Soapy-Timeouts oder Audio-Stream-Abbrüche) müssen noch explizit getriggert und klassifiziert werden.
|
|
|
|
|
|
|
|
### WS-02-T2 — Reaktionsstrategie definieren
|
|
|
|
- **Status:** TODO
|
|
|
|
- **Owner:** offen
|
|
|
|
- **Status:** IN PROGRESS
|
|
|
|
- **Owner:** Lead Coderaffe
|
|
|
|
- **Ziel:**
|
|
|
|
Pro Fehlerklasse klar definieren:
|
|
|
|
Reaktionen für jede FaultSeverity klar definieren (warn → loggen, degraded → degrade state, muted → stilllegen, faulted → Reset-Hürde).
|
|
|
|
- warn only
|
|
|
|
- degraded
|
|
|
|
- muted
|
|
|
|
- faulted
|
|
|
|
- **Nachweis:**
|
|
|
|
- `evaluateRuntimeState` eskaliert queueCritical-Läufe zuerst zu `degraded`, dann `muted`, schließlich `faulted` und protokolliert die entsprechenden Severity-Labels.
|
|
|
|
- `Engine.ResetFault()` bringt `faulted` deterministisch zurück auf `degraded`, damit die Supervisor-Logik das Manual-Reset respektiert.
|
|
|
|
- Tests in `internal/app/runtime_state_test.go` prüfen, dass die Transition-Counter (`degradedTransitions`, `mutedTransitions`, `faultedTransitions`) und `faultCount` bei den richtigen Ereignissen springen.
|
|
|
|
- **Restrisiken:**
|
|
|
|
Die aktuellen Schwellen basieren auf queueCritical-Streaks; zusätzliche FaultSources (Driver, Audio-Stream, Live-Update-Rejection) brauchen eigene Severity-Strategien.
|
|
|
|
|
|
|
|
### WS-02-T3 — Fault-Historie und Event-Log einführen
|
|
|
|
- **Status:** TODO
|
|
|
|
- **Owner:** offen
|
|
|
|
- **Status:** IN PROGRESS
|
|
|
|
- **Owner:** Lead Coderaffe
|
|
|
|
- **Ziel:**
|
|
|
|
Zustandswechsel und Faults auditierbar machen.
|
|
|
|
Zustandswechsel, Fault-Count und Trace-Historien auditierbar machen, damit `/runtime` und die UI eine nachvollziehbare Story liefern können.
|
|
|
|
- **Nachweis:**
|
|
|
|
- `EngineStats` enthält `faultHistory`, `transitionHistory`, `lastFault`, `faultCount` sowie `runtimeStateDurationSeconds` und Runtime-Indikatoren.
|
|
|
|
- `txBridge.TXStats` leitet diese Infos in `/runtime` und `/status` weiter, `internal/control/control_test.go` sichert, dass `faultHistory` und `transitionHistory` korrekt serialisiert werden.
|
|
|
|
- `internal/app/runtime_state_test.go` validiert die Historienkapazität, `go test ./...` deckt die API-Exposition ab.
|
|
|
|
- **Restrisiken:**
|
|
|
|
Die History-Kapazität ist auf 8 Einträge begrenzt; ein Audit-Log-Backend könnte später die Lücke auffangen.
|
|
|
|
|
|
|
|
## Offene Designfragen
|
|
|
|
- Wie fein granular darf die State-Maschine werden, ohne unwartbar zu werden?
|
|
|
|
|
Jan
1 месяц назад