Roadmap
From intent to impact, in the order the plan's dependencies allow.
Every milestone of the plan with the issues it holds, and the intents the work serves.
- NowM002plan.roadmap /now
- NextM003plan.roadmap /next
- Milestones41plan.roadmap /milestones
- Intents5intents.list /intents
What it is for
The milestone's own record: why it exists, what it promises, and what would prove it.
The problem
The pack assumes a self-updater and signed releases. Both premises are refuted. majordomus update regenerates provider projections from policy (lib/update.sh:4); there is no self-update command, and docs/DISTRIBUTION.md:416-439 says so; to upgrade, a person reruns install.sh with --version. Artifacts are checksummed, not signed: sha256 and size in releases/<tag>.json are checked by site/static/install.sh:478 (called at :706), and docs/DISTRIBUTION.md:151-153 defers signing on purpose. What exists is compatibility risk: the superseded check covers only a binary replaced at the same path (apps/majordomus-cli/src/lease.rs:695-709), while the installer uses one directory per version, so a new client attaches to an older server and only an Outdated warning records it (apps/majordomus-cli/src/capability/builtin/server.rs:410-424). version-surface prices the public surface only; mesh discovery and link versions (apps/majordomus-cli/src/mesh/protocol.rs:36-40, apps/majordomus-cli/src/mesh/link.rs:50-53), the lease schema and journal events are outside it. Measured in the runtime baseline audit of 2026-10-09 at master 1fb8d6be44 (plan/RUNTIME_BASELINE.md).
The outcome
An enrolled mesh node follows the stable release by itself through the one installer, forward only, activating in order and rolling back a failed activation (ADR 0161); a newer client replaces an older server in an ordered hand-off and an older client is told it is older; a change to any wire or on-disk schema needs a version bump; a released archive carries a provenance attestation the installer checks.
Where it stands
Implemented: install.sh verifies checksum and size, refuses traversal and non-HTTPS; release-verdict gates the release on CI; version-surface covers capabilities, routes, tools, commands and schemas; MCP protocol negotiation. Absent: a reader of the stable pointer on any node (every node is upgraded by hand), cross-path version hand-off, wire-schema pricing, a v1 advertisement fixture, provenance.
Where it should stand
The compatibility matrix in plan/RUNTIME_BASELINE.md lists adjacent client/server and mesh versions with a test for each pair, and docs/DISTRIBUTION.md states what each install path verifies. The owner decided on 2026-10-14 that a background update check is wanted (ADR 0161): every enrolled node follows releases/latest.json through self update, which re-runs install.sh, and the mesh shows each node's version (I2720-I2724).
In scope
- apps/majordomus-cli/src/lease.rs
- apps/majordomus-cli/src/capability/builtin/server.rs
- apps/majordomus-cli/src/mcp/protocol.rs
- apps/majordomus-cli/src/release
- apps/majordomus-cli/src/mesh/protocol.rs
- apps/majordomus-cli/src/mesh/link.rs
- scripts/ci/version-matches-surface
- .github/workflows/release.yml
- site/static/install.sh
- test/fixtures
- test/cases
- docs/DISTRIBUTION.md
- docs/MCP.md
- docs/MESH.md
- apps/majordomus-cli/src/mesh
- .ai/repo/mesh/majordomus.yaml
Out of scope
- A second installer or updater; install.sh stays the one path (pack M11), and self update re-runs it (ADR 0161).
- A network fetch on entering a repository.
- Restarting a client's server while it has work in flight; hand-off goes through I2127's session move.
Proven when
- An enrolled, following node is on the version releases/latest.json names within one check interval of a release, with no person on it
- A failed activation rolls back to the previous version by itself and the board names node, version and failed check
- A client of version N+1 beside a server of version N at another path ends with one server of N+1 and no lost session
- A wire or lease or journal schema change without a version bump fails version-surface
- Each release archive carries an attestation that verifies for this repository
objects.get0 msAPI/api/v1/objectMCPmajordomus_gettechnical view
Milestone
One milestone of the plan: what it holds, what can start, and what it waits for.
safe-self-update · order 144 · p0
Every mesh node follows the published release by itself, versions meet safely, and a release's provenance can be checked
activeClose
- Done
- 2 of 7
- Blocked
- 3
- Waits for
- none
- Blocked by
- none
- Unblocks
- none
- Serves
- none
Critical path
Issues
plan.roadmap0 msAPI/api/v1/plan/roadmapMCPmajordomus_plan_roadmaptechnical view
plan.issues0 msAPI/api/v1/plan/issuesMCPmajordomus_plan_issuestechnical view
Milestones
Every milestone, in the plan's order; the plan declares no dates, so none are drawn.
plan.roadmap0 msAPI/api/v1/plan/roadmapMCPmajordomus_plan_roadmaptechnical view
Intents
What the work is for, and whether the evidence says it is met.
intents.list264 msAPI/api/v1/intentsCLImajordomus intent listMCPmajordomus_intentstechnical view
Issues by status
Every issue of the plan, counted by the plan.
- active1
- blocked159
- cancelled10
- done161
- ready86
- verify7
plan.status0 msAPI/api/v1/plan/statusMCPmajordomus_plan_statustechnical view
Dependencies
Which milestone waits for which, as the plan records it.
| Milestone | Depends on | Blocked by |
|---|---|---|
| runtime-adapters | foundation | |
| intent-planning | intent-lifecycle | intent-lifecycle |
| execution-telemetry | runtime-adapters | runtime-adapters |
| intent-bound-work | intent-planning | intent-planning |
| cost-per-accepted-outcome | execution-telemetry | execution-telemetry |
| routing-recommendations | cost-per-accepted-outcome | cost-per-accepted-outcome |
| shared-policy | routing-recommendations | routing-recommendations |
plan.roadmap0 msAPI/api/v1/plan/roadmapMCPmajordomus_plan_roadmaptechnical view