The pool census read every function body to throw it away 82ms later: a heads reading of the same grammar, 2x on the corpus parse

[gunbai-bot]

The defect

pool_parse tokenizes and parses all 3875 corpus modules to build declaration heads, and census_heads_module_node replaces every function body with a shared stand-in 82ms later. The attribution probe (#9096's sibling, docs/probes/edge_index_tree_census_attribution_2026-08-24.md) measured that as 7.15s of the row's 14.24s and deliberately shipped no repair, naming it this class's next-rung trigger:

§6's bare minimum cost standing rule says a proven cost-shape defect is ALWAYS fixed […] It is this class's next-rung trigger, it is owed under §6, and it wants its own PR — not its own excuse.

This is that PR.

What it is — a reading, not a mode beside the parser

ParseContext carries heads_only; parse_heads_with_table is the entry that sets it. Every item head is parsed by the same productions. A brace-delimited fn-shaped body is skipped at token grain — depth-counted over brace shapes, which the tokenizer already decided, so a brace inside a string is not a brace — and the body slot takes the loud CensusHeadsBodyStripped stand-in.

Two things make this a reading of one grammar rather than a second, weaker parser:

• One spelling for the body. All four fn-shaped body sites (fn, func, pattern, interface) route through a single parse_item_block_body. No call site chooses, so the readings cannot drift apart per site.
• The census strip is kept, not folded into the parser. It normalizes the body slot on both readings. So the stand-in's exact shape is not a fact any consumer can depend on, and the two readings can only differ through the heads — which is precisely the surface the receipt measures. Deleting the strip as "now redundant" would have swapped a construction for a promise.

Measured — claim_executor --heads-reading-differential

3880 modules, roots dag + src/v2, both readings in one process over the same module list, census strip applied to both, compared as an identity:

compared=3880 divergent=0 narrowed=0 regressed=0 both_refused=0

run	full reading	heads reading	ratio
1	12175 ms	5885 ms	2.07x
2	11030 ms	5559 ms	1.98x
3	12882 ms	6382 ms	2.02x

Quote the ratio, not the absolutes. This is a shared container; the walls move ~15% run to run, the ratio does not, because both readings in a run pay the same contention. And it is the parse term only — tokenize and build_newline_index are outside both timers and unchanged by this — so it is not a claim about the whole pool_parse row.

RED control — the instrument can fail

One token mutated in the emitted mirror (depth + 1 → depth + 0, so a nested { stops deepening the count):

compared=3880 divergent=0 narrowed=0 regressed=2820 both_refused=0

2820 of 3880 red, exit 1. Reverted from the regen candidate, rebuilt, re-measured green (exit 0) — the restored tree is the one measured, not assumed restored. The mutation landing in regressed rather than divergent is why both columns exist: an early-ending skip leaves the stream mid-body and the next item refuses. Fail-closed, but not something to assume — a future mutation that does produce a silently shorter head list has somewhere to land.

Self-host fixed point

required-regen: first_generation_equal=true planned=134 executed=134 declared_divergent=1 [main.rs]
exit=0

The compiler built from this mirror re-emits this mirror. (main.rs is a pre-existing declared divergence.)

The one refusal this reading does not make — declared and counted

It refuses an unterminated body and every malformed item head, exactly as before. It does not refuse a well-braced but ungrammatical body — those tokens never reach the expression grammar.

That is a scope correction, not a hole: the required run's .dag parse sweep full-parses src/v1, dag and src/v2 and owns is the corpus grammatical. The census answering it a second time, as a side effect of building heads, was one fact with two authorities (§3) — and the expensive one, coupling every pool-derived resolve to the grammaticality of every body in the corpus.

What is honestly given up: for roots the sweep does not cover, that refusal is no longer taken anywhere. The sweep's roots are a superset of the required run's pool roots, so the live population is empty today. narrowed is its own counted column (0) rather than folded into pass or fail, so a future nonzero is visible instead of absorbed (§5).

Scope statements

• The differential is not enrolled in the required run, on purpose. Reading 3880 modules twice is exactly the cost this removes. Next-rung trigger: a diff-proportional form of the same check.
• No claim about pool_parse's whole row, and no end-to-end floor figure — different machine and architecture from the attribution probe, and the two sets are not subtracted from each other anywhere.
• v1 seed admission: PURPOSE test (operator ruling 2026-08-20) — a faster seed resolve is paid on every required-floor run.

Receipt: docs/probes/heads_reading_of_the_grammar_2026-08-24.md

[gunbai-bot]

The red is inherited from main, and the fix is already owned by #9133

witnesses failed on the merge ref fb304b3e1cea with:

required-ci: floor refused: REQUIRED-FLOOR REFUSAL cause=RouteGapFreezeIntersection count=4
  - test.claim.deploy_access_privilege_witness.witness_privileged_fixture_mutation_applies
  - test.claim.host_effect_apply_witness.witness_converged_is_settled
  - test.claim.host_effect_apply_witness.witness_oneshot_policy_terminal_not_converged
  - test.claim.host_effect_apply_witness.witness_shell_on_host_success_converges

Not this PR, and the check is mechanical rather than a judgement call. The refusal is an intersection of two declared rosters — v2.workflow.floor_route_gap floor_route_gap_roster and gunbc.witness_deferral_freeze frozen_path_deferrals. Both are static declarations. This PR's five files are the parser, its stage0 mirror, claim_executor, and a probe doc; it touches neither carrier, and nothing in a parse reading can add or remove a row from either.

Measured on origin/main itself, not inferred from the diff — all four identities are in both rosters at main's current head:

identity	in floor_route_gap_roster	in frozen_path_deferrals
all four above	yes	yes

Which two main commits produced it, by bisecting the carriers between main's last green run (0fcdd9d6d9d, 18:02Z) and its current head (8ab8a8e75af):

• 96cd1bff611 — Enforce route-gap freeze roster disjointness (Enforce pairwise witness-roster disjointness #9114) added the check.
• 664b339af06 — Delete the three unconditional shell.Exec mock arms (operator ruled) (Delete the three unconditional shell.Exec mock arms (operator ruled) #9049) added the four identities to floor_route_gap_roster.

At 0fcdd9d6d9d the identity is in the freeze roster and not in the route-gap roster (route_gap=0 freeze=1); at 8ab8a8e75af it is in both (route_gap=1 freeze=1).

Main has not yet rendered its own verdict on this, which is why it looks like a PR-specific failure and is not one: every witnesses run on main from 18:10Z onward — including the run for 96cd1bff611 itself — is still queued and has never executed. This PR's run is the first execution anywhere of the new disjointness check against the roster #9049 grew. The messenger, not the cause.

I am not pushing a fix, deliberately

gh pr list shows the line-stop is already owned: #9133 — "Retire four stale frozen_path_deferrals rows: the fleet-wide RouteGapFreezeIntersection line-stop", touching exactly dag/gunbc/witness_deferral_freeze.dag, MERGEABLE and open.

Pushing the same retirement here would mean two lanes editing one carrier for one fact, and would bundle an unrelated fleet-wide repair into a parser change — which is the thing that makes both harder to review and to revert. This PR waits on #9133 and then wants a re-run; it needs no change of its own.

If the operator would rather this PR carry the fix, say so and I will take it — but then #9133 should be closed rather than both landing.

— sent from quick-carp-438

[gunbai-bot]

Green — closing the loop on the inherited line-stop

#9133 merged (08488aee243), retiring the four stale frozen_path_deferrals rows. The intersection is now empty on main — measured per-identity rather than assumed: freeze=0 routegap=1 for all four, i.e. the freeze classification retired and the route-gap receipts preserved, which is the correct side to drop.

I merged main in rather than re-running the old check, because a rerun replays the previous merge ref and could not have told me whether #9133 fixed anything.

Both controls were re-taken on the merged tree, because main changed src/v1/02_parse.dag (#9028) and re-emitted four stage0 mirrors including this branch's own v1_compiler_parse.rs — a merge=generated-artifact path where a clean merge can silently take one side wholesale. A control taken before that merge says nothing about the tree that ships.

witnesses on 8872e487690	success
--required-regen, merged tree	first_generation_equal=true planned=134 executed=134, exit 0
--heads-reading-differential, merged tree	compared=3886 divergent=0 narrowed=0 regressed=0
parse wall, merged tree	10009 ms → 4995 ms (2.00x)

The .dag merge was also checked line-wise: all 7 lines this branch deletes relative to main are its own rewires (parse_block → parse_item_block_body, the occurrence_base signature). None of #9028 was dropped. The regen fixed point is what establishes the same for the mirror — on that path, coherence is re-derivation, not a clean merge.

Denominator moved 3880 → 3886 (main added modules); the ratio did not. The probe doc now marks the merged-tree run as the load-bearing measurement, with the three pre-merge runs kept as its history rather than quoted as current.

Not merging per the manual-merge policy. Worth stating plainly: the three approvals are all from one provider, so this sits at the one-distinct-provider floor, not at two independent reads.

— sent from quick-carp-438