HMS MediaEngine Agent
9536e08748
- ADR-0008: Build-first, gesammelte Windows-Validierung (Auftraggeber-Freigabe) - ADR-0004 vorläufig: Rust auf GStreamer-D3D11-Elementpfad - ADR-0005 vorläufig: Nuitka Onefolder - hms_protocol: IpcServer/IpcClient mit Handshake (hello/welcome), Capabilities-Austausch, Heartbeat 500 ms bidirektional, Snapshot/Delta, Loopback-only-Enforcement, Re-Sync nach Reconnect, Version-Mismatch-Fehler - 9 Integrationstests: echter TCP-Loopback, kein Mock
78 lines
3.2 KiB
Markdown
78 lines
3.2 KiB
Markdown
# STATUS
|
||
|
||
Stand: 2026-09-11
|
||
|
||
## Aktuelle Phase
|
||
|
||
**Phase 1 – Fundament und Netzwerkbasis** unter der **Build-first-Strategie
|
||
(ADR-0008)**: Die Phasen 1–5 werden plattformneutral vollständig gebaut;
|
||
Gate 0 und alle renderer-nahen Abnahmen werden gesammelt in einem späteren
|
||
Windows-Durchlauf validiert. Auftraggeber-Freigabe für die Reihenfolgeabweichung
|
||
vom 2026-09-11, dokumentiert in ADR-0008 gemäß PLAN.md §1.
|
||
|
||
## Letzter grüner Commit
|
||
|
||
- siehe `git log` und `TEST_REPORT.md` – jede Etappe endet mit grünem pytest
|
||
und Ruff und wird sofort nach Forgejo gepusht.
|
||
|
||
## Bestandene Gates
|
||
|
||
- keine; **Gate 0 bleibt offen** bis zum Windows-Hardware-Durchlauf
|
||
(Testplan in ADR-0008)
|
||
|
||
## Arbeitsweise (ADR-0008)
|
||
|
||
- Build-first: plattformneutral fertig bauen, Hardware-Validierung gesammelt
|
||
am Ende (Windows-Durchlauf).
|
||
- Kein Gate wird als grün gemeldet, solange der Windows-Durchlauf offen ist.
|
||
- Renderer-Nähe ausschließlich über den Backend-Vertrag (§12.6); Korrekturen
|
||
bleiben lokal im Adapter.
|
||
|
||
## Laufende Arbeit
|
||
|
||
Phase 0 (abgeschlossen, soweit ohne Hardware möglich):
|
||
|
||
- [x] Repository, Pflichtdokumente, ADRs 0001–0003
|
||
- [x] GStreamer-Pin 1.28.6, Kernpakete, Control Core, Renderer-Spike
|
||
- [x] Beispielplugins (Passthrough, Gaussian Blur mit 3 AQ-Varianten), Tools
|
||
- [x] 121 Unit-/Integrationstests grün, Ruff grün (Belege: TEST_REPORT.md)
|
||
|
||
Phase 1 (im Bau):
|
||
|
||
- [x] IPC-Verbindung Control Core ↔ Renderer: Handshake (hello/welcome),
|
||
vollständiger Snapshot nach Verbindung, Deltas mit monotoner Revision,
|
||
Command-Acks idempotent über message_id, Heartbeat 500 ms in beide
|
||
Richtungen, Re-Sync nach Reconnect, ausschließlich Loopback (§6.2)
|
||
- [ ] SQLite-Persistenz (WAL, Migrationen, Backup, §24)
|
||
- [ ] Launcher/Supervisor (Prozessstart, Heartbeat-Überwachung, kontrolliertes
|
||
Beenden, Crash-Erkennung)
|
||
- [ ] Persistente Node-Identität + Rollen in der App-Verkabelung
|
||
- [ ] mDNS/DNS-SD-Discovery + manuelle Node-Liste (§6.3)
|
||
- [ ] Paarung (PIN/Fingerprint) und Node-Vertrauen
|
||
- [ ] Cluster-Nachrichtenhülle mit Sequenzen/Revisionen (§6.5)
|
||
|
||
## Nächste drei Aufgaben
|
||
|
||
1. SQLite-Persistenz mit WAL, transaktionalem Autosave und Migrationstests (§24)
|
||
2. Launcher/Supervisor mit Heartbeat-Überwachung und kontrolliertem Beenden (§6.1A)
|
||
3. Discovery (mDNS) plus manuelle Fallback-Liste und Paarungsgrundlage (§6.3)
|
||
|
||
## Ausstehende Hardware-Validierung (ADR-0008 Testplan)
|
||
|
||
Nur auf echtem Windows mit GPU messbar; nichts davon gilt als erledigt:
|
||
|
||
- D3D11-Hardwaredecode aktiv; D3D11Memory durchgängig ohne CPU-Rundweg
|
||
- Framezeit p50/p95/p99; DMX → sichtbarer Frame p95 ≤ 2 Frames
|
||
- Adaptive-Quality-Wechsel ohne Stall; Golden Images; Shader-Compile auf GPU
|
||
- Portable Onefolder-Ausgabe auf sauberem Rechner (§29.6)
|
||
- Rust-Renderkern-Kompilierung und GStreamer-Plugin-Bindung (ADR-0004)
|
||
|
||
## Bekannte Blocker
|
||
|
||
- Windows-Referenzhardware fehlt in der Entwicklungsumgebung
|
||
(Linux-Container, CPU-only) – Kernblocker, durch ADR-0008 gemanagt.
|
||
- Rust-Toolchain (cargo) fehlt im Container: Rust-Quellcode wird entwickelt,
|
||
das Kompilierungsgate erfolgt im Windows-Durchlauf.
|
||
- pnpm fehlt im Container: wird für Phase 5 über Node-Corepack aktiviert
|
||
(kein Installationsblocker).
|