Ontological control-plane plan
State: open/active · Genre: plan
Status: Draft, 2026-09-30. This plan succeeds the SDLC 0.8 release campaign and its older SDLC 1.0 successor draft. The checkable sequence is RM-0RYV; the product direction and longer horizon remain in N-41AZ-vision.
Why the old 1.0 plan changes
Section titled “Why the old 1.0 plan changes”The earlier SDLC 1.0 plan described finishing and publishing the Bun/Node product as v1.0.0,
with its first public release at the end of the campaign, through sksizer/marketplace-sdlc.
That release sequence was overtaken: the revised campaign shipped SDLC v0.4.0 through v0.8.0
from sksizer/sdlc, and the v0.8.0 changelog records the product campaign as complete.
D-P3NF-sksizer-sdlc-is-product-home remains the product-home decision.
The useful next direction is the one now described in N-41AZ-vision: Ontological as the control plane, SDF as its operator app, and Foreman as its domain-blind engine. This plan does not set a new public version or release date. It carries forward the older plan’s durable practices — checkable milestones, task-level evidence, deterministic checks followed by judgment and review, and resumable work records — where they still fit.
The 0.8 record is reconciled
Section titled “The 0.8 record is reconciled”The 0.8 records were reconciled on 2026-09-30, task by task, against code, merged PRs, and the
changelog (N-RH55-sdlc-0-8-release-reconciliation). Of RM-E2L0’s 19 milestones, 18
are closed and M-E0U5 stays open. Tags v0.4.0, v0.7.0, and v0.8.0 are public
on sksizer/sdlc. The open items are a product maintenance track in RM-0RYV, not a stage of
this plan.
First: nested projects
Section titled “First: nested projects”M-FMVX ships before stage 1, as v0.10.0 of RM-DO9Z. sdlc
0.8 assumes one project per repository, and this repo’s nested solutions/determined project can’t
run its tasks through sdlc. The milestone is the narrow fix: multi-root task lookup, task start,
and one worktree root. It is shaped so stage 1’s planning_roots work (M-ZLTF) can replace its
root discovery.
Delivery sequence
Section titled “Delivery sequence”The roadmap groups the existing milestones into stages. It is intentionally not a semver release plan; release numbers are owned by RM-DO9Z.
1. Module graph and project roots
Section titled “1. Module graph and project roots”Accept D-XCXA-module-graph and D-SK9G-cross-project-addressing together (D-XCXA extends D-SK9G’s planning-roots shape) before the work that depends on their contracts. Start M-D2I1 with the read-only structural graph, which can ship before planning-root federation. Complete its control-unit views after M-ZLTF supplies planning roots and union loading. SDF is the first consumer; the graph stays read-only in this stage.
2. Engine and definition foundations
Section titled “2. Engine and definition foundations”Advance M-E1YP and M-3RZH as parallel substrate work. M-3RZH cuts along D-ME8T-definition-and-execution-packages, which is still proposed. The Foreman stack’s base PR conflicts with main; rebase the stack before anything else in M-E1YP. Before either milestone becomes ready, reconcile its task roster with current code and the implementation ledger. In particular, decide whether remote authority sync belongs inside the initial Foreman landing or should be tracked separately; it is currently included in M-E1YP.
3. Integrate the engine and publish the definition surface
Section titled “3. Integrate the engine and publish the definition surface”After M-E1YP, M-KBH8 moves one real implementation task through Foreman and reduces the SDLC lifecycle skills to orchestration heads. After M-3RZH, M-XS4P establishes the standalone definition packages and consumer surface. Treat any npm or public-repository release as its own reviewed release decision under the existing product-home and publishing contracts.
4. Dispatch across the roster
Section titled “4. Dispatch across the roster”M-DZEM already gives SDF explicit project registration and bounded setup. M-T5GN follows both M-KBH8 and M-ZLTF to dispatch work across trusted project roots. Keep per-project trust, worktree isolation, and the durable corpus as constraints throughout.
Later work in the vision
Section titled “Later work in the vision”The vision also names lifecycle simplification, SDF run/order panels, general marketplace skills, backplane peers and stores, a task-kind auto-merge class, and consuming definition packages across repositories. These remain future planning inputs. Promote each to a decision and milestone when the preceding stages establish its boundary and acceptance criteria.
Working rules
Section titled “Working rules”- The milestone and task entities are the execution record; this document explains the sequence and its rationale.
- Keep each milestone independently reviewable and update its state from evidence, not from a release headline.
- Run deterministic checks first, then the judgment and adversarial review appropriate to the change. Record outcomes where the next session can resume.
- Preserve human review for architectural decisions and public releases.