majordomus monitor

Everything that happens around this repository, followed in one stream: mesh sessions, claims, handovers and reviews on every linked machine, the executor's merges and failures, and GitHub's pull requests and runs, with what is addressed to you marked

majordomus monitor

Usage

majordomus monitor [OPTIONS]

Arguments

argument	value	default	description
--follow	flag	—	Keep following: ask again every `--interval` seconds and print only what is new
--after	<AFTER>	—	Start after this cursor (a page's `cursor`), instead of the newest signals
--limit	<LIMIT>	—	At most this many signals per page (default 50, at most 500)
--sources	<SOURCES>	—	A comma-separated subset of mesh, executor and github (default: all three)
--for	<READER>	—	Your names, comma-separated (a worker such as 1b, a role, a login): what names them is marked for you; default $MAJORDOMUS_MONITOR_FOR
--since	<SINCE>	—	How far back the first page reaches: seconds, or a number with s, m, h or d (default 1h)
--match	<PATTERN>	—	Keep only signals whose summary contains this text (case-insensitive)
--count	<COUNT>	—	Stop following after this many signals
--until	<UNTIL>	—	Stop following at the first signal of this kind (e.g. merged, review_requested, run_failed)
--timeout	<TIMEOUT>	—	Give up following after this long, exiting 10: seconds, or a number with s, m, h or d
--interval	<INTERVAL>	2	Seconds between two asks while following
--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); a layer none of which is tracked is read from the work tree `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	`text` for a person, `json` for a machine; both render the same answer `text` — Lines for a person `json` — One JSON document, deterministic

Examples

What happened in the last half hour

One page of the stream — the mesh, the executor's trail and GitHub — with what names you listed first. With no running server the answer is the reason.
```
$ majordomus monitor --since 30m --for 1b
```
What it asserts: exits 0; prints no running server.
Tested by apps/majordomus-cli/tests/cli_examples.rs, which runs the command against the built executable and asserts what the page states.
Wait for a pull request to merge

Follow the stream and exit 0 at the first merge whose summary names #885; `--timeout` gives up with exit 10, as it does here within a second when no server answers.
```
$ majordomus monitor --follow --match '#885' --until merged --timeout 1s --interval 1
```
What it asserts: exits 10.
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 monitor --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.