majordomus env

What this checkout is: the project, version control, the toolchains it declares, what the layer holds, the workflows, the provider projections and the local services

majordomus env

Usage

majordomus env [OPTIONS] [COMMAND]

Commands

majordomus env status The whole snapshot, resolved in full: what the layer holds is counted, and the cache the banner reads is written
majordomus env banner Render the snapshot for a terminal. Goes to standard error, never standard output, because direnv reads standard output as the environment it is setting
majordomus env export The variable assignments a shell in this repository benefits from, for `eval`. Assignments only: no command, no side effect
majordomus env enter Enter the repository: the assignments a shell here benefits from on standard output, the banner on standard error, the workflow bridge refreshed when a declaration behind it moved, and the runtime ensured — the whole of what entering this repository is, as one call, so that no person and no agent has to remember a sequence. Never builds, never reaches a remote network, and never waits for a server it started to answer
majordomus env explain Where each value came from: the file, command or constant that decided it, the resolver that read it, and how far it can be trusted
majordomus env preflight Whether Majordomus is in force in this checkout, claim by claim, with the evidence behind each verdict: git, the episode and its briefing, the task and handover, the policy, rules and ADRs, the shared server and the surfaces it serves, the peer board, recorded test runs, rule enforcement, provider projections and the deployment. A verdict that asserts something is in force always names its evidence. Resolves fast, from the rule tally a `--full` run cached; the HTTP route `/api/v1/environment/preflight` and the MCP tool `majordomus_preflight` answer the same value

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); 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	Output shape (accepted by every subcommand) `text` — Lines for a person `json` — One JSON document, deterministic

Examples

What this checkout is

`env` with nothing after it resolves the whole snapshot: the project and its version, the repository and its layer, version control, the toolchains the repository declares, what the layer holds counted per kind, the workflows the runner describes, the provider projections against the policy that renders them, and the local services. This is the resolution that counts the layer, so it builds the index and writes the cache the banner reads.
```
$ majordomus env
```
What it asserts: exits 0; prints project, repository, resolution.
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 env --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.