Skip to content

A rule enforced by a hook that never runs

Every artefact of enforcement exists — the rule, the script, the test — and no path connects them, so the control is fiction.

→ found a rule everyone believed was enforced and nothing ever invoked

cost when it happens
high
how often
common

The moment

The repository says a rule is enforced. The rule is written down, the script that checks it exists, there is even a test for the script. Nothing invokes it. It has never refused anything, and no one noticed, because everything that would demonstrate the enforcement exists except the enforcement.

Why it happens

Enforcement is a chain — rule, validator, dispatch, exit code, test, CI — and every link except one can be present. Each link is added by a different change at a different time, and no single artefact represents the whole chain, so nothing can be inspected to find the missing link. Seventeen such cases were found in the material this tool was distilled from.

Why a better model does not fix it

There is no model in this failure at all. It is a structural gap between things people wrote, and it is only visible to something that walks the chain from both ends.

What it costs

Confidence that is unearned, which is worse than knowing you have no control: the team stops watching for the violation because the check "handles it", and the violations accumulate unobserved until something forces an audit.

What Majordomus does

A rule the tool enforces declares its validator, the commands that dispatch it, the exit code a violation produces, the claims it stands behind and the tests that prove it. Nothing selects checks by hand: the dispatcher reads the declared rules, so a rule added there runs from that moment, and a rule whose validator does not exist is a reported failure rather than a silent skip. doctor walks the chain in both directions — a validator no rule declares fails too — and reconciles the policy's enforcement list against the hooks that name it, including whether the exit code survives.

Before and after

before   rule: "enforced by pre-commit"    hook: absent     result: green, always

after    $ majordomus doctor
         FAIL wiring  doctor-on-commit — declared in policy, no pre-commit hook invokes it
                      [reproduce: majordomus doctrine status]

What it does not do

It reconciles what this repository declares against what this repository runs. It cannot know that a rule ought to exist, and a rule that honestly says nobody enforces it is a passing state, not a failure.

What this looks like

Concrete situations, one per audience. Each is declared in the moment's front matter, so the before and the after are data rather than prose a page could drift from.

  1. The hook nobody installed platform-team

    before
    A pre-commit check is documented, committed and never installed in anyone''s clone, so it has stopped exactly nothing.
    after
    `doctor` reconciles the declared enforcement against the hook that names it, and fails when the path is missing, not executable or not invoked.
  2. The gate whose result was discarded enterprise

    before
    CI runs the check inside a shell pipeline that swallows its exit code; the pipeline is green whatever the check says.
    after
    Reconciliation checks that the exit code is propagated, not merely that the command appears.
  3. The convention only review enforces open-source-maintainer

    before
    A convention is called a rule, and its enforcement is the maintainer noticing.
    after
    A rule declares whether the tool enforces it or nobody does, so an honestly advisory rule is labelled as one.

How you would know

The observable symptoms this moment declares. They are the questionnaire on the index and the input of majordomus why diagnose; nothing else defines them.

  • A rule is described as enforced and nobody has watched it stop anything. believed-enforced
  • A check script exists on disk and nothing is known to invoke it. hook-exists-unwired
  • A gate runs and its exit code is discarded by whatever runs it. exit-code-swallowed

Where this lives in the tool

Everything below is read out of this moment's own front matter and resolved against the repository. A name here that did not exist would fail validation.

the commands that answer it

the capabilities of the executable that answer it

what it supervises — derived from the claims below

the claims that back this page, and the evidence behind each

the rules that govern it

  • majordomus.enforcement-wiring
  • majordomus.doctrine-wiring-integrity
  • project.rule-is-a-doctrine
  • majordomus.command-surface

the use cases that show the way out

If this one is familiar, so is the next

What this moment names, what names it, and what shares its area, audience or tags. The second and third are derived; only the first is written down.

All 38, and how they connect to the tool →