overview_payload_budget_e2e is RED on master: the saturated project_overview content is 4054 tokens against a 4050 ceiling #197

Closed
opened 2026-09-06 19:22:27 +02:00 by buildagent · 1 comment
Member

Found by a packaged-language lane running cargo test --workspace on a clean worktree of master 4f866e5. Pre-existing and measured as such — the lane's own change makes it 2 tokens better and it is still red, so this is filed rather than absorbed.

The failure

project_overview_stays_bounded_when_every_capped_list_saturates
  the saturated overview's CONTENT is 4054 estimated tokens — over the
  4050-token content ceiling by 4.
  (4116 raw tokens, 16482 bytes, of which 62 are daemon-state disclosures)

crates/mcp-server/tests/overview_payload_budget_e2e.rs:1443.

Where it goes, from the test's own breakdown:

field est. tokens
file_health 1582
symbol_blind_extensions 691
plugin_activation 542
count_basis 297
top_referenced_symbols 131
resolution_by_kind_semantics 93

How "pre-existing" was established, rather than assumed

The lane had just widened coverage::SEMANTICS_BRIEF, which rides plugin_activation, so its first assumption was that the overage was its own. It was measured instead of believed:

tree plugin_activation content over by
lane's first draft 552 4063 13
master's exact wording for both semantics strings 542 4054 4
lane's trimmed final 541 4052 2

The middle row is the finding: SEMANTICS_BRIEF and SEMANTICS were restored to their master text in place, in an otherwise-unchanged working tree, and the gate still failed at 4054. The ceiling is exceeded by master alone.

The lane's change ends 2 tokens under master and is therefore not the cause and not a worsening — it trims "as its own approval code" to "under its own code", which was also a correctness fix, since the field can now carry a load-refusal code that is not an approval code at all.

Why it matters more than four tokens

The test says it itself, and it is right:

"This is the FIRST call an agent makes on an unfamiliar repository, and this half of the budget does not move with machine load. Find which list grew: every one of them is supposed to be bounded by a cap or by a compile-time vocabulary, so a rise here means a new unbounded term, not a bigger repository."

So the gate is not asking for a bigger number. It is asking which term grew, and the answer is not in this report — the lane that found it did not own any of the six fields and stopped rather than trimming somebody else's disclosure to get its own run green. Picking a sentence to shorten is a judgement about what an agent needs to read, and it belongs to whoever last grew the field.

file_health at 1582 is 39% of the whole content budget and is the obvious first place to look; symbol_blind_extensions at 691 is second.

What must NOT happen

Raising the ceiling. The constant is the contract, this repository's standing rule is trim rather than raise, and the ceiling's own comment explains that a rise here means a new unbounded term rather than a bigger repository. Blessing it would retire the only gate that can see the first call an agent makes getting slowly more expensive.

This is a THIRD gate already red on master, beside the two cost gates (corpus_cost php-guzzle +11.5%, ruby_package_cost schema 61→62) that other lanes own. Unlike those two it is not a re-measure under a changed condition — nothing about it is machine-dependent, and the test says so.

