majordomus proceed step

One step, as one work order, read only: `do` (the capability to run next and its input), `fan_out` (what may run beside it), `report` (what to announce) and `next_due_at` (when to step again); for an intent, `done` once its realisation is met. The same state answers the same order and key. Exit 0 when work is ordered or the order is done, 10 when the step waits

Usage

majordomus proceed step [OPTIONS]

Arguments

argument	value	default	description
--intent	<ID>	—	The intent the session realises: only issues serving its unmet criteria are ordered, and the order is done when it is met. The whole plan when absent
--milestone	<ID>	—	The milestone whose READY issues come first; the active one when absent
--session	<ID>	—	The mesh session the step is for, whose own claims are not held against it
--at	<TIME>	—	The moment the step is taken at, RFC 3339 in UTC to the second; the clock when absent
--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); a layer none of which is tracked is read from the work tree `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

One step as one work order, when nothing is left to do

The same answer `GET /api/v1/proceed/step` and the MCP tool `majordomus_proceed_step` return, and what `/proceed` runs: `do`, the capability to run next and its input; `fan_out`, what may run beside it; `report`, what to announce; `next_due_at`, when to step again; and a `key` that the same state answers again. This fixture declares no plan, so nothing is unfinished: the order is `done`, runs nothing, schedules nothing, and the command exits 0; with nothing scheduled, the moment changes nothing it decides.
```
$ majordomus proceed step --format json
```
What it asserts: exits 0.
Tested by apps/majordomus-cli/tests/cli_examples.rs, which runs the command against the built executable and asserts what the page states.

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 proceed step --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.