# Architekturüberblick (Phase 0)

Verbindliche Referenz: `PLAN.md`. Diese Seite fasst Prozess- und Besitzgrenzen zusammen.

## Prozesse (§6.1)

| Prozess | Technologie | Aufgabe |
| --- | --- | --- |
| Launcher/Supervisor | Python (Phase 1) | Start, Portwahl, portable Pfade, Heartbeat, kontrolliertes Beenden |
| Control Core | Python, asyncio, FastAPI, Pydantic, SQLite/WAL (ab Phase 1) | autoritativer Zustand, REST/WS, Art-Net, Persistenz |
| Render Worker | Python-Orchestrator + GStreamer + nativer Renderkern (ADR-0004 offen) | Decode, GPU-Compositing, Ausgabe, Telemetrie |
| Web-Frontend | TypeScript, Vite (Phase 5, ADR-0006 offen) | Bedienoberfläche; niemals Videoausgang (§3.2) |

## Besitzgrenzen (§8)

- Jedes Paket hat eindeutige `hms_*`-Namen; kein Quereinbau zwischen `packages/*`.
- Control Core und Renderer verbinden ausschließlich über das versionierte IPC (ADR-0003).
- Der Renderer erhält pro Frame einen unveränderlichen Parametersnapshot (§11.4).

## Kernregeln (§33, Auszug)

- Python steuert, decodiert nicht und rendert keine Pixel.
- Windows: D3D11Memory durchgängig; kein CPU-Rundweg im Normalpfad.
- Plugins: versioniertes Manifest, kein Datei-/DB-Zugriff, Quarantäne bei Fehler.
- Alle Steuerquellen (Browser, Art-Net, später Timeline/Audio/KI) laufen über die zentrale Parameter-Engine.

## Steuerfluss Phase 0

```text
Lichtpult/Emulator → ArtDMX (UDP 6454) → hms_artnet.receiver
    → Control Core (hms_parameter.engine: Priorität CONSOLE)
    → IPC-Snapshot → Renderer (GStreamer-D3D11) → Opacity/Parameter an Frame-Grenze

Browser → REST/WebSocket → derselbe Command-/Parameter-Pfad (Priorität WEB)
```

Beide Quellen adressieren denselben Parametersatz; es gibt genau eine autoritative Instanz (Control Core).

## Phase-0-Spike

`hms_renderer` definiert die Pipelines als Launch-Strings; Ausführung und Messung erfolgen auf Referenz-Windows-Hardware (Gate 0). Messprotokoll: `TEST_REPORT.md`.