Files

jan d2ca1a2aef Tighten web surfaces and clean handoff

2026-04-20 21:12:52 +02:00

10 KiB

Raw Blame History

Qwen 14B Handoff

Zweck

Diese Datei ist die schnelle Uebergabe fuer ein kleineres Modell wie Qwen 14B. Sie soll den aktuellen Projektstand, die stabile Architekturgrenze und die naechsten sicheren Arbeitspfade kompakt erklaeren, ohne dass zuerst das ganze Repo rekonstruiert werden muss.

Aktueller Stand

Host-Core ist die zentrale Runtime und bleibt die einzige Kernarchitektur.
API v1 ist die verbindliche Aussenkante fuer State, Preview, Snapshot, Catalog, Commands und Event-Stream.
Die Creative Surface lebt in web/v1/ und ist die operatorische Web-Oberflaeche.
Die Technical Surface in web/v1/technical.html plus web/v1/technical.js ist die aktuelle technische Web-Oberflaeche.
Die Desktop-GUI in crates/infinity_host_ui/ existiert weiter als technische Engineering-/Diagnoseflaeche, ist aber nicht der primaere aktuelle UI-Arbeitspfad.
Persistenz, Recovery und Runtime-Show-Store sind vorhanden.
Show-Control-v1-Primitive sind faktisch eingefroren und dokumentiert.
Ein generischer externer Control-Pfad ist vorhanden, aber bewusst nicht grandMA-spezifisch.

Frisch umgesetzt in dieser Arbeitsphase

Creative Surface wurde kompakter gemacht, damit alle 18 Panels im 3x6-Raster gleichzeitig sichtbar bleiben.
Preview- und normale Pattern-Wirkung wurden diskreter gemacht:
- Preview-Ziel im Host liegt jetzt bei bis zu 60 Hz.
- Normale Preview-/Pattern-Helligkeit ist auf 10%-Stufen quantisiert.
- Preview-Updates und WebSocket-Preview-Frames werden nur noch bei inhaltlicher Aenderung weitergeschoben.
Die feste WS2812-Palette wurde in Host und Web-UI hinterlegt; alte freie/abweichende Palettennamen wurden ersetzt.
Globaler Master-Brightness sitzt nur noch im Header; redundante globale Brightness-Bedienung links ist entfernt.
Die Technical Surface ist robuster gegen unvollstaendige Snapshots, insbesondere fehlende recent_events.
Fuer Codex gibt es jetzt einen lokalen Route-/Browser-Smoke-Runner:
- scripts/codex_browser_smoke.sh
- prueft /, /technical und /technical.js gegen eine frische Kurzinstanz
- ersetzt noch keinen vollgerenderten Headless-Browser mit DOM-Interaktion

Lokale Umgebung auf diesem Rechner

Arbeitsverzeichnis des Rust-Projekts: /home/jan/Documents/RFP/Infinity_Vis_Rust
Dieses Repo ist hier ein echter Git-Clone mit .git.
Rust-Toolchain ist lokal vorhanden:
- cargo 1.95.0 (f2d3ce0bd 2026-03-21)
- rustc 1.95.0 (59807616e 2026-04-14)
Gewuenschte Toolchain laut rust-toolchain.toml:
- Channel: stable
- Components: rustfmt, clippy
Laufzeitpersistenz liegt standardmaessig in data/runtime_state.json
Das alte Python-Referenzprojekt soll lokal daneben liegen unter:
- /home/jan/Documents/RFP/RFP_Infinity-Vis

Lokaler Startpfad

Aus dem Rust-Repo heraus:

. "$HOME/.cargo/env"
cargo run -p infinity_host_api -- --config config/project.example.toml --bind 127.0.0.1:9001 --runtime-state data/runtime_state.json

Danach:

Creative Surface: http://127.0.0.1:9001/
Technical Surface: http://127.0.0.1:9001/technical
State API: http://127.0.0.1:9001/api/v1/state
Preview API: http://127.0.0.1:9001/api/v1/preview
WebSocket: ws://127.0.0.1:9001/api/v1/stream

Nicht neu interpretieren

Diese Grenzen sind verbindlich:

keine neue Parallelarchitektur neben Host-Core plus API
keine direkte grandMA-Kopplung in den Kern
keine Hardwarevalidierung als Hauptfokus
Creative Surface bleibt kreative/operatorische Oberflaeche
Desktop-GUI oder Technical Surface bleibt technische Betriebsoberflaeche

Wenn Verhalten unklar ist, gilt:

erst alte Referenz dokumentarisch vergleichen
dann an bestehende Host-/API-Semantik anpassen
nicht stillschweigend neue Bedienlogik erfinden

Wo der Arbeitsfortschritt festgehalten ist

Die wichtigsten Fortschrittsanker liegen hier:

