Finished phase 1

docs/ARCHITECTURE_RESILIENCE_REVIEW.md

@@ -15,8 +15,8 @@ Phase checklist:
 
 Checklist note:
 
-- The checked Phase 1 item means the subsystem vocabulary, dependency direction, state categories, and design package are in place.
-- It does not mean the target boundaries are fully extracted in code. The current implementation has Phase 1 compatibility seams, while the full ownership split continues through later phases.
+- The checked Phase 1 item means the subsystem vocabulary, dependency direction, state categories, design package, and runtime implementation foothold are in place.
+- It does not mean the whole app is fully extracted. Eventing, sole-owner render threading, live-state layering, background persistence, backend lifecycle, and richer telemetry continue through later phases.
 
 ## Timing Review
 
@@ -125,7 +125,7 @@ Recommended direction:
 
 The current design works better now, but it still relies on hand-managed reconciliation between:
 
-- persisted parameter state in `RuntimeHost`
+- persisted/committed parameter state in `RuntimeStore`
 - transient OSC overlay state in `RenderEngine`
 
 Relevant code:
@@ -293,7 +293,7 @@ Add lightweight tracing for:
 - preroll depth versus spare-buffer depth
 - preview present cost and skipped-preview count
 - control queue depth
-- `RuntimeHost` lock contention
+- runtime state lock contention
 
 That would make future tuning and failure diagnosis much easier.
 
@@ -364,8 +364,8 @@ Before changing major internals, formalize the target responsibilities for each
 Status:
 
 - Design deliverable: complete.
-- Compatibility seams in code: partially complete and expanding.
-- 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.
+- Runtime implementation foothold: complete.
+- Target boundary extraction: not complete across the whole app; remaining work is tracked by later phases, especially the event model, render ownership, live-state layering, backend lifecycle, telemetry, and persistence work.
 
 Target split:
 
@@ -415,7 +415,7 @@ Suggested deliverables:
 
 Current implementation note:
 
-The repo now has concrete classes for the Phase 1 subsystem names and several call paths already route through them. These classes should be treated as migration boundaries, not proof that the target architecture is fully extracted.
+The repo now has concrete runtime classes, folders, read models, and subsystem tests for the Phase 1 names. These classes are the runtime foothold for later phases; app-wide extraction still continues around eventing, render ownership, backend lifecycle, persistence, and telemetry.
 
 ### Phase 2. Introduce an internal event model
 
@@ -503,7 +503,7 @@ Other threads should only:
 
 Why this phase comes here:
 
-- it is much safer once state access and control coordination are no longer centered on `RuntimeHost`
+- it is much safer once state access and control coordination are no longer centered on one shared runtime object
 - it avoids coupling the render-thread refactor to storage and service refactors at the same time
 
 Expected benefits:
@@ -552,7 +552,7 @@ Target behavior:
 Why this phase comes after state splitting:
 
 - otherwise persistence logic will need to be rewritten twice
-- it should operate on the new `RuntimeStore` model, not on the current mixed-responsibility object
+- it should operate on the new `RuntimeStore` model, not on a mixed-responsibility runtime object
 
 Expected benefits:
 
@@ -640,7 +640,7 @@ If this is approached as a serious architecture program rather than opportunisti
 This order tries to avoid doing foundational work twice.
 
 - The event model comes before major subsystem extraction so coordination patterns stabilize early.
-- `RuntimeHost` is split before render isolation so the render thread does not inherit the current monolithic state model.
+- runtime state ownership is split before render isolation so the render thread does not inherit a monolithic state model.
 - Live state layering is formalized only after render ownership is clearer.
 - Persistence is moved later so it can target the final state model rather than the current one.
 - Telemetry is intentionally late so it instruments the architecture that survives the refactor.