phase 1 runtime complete

docs/ARCHITECTURE_RESILIENCE_REVIEW.md

@@ -6,7 +6,7 @@ Phase checklist:
 
 - [x] Define subsystem boundaries and target architecture
 - [ ] Introduce an internal event model
-- [ ] Split `RuntimeHost`
+- [x] Split `RuntimeHost`
 - [ ] Make the render thread the sole GL owner
 - [ ] Refactor live state layering into an explicit composition model
 - [ ] Move persistence onto a background snapshot writer
@@ -32,9 +32,9 @@ Those points are important because they affect not just average performance, but
 
 ## Key Findings
 
-### 1. `RuntimeHost` is carrying too many responsibilities
+### 1. The original runtime host carried too many responsibilities
 
-`RuntimeHost` currently acts as:
+The original `RuntimeHost` acted as:
 
 - config store
 - persistent state store
@@ -47,7 +47,7 @@ That makes it a single contention and failure domain. It is also why OSC and ren
 
 Relevant code:
 
-- [RuntimeHost.h](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/runtime/legacy/RuntimeHost.h:15)
+- `RuntimeHost.h`
 
 Recommended direction:
 
@@ -258,7 +258,7 @@ Recommended direction:
 
 Relevant code:
 
-- [RuntimeHost.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/runtime/legacy/RuntimeHost.cpp:1841)
+- `RuntimeHost.cpp`
 
 Recent OSC work already reduced this problem for live automation, but the broader architecture would still benefit from:
 
@@ -365,7 +365,7 @@ Status:
 
 - Design deliverable: complete.
 - Compatibility seams in code: partially complete and expanding.
-- Target boundary extraction: not complete; remaining work is tracked by later phases, especially the event model, `RuntimeHost` split, render ownership, and persistence work.
+- Target boundary extraction: not complete across the whole app; remaining work is tracked by later phases, especially the event model, render ownership, and persistence work.
 
 Target split:
 
@@ -453,9 +453,9 @@ Suggested outcome:
 
 - the app stops relying on “shared object plus mutex plus polling” as the default coordination pattern
 
-### Phase 3. Split `RuntimeHost` into persistent state, render snapshot state, and service-facing coordination
+### Phase 3. Finish live-state and service-facing coordination
 
-After the event model exists, break apart `RuntimeHost`.
+After the event model exists, finish separating live committed state and service-facing coordination from the runtime facades.
 
 Recommended split:
 
@@ -628,7 +628,7 @@ If this is approached as a serious architecture program rather than opportunisti
 
 1. Define subsystem boundaries and target architecture.
 2. Introduce the internal event model.
-3. Split `RuntimeHost`.
+3. Finish runtime live-state/service coordination.
 4. Make the render thread the sole GL owner.
 5. Formalize live state layering and composition.
 6. Move persistence to a background snapshot writer.
@@ -647,7 +647,7 @@ This order tries to avoid doing foundational work twice.
 
 ## Short Version
 
-The app is in a much better place than it was before the OSC timing work, but the main remaining architectural risk is still shared ownership. Too many responsibilities converge on `RuntimeHost` and the shared GL path. The most sensible path forward is:
+The app is in a much better place than it was before the OSC timing work, but the main remaining architectural risk is still shared ownership around the shared GL path. The most sensible path forward is:
 
 1. define boundaries
 2. establish an event model