63 lines
3.9 KiB
Markdown
63 lines
3.9 KiB
Markdown
# Phase 1 Subsystem Design Index
|
|
|
|
This directory contains the subsystem-specific design notes for Phase 1 of the architecture roadmap.
|
|
|
|
Start here if you want the Phase 1 package to read as one coherent deliverable rather than as separate subsystem writeups.
|
|
|
|
Parent documents:
|
|
|
|
- [Architecture Resilience Review](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/ARCHITECTURE_RESILIENCE_REVIEW.md)
|
|
- [Phase 1: Subsystem Boundaries and Target Architecture](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md)
|
|
|
|
## How This Set Fits Together
|
|
|
|
- [PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md) defines the top-level subsystem split, dependency rules, state categories, and migration guardrails.
|
|
- The notes in this directory expand each subsystem boundary without changing the parent Phase 1 design.
|
|
- The subsystem notes are meant to be read as design companions, not as independent alternate architectures.
|
|
|
|
## Recommended Reading Order
|
|
|
|
1. [PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/PHASE_1_SUBSYSTEM_BOUNDARIES_DESIGN.md)
|
|
2. [RuntimeStore.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RuntimeStore.md)
|
|
3. [RuntimeCoordinator.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RuntimeCoordinator.md)
|
|
4. [RuntimeSnapshotProvider.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RuntimeSnapshotProvider.md)
|
|
5. [ControlServices.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/ControlServices.md)
|
|
6. [RenderEngine.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RenderEngine.md)
|
|
7. [VideoBackend.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/VideoBackend.md)
|
|
8. [HealthTelemetry.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/HealthTelemetry.md)
|
|
|
|
That order mirrors the intended dependency story:
|
|
|
|
- durable state first
|
|
- mutation and publication next
|
|
- ingress and render boundaries after that
|
|
- device timing and operational visibility last
|
|
|
|
## Subsystem Notes
|
|
|
|
- [RuntimeStore.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RuntimeStore.md)
|
|
Durable runtime config, persisted layer state, presets, and package metadata ownership.
|
|
- [RuntimeCoordinator.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RuntimeCoordinator.md)
|
|
Mutation validation, state classification, reset/reload policy, and publication/persistence requests.
|
|
- [RuntimeSnapshotProvider.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RuntimeSnapshotProvider.md)
|
|
Render-facing snapshot build, publication, and versioning boundaries.
|
|
- [ControlServices.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/ControlServices.md)
|
|
OSC, HTTP/WebSocket, and file-watch ingress plus normalization and service-local buffering.
|
|
- [RenderEngine.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/RenderEngine.md)
|
|
Sole-owner render/GL boundary, render-local transient state, preview, and playout-ready frame production.
|
|
- [VideoBackend.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/VideoBackend.md)
|
|
Device lifecycle, input/output pacing, buffer policy, and producer/consumer playout direction.
|
|
- [HealthTelemetry.md](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/docs/subsystems/HealthTelemetry.md)
|
|
Logs, warnings, counters, timing traces, and subsystem health snapshots.
|
|
|
|
## What Phase 1 Should Settle
|
|
|
|
Phase 1 should leave the project with:
|
|
|
|
- one agreed subsystem vocabulary
|
|
- one agreed dependency direction map
|
|
- one agreed state-category model
|
|
- one agreed current-to-target migration story
|
|
|
|
Phase 1 does not need to settle every later implementation detail. The subsystem notes intentionally leave some questions open where later phases need room to choose concrete mechanics.
|