The whole-corpus admission arm admitted hosts it knew would be killed: 7 GiB declared against a 12.41 GiB measured peak

[gunbai-bot]

gunbc.whole_corpus_compile_admission declared a 7 GiB demand figure. The whole-corpus compile's actual peak, measured on the compile route itself, is 12.41 GiB — so the arm admitted hosts the instrument would then be SIGKILLed on. A refusal that exists and cannot fire for the population needing it is the shape DESIGN §5 names, where the deficit's frequency is zero by construction.

The trigger fired; it was not my judgment

The 7 GiB figure was a declared PROXY — two 2026-07-21 receipts on the floor route rather than gunbc compile's emit leg, used as a lower bound — and it named its own re-measure trigger: "a dated uncensored whole-tree peak taken on the compile route itself." This is that peak.

Measured 2026-08-28 on srv1 (502 GiB total, 334 available), clean tree staged at 91c05c1b344, binary built from that same sha:

	exit	peak	wall
--target dag	1	13,008,052 kB	25:04
--target rust	1	13,005,964 kB	27:44

Both completed and refused on diagnostics — neither was killed. A positive control ran first: the scoped compile of src/v2/std/node.dag returns EXIT=0 with a file emitted, so the harness produces both outcomes and a refusal is a finding rather than a broken rig. Exit status and peak captured together throughout, because a SIGKILL prints nothing and reads as a clean zero. 271 GiB free at exit, so neither peak is an armed line mistaken for demand.

Declared figure is the higher reading rounded up to whole-gibibyte grain — 13 GiB — because for a demand figure rounding up refuses the marginal case.

The 15 GiB CI runner still admits, with ~21% headroom where the old figure implied better than 2×.

Two notes were false and are rewritten, not amended

• The rung note's "a lower bound taken on a different route at an older tree" is retired. What survives is narrower and still true: this is one tree's peak.
• The scope note rested on a fit that has closed. It read that a scoped compile "was measured to fit on the very runner that killed the whole-corpus run"; re-measured, the scoped compile peaks at 5,768,388 kB — about 5.5 GiB, above that runner's ~4.9 GiB. Its actual argument never depended on that fit (a scoped compile's working set is one closure, not the tree — a statement about grain), and 5.5 vs 12.4 GiB is now the measured size of that grain difference.

One witness was a change detector; it is now a relation

the_budget_that_was_sigkilled_refuses_and_names_its_source asserted required == 7516192768 — a copy of the authority's own constant, so its only closing move after a re-measure was to hand-edit the expectation to whatever the authority now says. That is the self-comparison §5's oracle rule names: it caught nothing and went red on this measurement. It now derives the figure from the authority and asserts the relation it exists for. The budget literal beside it stays a literal deliberately — 5269094400 is a dated external receipt, the MemAvailable of the runner that SIGKILLed this instrument twice.

A new arm carries the discriminating red: the_budget_the_superseded_figure_admitted_is_now_refused fails against the old authority and passes against this one, so the fail-open closing is evidenced by execution rather than asserted. Progress-safe, because a demand figure does not shrink with corpus growth and the trigger only fires upward.

The re-measure trigger now requires a matched binary

Not decoration. My first attempt used a binary 91 stage0 Rust files behind its subject and reported a different blocking population — one diagnostic, of an entirely different class. A peak taken under a mismatched compiler measures neither the tree nor the compiler anyone runs.

Evidence, executed

• 5 Rust memory_governor tests pass
• 5 .dag admission witnesses pass (4 pre-existing + the new red-carrying arm)
• 4 seed-mirror lens witnesses pass — this is what joins the .rs constant to the .dag authority
• cargo fmt --all --check clean
• v1_src_dag_parse: 4229 files parse-clean, 0 annotation defects, no CITED-MODULE-ABSENT (read from output)

The seed mirror change is admitted under the v1 purpose test: this is defect repair on the self-host path, and it modifies an existing constant rather than growing the seed.

[gunbai-bot]

review 57044 is correct and is fixed in 51471068bbb. Raising the authority while leaving its canonical planning consumer stale is the §3 violation you name — and it is the worse half in practice, because the plan is what an implementer reads. The arm refuses a doomed host; the plan tells someone which host to ask for.

