Skip to content

The assembled context obeys a line budget, and every section it drops is named with its reason

context.builder_budget_lines caps what majordomus context prints. When the briefing would exceed it, sections are dropped — but never silently, and never the parts a worker cannot work without.

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

The count is of the printed document, not of its sections. Git, task, profile and open blockers are never dropped; record bodies degrade to a pointer before they disappear.

What it means

context.builder_budget_lines caps what majordomus context prints. When the briefing would exceed it, sections are dropped — but never silently, and never the parts a worker cannot work without.

How it works

Sections are dropped in a fixed order: recent history, then touched files, then decisions, then the bodies of the checkpoint and the handover. Git, the task, the profile and open blockers are never dropped, because a worker missing those is not under-informed but misinformed.

The two record bodies degrade rather than disappear: the section header stays and the body becomes body omitted for budget — read <path>, so the worker knows the record exists and where to find it.

Every drop is appended to the exclusion list with context budget <n> lines as its reason.

The count is of the document actually printed, header and trailer included — mj_ctx_render writes the whole page to a file and measures that file, re-rendering after each drop. An earlier version counted only the sections, which let a fifty-line page report "40 of 40 lines". A budget that reports a number smaller than the thing it governs is worse than no budget.

If what cannot be dropped is still over budget, the context is printed anyway and the exit code is 10: the worker gets the facts, and the caller learns the budget was not met.

How to see it

majordomus context --budget-lines 50 | tail -8
# ## EXCLUDED
# - history — context budget 50 lines
# - decisions — context budget 50 lines
#
# ## BUDGET
# 48 of 50 lines (dropped: history decisions)

# the reported count is the printed count
[ "$(majordomus context --budget-lines 50 | wc -l)" = 48 ]

majordomus context --budget-lines 5 >/dev/null; echo $?   # 10

What it does not cover

Lines, not tokens. The briefing is budgeted in lines, which any machine can count deterministically. What the separate context compiler selects is counted in tokens by majordomus economics measure (claim context-selection-counted); see ECONOMICS.md for what that measures and what it does not.

The budget governs the briefing, not what a worker loads afterwards. A worker is free to read the whole repository; nothing stops it and nothing measures it.

Why it exists

Context is the resource that runs out, and it runs out silently. A budget that is only advice is a wish; a budget with no visible exclusions produces a briefing that is mysteriously thin. Naming both — the cap and everything it cost you — is what makes the number actionable rather than decorative.

Detail rendered from docs/claims/context-selection-budget.md.

From the statement to the proof

  1. 1 · the public statement

    The assembled context obeys a line budget, and every section it drops is named with its reason

    Made on Context, Profiles.

  2. 2 · the canonical claim

    context-selection-budgetdeclared status: guaranteed in docs/CLAIMS.yaml

    Defined in read it on this site · share/skeleton/policy.yaml

  3. 3 · the implementation

    lib/context.sh · majordomus context

  4. 4 · the test and the scenarios

    Test: test/cases/23_context.sh

    Executed in Read only the context that fits the budget, and know what was dropped.

  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 23_context

Where this claim is used

Related claims same implementation

The moments this answers

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