Module plan 

The plan module: the milestone and issue model’s derivations, projected.

The records themselves have always been served — majordomus://issue/I0001 returns the file through objects.get — and that is the least interesting half of the model. What makes it worth having is everything nobody authored: which issues are READY, which are BLOCKED and on what, the topological waves the graph allows to run at once, the roadmap order the milestone graph implies, the milestone a worker is on and the one issue to take next. Until this module those lived only in lib/plan.sh, so an agent asking the shared MCP server what to work on could be handed 184 documents and no answer.

Every capability here reads crate::plan::Plan, built on the call out of records the index already holds. Nothing is cached: the plan changes under the process — a transition writes a lifecycle marker into a record between two calls — and a next that answered from a snapshot would send two workers to one issue.

One capability here writes: plan.transition moves an issue through start, verify and done. It is the first development operation of the runtime, and it is here because ADR 0040 decided that development semantics are capabilities of this registry and every surface a consumer of them — not because the registry’s read-only habit was an accident. Until it landed, an agent could be told what to work on and had no way to say it had started; the derivation and the transition were in two programs, and only one of them was reachable from MCP, HTTP or the Cockpit.

What it does not do is own the semantics. The guards are crate::plan::check, the resulting status is computed by the one derive every reader uses, and the record it writes is the same .ai/repo/project/issues/<id>.yaml lib/plan.sh writes, to the byte. plan evidence stays a command-line operation for now: it appends a block rather than setting a field, and it is the next transition to converge, not this one.

Structs

PlanIssueFilter

Which issues to answer with.

PlanIssueList

Issues matching a filter, with the vocabulary that names their statuses.

PlanMilestoneFilter

Which part of the plan to answer about.

PlanMilestoneProgress

One milestone’s progress, without its prose.

PlanNextIssue

The one issue a worker should take now.

PlanRecordInput

One record of the plan.

PlanRoadmap

The milestones in derived order, with the one being executed and the one after it.

PlanStatusReport

Where the plan stands: every milestone’s progress, the milestone being executed, and the one issue to take next.

PlanTransitionInput

The input of plan.transition: which issue to move, and which way.

PlanTransitionResult

What one transition did.

PlanValidation

The model’s own validation: what the graph refuses and what it merely warns about.

PlanWaveReport

The execution waves, with the overlaps that serialise issues the graph would let run together.

PlanWaveView

One wave, with the issues in it.

Enums

PlanRecord

One record of the plan, milestone or issue, with everything derived about it.

Constants

PLAN_URI

The URI under which the whole derived plan is read as an MCP resource.

Functions

module

The plan module: the derivations of the milestone and issue model, projected once.