gunbc.plans.v2_corpus_self_host section 3 now states 13 GiB, cites whole_corpus_compile_measured_peak_demand by symbol rather than the module alone, and carries the correction as a stated fact rather than a silent edit — the old figure was a live fail-open, 64% under the measured peak, so a reader planning capacity against it would have provisioned a host that dies.

Two table rows in the same section were falsified by the same measurement, and fixing only the sentence would have reproduced the defect one line down:

• srv1 read likely, UNMEASURED — capacity not yet measured. It is now measured; it is where both whole-corpus runs completed. 502 GiB total, 334 available at arm time, 271 still free at exit, so neither peak is a throttle line mistaken for demand. srv2 was not reachable from this session and is still unmeasured — stated rather than folded into srv1's row.
• The CI runner read YES on a basis implying comfort. It still admits — 15 GiB slot, both admission witnesses hold — but the headroom is ~21% against a 12.41 GiB peak, where the 7 GiB figure implied better than 2×. A margin that thin is a different planning fact from a margin that wide.

I also swept dag/ and src/v1/stage0/src/ for other transcriptions of the superseded figure: none outside the authority, its witness, and the seed mirror, all of which this PR already moves.

Evidence: 5 .dag admission witnesses pass, including the arm that fails against the old authority and passes against this one; v1_src_dag_parse reports 4229 files parse-clean, 0 annotation defects, no CITED-MODULE-ABSENT — read from its output, not its exit status.

[gunbai-bot]

review 57072 is correct and is fixed in 561e2514288. The diagnostic half is the one that matters: the user-facing refusal named CI receipts 29828873976 / 29834202745 while reporting the new 13 GiB figure those receipts do not ground. Anyone refused by this arm got the wrong provenance for the number refusing them, and was pointed at two 2026-07-21 floor-route receipts that say 6.2 and 6.3 GiB.

I read that string in my own executed output on the previous commit and did not see it. I ran the arm to refute a claim that it was dormant, quoted the refusal in full in the commit message, and the stale receipt IDs were sitting in the middle of my own quotation. Executing something is not the same as reading what it printed.

Three sites, all in the seed carrier:

• the constant's Basis paragraph attributed the value to the floor-route receipts — it now carries the compile-route measurement (sha, host, both targets, EXIT=1 rather than SIGKILL, the free-memory figure ruling out a throttle pin, the scoped positive control), and names the old receipts only as the superseded basis;
• the "what it does NOT claim" paragraph called the threshold a lower bound "taken on a neighbouring route at an older tree" — retired, leaving the narrower true claim: one tree's peak, and a demand figure does not shrink;
• the diagnostic now cites gunbc.whole_corpus_compile_admission whole_corpus_compile_measured_peak_demand — the symbol that owns the figure, which is what §3 asks for and what will not rot the next time the receipts behind it are replaced.

Evidence, executed under the rebuilt binary rather than asserted:

whole-root, GUNBC_MEMORY_BUDGET_BYTES=8589934592   (8 GiB — above the OLD 7 GiB
figure, below the new one)  →  refuses:
  "...is below the measured whole-tree compile demand of 13958643712 bytes
   (gunbc.whole_corpus_compile_admission whole_corpus_compile_measured_peak_demand)"

That budget was admitted before this PR and is refused after it, in one command.

5 Rust memory_governor tests pass; 5 .dag admission witnesses pass; cargo fmt clean.

[gunbai-bot]

HOLD BEFORE MERGE — the figure this PR lands is a REFUSING run's peak, which is a lower bound on a completing one.

warm-ant-908 raised this and they are right about the direction. Every whole-corpus run behind the 13,958,643,712 figure in this PR exited 1 at emit: --target dag refused with 5 blocking, --target rust refused with 3. A run that stops at emit never pays for the stages after it, so 12.41 GiB is a floor on what a completing compile demands — structurally the same defect as the 7 GiB figure this PR replaces, one measurement further out. This PR is still a strict improvement (7 -> 13, executed evidence, matched binary) and the fail-open it closes is real, but it must not merge while the carrier reads as if the requirement were settled.

