Skip to content

A profile declares which context a worker should load and no more

Each profile carries context toggles — task, current state, decisions, relevant files, failing output, recent history depth, architecture notes — and the always-loaded instruction file tells the worker not to read the whole repository to orient but to load what the profile names. The routine profile loads the task and the current state; deep-work adds architecture notes and two hundred commits of history.

advisory Projected into the worker's instructions. Whether a worker honours it is not observable from outside. Documentation, not enforcement.

majordomus context now assembles a briefing from those toggles, and that selection is guaranteed (see context-assembly). This claim stays advisory because nothing measures what the worker actually read once it has been handed the briefing.

What it means

Each profile carries context toggles — task, current state, decisions, relevant files, failing output, recent history depth, architecture notes — and the always-loaded instruction file tells the worker not to read the whole repository to orient but to load what the profile names. The routine profile loads the task and the current state; deep-work adds architecture notes and two hundred commits of history.

How it works

The toggles are validated fields in the profile; check --explain prints them for the active task; the projected body carries the rule "Load minimum sufficient context" as the second of ten. The always-loaded budget (a guaranteed claim) caps the one file every session must read.

How to see it

majordomus check --explain | grep '^  context\.'

What it does not cover

Advisory. Nothing measures what the worker actually read. The budget on the always-loaded file is the only guaranteed part of context control in v0.1; runtime clamps on read size are planned.

Why it exists

Context per session was the largest cost term in the environments studied, and the least managed: a session ran out of context mid-mission, a best-practices document prescribed re-sending the objective every fifty messages, and a one-megabyte knowledge store was referenced from nowhere.

Detail rendered from docs/claims/minimum-context.md.

Provenance

defined in
read it on this site · share/skeleton/profiles/routine.yaml
implemented in
lib/check.sh · majordomus check
proved by
test/cases/04_start_check.sh
claim id
minimum-context

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