Finished phase 1

docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md

@@ -9,9 +9,9 @@ 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 runtime target extraction in code: largely complete.
+- Phase 1 runtime implementation foothold: complete.
 
-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.
+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, collaborators, read models, and tests for those boundaries, and the compiled runtime path no longer depends on `RuntimeHost`. 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
 
@@ -97,7 +97,7 @@ This document is the parent note for the Phase 1 subsystem package. The bundle i
 
 ## Current Implementation Foothold
 
-The codebase now has an initial Phase 1 compatibility split in place:
+The codebase now has a Phase 1 runtime implementation foothold in place:
 
 - `RuntimeStore`
   - [RuntimeStore.h](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/runtime/store/RuntimeStore.h)
@@ -130,7 +130,7 @@ The codebase now has an initial Phase 1 compatibility split in place:
   - [VideoBackend.h](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/videoio/VideoBackend.h)
   - [VideoBackend.cpp](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/videoio/VideoBackend.cpp)
 
-These are still compatibility seams, not a completed subsystem extraction. Some responsibilities have moved behind the new boundaries, while other paths still delegate through compatibility helpers, `OpenGLComposite`, `DeckLinkSession`, and the existing bridge/pipeline classes. Their purpose is to give later work real code boundaries that can be expanded without first inventing the names:
+The runtime seams are now concrete code boundaries. Some app-level flows still delegate through compatibility helpers, `OpenGLComposite`, `DeckLinkSession`, and the existing bridge/pipeline classes, but runtime responsibilities have moved behind named collaborators:
 
 - UI/runtime control calls in `OpenGLCompositeRuntimeControls.cpp` now route through `RuntimeCoordinator`
 - runtime startup now initializes path resolution and config loading through `RuntimeConfigStore`, with shader package scan and lookup delegated to `ShaderPackageCatalog`
@@ -159,13 +159,17 @@ These are still compatibility seams, not a completed subsystem extraction. Some
 - `OpenGLComposite` now owns a `RenderEngine` seam for renderer, pipeline, render-pass, and shader-program responsibilities
 - `OpenGLComposite` now owns a `VideoBackend` seam for device/session ownership and callback wiring
 - `OpenGLVideoIOBridge` now acts as an explicit compatibility adapter between `VideoBackend` and `RenderEngine`, instead of `OpenGLComposite` directly owning both sides
+- `RuntimeSubsystemTests` now cover the new runtime seams around layer-stack storage, preset round-trips, mutation classification, and runtime-state JSON serialization
 
-That means the next extraction work can focus on moving responsibility behind these seams instead of first inventing them.
+That means Phase 2 can focus on eventing and coordination mechanics rather than inventing the runtime boundary vocabulary.
 
-Remaining extraction work includes:
+Later-phase extraction work includes:
 
 - moving persistence to an asynchronous writer in a later phase
 - replacing polling/shared-object coordination with the planned internal event model
+- making the render thread the sole GL owner
+- formalizing committed-live versus transient-overlay layering
+- making backend lifecycle and telemetry richer and more explicit
 
 ## Subsystem Responsibilities
 
@@ -586,7 +590,8 @@ Should eventually split across:
 
 Likely examples:
 
-- config loading/saving -> `RuntimeStore`
+- config loading/path resolution -> `RuntimeConfigStore`
+- persistent state saving -> `RuntimeStore`
 - layer stack mutation validation -> `RuntimeCoordinator`
 - render state building/versioning -> `RenderSnapshotBuilder`
 - render snapshot publication/cache -> `RuntimeSnapshotProvider`
@@ -682,7 +687,7 @@ Phase 1 can reasonably be considered complete once the project has:
 - 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.
+By that definition, Phase 1 is complete for runtime: the design package is complete, `RuntimeHost` is retired from the compiled runtime path, runtime seams are represented in code, and runtime subsystem tests cover the new boundaries. App-wide ownership work continues in later phases.
 
 ## Open Questions For Later Phases