Skip to content

check reports whether state, scope, blockers and checkpoint age are consistent right now

majordomus check is the read-only question a worker asks before claiming anything is done: does the task record still describe this checkout, are all touched files inside the declared scope, is any open question for this task unresolved, and how long since the last checkpoint. It prints one line per aspect, exits 0 when nothing fails, 10 when something does, 12 when there is no active task.

declared statusdeclared status: guaranteed Declared deterministic and blocking, implemented, and naming the behavioural test that is to prove it. Whether a recorded run supports it is the evidence verdict, shown beside it.

recorded evidencerecorded evidence: not run Declared guaranteed, and not supported by a recorded run: the test is named, and no passing run of the current inputs is recorded. how evidence is recorded

What it means

majordomus check is the read-only question a worker asks before claiming anything is done: does the task record still describe this checkout, are all touched files inside the declared scope, is any open question for this task unresolved, and how long since the last checkpoint. It prints one line per aspect, exits 0 when nothing fails, 10 when something does, 12 when there is no active task.

How it works

lib/check.sh loads the task record, computes the divergence label of its recorded head against HEAD, lists touched files from git status plus git diff --name-only <recorded head> HEAD, tests each against the scope, reads state/open-questions.md for [unresolved] <task id>, and compares checkpoint_at with the profile's interval. --explain prints the effective task, profile and policy; --checkpoint updates the timestamp and is the command's one documented write.

How to see it

majordomus check
# OK   state       t-… — advanced (head 3f2a9c1)
# FAIL scope       config/x.yml — outside claimed scope (lib/auth)  [reproduce: git status --porcelain; git diff --name-only 3f2a9c1 HEAD]
# OK   checkpoint  t-… — 7m ago, interval 15m
# OK   blockers    t-… — none open

What it does not cover

A stale checkpoint is a warning and never fails the check; work in progress is reported, not blocked. check does not run tests; finish does.

Why it exists

The source environment had no command that could answer "is this task in a sane state right now" without reading a transcript. Every recovery was a manual runbook.

Detail rendered from docs/claims/consistency-check.md.

From the statement to the proof

  1. 1 · the public statement

    check reports whether state, scope, blockers and checkpoint age are consistent right now

    Made on Finish contract, Scope.

  2. 2 · the canonical claim

    consistency-checkdeclared status: guaranteed in docs/CLAIMS.yaml

    Defined in read it on this site · docs/CLI.md

  3. 3 · the implementation

    lib/check.sh · majordomus check

  4. 4 · the test and the scenarios

    Test: test/cases/04_start_check.sh

    Executed in Decide whether finished work is actually finished, Checkpoint long work so a stop costs minutes, not the day, Block acceptance on a question nobody has answered.

  5. 5 · the recorded runs

    recorded evidence: not run how evidence is recorded

Verify it yourself

The test runs in a disposable temporary repository and asserts the behaviour, not a string in the source.

from a clone of the repository
bash test/run.sh 04_start_check

Where this claim is used

Related claims same implementation

The moments this answers

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