Step 6
This commit is contained in:
@@ -80,7 +80,7 @@ The coordinator decides which state category a mutation affects:
|
||||
|
||||
The design rule is that classification belongs here, not in the ingress layer and not in render code.
|
||||
|
||||
Phase 5 has started codifying the shared vocabulary for this classification in `RuntimeStateLayerModel`. The current model records committed session parameter values, layer bypass state, and runtime compile/reload flags as committed-live/session coordination state, even though some of those values are still physically backed by `RuntimeStore` during migration.
|
||||
Phase 5 codifies the shared vocabulary for this classification in `RuntimeStateLayerModel`. Current committed session parameter values and layer bypass state are committed-live/session state owned by `CommittedLiveState`; runtime compile/reload flags are coordination state rather than durable store truth.
|
||||
|
||||
### 4. Snapshot publication requests
|
||||
|
||||
@@ -248,13 +248,15 @@ Typical interaction:
|
||||
|
||||
This is the coordinator's primary logical domain.
|
||||
|
||||
Even while committed live state is physically stored inside `RuntimeStore`, the coordinator should be considered the policy owner of:
|
||||
The coordinator is the policy owner of:
|
||||
|
||||
- current layer stack composition
|
||||
- current selected shaders
|
||||
- current bypass flags
|
||||
- current operator-authored parameter values
|
||||
|
||||
`CommittedLiveState` is the physical owner for this current-session layer state. `RuntimeStore` persists or skips disk writes according to coordinator policy and remains the compatibility facade for existing mutation call shapes.
|
||||
|
||||
### Transient live overlay state
|
||||
|
||||
The coordinator defines the rules for transient state, but should not become the long-term storage owner for render-local transient data.
|
||||
@@ -534,7 +536,6 @@ Mitigation:
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should committed live state remain physically stored in `RuntimeStore`, or should the coordinator gain a live-session companion object before Phase 3?
|
||||
- Should preset load/save stay synchronous through early migration, or should the coordinator always treat them as policy requests whose persistence effects may complete later?
|
||||
- Should reload requests be modeled as a dedicated mutation class distinct from ordinary control mutations from the start?
|
||||
- How much normalization of parameter values should remain in store-side helpers versus moving into coordinator policy helpers?
|
||||
|
||||
Reference in New Issue
Block a user