phase 1 runtime complete

docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md

@@ -1,6 +1,6 @@
 # Phase 1 Design: Subsystem Boundaries and Target Architecture
 
-This document expands Phase 1 of [ARCHITECTURE_RESILIENCE_REVIEW.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/ARCHITECTURE_RESILIENCE_REVIEW.md) into a concrete target design. Its purpose is to define the long-term subsystem split before later phases introduce a full event model, split `RuntimeHost`, and move rendering onto a sole-owner render thread.
+This document expands Phase 1 of [ARCHITECTURE_RESILIENCE_REVIEW.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/ARCHITECTURE_RESILIENCE_REVIEW.md) into a concrete target design. Its purpose is to define the long-term subsystem split before later phases introduce a full event model and move rendering onto a sole-owner render thread.
 
 The main goal of Phase 1 is not to immediately rewrite the app. It is to establish clear ownership boundaries so later refactors all move toward the same architecture instead of solving local problems in conflicting ways.
 
@@ -9,15 +9,15 @@ The main goal of Phase 1 is not to immediately rewrite the app. It is to establi
 Phase 1 has two different meanings in this repo, and they should not be collapsed:
 
 - Phase 1 design package: complete.
-- Phase 1 target extraction in code: in progress.
+- Phase 1 runtime target extraction in code: largely complete.
 
-The completed design package includes the agreed subsystem names, responsibilities, dependency rules, state categories, and current-to-target migration map. The codebase also has concrete compatibility seams for those subsystems. That is different from saying every target boundary is fully extracted: several subsystems still delegate through compatibility helpers, and later roadmap phases are still responsible for the event model, remaining `RuntimeHost` split, sole-owner render thread, explicit live-state layering, background persistence, backend state machine, and fuller telemetry.
+The completed design package includes the agreed subsystem names, responsibilities, dependency rules, state categories, and current-to-target migration map. The runtime code now has concrete subsystem folders and collaborators for those boundaries. That is different from saying every target boundary is fully extracted across the whole app: later roadmap phases are still responsible for the event model, sole-owner render thread, explicit live-state layering, background persistence, backend state machine, and fuller telemetry.
 
 ## Why Phase 1 Exists
 
-Today the app works, but too many responsibilities still converge in a few places:
+At the start of this phase the app worked, but too many responsibilities converged in a few places:
 
-- `RuntimeHost` owns persistence, live layer state, shader package access, status reporting, and mutation entrypoints.
+- `RuntimeHost` owned persistence, live layer state, shader package access, status reporting, and mutation entrypoints.
 - `OpenGLComposite` coordinates runtime setup, render state retrieval, shader rebuild handling, transient OSC overlay behavior, and video backend integration.
 - DeckLink callback-driven playout still reaches directly into render-facing work.
 - Background services rely on polling and shared mutable state more than explicit subsystem contracts.
@@ -54,9 +54,9 @@ This phase is the target design and the dependency rules. Later phases perform t
 
 The following current code paths are the strongest evidence for the split proposed here:
 
-- `RuntimeHost` is both store and live authority:
-  - [RuntimeHost.h](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/runtime/legacy/RuntimeHost.h:15)
-  - [RuntimeHost.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/runtime/legacy/RuntimeHost.cpp:726)
+- `RuntimeHost` was both store and live authority:
+  - `RuntimeHost.h`
+  - `RuntimeHost.cpp`
 - `OpenGLComposite` is both app orchestrator and render/runtime coordinator:
   - [OpenGLComposite.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/OpenGLComposite.cpp:106)
   - [OpenGLComposite.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/OpenGLComposite.cpp:283)
@@ -575,7 +575,7 @@ Core responsibilities:
 
 This is not a one-to-one rename plan. It is a responsibility migration map.
 
-### Current `RuntimeHost`
+### Previous `RuntimeHost`
 
 Should eventually split across:
 
@@ -635,7 +635,7 @@ Likely examples:
 
 As later phases begin, these rules should be treated as guardrails.
 
-### 1. No new cross-cutting state should be added to `RuntimeHost`
+### 1. No new cross-cutting runtime object should be introduced
 
 If a new feature needs durable state, place it conceptually under `RuntimeStore`.
 If it needs render-local transient state, place it conceptually under `RenderEngine`.
@@ -664,7 +664,7 @@ Phase 1 is a design phase, but it should support incremental migration.
 Recommended order after this document:
 
 1. Introduce names and interfaces before moving logic.
-2. Create compatibility adapters around `RuntimeHost` rather than forcing a flag day.
+2. Create compatibility adapters around the subsystem facades rather than forcing a flag day.
 3. Move read-only render snapshot publication out before moving all mutation logic.
 4. Move service ingress boundaries out before removing the old polling shell.
 5. Isolate timing/health setters from the core store as early as practical.
@@ -679,7 +679,7 @@ Phase 1 can reasonably be considered complete once the project has:
 - agreed subsystem names and responsibilities
 - agreed allowed dependency directions
 - explicit state categories: persisted, committed live, transient overlay, health/timing
-- a current-to-target responsibility map for `RuntimeHost`, `RuntimeServices`, `OpenGLComposite`, and backend/render bridge code
+- a current-to-target responsibility map for runtime services, `OpenGLComposite`, and backend/render bridge code
 - a decision that later phases will build against this target rather than inventing new boundaries ad hoc
 
 By that definition, the Phase 1 design deliverable is complete. The implementation should still be described as partially extracted until the compatibility backing objects and cross-subsystem shims are removed.