Step 6

docs/PHASE_5_LIVE_STATE_LAYERING_DESIGN.md

@@ -6,13 +6,14 @@ Phase 1 named the subsystems. Phase 2 added the typed event substrate. Phase 3 m
 
 ## Status
 
-- Phase 5 design package: proposed.
-- Phase 5 implementation: Step 5 complete.
+- Phase 5 design package: complete.
+- Phase 5 implementation: complete.
 - Current alignment: Phase 3 introduced the first pure composition boundary and transient OSC overlay owner. Phase 5 now has a small `RuntimeStateLayerModel` inventory that names the current state categories, `RenderStateComposer` consumes a `LayeredRenderStateInput` whose fields make base persisted, committed live, and transient automation inputs explicit, `RuntimeLiveState` owns transient-overlay invalidation against current layer/parameter compatibility, settled OSC commits have an explicit session-only persistence policy, and `CommittedLiveState` physically owns current session layer state. `RuntimeStore` still owns file IO, config, package metadata, preset persistence, and persistence requests.
 
 Current live-state footholds:
 
-- `RuntimeStore` owns persisted layer stack, parameter values, presets, config, and render snapshot read models.
+- `RuntimeStore` owns file IO, config, package metadata, preset persistence, persistent-state serialization, and persistence requests.
+- `CommittedLiveState` physically owns the current committed/session layer stack and parameter values.
 - `RuntimeCoordinator` owns mutation validation, classification, accepted/rejected event publication, snapshot/reload follow-ups, and the policy switch between committed states and live snapshots.
 - `RuntimeSnapshotProvider` publishes render-facing snapshots from committed runtime state.
 - `RuntimeLiveState` owns transient OSC overlay bookkeeping, smoothing, generation tracking, and commit-settlement policy.
@@ -66,8 +67,8 @@ Phase 5 should formalize three layers:
 
 | Layer | Owner | Lifetime | Persistence | Render role |
 | --- | --- | --- | --- | --- |
-| Base persisted state | `RuntimeStore` / `LayerStackStore` | survives restart | written to disk | default layer stack, shader selections, saved parameter values |
-| Committed live state | `RuntimeCoordinator` or a new live-session collaborator | current running session | may request persistence depending on mutation type | operator/UI/current truth until changed again |
+| Base persisted state | `RuntimeStore` plus durable serialization/preset IO | survives restart | written to disk | default saved layer stack, shader selections, saved parameter values |
+| Committed live state | `CommittedLiveState` with policy owned by `RuntimeCoordinator` | current running session | may request persistence depending on mutation type | operator/UI/current truth until changed again |
 | Transient automation overlay | `RuntimeLiveState` or a new automation overlay collaborator | high-rate/short-lived | not persisted directly | temporary OSC/automation target applied over committed truth |
 
 The target composition rule is:
@@ -190,7 +191,7 @@ Layering should use stable render-facing identity:
 - parameter id for shader-defined identity
 - parameter control key for external-control identity
 
-Phase 5 should document which identity is authoritative when layer id and control key disagree or when a shader changes.
+Current policy treats render-facing layer identity plus parameter/control-key compatibility as authoritative. Incompatible transient overlays are pruned before composition, so stale OSC routes do not migrate onto unrelated controls after layer removal, preset load, shader change, or incompatible reload.
 
 ### Invalidations
 
@@ -307,7 +308,7 @@ Current policy:
 
 ### Step 5. Separate Committed-Live Concept From Durable Storage
 
-Decide whether to physically split committed-live state now or introduce a read/model boundary first.
+Separate the committed-live concept from durable storage with both a physical owner and a read/model boundary.
 
 Earlier conservative option:
 
@@ -320,7 +321,7 @@ Stronger option:
 - [x] make `RuntimeSnapshotProvider` consume committed live state through a read model
 - [x] leave durable writes in `RuntimeStore`
 
-Phase 5 does not need a flag-day split. It needs the concept to stop being implicit.
+The implementation now has the stronger split while keeping `RuntimeStore` as the compatibility facade for existing callers.
 
 Current implementation:
 
@@ -334,10 +335,10 @@ Current implementation:
 
 Before calling Phase 5 complete, update:
 
-- architecture review checklist
-- `RuntimeCoordinator`, `RuntimeStore`, `RuntimeSnapshotProvider`, `RenderEngine`, and `ControlServices` subsystem docs
-- Phase 6 assumptions about persistence inputs
-- Phase 7 assumptions about what render/backend state is not part of live parameter layering
+- [x] architecture review checklist
+- [x] `RuntimeCoordinator`, `RuntimeStore`, `RuntimeSnapshotProvider`, `RenderEngine`, and `ControlServices` subsystem docs
+- [x] Phase 6 assumptions about persistence inputs
+- [x] Phase 7 assumptions about what render/backend state is not part of live parameter layering
 
 ## Testing Strategy
 
@@ -397,12 +398,11 @@ Phase 5 can be considered complete once the project can say:
 - [x] reset/reload/preset behavior for transient overlays is centralized or clearly delegated
 - [x] OSC overlay settle/commit behavior is explicit, including persistence policy
 - [x] `RuntimeStore` remains durable-state focused and does not absorb transient automation policy
-- [ ] render-local temporal/feedback state remains separate from live parameter layering
-- [ ] subsystem docs and the architecture review reflect the final ownership model
+- [x] render-local temporal/feedback state remains separate from live parameter layering
+- [x] subsystem docs and the architecture review reflect the final ownership model
 
 ## Open Questions
 
-- Should committed live state remain physically in `RuntimeStore` for now, or move to a `CommittedLiveState` collaborator?
 - Should transient OSC overlay updates become app-level typed events, or stay source-local through `RuntimeServiceLiveBridge`?
 - Should overlay commit persistence be global, ingress-specific, or parameter-definition-driven?
 - What compatibility rule should apply when shader reload preserves a control key but changes parameter shape?