sdlc 1.0 release plan
State: open/draft · Genre: plan
Overview
Section titled “Overview”The path to sdlc 1.0 is SDF-first, with no fake services. The adoption wizard and operator screens are built directly in SDF (the Nuxt-in-Tauri desktop app) and read real repositories through the real APIs. Test repositories (M-V9RR) carry starter data in the formats the backend stores, so a screen is real from its first day. Each milestone runs the same loop: decide the stored format and build the read API, seed starter data, build the screen, then add the write side. Each release ships the backend together with the screen that shows it. Current public release: v0.8.0. Roadmap: sdlc 1.0 (see the roadmap entity linked to this note).
Releases
Section titled “Releases”| Release | Milestone | Delivers | Backend in the same release |
|---|---|---|---|
| v0.9.0 | M-YX34 | SDF shared on the web, with planning views | A headless SDF server that serves the built front end; the capability containment rule in the audit |
| v0.10.0 | M-FMVX | sdlc usable with nested projects; no SDF screen | Multi-root task lookup, task start, one worktree root |
| v0.11.0 | M-V9RR | Test repositories with starter data; story screenshots | A generator for the test repositories; the whole-app fixture mode removed; wizard sections keep per-section mocks until built |
| v0.12.0 | M-DZ6T | System overview | none |
| v0.13.0 | M-KJFH | Adopt flow | Apply modes in the setup action; a real drift report |
| v0.14.0 | M-0M28 | Checks and judgement | Standard enforcement and severity_floor with per-source filtering in verify changes; verify modes; drop-in step directories in resolveLayeredSteps; sdlc extend list |
| v0.15.0 | M-EG9L | Routing and steering | profiles: and routing: keys, resolveProfile, model and effort through headlessArgv, routing in the work tick |
| v0.16.0 | M-K7C0 | Config explorer | Config explain provenance for the filesystem layer |
| v0.17.0 | M-2QAE | Record | Journal (lib/services/journal, sdlc journal append/tail, automatic op.start and op.end), run and friction kinds, retro aggregation proposals |
| v0.18.0 | M-GX7X | Secure execution environment: wizard section 11, on Zoo | A sandbox policy in sdlc.yaml; Zoo as a session host; dispatch refusing sandboxed work when no sandbox is available |
| v0.19.0 | M-UVX0 | A model for planning roots; no screen | Workspace and PlanningRoot; ops receive the model in place of a path string |
| v0.20.0 | M-011K | Several repositories in one SDF server; project switcher and views that span roots | An actor per planning root; a tree API for roots; focus per tab |
| v1.0.0 | to be added | Every screen running on a real repository; release basics (binary, npm, marketplace, per-harness install tests, docs, sdlc config migrate) | Contract inventory and versioning; the compatibility promise |
Each milestone is its own release. A milestone that grows too large is split, and the releases after it are renumbered.
How each milestone runs
Section titled “How each milestone runs”The same loop, per milestone. Decided 2026-10-03, replacing the fixture-first loop (sketch on a fake transport, hammer out, derive, release).
- Stored format. Decide how the milestone’s data is stored: an entity kind, a file in the
corpus, a key in
sdlc.yaml. The parked foundation specs are the starting point, revised against what the screen needs. - Read API. Build the CLI op and the SDF route that return it, with generated transport additions through ontogen codegen.
- Starter data. Add starter files in that format to the test repositories (M-V9RR).
- Screen. Build the screen against the real API. The owner and the session iterate on it until the shape settles; a change to what a screen shows can mean a change to the stored format, and choices that settle become decision entities.
- Write side. Build whatever produces the data in real use, writing the same format.
- Release. The milestone closes when its screens run on a real repository and the version is tagged.
The screens sketched on a fake transport in #2533 are kept as the starting point for step 4 and rewired to the real API. Example data passed straight into a component in a Storybook story is component testing and stays.
The adoption wizard is the one exception to “no fake services” (owner, 2026-10-03). It is complete in the app ahead of its backing implementation, to show potential customers: a section reads the real API where one exists and a mock where it does not. Each release replaces one section’s mocks. Tracked in N-YQVC-master-consolidation.
Milestones overlap: one milestone’s format and read API can start while the previous one is in its screen step.