93 lines
2.9 KiB
Markdown
93 lines
2.9 KiB
Markdown
# Control Ownership
|
|
|
|
## Ziel
|
|
|
|
Diese Regeln definieren die konfliktfreie Steuersemantik zwischen allen aktuellen und spaeteren Control-Quellen auf derselben Host-Core-v1-Aussenkante.
|
|
|
|
Betroffene Quellen:
|
|
|
|
- kreative Web-UI
|
|
- technische Desktop-GUI
|
|
- generischer externer Control-Adapter
|
|
- spaetere grandMA-Anbindung
|
|
|
|
## Gemeinsame Grundregel
|
|
|
|
Der Host-Core bleibt die einzige mutierende Autoritaet fuer Show-State.
|
|
|
|
Keine Quelle darf:
|
|
|
|
- intern an Simulation-, Persistenz- oder UI-Zustaende vorbeischreiben
|
|
- eigene Sonderpfade fuer Pattern-, Preset-, Group- oder Transition-Logik einziehen
|
|
- die LED-Taktung oder Timing-Autoritaet uebernehmen
|
|
|
|
## Rollen
|
|
|
|
### Web-UI
|
|
|
|
- kreative Oberflaeche
|
|
- darf direkte Primitive und lokale staged Sessions benutzen
|
|
- staged Zustand bleibt lokal, bis `trigger_transition` explizit committed wird
|
|
|
|
### technische Desktop-GUI
|
|
|
|
- Engineering- und Diagnoseoberflaeche
|
|
- bevorzugt direkte Operationen, Beobachtung und Admin-Aktionen
|
|
- bekommt keine priorisierte Besitzrolle gegenueber anderen Quellen
|
|
|
|
### externer Control-Adapter
|
|
|
|
- darf nur auf die eingefrorene v1-Primitive-Semantik abbilden
|
|
- staged Sessions muessen pro externer Session sauber getrennt gehalten werden
|
|
- Fehlercodes aus dem Host werden unveraendert durchgereicht
|
|
|
|
### spaetere grandMA-Anbindung
|
|
|
|
- ist spaeter nur eine weitere Quelle auf derselben Bridge-/Primitive-Aussenkante
|
|
- bekommt keine Sonderrechte gegenueber Web-UI, GUI oder anderen Adaptern
|
|
|
|
## Konfliktregeln
|
|
|
|
### Direkte Operationen
|
|
|
|
- direkte Primitive mutieren sofort den globalen Host-State
|
|
- letzte erfolgreich ausgefuehrte Mutation gewinnt
|
|
- dazu gehoeren insbesondere:
|
|
- `blackout`
|
|
- `recall_preset`
|
|
- `recall_creative_snapshot`
|
|
- `set_master_brightness`
|
|
- `upsert_group`
|
|
|
|
### Staged Operationen
|
|
|
|
- staged Primitive mutieren den globalen Host-State nicht sofort
|
|
- staged Zustand gehoert immer nur zur lokalen Session der jeweiligen Quelle
|
|
- staged Sessions duerfen parallel existieren
|
|
- staged Inhalt wird erst mit `trigger_transition` global wirksam
|
|
|
|
### Commit-Verhalten
|
|
|
|
- `trigger_transition` ist der einzige Commit-Punkt fuer staged Pattern-/Parameter-/Transition-Intents
|
|
- ein erfolgreicher Commit konsumiert nur die staged Session der commitenden Quelle
|
|
- andere offene Sessions bleiben unveraendert bestehen
|
|
|
|
### Beobachtung
|
|
|
|
- `request_snapshot` und State-Projektionen sind read-only
|
|
- Beobachtung erzeugt keinen Ownership-Anspruch auf den Show-State
|
|
|
|
## Praktische Auswirkungen
|
|
|
|
- es gibt aktuell kein verteiltes Locking zwischen Quellen
|
|
- konfliktfreie Zusammenarbeit entsteht ueber:
|
|
- identische Primitive-Semantik
|
|
- lokale Session-Isolation fuer staged Flows
|
|
- last-write-wins fuer direkte globale Mutationen
|
|
- explizite Commits statt impliziter Side Effects
|
|
|
|
## Persistenz
|
|
|
|
- nur global wirksame Host-Mutationen und Persistenz-Kommandos beeinflussen Runtime-State-Dateien
|
|
- uncommittete staged Sessions sind absichtlich nicht Teil des globalen Persistenzzustands
|