Rules a machine decides, wired, tested and CI-blocking

A rule is enforced when a validator decides it, a command runs it, a test proves it and CI blocks on it; anything less is documentation, and the tool knows the difference.

status

stable

exposed through

• ✓cli
• ✓api
• ✓mcp
• ✓cockpit
• ✓docs

area

governance

verification

What it does

The effective rule set is the vendored baseline the tool ships plus the rules this repository wrote, resolved as a dependency graph: a missing dependency, a cycle or two rules claiming one identity is an error, and a set that does not resolve is not applied at all. A rule's class is blocking or advisory and there is no third; the class is read at dispatch time and is what routes a finding, so changing one word in a rule file changes whether majordomus check exits zero — and a test asserts exactly that.

majordomus doctor reads the source rather than a rule's description of itself: the validator function must exist, the commands the rule names must dispatch it, a blocking rule must be able to exit non-zero, a test must prove it, and CI must run that test without swallowing its exit code. A validator no rule declares is enforcement running under no rule, and fails.

What it does not do

A rule without a validator is normative for whoever reads it and enforced by nobody, and it says so; the tool does not pretend otherwise. There is no severity ladder, no baseline and no override: a project rule may add a constraint and may never weaken a vendored one.

The capabilities behind it

The capability modules of the executable this feature names, each with the capabilities it composes. The command line, the HTTP route, the MCP tool and the reference beside every row are projections of one declaration, not four registrations.

The commands that run it

• majordomus rules inspect

  The effective rule set, vendored baseline plus project rules.

• majordomus doctrine inspect · read-only

  What rules are enforced, by what, and whether each one is actually wired.

• majordomus doctor inspect · read-only

  Is Majordomus itself healthy, and is every enforcement it declares actually wired here?

• majordomus check verify · read-only

  Is the current task still consistent with its policy, its scope and this checkout?

• majordomus watch inspect · read-only

  What has drifted since the last update — policy, projections, state, retention.

The objects it is made of

Kinds of the layer. Each is a schema, a source class and a file on disk; the number beside it is what this repository holds today, counted at build time.

• rule109

What it answers

Operational moments from the Why catalogue that name one of this feature's mechanisms. Nothing here was assigned: a moment appears because it names a rule, a command, a capability or a claim this feature also names.

• →re-explained the same context to a brand-new session
• →found two agents fixing the same bug in two branches
• →watched the strongest model, at maximum effort, rename a variable
• →accepted "done" because the model said so, and paid for it the next morning
• →opened CLAUDE.md and AGENTS.md and found two different rulebooks for one repository
• →found a task "in progress" that nobody had touched for three weeks
• →asked what the workers did last night and had only transcripts to grep
• →found the rule for that directory in a README no session ever loaded
• →read three roadmaps for one project and believed none of them
• →watched the always-loaded instruction file grow past a thousand lines
• →watched one worker revert another worker's change, on purpose
• →found five worktrees and could not say which of them still mattered
• →found finished work on a branch that nobody ever merged
• →had two sessions writing into one checkout without either knowing
• →changed a policy in one place and found the old one still in force in three others
• →found a rule everyone believed was enforced and nothing ever invoked
• →found code that contradicted a decision the repository had written down
• →found a substantial change that no issue, ticket or plan ever asked for
• →closed an issue whose acceptance criteria nothing had actually checked
• →was asked how far the milestone had got and had to go and ask four people
• →read a promise in the README that no test stood behind
• →shipped an interface change whose contract document still described the old one
• →pasted a command from the documentation and watched it fail
• →had a green pipeline over generated files that no longer matched their sources
• →let a fast, cheap session make a decision the whole codebase now lives with
• →looked at the bill and could not say which of it produced anything
• →found the same thing explained three times, slightly differently
• →published a page that promised more than any test could support
• →spent the first hour in an unfamiliar repository working out what was normal here
• →reviewed a well-written contribution that broke a convention it had no way to discover
• →could not reproduce a result because nothing recorded the state it came from

The rules that hold it

• blockingA new enforced rule is a doctrine, not an inline checkproject.rule-is-a-doctrine
• blockingDoctrine wiring integritymajordomus.doctrine-wiring-integrity
• blockingEnforcement wiringmajordomus.enforcement-wiring
• blockingRule package integritymajordomus.rule-package-integrity
• blockingNo claim without a testproject.no-claim-without-test

What is guaranteed

• guaranteed Every rule the tool enforces is declared once, as a rule object in the repository's effective set, and doctor proves each one is reached by the command that claims to run it
• guaranteed A doctrine's class is what decides whether a violation stops the command, not a label beside it
• guaranteed Wiring is found in a hook or in any subhook of the directory that hook dispatches to
• guaranteed Every enforcement the policy declares is reconciled against what actually runs
• guaranteed The rule baseline is vendored into the repository with a manifest naming every file and its hash, and a hand edit is detected and refused
• guaranteed The effective rule set is resolved as a dependency graph in a deterministic order, and a set that does not resolve is applied by nothing
• guaranteed watch reports policy, projection, state, scope, handover, verification, staleness and retention drift

Executable use cases

• policyProve a rule is actually enforced, not merely written down
• policySee which rules apply here and what enforces them
• policyGate CI on the tool itself, with an exit code that is a contract
• driftFind out what has drifted since anyone last looked