Skip to content

majordomus devtask milestone

One milestone as an executable dependency graph: ready, blocked, parallelizable, critical blockers, cycles

majordomus devtask milestone

Usage

majordomus devtask milestone [OPTIONS] <ID>

Arguments

argumentvaluedefaultdescription
<ID> <ID> required The milestone id, as the canonical model spells it
--repo <PATH> Start the search for the repository root here (default: the current directory) (accepted by every subcommand)
--discovery vcs | filesystem vcs How declarative files are enumerated (accepted by every subcommand)
  • vcs — Tracked files, through the version-control index (the layer's contract)
  • filesystem — A walk of the work tree with the same glob semantics; untracked files included
--strict flag Refuse to proceed when any file of the layer carries an error diagnostic (accepted by every subcommand)
--share <DIR> The tool distribution's share directory (kinds.yaml, schemas/); default: $MAJORDOMUS_SHARE, then the repository's own share/, then the one beside the executable (accepted by every subcommand)
--format text | json text Output shape (accepted by every subcommand)
  • text — Lines for a person
  • json — One JSON document, deterministic

Examples

  • What to work on next in one outcome, and what to unblock first

    The issues partitioned by readiness, the critical blockers ordered by how much unfinished work each holds back, and the startable work partitioned into subsets that may genuinely run at the same time. A pure function of the canonical records — no git, no clock, no network — so two runs on two machines produce the same bytes and a reader derives nothing itself.

    $ majordomus devtask milestone foundation

    Verified by the example tests: exits 0; prints READINESS.

  • The graph, as the shape the API and MCP answer with

    Every partition the plan implies and no surface should recompute: `ready`, `blocked`, `waiting`, `active`, `review`, `completion_blocked`, `complete`, `cancelled`, plus `critical_blockers`, `parallelizable` with the scope path behind each serialisation, and `cycles` as strongly connected components.

    $ majordomus devtask milestone foundation --format json

    Verified by the example tests: exits 0; prints one JSON document carrying /counts/total, /ready, /critical_blockers, /parallelizable.

Where this comes from

Declared once in apps/majordomus-cli/src/cli.rs: clap for the structure, typed Rust metadata beside it for the examples. This page, majordomus devtask milestone --help, docs/generated/cli.md and docs/generated/cli.json are projections of that one declaration.

The whole command line on one page: the registry's command-line page. The task lifecycle (init, start, finish, doctor, ...) belongs to the shell tool, a different program: Commands and its specification.