majordomus mesh status
Whether the mesh runs in this checkout's server and why not when it does not, with every provider's state and the registry's tallies
majordomus mesh status
Usage
majordomus mesh status [OPTIONS]Arguments
| argument | value | default | description |
|---|---|---|---|
| --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 | `text` for a person, `json` for a machine; both render the same answer
|
Examples
-
Whether this checkout's server runs a mesh
The mesh lives inside the shared server, so the command asks the running server for `mesh.status` and renders it. No server, or no mesh declaration, is an answer with its reason — never an error: the default posture is that nothing leaves the machine until a declaration says otherwise.
$ majordomus mesh statusWhat it asserts: exits 0; prints mesh.
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 mesh status --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.