aiden/video-shader-toys
1
0
Fork 1
Code Issues Pull Requests Actions Releases 5 Wiki Activity

Step 6
Some checks failed
CI / React UI Build (push) Successful in 11s
Details
CI / Native Windows Build And Tests (push) Successful in 2m43s
Details
CI / Windows Release Package (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Aiden
2026-05-11 19:25:29 +10:00
parent 79855d788c
commit d332dceb5b
9 changed files with 78 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/subsystems/RuntimeStore.md
View File

@@ -95,7 +95,7 @@ Those are coordinator concerns, not store concerns.
`RuntimeStore` should own the following state categories.
Phase 5 names this boundary in code through `RuntimeStateLayerModel`: persisted layer stack data, saved parameter values, and stack presets are classified as base persisted state. Operator/session values may still be backed by the store during migration, but their mutation policy is committed-live policy owned by the coordinator, not durable-store policy by default.
Phase 5 names this boundary in code through `RuntimeStateLayerModel`: persisted layer stack data, saved parameter values, and stack presets are classified as base persisted state. Operator/session values are owned by `CommittedLiveState`; their mutation policy is committed-live policy owned by the coordinator, not durable-store policy by default.
Phase 5 also adds `CommittedLiveState` as the physical owner of current session/operator layer state and `CommittedLiveStateReadModel` as the named read boundary for render snapshot publication. `RuntimeStore` still owns file IO, config, package metadata, preset persistence, and persistence requests, but it delegates current-session layer mutations to `CommittedLiveState`.
@@ -366,10 +366,14 @@ Those belong under other target subsystems.
- runtime host config load and resolved paths
The current codebase has completed this part of the split: `RuntimeConfigStore` owns config parsing, path resolution, configured ports/formats, runtime roots, and shader compiler paths, while `RuntimeStore` exposes compatibility-shaped delegates for existing callers.
- `CommittedLiveState`
- current committed/session layer stack and parameter values
- layer CRUD/reorder and shader selection for the running session
- committed-live read model for snapshot publication
- `LayerStackStore`
- durable layer stack and parameter values
- layer CRUD/reorder and shader selection
- stack preset value serialization/load
- backing layer stack mechanics used by committed-live state
- layer CRUD/reorder and shader selection helpers
- stack preset value serialization/load helpers
- `RuntimeStatePresenter` / `RuntimeStateJson`
- runtime-state JSON assembly
- layer-stack presentation serialization
@@ -382,7 +386,7 @@ The current codebase has completed this part of the split: `RuntimeConfigStore`
- `PersistenceWriter` helper
- synchronous at first, async/debounced later
The current codebase has completed the layer split: `LayerStackStore` owns durable layer state, layer CRUD/reorder, parameter persistence, and stack preset value serialization/load. `RuntimeStore` keeps file IO and facade methods for existing callers.
The current codebase has completed the committed-live split: `CommittedLiveState` owns current committed/session layer state using `LayerStackStore` backing mechanics. `RuntimeStore` keeps file IO, package metadata, persistence serialization, persistence requests, preset file access, and facade methods for existing callers.
The current codebase has completed the render snapshot split: `RenderSnapshotBuilder` owns render-state assembly, cached parameter refresh, dynamic frame-field refresh, and render snapshot versions. `RuntimeSnapshotProvider` depends on this builder rather than on `RuntimeStore` friendship.
@@ -536,16 +540,7 @@ Current recommendation:
- keep only durable reference/package metadata here
### 2. Should Committed Live State Be Co-Located With Persisted State?
The Phase 1 parent doc leaves open whether committed live state stays in the store or is split with a live companion model owned by the coordinator.
For `RuntimeStore`, the important rule is:
- if a piece of state is part of the durable truth model, the store should own it
- if it is transient or session-only, it should not be forced into the store just for convenience
### 3. Should Preset Application Be A Store Operation Or A Coordinator Operation?
### 2. Should Preset Application Be A Store Operation Or A Coordinator Operation?
The file load and preset parse clearly belong here.
@@ -556,7 +551,7 @@ Current recommendation:
- `RuntimeStore` loads preset content
- `RuntimeCoordinator` decides how to apply it
### 4. How Early Should Async Persistence Land?
### 3. How Early Should Async Persistence Land?
Phase 1 does not require it, but the store design should not block it.