Scope
start takes the paths a task may touch; check and finish fail on files outside them; other worktrees' overlapping claims are reported
start takes the paths a task may touch; check and finish fail on files outside them; other worktrees' overlapping claims are reported
Where it lives
State it owns
.ai/local/state/current.yaml
The command that acts on it
majordomus check
Is the current task still consistent with its policy, its scope and this checkout?
- read-only
- active task required
- --json
majordomus check [--explain] [--overlap] [--checkpoint] [--rule <id>] [--json]
See it refuse, and accept
check is read-only and answers three questions at once: does the record still describe this checkout, is the work inside the claimed scope, and is anything blocking acceptance.
Given this repository
# ... and an active task scoped to lib, with work done inside that scope. . "$FIXTURE_SETUP/installed.sh" "$MJ" start "narrow the parser" --scope lib >/dev/null echo work >> lib/a
Run
$ majordomus check
Output contains
- OK scope
- 0 failing
exit
0
Every finding is printed, not only the failures, so the report says what was checked rather than only what went wrong.
Given this repository
# An active task scoped to lib, with a change under docs that the task never claimed. . "$FIXTURE_SETUP/active-task.sh" echo stray >> docs/d
Run
$ majordomus check
Output contains
- FAIL scope
- docs/d
exit
10
check names the individual file, because the useful question is which change to move or claim — not merely that something is wrong.
What enforces it
- majordomus.questions-store-integrity blocking enforced by doctor, watch Every entry in open-questions.md parses, because a gate that cannot read an entry can be bypassed by mistyping one.
- majordomus.scope-integrity blocking enforced by check, finish, watch A task touches only the paths it claimed; work found elsewhere is not accepted as done.
- majordomus.state-consistency blocking enforced by check, finish, watch The task record still describes this checkout — same branch, and HEAD at or ahead of the recorded commit.
What is guaranteed
- guaranteed An entry in the questions store that does not parse blocks acceptance exactly as an unresolved question doesproved by test/cases/21_decision_question.sh
- guaranteed A task is started with a declared file scope and a profile, and only one task is active per checkoutproved by test/cases/04_start_check.sh
- guaranteed check reports whether state, scope, blockers and checkpoint age are consistent right nowproved by test/cases/04_start_check.sh
- guaranteed A touched file outside the claimed scope is a failure, not a warningproved by test/cases/04_start_check.sh
- guaranteed Overlap between parallel workers is computed on claimed paths in both containment directionsproved by test/cases/04_start_check.sh
- planned A task will know which commits it produced, rather than inferring them from a range
- guaranteed A task record names the checkout it belongs to, and another checkout is never held to its scopeproved by test/cases/27_foreign_task.sh
Rules this command runs
Doctrines whose enforced_by names check. Enforcing a rule and being governed by one are different relations, so they are listed separately.
- majordomus.knowledge-integrity
- majordomus.checkpoint-freshness
- majordomus.ledger-integrity
- majordomus.blocker-resolution
- majordomus.decision-records
- majordomus.scope-integrity
- majordomus.state-consistency
- majordomus.task-on-the-mesh
- majordomus.use-case-coverage
- majordomus.obligation-closure
- majordomus.completion-gates
The moments this answers
- found two agents fixing the same bug in two branches Two workers spend a day each on one defect because ownership was implicit and neither could see the other.
- watched a session undo last week's decision, for the reason it was made A decision whose reason lived in a conversation cannot be reviewed, only re-argued — by a worker with less information than the first one had.
- found a task "in progress" that nobody had touched for three weeks A status that was authored rather than computed is true at the moment of writing and decays silently from then on.
- watched one worker revert another worker's change, on purpose A worker sees an unexplained change in its path, judges it wrong, and removes it — correctly, on the evidence it had.
- found five worktrees and could not say which of them still mattered Isolation is cheap to create and expensive to reason about: nothing records what a worktree was for or whether its work landed.
- had two sessions writing into one checkout without either knowing Two workers in one working tree see each other only as unexplained file changes, and each treats the other as noise.
- found a substantial change that no issue, ticket or plan ever asked for Work arrives with no bounded contract behind it, so its scope, its acceptance criteria and its ownership are all decided after the fact.
- was asked who made a change and under what policy, and had only a commit Attribution stops at the commit, so what authorised a change, what verified it and what governed it are unrecoverable.