Phase 1: IPC-Verbindungsschicht + Build-first-Strategie (ADR-0008)

- 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

STATUS.md

@@ -1,40 +1,77 @@
 # STATUS
 
-Stand: 2026-09-10
+Stand: 2026-09-11
 
 ## Aktuelle Phase
 
-**Phase 0 – technischer Spike und Go/No-Go** (PLAN.md §31, §36)
+**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
 
-- 0922cc1 – Phase-0-Grundlage: 121 Unit-/Integrationstests grün, Ruff grün (Belege: `TEST_REPORT.md`)
+- 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 ist offen**
+- 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
 
-Erster Arbeitsauftrag (§36 Nr. 1–3 erledigt, Nr. 4–15 in Arbeit):
+Phase 0 (abgeschlossen, soweit ohne Hardware möglich):
 
-- [x] Repository gemäß Eigentumsgrenzen initialisiert (§8)
-- [x] Pflichtdokumente + ADR-Vorlage + ADRs 0001–0003 angelegt
-- [x] GStreamer-Version für Windows gepinnt: **1.28.6** (`build/windows/GSTREAMER.md`, ADR-0002)
-- [x] Kernpakete mit Unit-Tests: IPC-Protokoll (§6.2), Parameter-Engine (§11), Art-Net-Pakete/Empfänger (§16), Adaptive Quality (§5.2), Capability-Probe (§5.2), Plugin-SDK-Validierung (§14.5, §27.2)
-- [x] Minimaler Control Core: FastAPI-REST + WebSocket für denselben Parametersatz (§36 Nr. 9)
-- [x] Renderer-Spike: D3D11-/Dev-GL-Pipeline-Definitionen + CLI (§36 Nr. 4–5); ohne GStreamer-Installation kontrollierter Abbruch (Exit-Code 2), keine Erfolgssimulation (§33)
-- [x] Beispielplugin Passthrough (HLSL + GLSL + GLES) als SDK-Referenz (§36 Nr. 6)
-- [x] Tools: Art-Net-Emulator, Capability-Probe, Plugin/Shader-Validator
+- [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. **Gate-0-Messungen auf Referenz-Windows-Hardware:** D3D11-Hardwaredecode, durchgängiger `D3D11Memory`-Pfad ohne CPU-Readback, Framezeit p99, DMX-Latenz (≤ 2 Frames), ruckelfreier Adaptive-Quality-Wechsel (§25, §36 Nr. 11)
-2. Portable Onefolder-Ausgabe erzeugen und auf sauberem Windows-Rechner testen (Nuitka vs. PyInstaller → ADR; §36 Nr. 12–13)
-3. Nativen Renderkern festlegen (Rust vs. C++, Bridge vs. GStreamer-Plugin → ADR-0004) und Renderer über IPC-Handshake an die Parameter-Engine anbinden (Phase 1)
+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
 
-- **Keine Windows-Referenzhardware in der Entwicklungsumgebung** (Linux-Container, CPU-only). Alle Gate-0-Kriterien sind ausschließlich auf echter Hardware gültig (§29.7, §33). Spike-Code ist bereit; Messungen und Portabilitätstest stehen aus.
-- pnpm/Node-Frontend noch nicht eingerichtet (Phase 5, ADR-0006 offen).
-- HLSL-Live-Parameter im D3D11-Pfad erfordert den nativen Renderkern (ADR-0004 offen); GLSL-Testvariante für den Dev-Pfad liegt bei.
+- 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).