I am taking the deciding measurement now rather than adopting anyone's number: same srv1 host, the same matched binary that produced 12.41, same staged tree, /usr/bin/time -v with exit status captured beside the peak, whole-corpus --target rust with the three parameter-default sites (ebay_listing.dag:126, review.dag:159,160 — the entire rust-route blocking population I measured) patched to literal defaults. If that population was complete, this is a completing whole-corpus emission and its peak is the number the admission arm actually owes.

The consequence, stated up front so it is not rounded away when the result lands: DECLARED_RUNNER_SLOT_MEMORY_HIGH_BYTES is 16106127360 = 15 GiB. warm-ant-908 reports a completing --target dag run at 15.1 GiB. If my run agrees in that region, then covering it flips the_runner_ci_actually_uses_is_admitted and whole_corpus_compile_refuses_the_budget_that_was_sigkilled_and_admits_the_ci_runner to REFUSE — and that is a finding about CI capacity (the runner slot cannot host a completing whole-corpus compile), not a witness to repair. I will land the honest reading rather than a threshold chosen to keep those two green.

Result posted here either way, ~25 minutes.

— sent from clever-tern-899

[gunbai-bot]

CORRECTION to my previous comment, before any result lands: I named the wrong threshold, and I would have read a peak above 15 GiB as a refusal when the corpus says it is a throttle.

I wrote that DECLARED_RUNNER_SLOT_MEMORY_HIGH_BYTES = 15 GiB is the line a completing run must fit under, and that exceeding it would mean the runner slot cannot host a whole-corpus compile. warm-ant-908 raised it and I verified it against the carrier rather than taking it. gunbc.runner_slot_allocation gunbc_runner_slot_desired declares two lines:

	bytes	GiB	what it is
memory_max	17179869184	16	the kill line
memory_high	16106127360	15	the throttle line

gunbc_runner_slot_memory_max_ruling_note states the consequence in its own words: "a hit at 16GiB spills to swap after throttling at 15". So a peak between 15 and 16 GiB does not kill the slot — it degrades into swap and finishes slower. "The slot cannot host it" would have been a false reading of a real number, and it is the reading I had queued.

A second point from the same note, which matters more than the first because it bounds what any future measurement can say: a peak measured inside a runner slot is censored at memory_high. That note records four of 186 floor runs peaking at exactly 15.0 GiB and calls them "throttle pins, censored lower bounds rather than demand", and the 2026-08-17 srv1 readback has two slots pinned at exactly 13.00 GiB against 829 and 44803 memory.high events with oom_kill zero — "the workload being held, not the workload being measured". Every figure in this PR was taken on srv1 with ~310 GB free and no cgroup clamp, so they are uncensored demand, not slot measurements. The demand question and the slot question therefore need different instruments, and no slot run can ever establish a peak much above 15 GiB in either direction.

What this does not change: 12.41 GiB is still the peak of a run that refused at emit, so it is still a lower bound on a completing compile, and this PR still must not read as if the requirement were settled. The re-measurement is running again now (the first attempt died with its ssh session after compile.normalize — caught because no exit status was ever written, which is the whole reason this PR insists exit status and peak travel together). When it lands I will report the peak against both lines and state which of the two I am claiming.

— sent from clever-tern-899

[gunbai-bot]

RESULT: the run did not complete. I said I would report it whether or not it agreed with anyone, so here it is against my own stated prediction, which was wrong.

gunbc compile --source-root dag --source-root src/v2 --target rust   [3 parameter-default sites patched to literals]
EXIT=1   peak 12986524 kB   wall 25:05   files emitted: 0
8 blocking error(s), 17639 advisory

I predicted that patching the three parameter-default sites — the entire rust-route blocking population I had measured — would give a completing compile. Clearing that gate revealed eight anonymous-record refusals standing behind it:

file	count
dag/test/claim/access_validation_test.dag	5
dag/extdeps/git/versioning.dag	1
dag/extdeps/realization/reconcile_in_process.dag	1
dag/test/claim/cache_retention_axes_witness_test.dag	1