README.md Der Einstieg, grobe Struktur und verlinkte Referenzdokumente.
docs/show_control_primitives.md Die stabile interne Show-Control-v1-Semantik inklusive staged/direct-Trennung, Fehlercodes und Event-Auswirkungen.
docs/pattern_matrix_v1.md Alter Python-Bezug versus neue Host-Pattern-IDs, Parameterbasis und UI-Arbeitsmodi.
docs/external_control_bridge.md Zielbild und Regeln fuer die generische externe Steuerkante.
docs/control_ownership.md Konflikt- und Ownership-Regeln zwischen Web-UI, technischer GUI und externen Control-Quellen.
docs/local_software_only_runbook.md Reproduzierbarer software-only Startpfad.
docs/codex_worklog.md Knapper Verlauf der letzten Codex-Arbeitspakete inklusive Tests, Abweichungen und lokalen Smoke-Checks.
crates/infinity_host/tests/show_control_v1_golden.rs Golden-Trace- und Replay-Schutz fuer die zentrale v1-Semantik.
Git-Historie:
- a56cecb Software-only show-control readiness baseline
- 07c52db Stabilize control surface and external bridge v1

Projektstruktur

crates/infinity_host/ Kernruntime, Simulation, Show-Store, Pattern-Logik, externe Control-Semantik.
crates/infinity_host_api/ HTTP- und WebSocket-API v1, DTO-Mapping, Contract-Tests.
crates/infinity_host_ui/ Desktop-Engineering-Oberflaeche fuer technische Konfiguration und Diagnose.
crates/infinity_config/ Projektkonfiguration und Validierung.
crates/infinity_protocol/ Gemeinsame Protokoll- und Modelltypen.
web/v1/ Creative Surface und Technical Surface im Browser.
docs/ Architektur-, Runbook-, Ownership-, Pattern- und API-Dokumentation.
scripts/ Kleine Starthelfer fuer lokalen software-only Betrieb.
data/runtime_state.json Laufzeitpersistenz fuer Host-State, Runtime-Presets, Gruppen und Snapshots.

Wichtigste Dateien nach Thema

Host und Semantik

API

Web-UI

Was aktuell als stabil gelten soll

API v1 nach aussen nicht unkoordiniert brechen.
Show-Control-v1-Primitive nicht still veraendern.
Fehlercodes und Event-Semantik nicht neu mischen.
Test/Edit bleibt direkt.
Show/Event bleibt staged plus Commit ueber Go oder Fade Go.
Preview-Only und Offline-Status ehrlich anzeigen, keine Fake-Nodes.
Creative Surface nicht mit technischen Mapping-Details ueberladen.
Technical Surface muss gegen partielle/startende State-Snapshots robust bleiben.

Sichere Arbeitsreihenfolge fuer weitere Aenderungen

Zuerst relevante Docs lesen, nicht direkt Code uminterpretieren.
Dann Contract-Tests und Golden-Replays als Schutzplanken ansehen.
Danach gezielt nur in der betroffenen Schicht arbeiten:
- Pattern-/Runtime-Logik: crates/infinity_host/
- API-Vertrag: crates/infinity_host_api/
- Operator-UI: web/v1/
Danach passende Tests laufen lassen.

Empfohlene Minimalpruefungen

. "$HOME/.cargo/env"
cargo test -q -p infinity_host
cargo test -q -p infinity_host_api --test contract
scripts/codex_browser_smoke.sh 9012

Fuer lokalen software-only Start:

. "$HOME/.cargo/env"
cargo run -p infinity_host_api -- --config config/project.example.toml --bind 127.0.0.1:9001 --runtime-state data/runtime_state.json

Offene Vorsichtspunkte

Das alte Python-Projekt ist derzeit nicht lokal neben dem Repo ausgecheckt. Fuer echte 1:1-Conformance-Vergleiche sollte es bewusst lokal daneben geklont werden.
Das Runbook enthaelt noch einen veralteten Hinweis aus der frueheren Arbeitsbaum-Phase; aktuell ist das Repo wieder ein echter Git-Clone mit .git.
Die grosse Pattern-Conformance gegen das alte Python-Projekt ist noch nicht vollstaendig als separater, systematischer Abgleich abgeschlossen.
Ein echter gerenderter Headless-Browser-Runner mit DOM-Interaktion ist lokal noch nicht sauber eingerichtet; vorhanden ist aktuell nur der Route-/Asset-Smoke ueber scripts/codex_browser_smoke.sh.

Kurzbriefing fuer das naechste Modell

Wenn du dieses Projekt weiterbearbeitest:

halte Host-Core plus API als einzige Grundarchitektur stabil
behandle die bestehende Show-Control-v1-Semantik als Aussenkante
nimm das alte Python-Projekt als Primarreferenz fuer UX und Pattern-Verhalten, nicht fuer technische Architektur
veraendere diskrete UI-Controls, Fehlercodes oder staged/direct-Semantik nicht stillschweigend
bevor du groessere UI- oder Pattern-Aenderungen machst, vergleiche erst gegen die vorhandenen Docs und Tests

10 KiB Raw Blame History