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

Phase 6 step 1
All checks were successful
CI / React UI Build (push) Successful in 10s
Details
CI / Native Windows Build And Tests (push) Successful in 2m40s
Details
CI / Windows Release Package (push) Successful in 2m47s
Details

Browse Source
This commit is contained in:
Aiden
2026-05-11 19:44:35 +10:00
parent a91cc91a21
commit 68503256dc
7 changed files with 79 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/PHASE_6_BACKGROUND_PERSISTENCE_DESIGN.md
View File

@@ -7,15 +7,16 @@ Phases 1-5 separate durable state, coordination policy, render-facing snapshots,
## Status
- Phase 6 design package: proposed.
- Phase 6 implementation: not started.
- 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.
- Phase 6 implementation: Step 1 complete.
- Current alignment: `RuntimeStore` owns durable serialization, config, package metadata, preset IO, and persistence requests; `CommittedLiveState` owns the current committed/session layer state; and `RuntimeCoordinator` publishes typed persistence requests 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, 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.
- `RuntimeEventType::RuntimePersistenceRequested` now carries a `PersistenceRequest`.
- `PersistenceRequest` and `PersistenceSnapshot` name the request/snapshot contract that later steps will hand to the writer.
- 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
@@ -183,9 +184,16 @@ Make request types and event payloads explicit enough that callers stop thinking
Initial target:
- keep existing coordinator persistence decisions
- introduce a `PersistenceRequest`/`PersistenceSnapshot` shape
- document which requests are debounceable
- [x] keep existing coordinator persistence decisions
- [x] introduce a `PersistenceRequest`/`PersistenceSnapshot` shape
- [x] document which requests are debounceable
Current implementation:
- `runtime/persistence/PersistenceRequest.h` defines `PersistenceTargetKind`, `PersistenceRequest`, and `PersistenceSnapshot`.
- `RuntimePersistenceRequestedEvent` carries a typed `PersistenceRequest`.
- `RuntimeCoordinator` emits runtime-state persistence requests with reason, debounce key, and debounce policy.
- Existing synchronous save behavior is intentionally unchanged until Step 2/3.
### Step 2. Extract Snapshot Writing From `RuntimeStore`