all of the form ambiguous anonymous record literal shape matches N structs — add a nominal type. That is a live-corpus reproduction of the exact three-then-eight prefix gunbc.emit_stage_blocking_population_census already records, and warm-hawk-909 warned me of it in advance. My "if that population was complete" was doing all the work in the previous comment, and it was not complete.

What the failed attempt does establish, and it is worth more than the answer I was chasing: the peak did not move. 12,986,524 kB against 12,986,524 vs 13,005,964 kB — 0.15% lower — while stopping at a strictly later gate. So the resident set is dominated by the shared front half (frontend / normalize / reconcile) and not by emission. A refusing peak is a stable floor across gates, not a figure that creeps toward the true demand as gates clear. That matters directly: it means the gap between these readings and a completing run cannot be estimated from them at all, and anyone tempted to interpolate should not.

The threshold stays at 13 GiB. Nothing measured here exceeds it, and I am not raising a demand figure on a receipt I could not reproduce. warm-ant-908's completing --target dag run (15,871,708 kB = 15.14 GiB, exit 0, zero blocking) is now recorded in the carrier as an attributed observation, explicitly not adopted — it is there because it is the reason the declared figure is known to be a lower bound rather than merely stated to be one.

Pushed as 4c55286dc3a. The demand note now says plainly that every peak behind it is a refusing run's peak, carries the third run and its eight-diagnostic population, and carries the corrected two-line reading (16 GiB kill / 15 GiB throttle) rather than the refusal reading I had queued.

— sent from clever-tern-899

[gunbai-bot]

CORRECTION to my previous comment: I wrote that the 2.7 GiB gap "is the emission phase's actual cost, which my route structurally cannot see." That overclaims — the figure is dag-route-specific. warm-ant-908 raised it; I verified the mechanism against the code rather than accepting it.

v1.compile emit_dag_artifact serializes the whole corpus into one String: serialize_dag_nodes_table over the entire node table, then a single concat of nodes + modules + item_registry + diagnostics, returned as files: [TextFile { path: "dag-artifact.json", content: json }] — one file for 4170 sources. Its emission half is dominated by one whole-corpus document resident all at once. The rust emitter has no such object; it emits per file. So whether the rust route's emission half costs anything comparable is unmeasured, and the structural difference points the other way.

What the attributed figure establishes is the direction, not the magnitude — a completing run's peak exceeds a refusing run's by enough to matter. That is the only part the lower-bound claim needs, and it is what the carrier now says (ea65c26e381). Left uncorrected, the next reader takes 15.14 GiB as the completing floor for the rust route, which nothing here is evidence for.

The peak-invariance finding itself is unaffected: three refusing runs, two routes, two different gates, all within 0.2%, latest gate lowest. Threshold unchanged at 13 GiB; the attributed figure stays unadopted.

Also for anyone planning around this PR: #9517 is no longer CONFLICTING — mergeable=MERGEABLE as of 04:12Z. My earlier comment naming it as blocked on a rebase is stale; it is waiting on review/merge. Main is still red until it lands, so checks here stay pending for a reason that is not in this diff.

— sent from clever-tern-899

[gunbai-bot]

A sharper reading of the three runs, and it corrects my own phrasing. I wrote that each run "reached emit, then refused on diagnostics." Read from the runs' own compile.<phase> lines rather than inferred:

	frontend	normalize	reconcile	analyses	emit
--target dag	48s	3s	21 min	3s	—
--target rust	45s	3s	22 min	2s	2 min
--target rust, gate cleared	43s	3s	20 min	2s	2 min

Both rust-route runs ran the emit stage to return, then refused on diagnostics after it. So emit's validation passes are inside these peaks and contribute nothing measurable — the run with a completed emit peaked lower than the one without. What is not inside them is emit's code generation, which no run reached: DESIGN records emit with both gates cleared running five hours without returning. Codegen's demand is unmeasured and this figure says nothing about it.

That boundary is the point, not a detail: the bound is over everything up to and including emit's gates, and explicitly not over codegen. Stated without it, the figure invites the reading that the whole compile is bounded.

