Finished phase 1

docs/subsystems/RuntimeCoordinator.md

@@ -6,9 +6,9 @@ This document defines the target design for the `RuntimeCoordinator` subsystem i
 
 ## Why This Subsystem Exists
 
-Today the app's mutation path is split across several places:
+Before the Phase 1 runtime split, the app's mutation path was split across several places:
 
-- `RuntimeHost` performs validation, mutation, persistence, render-state invalidation, and some status updates:
+- `RuntimeHost` performed validation, mutation, persistence, render-state invalidation, and some status updates:
   - `RuntimeHost.h`
   - `RuntimeHost.cpp`
 - `OpenGLComposite` currently acts like an orchestration shell and a mutation coordinator at the same time:
@@ -58,7 +58,7 @@ Examples:
 - whether a trigger should update committed state, transient state, or both
 - whether a structural change should preserve compatible transient state such as feedback buffers
 
-This is the main policy surface that is currently spread between `RuntimeHost` methods such as:
+This is the policy surface that used to be spread between `RuntimeHost` methods such as:
 
 - `AddLayer(...)`
 - `SetLayerShader(...)`
@@ -246,7 +246,7 @@ Typical interaction:
 
 This is the coordinator's primary logical domain.
 
-Even if the implementation initially stores committed live state inside `RuntimeHost` or later inside `RuntimeStore`, the coordinator should be considered the policy owner of:
+Even while committed live state is physically stored inside `RuntimeStore`, the coordinator should be considered the policy owner of:
 
 - current layer stack composition
 - current selected shaders
@@ -316,7 +316,7 @@ The coordinator likely needs collaborators conceptually equivalent to:
 - `IRuntimeStore`
 - `IRuntimeSnapshotProvider`
 - `IHealthTelemetry`
-- later, a compatibility shim for still-existing `RuntimeHost` behavior during migration
+- compatibility adapters only where older call shapes still need to be supported during migration
 
 ### Mutation result shape
 
@@ -357,7 +357,7 @@ Methods like:
 
 currently do this pattern:
 
-1. call `RuntimeHost` mutation
+1. call a host/store mutation directly
 2. decide whether to call `ReloadShader(...)`
 3. call `broadcastRuntimeState()`
 
@@ -365,9 +365,9 @@ See [OpenGLCompositeRuntimeControls.cpp](/c:/Users/Aiden/Documents/GitHub/video-
 
 That "call host, then decide reload/broadcast policy" logic is a direct candidate for migration into `RuntimeCoordinator`.
 
-### `RuntimeHost`
+### Previous `RuntimeHost`
 
-`RuntimeHost` currently combines:
+`RuntimeHost` previously combined:
 
 - mutation validation
 - state mutation
@@ -375,7 +375,7 @@ That "call host, then decide reload/broadcast policy" logic is a direct candidat
 - persistence writes
 - render-state dirty marking
 
-Examples in `RuntimeHost.cpp`:
+Examples from the old `RuntimeHost.cpp`:
 
 - `AddLayer(...)`
 - `SetLayerShader(...)`
@@ -452,14 +452,14 @@ The coordinator should be introduced incrementally.
 
 Introduce typed mutation request/result objects without changing most internals yet.
 
-### Step 2. Wrap current `RuntimeHost` mutations behind coordinator entrypoints
+### Step 2. Wrap direct runtime mutations behind coordinator entrypoints
 
-The first implementation can still delegate heavily into `RuntimeHost`, but the call sites should stop deciding policy on their own.
+The first implementation could still delegate heavily into existing runtime mutation paths, but the call sites should stop deciding policy on their own.
 
 For example, instead of:
 
 1. `OpenGLComposite::AddLayer()`
-2. `RuntimeHost::AddLayer()`
+2. direct layer-add mutation
 3. `ReloadShader(true)`
 4. `broadcastRuntimeState()`
 
@@ -470,7 +470,7 @@ the flow becomes:
 3. coordinator returns a result describing snapshot, reset, and persistence needs
 4. composition root dispatches those downstream effects
 
-### Step 3. Move validation and classification out of `RuntimeHost`
+### Step 3. Move validation and classification out of direct mutation helpers
 
 Once coordinator entrypoints are stable, pull up:
 
@@ -480,9 +480,9 @@ Once coordinator entrypoints are stable, pull up:
 
 while leaving raw store operations in place.
 
-### Step 4. Narrow `RuntimeHost` into store and snapshot collaborators
+### Step 4. Split storage and snapshot collaborators
 
-Only after the coordinator is clearly owning policy should `RuntimeHost` be split into real target subsystems.
+Only after the coordinator is clearly owning policy should storage and snapshot responsibilities be split into real target subsystems.
 
 ## Key Risks
 
@@ -498,7 +498,7 @@ Mitigation:
 
 ### Risk 2. Call sites bypass coordinator during migration
 
-If new code continues calling `RuntimeHost` directly for convenience, the architecture will fork into two policy systems.
+If new code bypasses `RuntimeCoordinator` for convenience, the architecture will fork into two policy systems.
 
 Mitigation: