Master consolidation

State: open/active · Genre: plan

The one place that tracks every open strand of Ontological and sdlc work, as a checklist. The central planning session owns this file. Opened 2026-10-03.

How this file is used

One central session. It keeps this file current and is the only writer of the checklists.
Side sessions. A smaller planning or implementation session gets a row in Side sessions before it starts, and a checklist item here names what it will bring back. When it ends, its row is closed and its item is ticked or rewritten.
Nothing lives only outside the repo. Plan files under ~/.claude/plans/, session memory and scratch files are working copies. Anything in them that still matters is copied into this file or into an entity, and the source is listed under Source documents.
This file links, it does not restate. Detail lives in the roadmap, milestone, task, capability and note entities. A checklist item names the entity or PR that holds the detail.
A box is ticked only when the change is on main.

Priorities

Consolidate the plans. Every open strand is in this file or in an entity it links to.
Dogfood, and see the system. Plan and run this work through sdlc itself, and get a coherent view of capabilities and tasks. That view is the first working piece of the control plane. The next milestone is M-YX34: SDF shared on the web, with planning views.
Hammer out the adoption prototype. On real repositories, not fake services. Use it to settle what the sdlc product looks like and what is left to build. The one exception is the wizard itself: it is complete in the app ahead of its backing, with mocks where a part does not exist yet, to show to potential customers.

Everything else waits under Later.

1. Consolidate the plans

2. Dogfood, and see the system

The aim is one coherent picture that answers: which capabilities exist or are planned, which milestone delivers each, which tasks are open under it, and what is running now.

Link the work to the capability graph

capabilities lists on the seven SDF milestones (M-V9RR, M-DZ6T, M-KJFH, M-0M28, M-EG9L, M-K7C0, M-2QAE), pointing into the C-0050 tree.
capabilities lists on the strategy milestones as they are created.
Decide how a task reaches a capability (decision 5). Today the path is task → milestone → capability; there is no direct link.
roadmap check and the strict audit green with those links in place.

Model by containment

Capabilities nest to any depth through parent_key, so each level stays small enough to hold in mind. This applies to every subtree, not only Model. Nesting is a modelling aid and is not enforced: it follows from the capabilities’ own definitions, there can be several roots, and a capability can stay unnested (decision 9).

