Jan/Infinity_Vis_Rust
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
Infinity_Vis_Rust/docs/qwen14b_handoff.md

10 KiB
Raw Permalink 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:

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

Wo der Arbeitsfortschritt festgehalten ist

Die wichtigsten Fortschrittsanker liegen hier:

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

  1. Zuerst relevante Docs lesen, nicht direkt Code uminterpretieren.
  2. Dann Contract-Tests und Golden-Replays als Schutzplanken ansehen.
  3. Danach gezielt nur in der betroffenen Schicht arbeiten:
    • Pattern-/Runtime-Logik: crates/infinity_host/
    • API-Vertrag: crates/infinity_host_api/
    • Operator-UI: web/v1/
  4. 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
Reference in New Issue View Git Blame Copy Permalink