Skip to content

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
feature status: stable
domain
Governance
on the homepage
featured

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.

Why it exists

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.

Every moment it answers (31)

How it works

The capability modules of the executable this feature names, each with the capabilities it composes. The interfaces each one reaches are listed under Interfaces below: they are projections of one declaration, not separate registrations.

Health health behaviorally verified

Whether what this process serves is healthy, decided by the engines that already decide it: the index's diagnostics, the registry builder, the benchmark projection's coverage, the comparison `generate --check` makes and the lease reading `server.status` answers from. No check here has an opinion of its own.

Rules rules behaviorally verified

What this repository refuses, and what it can actually show for each refusal. A rule declares a class — blocking, where a gate refuses the work, or advisory, where a reader is expected to have read it — and an enforcement block naming either the validator the dispatcher calls or the behavioural cases that prove it. This module joins that declaration to the tree and to the ledger of recorded runs, and reports, per rule, whether what it names is there, whether a runner owns it, whether it was ever run, whether the run passed, and whether the run is older than what it is about. A blocking rule whose proof is missing, dangling or failing is a finding, because a rule nobody can prove is a rule nobody enforces.

Shell automation shell behaviorally verified

The repository's shell automation measured against the tracked migration inventory: new shell is refused unless an exemption declares why it has to be shell and when it stops being, and an exemption whose file is gone is refused too, so the list only shrinks as units move into typed and scripted capabilities (ADR 0069).

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.

  • rule190

Where it sits

domain
Governance — The rules are written once, in the repository, projected into every tool's instructions, and a blocking rule stops the command instead of advising it.
areas of work
governanceverification
names
Finish contractPolicy
named by
KnowledgeCoverageFinish contractPolicyUse casesCICommits

Interfaces

Each capability behind it, on every interface it is projected onto. A link goes to this site's reference for that interface; an HTTP route and an MCP tool are answered by a running majordomus serve, not by this site.

The capabilities behind this feature, by interface
capabilitycommand lineHTTPMCP tool
health.live —none GET /api/v1/live —none
health.ready —none GET /api/v1/ready —none
health.report —none GET /api/v1/health majordomus_health
rules.proves majordomus rules proves GET /api/v1/rules/proves majordomus_rule_proves
rules.report majordomus rules report GET /api/v1/rules majordomus_rules
rules.show majordomus rules show GET /api/v1/rules/rule majordomus_rule
shell.check majordomus shell check GET /api/v1/shell/check majordomus_shell_check
in the Cockpit, of a running server
/cockpit/health Health

Evidence

What is guaranteed

Each claim this feature names, with the status its row declares, the verdict the recorded runs support, and the test that settles it.

Executable use cases

The rules that hold it

  • blocking A new enforced rule is a doctrine, not an inline checkproject.rule-is-a-doctrine
  • blocking Doctrine wiring integritymajordomus.doctrine-wiring-integrity
  • blocking Enforcement wiringmajordomus.enforcement-wiring
  • blocking Rule package integritymajordomus.rule-package-integrity
  • blocking No claim without a testproject.no-claim-without-test
  • blocking English onlyproject.english-only
  • blocking Every finding carries a reproduce commandproject.finding-carries-reproduce

Using it

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

    It checks governance 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.

From the executable's command line

The synopsis of each, as the executable's own help prints it.

Where this page comes from

the file
.ai/repo/features/doctrine.md
the same answer
majordomus product show doctrine
read further

Doctrine

Dogfooding

Searches the titles and descriptions of every page this site publishes.