The containment pass: 27 capabilities given parents, a Determined root, a structural graph and an SDLC dashboard capability (#2559). 24 stay unnested.
The rest is in M-YX34: the graph opening folded (T-31MH) and a tree output for sdlc capability graph (T-4RB7).

See it

The order is: share SDF on the web (M-YX34), dogfood its planning views, then the wizard (priority 3). Until SDF serves these views, a scratch viewer on port 8787 reads the corpus from git.

The capability graph in SDF: the System page’s Capabilities source draws containment as nested boxes, with filters for kind, audience and state (#2217).
SDF runs headless for the network, behind the platform token (#2546).
M-YX34, the rest: the capability graph opens at a readable depth; capability pages show milestones and tasks; note pages and a roadmap page exist.
sdlc capability graph --audience user prints the feature tree in the terminal.
A generated planning view: one page listing each capability with its milestones and open task counts, written by sdlc docs generate. This is the cheapest coherent view and needs no UI.
The SDF system overview (M-DZ6T): rings for structure, capability, work and runs, on real data. This is where priority 2 and priority 3 meet; it is sketched in #2533 on a fake transport.

Run the work through sdlc

First capability-groom run, on C-0069 Agent model router. It tests whether a capability can be groomed into ready tasks from the graph alone.
Ontology group skills in the craft package: driver-capture, term-define, product-define; narrow capability-map to survey and capability-review to verify (N-SX7H-skills).
The orchestrator in daily use on this repo:
- orchestrator.router.live_enabled switched on (user only);
- the Orca host fixed;
- an orchestrate page in the TUI;
- the PR review loop kept running from one known session.
Derive tasks from priority 3 dispatched by the orchestrator, not by hand.

3. Hammer out the adoption prototype

No fake services (decision 10). Screens read real repositories through the real APIs, and test repositories carry starter data in the formats the backend stores. The loop per milestone is: stored format and read API, starter data, screen, write side, release (N-6DUQ-sdlc-1-0-release-plan).

The screens for all seven adoption milestones were sketched on a fake transport in #2533, a draft that has never been typechecked. They are kept as the starting point and rewired milestone by milestone.

The wizard, complete in the app

The owner wants the adoption wizard complete as a deliverable before its backing implementation exists, to show potential customers what adoption looks like (2026-10-03). It lives in the app as the actual wizard, not as a separate demo build. A section reads the real API where one exists and a mock where it does not. This is UX prototyping in a mixed environment, and mocks are accepted for it (decision 11). It amends decision 10 for the wizard only; the other screens still read real repositories. Each release below replaces one section’s mocks with the real thing.

All eleven sections complete in the app. Ten are sketched in #2533; secure execution (M-GX7X) is not.
Mocks sit behind the same data interface the real API will fill, one per section, so a release swaps a section without touching its screen.
A list in this note of which sections are real and which are mocked, kept current.
Mock data that tells one coherent story about one example project.
A mocked section never writes to a repository. Apply writes only what is real.

Rework the draft

Per release

One milestone per release. Each line is done when its screens run on a real repository.

The prototype’s hand-written types (app/types/{adopt,record,config}.ts, PrototypeData) are replaced by generated ones as each read API lands. app/generated/* is never edited by hand.

Decisions needed

#	Question	Recommendation	Settled
1	RM-DO9Z v0.9.0 and the nested-projects milestone in #2474 share a version number.	Fold nested projects into RM-DO9Z v0.9.0 as a third milestone.	yes, 2026-10-03: folded, then renumbered to v0.10.0 when each milestone became its own release
2	Is 1.0 declared before or after self-hosting?	After. 1.0 freezes contracts, and the capability model is the largest one.	no
3	When is `wizard-prototype.html` retired?	When #2533 leaves draft.	no
4	Skill fills: one `.lifecycle` file per skill, or step directories?	Keep `.lifecycle` files; revisit at v0.14.0, when step directories arrive.	no
5	Does a task link to a capability directly?	No. Keep task → milestone → capability until the planning view shows it is not enough.	no
6	Does the model router decide by rules or by a classifier?	Rules first; the classifier (`C-0088`) as a later adapter.	no
7	Does the corpus move to `sdlc/model/`?	Not before 1.0.	no
8	Is the skill package name `craft` final?	Yes, unless a better name appears before the first publish.	no
9	One capability root, or several? Is nesting enforced?	Several roots, and nesting is not enforced. A capability nests where its definition makes it part of another; unnested capabilities are allowed. Nesting is there to help conceptual modelling.	yes, 2026-10-03
10	Fake services, or real APIs over test repositories?	Real APIs. Test repositories carry starter data; each milestone starts with its stored format and read API. The wizard is the one exception (decision 11).	yes, 2026-10-03
11	How is the complete wizard delivered ahead of its backing?	In the app, as the actual wizard. Parts that do not exist yet are mocked; this is UX prototyping in a mixed environment and mocks are accepted for it. Wizard only.	yes, 2026-10-03

Every milestone is its own 0.x release. A milestone that grows too large is split and the later releases are renumbered; that needs no decision here.

User-only items

1. GitHub Actions billing. CI has not run since the spending limit was hit, so nothing is typechecked.
2. Switch on orchestrator.router.live_enabled on main.
3. npm publish and the plugin update to 0.8.0.
4. Review and merge sksizer/rust-ontogen#191.

Open pull requests

PR	What	State	Next
#2533	SDF adoption prototype	draft, reviewed once	fix the four findings

Side sessions

A side session is added here before it starts. Implementation runs in subagent orchestrators that delegate all implementation to cheaper models. Each PR gets a review from a fresh subagent that has none of the author’s context, then a response to that review.

Session	Scope	Branch or worktree	Brings back	State
adoption-wizard-sdf-implementation	Sketch all seven SDF milestones	`~/Developer/dev-sdf-prototype`	#2533	handed over 2026-10-03
PR review loop	Comment-only review of open PRs, every 20 minutes	none	review comments	running
M-YX34 headless server orchestrator	SDF served with no desktop window and no dev server; every API request needs the token	`~/Developer/dev-sdf-serve`	#2546	merged 2026-10-03
M-YX34 read-only viewer orchestrator	Tokenless network browser: per-browser focus and a guard allowlist	`~/Developer/dev-sdf-viewer`, branch `feat/sdf-readonly-viewer`	#2549, closed unmerged: a network browser is given the token instead	closed 2026-10-03
M-YX34 task entities	Ten tasks for the rest of v0.9.0	`~/Developer/dev-yx34-tasks`	#2556	merged 2026-10-03
Capability containment pass	Apply the owner’s decisions on the containment proposal	`~/Developer/dev-containment`	#2559	merged 2026-10-03
Nested projects orchestrator	`T-9WPJ`, `T-55H8`, `T-8CK0` of M-FMVX, one PR each	`~/Developer/dev-nested`	#2560, #2561, #2566	awaiting merge
Note API and pages orchestrator	`T-1ODN` then `T-KQ7W`	`~/Developer/dev-notes`	#2569, #2572	awaiting merge
SDF UX analysis	Review colours, layout and navigation of the SDF app from screenshots of every page; findings only	`~/Developer/dev-sdf-ux`	#2580, note N-NR85	awaiting merge
SDF contrast repairs	Text and status tokens to the 4.5:1 minimum, then hard-coded colours onto `--d-*` tokens; colour only	`~/Developer/dev-sdf-contrast`	two stacked PRs	running
SDF UI revamp brief	Audit of how far SDF follows its shared UI system, two or three visual directions, a staged plan; planning only	`~/Developer/dev-sdf-revamp`	a brief note as a PR	running
v0.10.0 CLI tasks orchestrator	`T-S4XK`, `T-OQAT`, `T-0A07`, `T-3N5B` of M-FMVX, one PR each	`~/Developer/dev-fmvx-*`	four PRs	running
M-YX34 CLI and serve tasks orchestrator	`T-4RB7`, `T-DE6D`, `T-IFXN`, one PR each	`~/Developer/dev-yx34-*`	three PRs	running

Parked backend specs

Written during the foundation planning and set aside when the work turned fixture-first. Under decision 10 each is the first step of its milestone, not a later one. Each is revised against what the prototype needs, then filed as its milestone’s stored-format and read-API task. The release and milestone columns follow the releases table in N-6DUQ-sdlc-1-0-release-plan.

Spec	What it adds	Release	Milestone
standard-enforcement	`enforcement` and `severity_floor` on a standard, with per-source filtering in `verify changes`; verify modes	v0.14.0	M-0M28
fs-step-layer	drop-in step directories in `resolveLayeredSteps`	v0.14.0	M-0M28
extend-points-and-list	the extension points and `sdlc extend list`	v0.14.0	M-0M28
config-profiles-routing	`profiles:` and `routing:` keys in `sdlc.yaml`	v0.15.0	M-EG9L
resolve-profile	`resolveProfile`	v0.15.0	M-EG9L
dispatch-model-effort	model and effort passed through `headlessArgv`	v0.15.0	M-EG9L
routing-in-work-tick	routing applied in the work tick	v0.15.0	M-EG9L
docs-sdlc-yaml-prose	prose reference for `sdlc.yaml`; the source names no release	v0.16.0 (proposed)	M-K7C0
journal-core	the journal service, `lib/services/journal`	v0.17.0	M-2QAE
journal-ops	`sdlc journal append` and `tail`	v0.17.0	M-2QAE
journal-auto-op-events	automatic `op.start` and `op.end` events	v0.17.0	M-2QAE
entity-run	a `run` entity kind	v0.17.0	M-2QAE
entity-friction	a `friction` entity kind, with retro proposals	v0.17.0	M-2QAE

Prototype gaps

Known when the prototype was handed over. Each is fixed in #2533 or filed as a backlog item.

Apply mode (working tree, branch, dry-run) is chosen in the UI but not sent; actionSetupProject takes only installHarness.
The drift report is invented data; a real one arrives with the adopt flow (M-KJFH).
Locked nav modules are not dimmed; the app-frame nav has no per-module state.
The run detail page highlights the Journal tab.
The 3D overview canvas is grey in dark mode.
three is pinned to one copy in SDF’s .storybook/main.ts only; graph-canvas pins 0.169 and the force-graph libraries need 0.185.
packages/ts/graph-canvas gained additive fx/fy/fz pinning, a shared-package change that rides in the prototype PR.

Later

Not on the path of the three priorities. Each stays where it is recorded until it is pulled in.

Structure and control units, projects and roster, the Foreman contract, shared consoles, multi-machine, multi-repo dispatch, the definition package: rows 3, 4, 6, 7, 11, 12 and 13 of N-6UK4-top-level-roadmap.
Pull the ontology apart by module. Terms, capabilities and the other entities live in one corpus under docs/planning/ today. Each should move to the module it is about: for example, TM-0040-function belongs with the control plane, and a product’s capabilities with that product. It depends on planning roots and qualified links (M-ZLTF, D-SK9G-cross-project-addressing) and on the module graph (D-XCXA-module-graph, M-D2I1), and it follows the same idea as containment: an entity sits where its definition places it.
Additional features: the local model and harness runner (C-0073) and the agent model router beyond its first grooming (C-0069).
SDF follow-ups: a startup check (B-CSHR-sdf-startup-check), rejected-token handling in the generated client (B-L4QF-sdf-rejected-token-handling), the stale sdlc CLI (B-X0EC-sdf-stale-sdlc-cli), and moving the headless server upstream (B-J14M-headless-server-upstream).
A harness attribution setting, an sdlc:manual exclude label, lefthook on PATH in new worktrees.

Source documents

Working documents outside the repo, and what happened to their content.

Source	Content	Disposition
`~/.claude/plans/toasty-soaring-ullman.md`	SDF adoption plan: decisions, milestones, releases, sketch task specs, parked spec names	Milestones, releases and tasks are entities (RM-DO9Z, N-6DUQ-sdlc-1-0-release-plan). Parked spec names are copied above. That file holds only the spec names and the release mapping; no fuller spec text has been found.
`~/.claude/plans/ok-i-want-to-lexical-wirth.md`	The sdlc 0.8 build plan in 14 phases	Superseded by N-S4AJ-sdlc-0-8-plan and RM-E2L0; v0.8.0 shipped.
Session memory, `sdf-adoption-prototype-campaign`	Prototype handoff: gaps, cleanup, open decisions	Copied into priorities 1 and 3 and Prototype gaps.
Session memory, `ontology-foundation-campaign`	PR states, capability tree ids, follow-ups	Follow-ups copied into priority 1.
Session memory, `orchestrator-adoption`	Orchestrator rollout state and next steps	Next steps copied into priority 2.
`docs/planning/strategy/wizard-prototype.html`	The first HTML mock of the wizard	Replaced by #2533; to be removed (decision 3).

← Back to Notes