Skip to content

Policy

one provider-neutral policy.yaml; unknown keys are errors

one provider-neutral policy.yaml; unknown keys are errors

Where it lives

The command that acts on it

majordomus update

Regenerate every provider instruction file from the one policy, deterministically.

  • generated-output-mutating
majordomus update [--dry-run] [--diff <target>] [--force]

See it refuse, and accept

One policy, several provider instruction files, generated deterministically. Running it twice leaves byte-identical files, which is what makes a stamp able to detect a hand edit.

Given this repository

# Installed, but the provider instruction files have not been generated yet.
"$MJ" init >/dev/null
mkdir -p lib && echo a > lib/a && git add . && git commit -qm base

Run

$ majordomus update

Output contains

  • create CLAUDE.md
  • carries its own stamp

exit 0

Each target named in the policy's projections is written, and a stamp of each is recorded together with the hash of the policy that produced it.

Given this repository

# A repository with Majordomus installed and projections generated, and one commit of work.
"$MJ" init >/dev/null
"$MJ" update >/dev/null
mkdir -p lib docs
echo a > lib/a
echo d > docs/d
git add . && git commit -qm base

Run

$ majordomus update

Output contains

  • unchanged CLAUDE.md

exit 0

Deterministic output is not a nicety here. If regeneration produced a different file each time, a stamp could never distinguish a hand edit from the generator's own noise.

What enforces it

What is guaranteed

The moments this answers