# 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 (plattformneutral abgeschlossen, ADR-0008):

- [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)
- [x] SQLite-Persistenz (WAL, Migrationen mit Backup, Integritätscheck,
      Projekt-/Einstellungs-/Plugin-Status-CRUD, §24)
- [x] 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)
- [x] Cluster-Nachrichtenhülle: Pflichtfelder, Sequenzen, Revisionen,
      Trace-ID, Idempotenz-Tracker mit vorwärts-only-Statuskette (§6.5)
- [x] 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)
- [x] 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)
- [x] Discovery-Modell: mDNS-Service _hmsmedia._tcp.local. mit TXT ohne
      Secrets, Capability-Digest, persistente manuelle Fallback-Liste
      (ADR-0009)
- [x] Node-Identität + Rollen in der App-Verkabelung: Control Core lädt
      persistente node_id (Launcher/Produktion) bzw. Dev-ephemeral,
      Registry registriert die eigene Node, Endpunkte /system/identity
      und /cluster/nodes nach UI-Kategorien (§3.6, §6.3, §27.1)
- [ ] mDNS-Echtnetz-Betrieb mit zeroconf auf Zielsystemen (Modell fertig;
      Multicast-Test gehört zu Gate 1, ADR-0009)

Phase 2 (im Bau):

- [x] Domänenmodell: Project/Composition/Layer/Source/EffectInstance/
      MediaAsset/OutputSurface/PresetScene mit Validierungen (§10.1)
- [x] Medien-Engine: PlaybackController (Play/Pause/Stop/Retrigger, Loop/
      Once/Ping-Pong, In/Out, ±4x Speed, Ende-Ereignis), PreloadSlot für
      atomaren Clipwechsel, MediaLibrary mit Duplikaterkennung und Bank-
      Slots, ContentManifest mit SHA-256 und Chunk-Hashes (§12, §13, §6.4)
- [x] Project-State-Store mit monotonen Revisionen, Snapshot/Delta
      (neu/geändert/gelöscht), Szenenaktivierung als Zielzustand,
      Projekt-/Livezustand getrennt (§6.4, §24.2, §18.1)
- [x] Servergruppen + Zielrouting: All/Node/Output/Group, Zielregeln
      selected/tag_query/all, Commit-Vorschau (§6.3, §10.1, §17.5)
- [x] Clock-Offset-/Drift-Messung: RTT-Min-Filter (≤2× Min), Drift erst
      ab 1 s Fenster, Showzeit→lokale-Zeit-Abbildung (§6.4)
- [x] zeitgestempelte Preset-Aktivierung: Vorlauf 200 ms, Arm/Execute/
      Ack, FAILED bei fehlender Arm-Bestätigung (§6.5)
- [x] Renderer-Anbindung: RemoteStateMirror (Renderer) + RendererStateLink
      (Control Core) über IPC; Pflicht-Snapshot nach (Re-)Connect, danach
      Deltas (neu/geändert/gelöscht), Deltas vor Snapshot abgelehnt,
      Duplikate idempotent; End-to-End-Integrationstest über echtes
      TCP-Loopback ohne Mocks (§6.2, §6.4)

Phase 3 (plattformneutral abgeschlossen, ADR-0008):

- [x] Plugin-Lifecycle-Manager: Zustandsgraph discovered→validated→
      installed→enabled→compiled→active mit quarantined/incompatible,
      Show-Lock-Schutz (§14.5, §14.6, §26.3), Versionsupdate-Zyklus
- [x] Alle 10 Pflicht-Generatoren (§15.1): solid, gradient, checker_grid,
      stripes_chaser, noise_clouds, plasma, wave_bars, shapes,
      drops_ripples, starfield – je HLSL/GLSL/GLES + AQ-Varianten
- [x] Alle 14 Pflicht-Filter (§15.2): transform2d, color_adjust,
      gradient_map, blur_sharpen (separabel 2-Pass), pixelate_quantize,
      mirror_tile, kaleidoscope, wave_displace, rgb_split, glow_bloom,
      edge_emboss, vignette, strobe_pulse (Safety ≤2 Hz), feedback_trails
- [x] SDK-Dokumentation: 7 Dateien in docs/plugin-sdk/ (Manifest-Referenz,
      Shader-Vertrag, DMX-Slots, Lifecycle, AQ, Beispiel-Walkthrough)
- [ ] Golden-Image-Tests-Infrastruktur (Ausführung auf Windows-Hardware)
- [ ] Backend-Adapter: Shader-Loader für D3D11/GL/GLES (Rust, ADR-0004)

Phase 4 (im Bau):

- [x] Fixture-Engine Master32: 32-Kanal-Dekodierung mit 16-Bit-Werten,
      Blackout/Freeze, Flanken-Trigger, reservierte Kanäle neutral (§16.3)
- [x] Fixture-Engine Layer64: 64-Kanal-Dekodierung mit modusabhängigem
      Source-Block, Load/Commit-Semantik mit pending selection,
      Pickup/Takeover, Retrigger, FX1/FX2 P1–P8 (§16.4, §16.5)
- [x] Speed-Mapping §16.6: Mittelpunkt=Pause, ±4×, definierter 1×-Wert
      40960, monoton; ursprünglicher Implementierungsfehler korrigiert
- [x] UniversePlan: kollisionsfreie Bereiche je Node, Überschneidung =
      Blocker, Preflight (§16.2)
- [ ] Fixture-Verkabelung: Fixture-Engine an Art-Net-Receiver und
      Parameter-Engine anbinden (Layer-Komposition je Universe)
- [ ] Patchverwaltung + Patch-Export mit Node-ID/Universe (§16.2)
- [ ] Kanalliste-Export (CSV existiert; PDF/GDTF folgt in Phase 4 Rest)

## Nächste drei Aufgaben

1. Fixture-Verkabelung: Art-Net-Receiver → Master32/Layer64-Engines →
   Parameter-Engine (8 Layer je Universe, §16.2)
2. Patch-Verwaltung: Zuordnung Layer→Fixture-Adresse, Export-Format
3. Phase 5 vorbereiten: Frontend-Scaffold (ADR-0006 React vs. Svelte)

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