majordomus commands explain
Why one command appears where it does: the declaration it came from, the policy that placed it, and the reason for every surface that withholds it
majordomus commands explain
Usage
majordomus commands explain [OPTIONS] <ID>Arguments
| argument | value | default | description |
|---|---|---|---|
| <ID> | <ID> | required | The command's identity, `executable.worktree.status` |
| --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)
|
| --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)
|
Examples
-
Why a command appears where it does
The same command with its provenance: the file that declares it, the reader that found it, the capability behind it when there is one, what it requires, and the file the exposure policy lives in. Nothing about a command's placement is a mystery a grep has to solve.
$ majordomus commands explain executable.serveVerified by the example tests: exits 0; prints declared in, policy.
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 commands explain --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.