75ca88ddbe
- 10 Generatoren mit Manifest + HLSL + GLSL + GLES je Plugin: solid, gradient, checker_grid, stripes_chaser, noise_clouds (AQ Octaves 2/3/5), plasma, wave_bars, shapes, drops_ripples, starfield (AQ 32/128/512 Partikel) - 14 Filter mit Manifest + Shader je Backend: transform2d (keine AQ-Geometriereduktion), color_adjust, gradient_map, blur_sharpen (separabel 2-Pass, AQ 5/9/17 Samples), pixelate_quantize, mirror_tile, kaleidoscope, wave_displace (Noise adaptiv, Amount unverändert), rgb_split, glow_bloom (Kaskade 2/4/8), edge_emboss, vignette, strobe_pulse (Safety clamp 2 Hz, nie durch DMX allein freischaltbar), feedback_trails (Double-Buffer, Clear-Trigger, §15.3) - Uniform-Vertrag §14.4 in allen 75 Shadern; Generatoren sampeln nie u_input_texture; alle Filter mit mix-0-Bypass (§15.3) - 195 parametrisierte Plugin-Tests: Manifest/Backends/DMX-Slots<=8/ AQ>=3 Varianten/Uniform-Satz/Vollstaendigkeit exakt 10+14 - Nachtraegliche Manifest-Fixes: AQ-Bloecke fuer 4 1-Pass-Filter, mix-Parameter fuer feedback_trails (Slot-Overlap vermieden) - Gesamtsuite 506 gruen, Ruff gruen
6.6 KiB
6.6 KiB
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 logundTEST_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 0001–0003
- 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 (plattformneutral abgeschlossen, ADR-0008):
- 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 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):
- Domänenmodell: Project/Composition/Layer/Source/EffectInstance/ MediaAsset/OutputSurface/PresetScene mit Validierungen (§10.1)
- 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)
- 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)
- Servergruppen + Zielrouting: All/Node/Output/Group, Zielregeln selected/tag_query/all, Commit-Vorschau (§6.3, §10.1, §17.5)
- Clock-Offset-/Drift-Messung: RTT-Min-Filter (≤2× Min), Drift erst ab 1 s Fenster, Showzeit→lokale-Zeit-Abbildung (§6.4)
- zeitgestempelte Preset-Aktivierung: Vorlauf 200 ms, Arm/Execute/ Ack, FAILED bei fehlender Arm-Bestätigung (§6.5)
- 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 (im Bau):
- Plugin-Lifecycle-Manager: Zustandsgraph discovered→validated→ installed→enabled→compiled→active mit quarantined/incompatible, Show-Lock-Schutz (§14.5, §14.6, §26.3), Versionsupdate-Zyklus
- 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
- 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
- SDK-Dokumentation (docs/plugin-sdk/) und Beispielplugin-Anleitung
- Backend-Adapter-Vertrag: Shader-Loader-Schnittstelle für D3D11/GL/ GLES (Rust-Renderkern, ADR-0004)
- Golden-Image-Tests-Infrastruktur (Vorbereitung, Ausführung auf Windows-Hardware)
Nächste drei Aufgaben
- SDK-Dokumentation (docs/plugin-sdk/) mit Beispielplugin-Anleitung
- Phase 4: Art-Net-Fixture-Vollverhalten (Master32/Layer64, §16.3/§16.4)
- Renderer-Backend-Adapter-Vertrag: Shader-Loader für D3D11/GL/GLES
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).