majordomus devtask issue

One issue as an executable development task, every field carrying where it came from

Usage

majordomus devtask issue [OPTIONS] <ID>

Arguments

argument	value	default	description
<ID>	<ID>	required	The issue id, as the canonical model spells it. An id the model does not declare is answered, not refused
--no-git	flag	—	Answer from the canonical records alone, without consulting git — a deterministic answer that is the same on every machine
--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

One issue as work to be done, not as metadata

Identity, intent, status, milestone, dependencies, blockers, branches, commits, sessions and readiness in one answer, composed from the derivations that already own each half — the plan for the graph, `trace` for git, the canonical record for everything a person wrote. Nothing is manufactured: a key the record does not carry is `unknown` with the reason, never an empty string that reads as authored.
```
$ majordomus devtask issue I0001
```
Verified by the example tests: exits 0; prints readiness, explicit.
The same, as the shape the API and MCP answer with

One domain model behind every projection: this document is what `GET /api/v1/devtask/issue` returns and what the `majordomus_devtask` tool answers, with the four groups kept apart by the type — what a person authored, what the plan derives, what happened locally, and where the external projection stands — and a provenance on every field.
```
$ majordomus devtask issue I0001 --no-git --format json
```
Verified by the example tests: exits 0; prints one JSON document carrying /declaration/title/provenance, /position/status/provenance, /readiness/state, /attestation/explicit.
An id the model does not declare is answered, not refused

A typo that read as "nothing has been authored" is the one answer a work surface must never give, so an unknown id answers with `declared: false`, the readiness `undeclared`, and every canonical field `unknown` with the reason on it.
```
$ majordomus devtask issue I9999 --no-git
```
Verified by the example tests: exits 0; prints undeclared.

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 issue --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.