Der minimale GUI-Vertical-Slice ist jetzt als eigenes Crate umgesetzt. Die Desktop-App liegt in crates/infinity_host_ui/src/main.rs und crates/infinity_host_ui/src/app.rs: lokales Fenster per eframe, globale Controls für Blackout, Master Brightness und Pattern, eine 6-Node-Übersicht, die 18er Mapping-Tabelle mit Node, top/middle/bottom, physischem Output/Kanal, 106 LEDs, direction, color_order, enable_flag, plus Walk 106-Testtrigger pro Panel und einen Status-/Event-Bereich für online/offline, letzter Kontakt und Fehlerstatus.

Damit die UI sauber getrennt bleibt, habe ich infinity_host zu einer wiederverwendbaren Core-Schicht ausgebaut: crates/infinity_host/src/lib.rs, control.rs und mock.rs definieren Snapshot-/Command-Typen und einen Mock-Simulationsdienst mit Hintergrundthread. Die UI pollt nur Snapshots über HostUiPort; sie treibt keine Realtime-Logik. Den Workspace und die Build-Hinweise habe ich in Cargo.toml, README.md und docs/build_and_deploy.md ergänzt.

Verifikation war hier nur eingeschränkt möglich: cargo und rustc sind in dieser Umgebung nicht installiert, daher konnte ich die App nicht kompilieren oder starten. Der nächste sinnvolle Schritt wäre erst nach deinem Go, den vorhandenen HostUiPort statt des Mock-Backends an echten Transportstatus anzubinden.

docs/architecture.md

@@ -11,6 +11,7 @@ Build a live-capable LED control platform that keeps realtime output determinist
    - Presets and topology editing
    - Monitoring and diagnostics
    - Never the timing master for LED output
+   - First vertical slice is implemented as `crates/infinity_host_ui`
 2. Realtime engine
    - Owns the monotonic clock
    - Computes scene state, transitions, and dirty regions
@@ -78,8 +79,7 @@ The codebase deliberately blocks activation when these remain unresolved:
 
 ## Planned Next Steps
 
-1. Add the actual UI adapter on top of `infinity_host`
+1. Expand the new UI slice from mock service to real host transport adapters
 2. Implement UDP transport with separate control and realtime sockets
 3. Connect firmware driver backends after hardware validation
 4. Add deterministic effect registry shared between host planning and firmware capability negotiation
-