Profiles
one bundle per task class, each setting capability class, reasoning effort, verbosity, presentation, context toggles, verification, and checkpoint interval independently
one bundle per task class, each setting capability class, reasoning effort, verbosity, presentation, context toggles, verification, and checkpoint interval independently
Where it lives
State it owns
What implements it
Specified in
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.checkpoint-freshness advisory enforced by check, watch A task whose last checkpoint is older than its profile's interval is reported, not stopped.
- majordomus.policy-integrity blocking enforced by doctor, watch The policy and every profile parse, declare version 1, and carry no key the schema does not define.
- majordomus.profile-requirements blocking enforced by finish A profile may demand more than the shared contract — a regression test, a decision record — and finish refuses without it.
What is guaranteed
- guaranteed Every profile is parsed, its unknown keys rejected, and the default profile proven to existproved by test/cases/02_doctor_basic.sh
- advisory Capability class, reasoning effort, output verbosity, context and verification are five independent axesproved by test/cases/03_update.sh
- advisory A profile names a capability class rather than a vendor modelproved by test/cases/03_update.sh
- advisory A profile declares which context a worker should load and no moreproved by test/cases/04_start_check.sh
- advisory Escalating reasoning effort after repeated blocked attempts is recorded rather than assumedproved by test/cases/03_update.sh
- advisory A profile sets how often a worker should checkpoint, and a stale task is reportedproved by test/cases/04_start_check.sh
- guaranteed The context a worker is given is assembled from durable state in authority order, and what a profile excludes is excludedproved by test/cases/23_context.sh
- guaranteed The assembled context obeys a line budget, and every section it drops is named with its reasonproved by test/cases/23_context.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.checkpoint-freshness
- majordomus.ledger-integrity
- majordomus.blocker-resolution
- majordomus.decision-records
- majordomus.scope-integrity
- majordomus.state-consistency
- majordomus.use-case-coverage
- majordomus.obligation-closure
The moments this answers
- watched the strongest model, at maximum effort, rename a variable Capability, reasoning depth, context size and verbosity collapse into one habit — everything on — because nothing ever named them separately.
- 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.
- found the rule for that directory in a README no session ever loaded A local rule is either in the always-loaded file, where every session pays for it, or beside the code, where nothing relates it to the path being edited.
- spent an hour discovering something the repository already knew, twice A worker learns something expensive about the codebase, uses it once, and it dies with the session because nothing turned it into a durable record.
- watched the always-loaded instruction file grow past a thousand lines Everything important gets appended to the always-loaded file, so every session pays for every rule and reads none of them carefully.
- let a fast, cheap session make a decision the whole codebase now lives with Capability is dialled down for cost and nothing distinguishes the tasks where that is prudent from the ones where it is expensive.
- could not say why one provider was used for that work and another for this Provider and model selection is made implicitly, per session, and recorded nowhere, so it cannot be reviewed or repeated.
- lost a failure a worker had already reproduced, because the session ended A failure observed inside a session is described in that session and nowhere else, so the next one starts from the report rather than the evidence.