Files
hms-mediaengine/STATUS.md
T
HMS MediaEngine Agent c4574927fd Phase 1: Cluster-Fundament – Nachrichten, Registry, Paarung, Discovery
- hms_cluster: ClusterMessage (§6.5: Pflichtfelder, Sequenzen, Revisionen,
  execute_at, Trace-ID), CommandTracker (idempotent, vorwärts-only:
  accepted->armed->executed/failed)
- NodeRegistry: online/degraded/stale/offline über Schwellen, UI-Kategorien
  discovered/paired/unknown/incompatible/offline, Doppel-Node-ID blockiert,
  IP-Wechsel erhaelt node_id (§6.3, §6.5)
- Pairing: PIN (TTL 120s, Versuchslimit), Fingerprint (SHA-256 gruppiert),
  Token nur als Hash, Scopes read/control/content_sync/admin, Ablauf +
  sofortiger Widerruf (§6.3, §27.1, ADR-0010)
- Discovery-Modell: _hmsmedia._tcp.local. TXT ohne Secrets, Capability-
  Digest, persistente manuelle Fallback-Liste (ADR-0009)
- ADR-0009 (mDNS + Fallback) und ADR-0010 (Paarung) dokumentiert
- 25 Unit-Tests; Gesamtsuite 183 Tests gruen, Ruff gruen
2026-09-11 01:06:26 +02:00

4.1 KiB
Raw Blame History

STATUS

Stand: 2026-09-11

Aktuelle Phase

Phase 1 Fundament und Netzwerkbasis unter der Build-first-Strategie (ADR-0008): Die Phasen 15 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):

  • Repository, Pflichtdokumente, ADRs 00010003
  • GStreamer-Pin 1.28.6, Kernpakete, Control Core, Renderer-Spike
  • Beispielplugins (Passthrough, Gaussian Blur mit 3 AQ-Varianten), Tools
  • 121 Unit-/Integrationstests grün, Ruff grün (Belege: TEST_REPORT.md)

Phase 1 (im Bau):

  • 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 mit Backup, Integritätscheck, Projekt-/Einstellungs-/Plugin-Status-CRUD, §24)
  • Launcher/Supervisor: echte Kindprozesse, portable Umgebung, freie Portwahl, kontrolliertes Beenden (terminate→kill) mit Recovery- Markierung, Restart-Policy mit Crashloop-Erkennung (§6.1A, §26.2, §26.4)
  • Cluster-Nachrichtenhülle: Pflichtfelder, Sequenzen, Revisionen, Trace-ID, Idempotenz-Tracker mit vorwärts-only-Statuskette (§6.5)
  • Node-Registry: online/degraded/stale/offline über Schwellen, UI-Kategorien discovered/paired/unknown/incompatible/offline, Doppel-Node-ID-Fehler, IP-Wechsel erhält node_id (§6.3, §6.5)
  • Paarung: kurzlebige PIN (TTL 120 s, Versuchslimit), sichtbarer Fingerprint, Token nur als Hash mit Scopes read/control/content_sync/ admin, Ablauf und sofortiger Widerruf (§6.3, §27.1, ADR-0010)
  • Discovery-Modell: mDNS-Service _hmsmedia._tcp.local. mit TXT ohne Secrets, Capability-Digest, persistente manuelle Fallback-Liste (ADR-0009)
  • Node-Identität + Rollen in die App-Verkabelung (Control Core lädt node_id aus identity/, startet Discovery-Service auf Zielsystemen)
  • mDNS-Echtnetz-Betrieb mit zeroconf auf Zielsystemen (Modell fertig; Multicast-Test gehört zu Gate 1, ADR-0009)

Nächste drei Aufgaben

  1. Node-Identität + Rollen in der App-Verkabelung (Control Core Startup)
  2. mDNS-Echtnetz mit zeroconf auf Zielsystemen + Gate-1-LAN-Test vorbereiten
  3. Phase-2-Beginn vorbereiten: Master-Canvas/Layer-Modell im Domain-Paket

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).