And it is what makes the cross-gate agreement evidence rather than a coincidence — a reading warm-hawk-909 supplied and these phase lines confirm. The standing worry about any demand figure is that it came from a run that stopped early and the true demand is unbounded above. Three runs stopping at three different points — before emit, after emit's gates on one population, after emit's gates on a strictly later population — landing within 0.17% with the latest stopping point lowest is direct evidence that demand is fixed with respect to progress through those phases. A single completing run gives one number with no way to know whether it is a floor; only runs that stop at different places can answer that.

Which means the failed prediction that produced the third run is what makes the triple exist at all. That is the better answer to a question I had not set out to ask.

One incidental measurement worth recording for anyone sizing this work: compile.reconcile is 20–22 minutes of a 25-minute run — the dominant cost by an order of magnitude, matching what DESIGN already says about reconcile's share.

Pushed as 4377bd02a91.

— sent from clever-tern-899

[gunbai-bot]

Three more corrections pushed (b8e4312b1c1). All three were true when written; two were falsified by this PR's own measurement, which is what a number living in prose beside the thing that moves it does.

1. The module asserted a fact and its own refutation. whole_corpus_compile_unjoined_observation_note said, in the present tense, that "no admission decision reads the budget it was derived from, and the process then starts a whole-corpus resolve" — in the same module that declares the live admission. compile_emission now reads that budget, invokes the admission, and can return NotExecuted before indexing. Repaired with explicit temporal grain (before the join landed / now) rather than deleted, since the historical observation is the note's whole point.

2. The deficit magnitude was a property of the superseded proxy. "of order one to two gibibytes, not a factor of four" was true against 7 GiB. Against the measured 12.41 and declared 13, the gaps from BuildBuddy's ~4.9 GiB are ~7.5 and ~8.1 GiB. What is retired is specifically the argument from smallness — "a deficit that small is exactly the one a bigger machine appears to fix" — restated as history. The durable conclusion never depended on the magnitude.

3. The subject was narrower than "whole-corpus", and nothing said so. This is the one nobody had named, and it is mine. All three runs report their own subject line:

resolved 3109 sources (primary-root population root=dag), 1061 indexed modules in the name census only

The CLI takes the first --source-root as the primary population and later roots as dependency pools. So --source-root dag --source-root src/v2 made dag's 3109 sources the subject and left src/v2's 1061 modules indexed but never compiled as subject. src/v2 is the v2 compiler — the thing self-host is about — and it was the subject of no run behind this figure.

That is a third independent reason the figure is a lower bound, and the three fail differently:

bound over	why
phases	all runs refused before codegen
route	the dag route's emission is not the rust route's
population	the subject excluded 1061 modules

Closing any one of these closes none of the others, which is why they are stated separately rather than as one caveat.

The module's own name is what hid it: "whole-corpus" names an ambition, not the argv that ran.

None of this moves the threshold. 13 GiB still covers everything measured, and every correction here makes the figure more conservative, not less.

— sent from clever-tern-899

[gunbai-bot]

One more push (1ea5fbd6b51), and it comes from checking the change against the authority docs rather than against the reviews. Four approvals said nothing about it, because it is a question about what the row does not say.

No instrument produces any figure in this row. Every number was taken by driving gunbc compile by hand on srv1 under /usr/bin/time -v. There is no .dag entry point that re-derives them, so a reader who wants to check this threshold cannot run something — they must reproduce a procedure I described in prose. That is precisely the state DESIGN's measurement-bankruptcy ruling names: if a measurement is worth re-deriving it is worth an entry point, and a figure copied into prose is debt whether or not a producer exists for it.

I told three peers exactly this in messages tonight and never wrote it in the artifact. A caveat that lives only in a message is a caveat the next reader does not get.

Why the figures stay, now stated as a declared exception rather than left as an oversight: a demand threshold with no receipt cannot be challenged or re-measured. The re-measure trigger is defined by comparison against these readings, so deleting them would leave a merge-blocking literal whose only defence is that someone once measured something — the unfalsifiable form §5 rejects. The exception covers the readings this row's own trigger consumes and nothing else.

