Roadmap

The problem

This repository models the work: milestones are outcomes, issues are execution contracts, commits trace to issues and claims trace to recorded runs. Nothing above the milestone records what must become true for a person, so no command can say which outcome a change serves, whether a set of finished milestones achieved what they were for, or which intents have no work and which work has no intent. The public site stated as much: 'There is no intent object, no intent registry and no intent id.' An intent lived only in a prompt, and a prompt is unversioned, unenforced and gone when the session ends.

The outcome

An intent is a typed record above the milestones that realise it: a statement, its invariants, and satisfaction criteria each naming the evidence that settles it. Its stage is derived from the plan's milestone status and its satisfaction from the evidence ledger, never stored. A gate refuses an intent that names no milestone or evidence that resolves to nothing, a session's preflight names the intent its work serves or refuses, the Cockpit shows intents with measured and enforced coverage of its scripts, and a milestone closes on GitHub only when the intents it serves are satisfied.

Where it stands

Milestones and issues are validated by majordomus plan validate; claims are joined to recorded runs by majordomus evidence. There is no intent kind, no intent capability and no gate that relates work to an intent.

Where it should stand

A worker asks which intent a change serves and one capability answers from the plan, or refuses naming the missing link. A reader asks whether an intent is satisfied and the answer is derived from recorded evidence, not from a merged pull request.

In scope

• .ai/repo/project
• .ai/repo/ci/gates.yaml
• .ai/repo/rules/project
• .ai/repo/adrs
• apps/majordomus-cli/src
• share/schemas/majordomus/intent
• share/kinds.yaml
• share/cockpit
• site/data
• test/cases

Out of scope

• A second task lifecycle beside the plan; the stage is derived and nothing transitions
• Storing an intent status, or stamping an intent from a merge
• Deriving a plan from an intent automatically

Proven when

• Slice 1 — typed record and gate: the intent kind, its schema in the distribution and the skeleton, the read-only capabilities intents.list, intents.record, intents.validate and intents.preflight on every surface, and the intent-check gate refusing an invalid intent model
• Slice 2 — satisfaction is decided by evidence alone (ADR 0107): completion discharges obligations and never decides whether an intent is satisfied; the intent engine is the one authority for a criterion's verdict, and a derived verdict answers satisfaction separately from the plan-derived stage
• Slice 3 — preflight join: devcontext and the session start name the intent the task serves, from intents.preflight, and load its governance
• Slice 4 — Cockpit Intent view, with the Cockpit's JavaScript coverage measured and enforced by a gate
• Slice 5 — GitHub reconciliation: milestones projected with the intent they serve, and a closure gate that refuses to close a milestone whose intents are unsatisfied