majordomus serve status

Where this checkout's server stands — absent, starting, ready, outdated or stale — and every server of the repository

Usage

majordomus serve status [OPTIONS]

Arguments

argument	value	default	description
--format	text \| json	text	Output shape `text` — Lines for a person `json` — One JSON document, deterministic
--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)

Examples

Where this checkout's server stands, and every server of the repository

The standing of this checkout's server measured against what this executable would serve, the lease it holds, and every checkout git registers for the repository with its own server. Asked of the running server when there is one, so that the answer includes the lease that process holds; answered locally otherwise.
```
$ majordomus serve status
```
Verified by the example tests: exits 0; prints standing.

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