majordomus worktree list

Every registered worktree with its standing, one line each; exit 10 when the topology has an error

Usage

majordomus worktree list [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) `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

Every worktree, the misplaced ones obvious

The primary checkout first, then every linked worktree with its standing, its branch, where it belongs when it is somewhere else, and its uncommitted work. The primary checkout is exempt from the path rule and held to the trunk rule instead.
```
$ majordomus worktree create feature/example
$ majordomus worktree list
```
Verified by the example tests: exits 0; prints PRIMARY, CANONICAL, -wt/feature/example.

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 worktree list --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.