Top-level roadmap
State: open/active · Genre: plan
Status: working draft, 2026-10-02. Part of the strategy hub. Once the list settles, each row becomes a milestone entity under one roadmap entity, and this page links to them.
Milestones, in order
Section titled “Milestones, in order”| # | Milestone | Delivers | Functions |
|---|---|---|---|
| 1 | Ontology foundation | The modular capability model and the rest of the ontology modeling, plus the tightly scoped skills that support it (Skills): skill authoring, capability grooming, decisions, research, and the ontology group. Used to plan everything after it. | model |
| 2 | Operate one repo | The orchestrator in daily use on dev from a single coordinator. Live delivery on, session hygiene, Orca fixed, cmux verified or dropped. sdlc 0.10.0 nested projects (M-FMVX). | act, steer, adopt |
| 3 | Structure and control units | The module graph and control units (D-XCXA-module-graph, M-D2I1), and definition kinds that compose (M-3RZH). | model, observe |
| 4 | Projects and roster | Cross-project addressing (D-SK9G, M-ZLTF): one roster, planning roots, qualified links. | adopt, model |
| 5 | The map | Structure and capability views across projects, rolled up per control unit. SDF first, matched in the TUI and CLI. SDF’s system overview is M-DZ6T. | observe, steer |
| 6 | Foreman contract | The engine ports and a fixture suite, with a TypeScript implementation (the orchestrator behind the ports) and a Rust implementation (M-E1YP) passing the same fixtures. sdlc runs on the contract (M-KBH8). | act, decide, record |
| 7 | Shared consoles | One set of view models for the CLI, TUI and SDF: an orchestrate view, one web UI, a parity check. | steer |
| 8 | Self-hosting | Ontological plans and runs its own development through itself: a roadmap in modular capability terms, the loop doing the work, evidence recorded. | all |
| 9 | Release basics | Binary and npm, marketplace, per-harness install tests, CI working again, docs, the adoption wizard. Contract inventory, versioning, and sdlc config migrate. The SDF release plan is RM-DO9Z; the adopt flow is M-KJFH. RM-DO9Z (v0.9.0 to v0.17.0, one milestone each) runs ahead of this row and is not part of it. | adopt |
| 10 | 1.0 | Declare the compatibility promise. | — |
| 11 | Multi-machine | A loop lease, then execution state moved into refs/sdlc, then limits counted across machines, then peer loops. | coordinate |
| 12 | Multi-repo dispatch | Dispatch across the roster (M-T5GN). | coordinate |
| 13 | Definition package | The definition half published on its own (M-XS4P, D-ME8T). | model |
Milestones 2 through 7 can overlap once milestone 1 is done. Milestone 8 needs 3 through 6.
Additional features
Section titled “Additional features”Feature milestones that ride alongside the control-plane sequence. Each one is groomed with
capability-groom before it is placed in the order above; none is on the path to 1.0 unless
grooming says so.
| Feature | Delivers | Functions |
|---|---|---|
| Local model and harness runner | An out-of-the-box option to run work on a local harness and model, with no cloud account: headless dispatch for the pi harness (pi exists today as an interactive harness only) and a local model such as DeepSeek are the first candidates. Installed and configured by the adoption wizard as a choice, selectable per kind of work through the routing table (Adopting a project). | act, adopt |
| Agent model router | One facility that picks the model, and the harness or endpoint that serves it, for a request: skills call it for their own sub-calls, the orchestrator calls it per operation. Local by default (the local runner above), with remote providers as configured options. The routing decision itself can be rule-based or made by a classifier model; Jev, a new general classifier model, is the first candidate for that role. Policy lives in the routing table (Adopting a project), with per-machine overrides; every choice is recorded with the run. | decide, act, record |
| Secure execution with Zoo | Sessions run inside managed VM sandboxes through the Zoo app (apps/zoo, the AgentZoo sandbox manager) as a host, so a harness never touches the operator’s machine directly. A host implementation next to terminal, tmux, Orca and cmux, plus the policy that says which work must run sandboxed. | act, steer |
Open questions
Section titled “Open questions”- 1.0 before or after self-hosting? The recommendation is after: 1.0 freezes contracts, and the modular ontology is the largest contract. Shipping 1.0 first means redesigning it under a compatibility promise. The alternative is 1.0 once the release basics run, with self-hosting right after.
- Multi-machine before or after 1.0? Placed after, because a single coordinator comes first. It moves earlier if running from two machines is part of self-hosting.
- What self-hosting requires. Planning in SDF (DR-F2QX-plan-the-project-in-its-own-tool-from-the-first-day), or the loop running our own roadmap modeled in capabilities.