Phase 5 step 5

docs/PHASE_5_LIVE_STATE_LAYERING_DESIGN.md

@@ -7,8 +7,8 @@ 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 4 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, and settled OSC commits have an explicit session-only persistence policy. Committed runtime values are still physically stored through `RuntimeStore`/`LayerStackStore`.
+- Phase 5 implementation: Step 5 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 snapshot publication consumes a named `CommittedLiveStateReadModel`. Committed runtime values are still physically backed by `RuntimeStore`/`LayerStackStore` during this conservative migration step.
 
 Current live-state footholds:
 
@@ -21,6 +21,7 @@ Current live-state footholds:
 - `RuntimeStateLayerModel` names the Phase 5 state categories and classifies current fields as base persisted, committed live, transient automation, render-local, or health/config state.
 - `RuntimeCoordinator` can request layer-scoped transient OSC invalidation, while `RuntimeLiveState` prunes overlays that no longer map to the current render-facing layer/parameter definitions.
 - `RuntimeCoordinator::CommitOscParameterByControlKey(...)` commits settled OSC values into session state without requesting persistence by default.
+- `CommittedLiveStateReadModel` names the current committed/session read boundary that feeds render snapshot publication while remaining physically backed by `RuntimeStore`.
 
 ## Why Phase 5 Exists
 
@@ -310,9 +311,9 @@ Decide whether to physically split committed-live state now or introduce a read/
 
 Conservative option:
 
-- leave storage physically in `RuntimeStore`
-- add a named committed-live read model
-- keep persistence decisions in `RuntimeCoordinator`
+- [x] leave storage physically in `RuntimeStore`
+- [x] add a named committed-live read model
+- [x] keep persistence decisions in `RuntimeCoordinator`
 
 Stronger option:
 
@@ -322,6 +323,13 @@ Stronger option:
 
 Phase 5 does not need a flag-day split. It needs the concept to stop being implicit.
 
+Current implementation:
+
+- `CommittedLiveStateReadModel` carries the current committed/session layer stack and shader package metadata used by snapshot publication.
+- `RenderSnapshotReadModel` contains `committedLiveState` rather than exposing layer-stack fields directly.
+- `RenderSnapshotBuilder` builds render snapshots and parameter refreshes from committed-live read APIs.
+- `RuntimeStore` still provides the physical backing during this phase, but session-only committed changes can be observed through the committed-live read model without requiring durable persistence.
+
 ### Step 6. Update Docs And Exit Criteria
 
 Before calling Phase 5 complete, update:
@@ -388,7 +396,7 @@ Phase 5 can be considered complete once the project can say:
 - [x] `RenderStateComposer` or its replacement consumes a layered input contract
 - [x] reset/reload/preset behavior for transient overlays is centralized or clearly delegated
 - [x] OSC overlay settle/commit behavior is explicit, including persistence policy
-- [ ] `RuntimeStore` remains durable-state focused and does not absorb transient automation 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
 

docs/subsystems/RenderEngine.md

@@ -113,6 +113,8 @@ Phase 5's `RuntimeStateLayerModel` explicitly keeps temporal history, feedback s
 
 `RuntimeLiveState` now owns transient automation invalidation for render-facing compatibility. It can clear overlays for a target layer/control key and prunes overlays that no longer resolve to the current layer and parameter definitions before applying them to a frame. This keeps shader reload, preset load, and layer removal behavior local to the live-state/composition boundary instead of scattering it through GL drawing code.
 
+Render snapshots now flow through a named `CommittedLiveStateReadModel`, so render-facing committed state is distinct from durable storage even while both are physically backed by the same store during migration.
+
 ### 5. Shader Build Application
 
 Compilation itself may eventually move into a separate build service, but once shader build outputs exist, `RenderEngine` owns:

docs/subsystems/RuntimeCoordinator.md

@@ -274,6 +274,8 @@ For OSC specifically, the coordinator should eventually decide:
 
 Phase 5 sets the default settled OSC policy to session-only. `CommitOscParameterByControlKey(...)` updates committed session state through the store with persistence disabled, publishes ordinary mutation/state-change observations, and does not request a persistence write unless a future explicit policy opts into durable OSC commits.
 
+The committed-live concept now has a named read model, `CommittedLiveStateReadModel`. The coordinator remains the owner of whether a mutation should be durable or session-only, while `RuntimeStore` temporarily backs the read model until a physical `CommittedLiveState` collaborator is worth extracting.
+
 ### Health and timing state
 
 The coordinator may emit events like:

docs/subsystems/RuntimeStore.md

@@ -97,6 +97,8 @@ Those are coordinator concerns, not store concerns.
 
 Phase 5 names this boundary in code through `RuntimeStateLayerModel`: persisted layer stack data, saved parameter values, and stack presets are classified as base persisted state. Operator/session values may still be backed by the store during migration, but their mutation policy is committed-live policy owned by the coordinator, not durable-store policy by default.
 
+Phase 5 also adds `CommittedLiveStateReadModel` as the named read boundary for current session/operator state. During the conservative migration, `RuntimeStore` still backs that model physically, but snapshot publication consumes the committed-live read model rather than treating render-facing state as raw durable storage.
+
 ### Runtime Configuration
 
 Examples: