aiden/video-shader-toys
1
0
Fork 0
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

11
docs/PHASE_6_BACKGROUND_PERSISTENCE_DESIGN.md
View File

@@ -8,15 +8,15 @@ Phases 1-5 separate durable state, coordination policy, render-facing snapshots,
- Phase 6 design package: proposed.
- Phase 6 implementation: not started.
- Current alignment: `RuntimeStore` owns durable state and serialization, while `RuntimeCoordinator` already publishes explicit persistence-request outcomes for persisted mutations. The remaining issue is that actual disk writes are still synchronous store work rather than queued, debounced, atomic background writes.
- Current alignment: `RuntimeStore` owns durable serialization, config, package metadata, preset IO, and persistence requests; `CommittedLiveState` owns the current committed/session layer state; and `RuntimeCoordinator` already publishes explicit persistence-request outcomes for persisted mutations. The remaining issue is that actual disk writes are still synchronous store work rather than queued, debounced, atomic background writes.
Current persistence footholds:
- `RuntimeStore` owns persistent runtime-state serialization and stack preset serialization.
- `LayerStackStore` owns durable layer and parameter state.
- `RuntimeStore` owns persistent runtime-state serialization, stack preset serialization, and durable file IO.
- `CommittedLiveState` owns current committed/session layer and parameter state.
- `RuntimeCoordinatorResult::persistenceRequested` exists as an explicit mutation outcome.
- `RuntimeEventType::RuntimePersistenceRequested` exists as the event-level persistence request.
- Phase 5 is expected to clarify which live-state mutations are durable, committed-live, or transient.
- Phase 5 clarified which live-state mutations are durable, committed-live, transient automation, or render-local. Settled OSC commits are session-only by default and do not request persistence.
## Why Phase 6 Exists
@@ -61,7 +61,7 @@ Phase 6 should make persistence a small pipeline:
```text
RuntimeCoordinator accepts mutation
-> publishes/returns persistence request
-> PersistenceWriter captures a durable snapshot
-> PersistenceWriter captures a durable snapshot from RuntimeStore serialization
-> background worker debounces/coalesces writes
-> atomic write commits file
-> HealthTelemetry/runtime event records success or failure
@@ -70,6 +70,7 @@ RuntimeCoordinator accepts mutation
The key rule is:
- `RuntimeStore` owns durable state and serialization
- `CommittedLiveState` owns current session state; only coordinator-approved durable snapshots should be persisted
- `PersistenceWriter` owns when and how snapshots are written
- `RuntimeCoordinator` owns whether a mutation requests persistence