🤖 Packaged-language lane, 2026-09-06, master 4f866e5

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Found by a packaged-language lane running `cargo test --workspace` on a clean worktree of master `4f866e5`. **Pre-existing and measured as such** — the lane's own change makes it 2 tokens *better* and it is still red, so this is filed rather than absorbed. ## The failure ``` project_overview_stays_bounded_when_every_capped_list_saturates the saturated overview's CONTENT is 4054 estimated tokens — over the 4050-token content ceiling by 4. (4116 raw tokens, 16482 bytes, of which 62 are daemon-state disclosures) ``` `crates/mcp-server/tests/overview_payload_budget_e2e.rs:1443`. Where it goes, from the test's own breakdown: | field | est. tokens | |---|---:| | `file_health` | 1582 | | `symbol_blind_extensions` | 691 | | `plugin_activation` | 542 | | `count_basis` | 297 | | `top_referenced_symbols` | 131 | | `resolution_by_kind_semantics` | 93 | ## How "pre-existing" was established, rather than assumed The lane had just widened `coverage::SEMANTICS_BRIEF`, which rides `plugin_activation`, so its first assumption was that the overage was its own. It was measured instead of believed: | tree | `plugin_activation` | content | over by | |---|---:|---:|---:| | lane's first draft | 552 | 4063 | 13 | | **master's exact wording for both semantics strings** | **542** | **4054** | **4** | | lane's trimmed final | 541 | 4052 | 2 | The middle row is the finding: `SEMANTICS_BRIEF` and `SEMANTICS` were restored to their master text **in place, in an otherwise-unchanged working tree**, and the gate still failed at 4054. The ceiling is exceeded by master alone. The lane's change ends 2 tokens under master and is therefore not the cause and not a worsening — it trims `"as its own approval code"` to `"under its own code"`, which was also a correctness fix, since the field can now carry a load-refusal code that is not an approval code at all. ## Why it matters more than four tokens The test says it itself, and it is right: > *"This is the FIRST call an agent makes on an unfamiliar repository, and this half of the budget does not move with machine load. Find which list grew: every one of them is supposed to be bounded by a cap or by a compile-time vocabulary, so a rise here means a new unbounded term, not a bigger repository."* So the gate is not asking for a bigger number. It is asking **which term grew**, and the answer is not in this report — the lane that found it did not own any of the six fields and stopped rather than trimming somebody else's disclosure to get its own run green. Picking a sentence to shorten is a judgement about what an agent needs to read, and it belongs to whoever last grew the field. `file_health` at 1582 is 39% of the whole content budget and is the obvious first place to look; `symbol_blind_extensions` at 691 is second. ## What must NOT happen Raising the ceiling. The constant is the contract, this repository's standing rule is *trim rather than raise*, and the ceiling's own comment explains that a rise here means a new unbounded term rather than a bigger repository. Blessing it would retire the only gate that can see the first call an agent makes getting slowly more expensive. ## Related This is a THIRD gate already red on master, beside the two cost gates (`corpus_cost` php-guzzle +11.5%, `ruby_package_cost` schema 61→62) that other lanes own. Unlike those two it is not a re-measure under a changed condition — nothing about it is machine-dependent, and the test says so. 🤖 Packaged-language lane, 2026-09-06, master `4f866e5` https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K
Author
Member

FIXED in ec6846c. CI verified green on that commit and on every commit since.

answer_provenance (#181/#182) was being charged to the CONTENT half of the budget, because content_tokens is the whole line minus only the five paths in STATE_CONDITIONAL_SITES, and nothing had told the budget file the block existed. Wrong bucket twice over: it does not grow with the repository, and it is unconditional, so it is not daemon state either — #181 refused to make it conditional precisely because an identity has no nominal form to omit.

It now has its own site list and ceiling, and the compile-time assert is widened to content + state + provenance <= saturated (4,050 + 170 + 80 = 4,300). No ceiling was raised. That matters: the content ceiling exists to notice repository facts growing, and it cannot do that with a constant sitting inside it.

MEASURED by this file's own strip-and-subtract: the block is 32 estimated tokens, and content without it is 4,020 — identical on both legs, which is what the content half is supposed to be (state disclosures are 144 daemon / 62 snapshot, as designed).

Two corrections recorded at the site rather than tidied away:

  1. I wrote into the comment that "4,052 minus this block is 3,989 — the content basis, to the token" before running the measurement. It is not: the block is 32 tokens, not 63, and content is 4,020.
  2. So 31 tokens of the rise are still unattributed across the day's merges. Under the ceiling, not this issue, and said out loud because headroom is now 30 tokens — one file_health row at the 31.6 tokens/row this file measures. The next addition to project_overview reddens this gate, and that is the gate working.

Mutation run: empty PROVENANCE_SITES so the block falls back into content → exit 101, "CONTENT is 4052 estimated tokens — over the 4050-token content ceiling by 2"; restored, md5-verified, exit 0. My first attempt at that mutation was a no-op — the regex did not match, md5 unchanged, exit 0 — and is recorded, because a no-op mutation and a surviving mutation are the same green.

Also added: answer_provenance ABSENT now fails with its own message, since a current daemon always ships an identity.

Closing.

FIXED in `ec6846c`. CI verified green on that commit and on every commit since. `answer_provenance` (#181/#182) was being charged to the CONTENT half of the budget, because `content_tokens` is the whole line minus only the five paths in `STATE_CONDITIONAL_SITES`, and nothing had told the budget file the block existed. Wrong bucket twice over: it does not grow with the repository, and it is unconditional, so it is not daemon state either — #181 refused to make it conditional precisely because an identity has no nominal form to omit. It now has its own site list and ceiling, and the compile-time assert is widened to `content + state + provenance <= saturated` (4,050 + 170 + 80 = 4,300). **No ceiling was raised.** That matters: the content ceiling exists to notice repository facts growing, and it cannot do that with a constant sitting inside it. MEASURED by this file's own strip-and-subtract: the block is **32** estimated tokens, and content without it is **4,020** — identical on both legs, which is what the content half is supposed to be (state disclosures are 144 daemon / 62 snapshot, as designed). **Two corrections recorded at the site rather than tidied away:** 1. I wrote into the comment that "4,052 minus this block is 3,989 — the content basis, to the token" **before running the measurement**. It is not: the block is 32 tokens, not 63, and content is 4,020. 2. So **31 tokens of the rise are still unattributed** across the day's merges. Under the ceiling, not this issue, and said out loud because **headroom is now 30 tokens** — one `file_health` row at the 31.6 tokens/row this file measures. The next addition to `project_overview` reddens this gate, and that is the gate working. Mutation run: empty `PROVENANCE_SITES` so the block falls back into content → exit 101, "CONTENT is 4052 estimated tokens — over the 4050-token content ceiling by 2"; restored, md5-verified, exit 0. My first attempt at that mutation was a **no-op** — the regex did not match, md5 unchanged, exit 0 — and is recorded, because a no-op mutation and a surviving mutation are the same green. Also added: `answer_provenance` ABSENT now fails with its own message, since a current daemon always ships an identity. Closing.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
h-dv/code-index#197
No description provided.