Skip to content

Milestones and issues as data; status derived, never stored

Milestones are outcome specifications and issues are execution contracts, one YAML file each; the dependency graph decides execution waves and the next ready issue; a milestone whose dependencies are not accepted is blocked whatever its own issues say; and the GitHub projection is rendered offline from the same model.

An issue records what happened to it and the engine derives whether it is blocked, ready, active, verifying or done from the dependency graph, so the roadmap cannot disagree with the plan.

status
stable
exposed through
area
work-tracking

What it does

majordomus plan validate refuses a cycle, an edge that resolves to nothing and a record that breaks its schema; plan next answers which issues may be executed now; plan roadmap draws the milestone graph the website renders. A branch created for an issue is named after it, so the worktree topology can read the issue back from the branch, and an issue is done only with the evidence its contract requires. Above the branch the same edge is read in both directions and stored nowhere: the trace capability module derives an issue's branches and commits from git, scripts/traceability joins the pull requests GitHub holds, and a commit no execution contract accounts for is reported as unattributed rather than quietly left out.

What it does not do

It does not talk to GitHub on its own: the projection of issues and milestones is rendered offline and applied only when a person runs the sync with a token. Nothing here estimates effort or schedules dates.

The capabilities behind it

The capability modules of the executable this feature names, each with the capabilities it composes. The command line, the HTTP route, the MCP tool and the reference beside every row are projections of one declaration, not four registrations.

Traceability trace behaviorally verified

Which branches and commits realised an issue, and which issue and milestone a commit served — derived from git and from the canonical project model on every call, stored nowhere. A branch names an issue when one of its path components is an issue id; a commit belongs to the issue whose branches hold it; a commit no such branch holds is reported as unattributed rather than left out, because work with no execution contract is what a traceability report exists to make visible. Pull requests are a GitHub fact and this executable makes no network call: `scripts/traceability` reads them and joins them to this answer over the branch name.

apps/majordomus-cli/src/capability/builtin/trace.rs

The commands that run it

  • majordomus plan begin

    The milestone and issue model — validate it, read it, and move one issue through it.

The objects it is made of

Kinds of the layer. Each is a schema, a source class and a file on disk; the number beside it is what this repository holds today, counted at build time.

  • milestone17
  • issue202

What it answers

Operational moments from the Why catalogue that name one of this feature's mechanisms. Nothing here was assigned: a moment appears because it names a rule, a command, a capability or a claim this feature also names.

The rules that hold it

What is guaranteed

Executable use cases