# 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