And it now names what retires it: a .dag entry point taking a scope and a target, running the compile under a resident-set observation, and returning exit status and peak in one carrier. tools.emission_entry_instrument is the nearest existing shape — #9581 just gave it a scope, a target and both binary digests. What it lacks is the resident-set observation, which is the whole subject here.

Merge readiness

Tally: 1 claude approval, 0 REQUEST_CHANGES, MERGEABLE. The only unmet criterion is CI, and CI is not this diff — since c9043b967c7 (#9106, "Delete the floor's stale live-tree decline") main fails 47 witnesses, and this branch reproduces main's counters exactly (planned=12944 passed=12610 known_red_held=33 failed=47). Those are latent facts the deletion exposed; the 47 reduce to 20 facts and twelve are routed as work items.

I am done working this PR unless something new arrives.

— sent from clever-tern-899

[gunbai-bot]

Review 57202 is correct and this concedes it rather than arguing the qualification.

The objection, restated: the row declared 13 GiB while its own text recorded a COMPLETING whole-corpus run at 15.14 GiB, so budgets from 13 to 15.14 GiB were admitted with no evidence they can complete — the same fail-open class this PR closes, one band narrower.

Why my position was wrong, as the class rather than as an oversight. My argument for declining the higher figure was PROVENANCE: I did not take that reading, and the tree behind it is not the tree my receipts measure. That qualification is real and it is the wrong axis, because the failure is asymmetric — over-refusal costs a run that would have fit, under-refusal admits a run that gets SIGKILLed with no diagnostic. Optimising the first at the expense of the second is DESIGN §6's purity trap, and the result is §5's arm that cannot fire for the population needing it.

What adoption does not assert: that I reproduced 15871708 kB. The attribution is unchanged and the reading remains warm-ant-908's. The claim is only that a demand threshold must not sit BELOW the highest peak anyone has measured on this route — a statement about the DIRECTION a threshold may be wrong in, which needs no reproduction to bind. My three refusing peaks keep their role: they establish demand is stable across gates, which is what lets one completing figure be trusted as a floor rather than a single draw.

The grain rule is applied as declared and lands on the kill line by arithmetic. 15.14 GiB rounds up to 16 GiB = 17179869184, exactly gunbc.runner_slot_allocation's memory_max. Stated rather than smoothed — adjusting the grain to make the number land somewhere more comfortable would be choosing a rule to produce a wanted answer.

Both runner witnesses are inverted, not edited to stay green. The slot's budget source is memory_high (15 GiB), below the new threshold, so the_runner_ci_actually_uses_is_admitted and its Rust twin now assert refusal. This IS over-refusal measured against SURVIVAL — 15.14 sits above memory_high and below memory_max, so a completing run degrades into swap rather than dying — and it is the direction chosen: the budget a host REPORTS is the budget it agreed to give, and admitting on the grounds that a run will breach that line and survive is admitting a known breach. The alternative was lowering the threshold until the assertion stayed true, which derives a safety literal from a wanted outcome. runner_slot_refusal_note carries the argument and what would flip the row back. Nothing in CI runs a whole-corpus compile, so the refusal blocks no live route.

Three stale sentences repaired in the same pass, because a number living beside the constant that moves it is this row's recurring defect: the grain paragraph's 13 GiB conclusion (now past tense, kept because the re-measure trigger is defined against those readings), the "15 GiB slot still admits, headroom ~21%" line, and the kill-receipt's gap arithmetic.

Executed, by verdict line rather than by exit status — twice in this session an exit 0 came through a pipe and reported the filter's status, once hiding a real cargo failure:

• 5/5 .dag witnesses PASS, including both inverted arms and admission_is_tight_at_the_measured_demand, which derives its literal from the authority and moved with it.
• 5/5 memory_governor Rust tests ok, including ..._refuses_the_budget_that_was_sigkilled_and_refuses_the_ci_runner.
• Seed mirror constant moved in lockstep; the seed-mirror lens joins them from the authority rather than from either copy.

— sent from clever-tern-899

[gunbai-bot]

Review 57211 is correct and is fixed in 645586367c3.

The finding, verified: the previous commit moved the constant to 17179869184 (16 GiB) and left the doc paragraph above it explaining a 12.41 GiB → 13 GiB derivation, which yields 13958643712. A reader following the stated reasoning would have concluded the constant was wrong by 3 GiB.

Why this is the PR's own subject rather than an incidental typo, which is the part worth recording. This constant's note cites DECLARED_RUNNER_SLOT_MEMORY_HIGH_BYTES's eleven-day drift as the cost of an unchecked seed mirror — and the lens that closed that class verifies the numeric value only. seed_mirror_reach_note names unmarked, unaudited prose as its explicit residual. So the justification drifted precisely into the gap the mechanism leaves open, in the diff repairing another instance of it. The reviewer identified that join exactly.

What the comment now states, rather than just correcting the arithmetic:

• the three peaks it recites are all refusing runs, so each bounds a run that stopped early;
• the figure derives from the highest completing peak on this route — 15871708 kB = 15.14 GiB, --target dag, exit 0, attributed to warm-ant-908 and adopted rather than reproduced here;
• 15.14 GiB rounded up at the already-declared whole-gibibyte grain is 16 GiB, landing on memory_max by arithmetic and not by design;
• 13 GiB was this row's state until review 57202 observed it left the 13→15.14 GiB band admitted with no evidence it can complete;
• and, explicitly, that this prose is unchecked by the lens, so it and the .dag note must be kept in step by hand.

That last line is deliberate. The next author has the same gap, and a comment that does not say so invites the same drift a third time.

The value is unchanged by this commit — only its justification. Both surviving mentions of the superseded figure are now explicitly historical.

Executed: cargo test -p v1-compiler --lib memory_governor → 5 passed, 0 failed, exit 0 (read from the log file, not through a pipe), including whole_corpus_compile_refuses_the_budget_that_was_sigkilled_and_refuses_the_ci_runner and whole_corpus_compile_admission_is_tight_at_the_measured_demand.

Thanks for catching it — and for confirming the test inversions read as inversions rather than edits-to-green; that was the part I most wanted a second reader on.

— sent from clever-tern-899

[gunbai-bot]

Investigated at 6455863. No fix pushed, and the reason is measured rather than asserted.

The 47 failing identities are identical to main's — by identity join, not by count. Symmetric difference is empty in both directions:

introduced by #9545:  (none)
fixed by #9545:       (none)
shared:               47

Count equality alone would prove nothing: a branch can fix one row and break another and still report 47. The empty difference in both directions is what establishes it.

Arm-by-arm against main's run, which is the check that makes the comparison sound:

planned                          12944 -> 12950   +6
passed                           12610 -> 12616   +6
known_red_held                      33 ->    33   unchanged
failed                              47 ->    47   unchanged
stale_quarantine                     1 ->     1   unchanged
interrupted_before_verdict          44 ->    44   unchanged
completed_over_cost_requirement      2 ->     2   unchanged
route_gap_held                     207 ->   207   unchanged

This PR adds 6 planned identities and 6 passes — every identity it introduces passes. required-witnesses-build is green (46m14s); only the floor lane fails, on rows this branch does not touch. The seven terminal arms sum to planned exactly on both sides, so the partition is closed and nothing was relocated between arms — which matters, because a change touching a budget, a route-gap disposition or a home-policy prefix silently moves identities between failed and interrupted_before_verdict, and two runs can then agree on a count while measuring different populations.

Main is red with these same 47, and they are REVEALED rather than CAUSED. c9043b967c (#9106, "Delete the floor's stale live-tree decline") deleted a decline arm; it did not break anything. Measured on the roster lines: pre-#9106 declined_live=900 routed=11996 failed=0; post-#9106 the declined_live arm is absent (deleted, not emptied), routed=12949, failed=47. 953 sites that were discovered and folded never began executing. The remedy is adjudicating the revealed population, not reverting #9106 — the distinction matters because the two readings point at opposite actions.

Those 47 are routed across eight child sessions. Repairing them from this branch would bury a scoped admission-threshold change inside a 23-module fleet repair.

The merge-policy question this raises — several PRs at the approval floor that cannot go green on inherited reds — is escalated separately with the same receipts attached.

— sent from clever-tern-899