Finished phase 1

docs/subsystems/RuntimeStore.md

@@ -2,7 +2,7 @@
 
 This document expands the `RuntimeStore` portion of [PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md) into a subsystem-specific design note.
 
-The purpose of `RuntimeStore` is to give the Phase 1 target architecture one clear home for durable runtime data. In the current codebase, that responsibility is spread through `RuntimeHost`, where persistence, mutation entrypoints, render-state building, shader metadata access, and status reporting all share the same object and lock domain. `RuntimeStore` is the design boundary that separates "what the app knows and saves" from "how the app decides to mutate it" and "how rendering consumes it."
+The purpose of `RuntimeStore` is to give the Phase 1 target architecture one clear home for durable runtime data. Before the Phase 1 runtime split, that responsibility was spread through `RuntimeHost`, where persistence, mutation entrypoints, render-state building, shader metadata access, and status reporting all shared the same object and lock domain. `RuntimeStore` is the design boundary that separates "what the app knows and saves" from "how the app decides to mutate it" and "how rendering consumes it."
 
 ## Role In The Phase 1 Architecture
 
@@ -259,7 +259,7 @@ This implies:
 - that mutex should protect durable models only
 - render-facing consumers should eventually read via `RuntimeSnapshotProvider`, not by reaching into the store
 
-One of the main goals here is reducing the current situation where `RuntimeHost` lock scope effectively mixes:
+One of the main goals here is avoiding the old situation where runtime lock scope effectively mixed:
 
 - persistent state
 - status reporting
@@ -296,9 +296,9 @@ The store may emit errors or return result objects, but it should not coordinate
 
 ## Current Code Mapping
 
-Today, `RuntimeHost` contains most of the responsibilities that should move into `RuntimeStore`.
+Before the Phase 1 runtime split, `RuntimeHost` contained many responsibilities that needed to move into `RuntimeStore` or adjacent runtime collaborators.
 
-Key current code paths:
+Previous code paths:
 
 - config load:
   - `RuntimeHost.cpp`
@@ -318,7 +318,7 @@ Key current code paths:
   - `RuntimeHost.cpp`
   - `RuntimeHost.cpp`
 
-Durable-state mutation entrypoints that currently live on `RuntimeHost` but conceptually split between coordinator and store:
+Durable-state mutation entrypoints that previously lived on `RuntimeHost` but conceptually split between coordinator and store:
 
 - layer stack edits:
   - `AddLayer`
@@ -336,7 +336,7 @@ The target split should be:
 - validation/policy/orchestration -> `RuntimeCoordinator`
 - durable state write application -> `RuntimeStore`
 
-Methods that should not move into `RuntimeStore` even though they currently live on `RuntimeHost`:
+Methods that were intentionally not moved into `RuntimeStore` because they belong under other runtime subsystems:
 
 - render-state building and caching:
   - `GetLayerRenderStates`
@@ -361,7 +361,7 @@ Those belong under other target subsystems.
 - `RuntimeConfigStore`
   - runtime host config load and resolved paths
 
-The current codebase has begun this split: `RuntimeConfigStore` owns config parsing, path resolution, configured ports/formats, runtime roots, and shader compiler paths, while `RuntimeStore` keeps compatibility delegates for existing callers.
+The current codebase has completed this part of the split: `RuntimeConfigStore` owns config parsing, path resolution, configured ports/formats, runtime roots, and shader compiler paths, while `RuntimeStore` exposes compatibility-shaped delegates for existing callers.
 - `LayerStackStore`
   - durable layer stack and parameter values
   - layer CRUD/reorder and shader selection
@@ -378,13 +378,13 @@ The current codebase has begun this split: `RuntimeConfigStore` owns config pars
 - `PersistenceWriter` helper
   - synchronous at first, async/debounced later
 
-The current codebase has begun the layer split: `LayerStackStore` owns durable layer state, layer CRUD/reorder, parameter persistence, and stack preset value serialization/load. `RuntimeStore` still owns locking, file IO, and compatibility delegates for existing callers.
+The current codebase has completed the layer split: `LayerStackStore` owns durable layer state, layer CRUD/reorder, parameter persistence, and stack preset value serialization/load. `RuntimeStore` keeps file IO and facade methods for existing callers.
 
-The current codebase has begun the render snapshot split: `RenderSnapshotBuilder` owns render-state assembly, cached parameter refresh, dynamic frame-field refresh, and render snapshot versions. `RuntimeSnapshotProvider` depends on this builder rather than on `RuntimeStore` friendship.
+The current codebase has completed the render snapshot split: `RenderSnapshotBuilder` owns render-state assembly, cached parameter refresh, dynamic frame-field refresh, and render snapshot versions. `RuntimeSnapshotProvider` depends on this builder rather than on `RuntimeStore` friendship.
 
-The current codebase has also begun the presentation split: `RuntimeStatePresenter` owns top-level runtime-state JSON assembly, while `RuntimeStateJson` owns the layer-stack and parameter presentation shape used by runtime state clients.
+The current codebase has also completed the presentation split: `RuntimeStatePresenter` owns top-level runtime-state JSON assembly, while `RuntimeStateJson` owns the layer-stack and parameter presentation shape used by runtime state clients.
 
-The current codebase has also begun the package split: `ShaderPackageCatalog` owns package scanning and registry comparison, while `RuntimeStore` uses it to keep layer state valid and to build compatibility read models.
+The current codebase has also completed the package split: `ShaderPackageCatalog` owns package scanning and registry comparison, while `RuntimeStore` uses it to keep layer state valid and to build compatibility read models.
 
 These can still be presented through one subsystem façade during migration.
 
@@ -413,7 +413,7 @@ The safest migration path is to extract responsibilities by interface, not by bi
 
 ### Step 1: Introduce The `RuntimeStore` Name And Facade
 
-Create a façade interface that wraps the durable-data parts of `RuntimeHost`.
+Create a facade interface for the durable-data parts that used to live in `RuntimeHost`.
 
 Initial likely contents:
 
@@ -422,7 +422,7 @@ Initial likely contents:
 - preset load/save access
 - package catalog read access
 
-This stage is now past the initial compatibility point: `RuntimeStore` owns its durable/session backing fields directly rather than wrapping a `RuntimeHost` object.
+This stage is complete: `RuntimeStore` owns its durable/session backing fields directly rather than wrapping a `RuntimeHost` object.
 
 ### Step 2: Move Pure Persistence Helpers First
 
@@ -587,4 +587,4 @@ It should not answer:
 - how hardware pacing should work
 - what health warnings should be emitted
 
-If this boundary holds, later phases can safely split `RuntimeHost` without just recreating the same coupling under a different class name.
+If this boundary holds, later phases can continue without recreating the old coupling under a different class name.