Step 6
Some checks failed
CI / React UI Build (push) Successful in 11s
CI / Native Windows Build And Tests (push) Successful in 2m43s
CI / Windows Release Package (push) Has been cancelled

This commit is contained in:
Aiden
2026-05-11 19:25:29 +10:00
parent 79855d788c
commit d332dceb5b
9 changed files with 78 additions and 74 deletions

View File

@@ -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?