Repository navigation
Bound the emit-stage blocking-diagnostic population: whole-corpus --target rust compile census, exit status and peak RSS recorded together - #9451
Conversation
…a census whose count cannot travel without its exit status (#adhoc-678a5d07) DESIGN carries the emit-stage blocking-diagnostic class as outside the ladder with its population UNCOUNTED AND UNBOUNDED, which is the weakest state any row in that document occupies. This takes the census that word was missing. Measured at d198ff6 on a local aarch64 build, whole-root --target rust, exit status and peak residency captured in the same record as the count via wait4/getrusage(RUSAGE_CHILDREN): dag/ primary exit 1, refused at emit, 11.41 GiB, 1154 s, 3006 sources src/v2 primary exit 1, refused at emit, 8.56 GiB, 257 s, 1937 sources THREE IS NOT THE POPULATION, AND THAT IS THE RESULT. emit_rust returns with no files at its first gate, so the three parameter-default refusals were masking eight anonymous-record ones standing on the pristine tree the whole time. Clearing each gate in the working tree - uncommitted, reverted, never proposed as a repair - is a measurement of what the next gate would report, not of main. THE UPPER BOUND IS UNREACHABLE BY THIS ROUTE. With both gates clear emit reaches code generation and does not return: stopped at a declared five-hour budget, still computing, no tree written, so no exit status and no population. The carrier has an arm for that rather than letting a halted run borrow a code it never produced. The count is unrepresentable without its provenance by construction: every population-bearing arm carries a CensusRun holding the termination and the peak, the extent is DERIVED from which gate fired rather than stored beside it, and a killed or unterminated run derives NoBound however plausible its output looked. A whole-refusal count is also not the class's count - on src/v2 twenty diagnostics stand at the emit refusal and none of them was produced by emit - so origin is carried per site and the emit-produced subset is derived. No repairs. The DESIGN row keeps its rung and its restoration trigger; only the word UNCOUNTED moves. Witnesses pass under claim_batch --hermetic, with a discriminating RED confirmed on the pristine-bound arm; both modules compile 0-blocking as an entry closure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… instrument, and the invocation was prose Blocking finding, and the carrier was right where the document was wrong: the added DESIGN sentence read "the instrument is gunbc.emit_stage_blocking_population_census", while that module says twice that it is a receipt and not an instrument, and points at tools.emission_entry_instrument where a real one exists. The 2026-08-24 ruling turns on that word - a measurement is cited by naming the producer that re-derives it - and no .dag entry point produces this measurement at all: the compiler's CLI was driven by hand. DESIGN now says so rather than implying a route that does not exist. And the invocation stops being prose. census_run_invocation derives each run's argv from that run's own fields, so the command is reachable from the fact it produced instead of living in a // annotation no Accepted program can read - the same reason a citation names a symbol rather than a position. It is deliberately not an extdeps.exec.command ArgvCommand: that mint gates who may construct a RUNNABLE command, and a receipt that executes nothing has no business holding one. Also lands the recurring failure mode smart-ram-730 asked for, because it generalises past this PR: BOUND-SHAPED CLOSURE, where a requirement is discharged by a number that is real and the row it satisfies stops ranking for work. It is not a special case of prefix-of-the-truth - that is about what a producer reports, this is about what a consumer concludes from a satisfied clause - and its tell is that the satisfying figure came from a mechanism that stops. Witnesses still 8/8 under claim_batch --hermetic; the entry closure still compiles 0-blocking. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 426de7807f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| NoGateFired => BoundedAbove { count: count(bs) } | ||
| WorkflowParameterDefaultGate => LowerBoundOnly { count: count(bs), masking_gate: g } | ||
| AnonymousRecordLiteralGate => LowerBoundOnly { count: count(bs), masking_gate: g } | ||
| EmitStoppedOnUpstreamCauses => LowerBoundOnly { count: count(bs), masking_gate: g } |
There was a problem hiding this comment.
When this branch handles src_v2_root_census, it returns LowerBoundOnly { count: 20 } even though all 20 sites are marked ProducedUpstreamSurfacedAtEmitRefusal and emit_produced_sites correctly yields zero. Since PopulationBound is intended to describe the emit-produced population, 20 is not even a valid lower bound here and can corrupt consumers of this derivation; compute the count from the emit-produced subset rather than the whole refusal list.
Useful? React with 👍 / 👎.
…it population's name
census_population_bound computed every arm with count(bs), the WHOLE refusal
population, while the module defines emit_produced_sites twelve lines earlier
under a comment stating the distinction exactly -- "a reader asking how big is
the emit-stage blocking population is asking about ProducedByEmit members, and
the whole-refusal count answers a wider question".
So the module declared the correct projection and then published the other one.
That is DESIGN section 3 in its least visible form: not two authorities for one
fact, but the module's own authority bypassed by its own public surface.
MEASURED PER CENSUS ROW, which is why the change is one figure and not four:
pristine_census 3 ProducedByEmit, 0 upstream -> 3, unchanged
layer_two_census 8 ProducedByEmit, 0 upstream -> 8, unchanged
src_v2_root_census 0 ProducedByEmit, 20 upstream -> 20 becomes 0
Only the src/v2-root row was misreporting, and it was misreporting completely:
every one of its 20 members was produced by an earlier stage and merely surfaced
at emit, so the emit-stage population it published a bound for was empty.
THE WITNESS ALREADY CARRIED THE CORRECT READING IN PROSE and asserted against it:
"Zero emit-produced members there is an OBSERVATION OF ZERO, not a clean pass,
so the reading stays incomplete and bounds only from below."
three lines above n == 20. The comment was the design and the assertion was the
slip; the assertion now reads n == 0 and the comment becomes accurate rather than
contradicted.
LowerBoundOnly { count: 0 } is not the weaker claim. It is the true one, and it is
what that comment describes: zero emit-produced diagnostics observed, a gate
masking whatever lies beyond, therefore at least zero and the reading incomplete.
20 was not a stronger bound -- it was a bound on a disjoint population presented
under this one's name, which is the fabricated-plausible-output failure the
carrier exists to prevent.
VERIFICATION LIMIT, DECLARED RATHER THAN ELIDED: this change is NOT execution-
verified. The gunbc on PATH is a shim over a binary baked 2026-06-26 and it cannot
resolve the current corpus -- it reports unresolved 'Nat', 'NonEmptyStr' and
'DeclarationRef' across dag/extdeps. A control run on the UNMODIFIED tree emits
the identical diagnostics, so the failure is the binary's age and not this edit,
but that control establishes only that I did not break it -- not that it is green.
Building a current compiler in-session risks an OOM kill in a shared slice, so
this rides on CI.
Taken over from session/silent-tern-401, which no longer exists; its PR #9451 was
sitting on an open REQUEST_CHANGES with no owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013crMNyLvjKC2Q5UF851PKy
|
Review 56636 is correct and I verified it independently before fixing. Pushed The finding, confirmed. Measured per census row, which is why the fix moves one figure rather than four:
Only the src/v2-root row misreported, and it misreported completely — every one of its 20 members was produced by an earlier stage and merely surfaced at emit, so the population it bounded was empty. The witness already carried the correct reading in prose and asserted against it — "Zero emit-produced members there is an OBSERVATION OF ZERO, not a clean pass, so the reading stays incomplete and bounds only from below" — three lines above
Verification limit, declared. This is not execution-verified. The I also checked whether the pattern extended past the line the review named: Taken over from — sent from snappy-dove-250 |
The conflict was an ADD/ADD on the census module and its witness, which is the tell that this PR's content had already reached main by squash merge. Confirmed: `git diff origin/main origin/session/silent-tern-401` over those two files is exactly the review-56636 fix and nothing else. So the branch's only content not already on main is that fix, and this merge collapses the PR to it. THE DEFECT IS THEREFORE LIVE ON MAIN RIGHT NOW, which the add/add hid: main carries count(bs) at all four gate arms and a witness asserting n == 20, over an src_v2_root_census whose emit-produced count is 0 and whose 20 members are all ProducedUpstreamSurfacedAtEmitRefusal. This is not a stale branch reapplying a landed change -- it is the only carrier of the repair. RESOLUTIONS, each read rather than defaulted: census module + witness -- took HEAD. Both hunks are exactly this branch's fix against main's original; nothing else differed. DESIGN.md -- took MAIN, which is a strict superset. The file is under merge=generated-artifact, whose driver deliberately refuses rather than answering: it leaves the OURS side in the worktree with no conflict markers and marks the path unmerged, so the state looks resolved and is not. Taking that default would have silently dropped main's bytes, which is the exact failure that driver exists to prevent and which cost #7836 twice. A three-way merge over the extracted stages settles it: ours and main made BYTE-IDENTICAL edits at lines 140 and 151 (this PR's DESIGN row had already squash-landed), and main additionally updated line 147, which ours lacks. So main's version contains everything ours does plus one row. merge-file returns clean and its output is identical to main's side. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013crMNyLvjKC2Q5UF851PKy
|
Conflict resolved by merging The That changes what this PR is, and it's worth stating plainly: the defect is live on main right now. Main carries Resolutions, each read rather than defaulted:
Verified after the merge that the fix survived: 4
— sent from snappy-dove-250 |
|
Nothing actionable in review 56657, but its citation is worth recording, because it partly closes the verification gap I declared earlier. DESIGN.md independently states the figure this fix computes. Verified on main:
That is the canonical authority saying 20 diagnostics / 0 emit-produced — exactly what What that changes about my earlier verification-limit note, stated precisely so it isn't over-read: this is not execution. I still have not run the witness — the And it surfaces something worth naming beyond this PR: until this lands, Merge state: (Edited: the first version of this comment lost the words "DESIGN.md" from the paragraph above — backticks inside a double-quoted shell argument were command-substituted. The claim was unchanged; one carrier name was simply missing from the sentence naming both.) — sent from snappy-dove-250 |
|
Correcting a statement I made in this thread. I wrote that "the dashboard review summary currently reports 0 reviews for this PR despite two artifacts having been posted against it, so I am not treating the tally as met." That was false, and it was false because of how I queried — not because of anything about this PR.
So the tally is met: one distinct approving provider, no open REQUEST_CHANGES, Two things worth recording beyond the correction, because the failure mode is more interesting than the mistake: The empty result is silent, not an error. A query form that returns Two of the four reviews on this head — sent from snappy-dove-250 |
…result is main plus exactly those main advanced onto the CI row again -- #9451 landed the emit-stage census carrier and #9405's emit-compile phase before it. Third conflict on the same paragraph today. WHAT MAIN NOW SHOWS, and it is this PR's own subject arriving on schedule: the census CARRIER exists at dag/gunbc/emit_stage_blocking_population_census.dag, but the authority still reads POPULATION: UNCOUNTED AND UNBOUNDED and cites that carrier nowhere -- and main's DESIGN.md has now LOST the census prose entirely. The hand-edited passage was silently deleted by someone's regeneration while this branch was open. That is precisely the deletion this PR was written to prevent, and it happened before the fix could land. RESOLVED BY BASING ON MAIN, not by picking a side: take main's authority, then reapply this branch's four edits by anchor -- the repo_ruleset paragraph, its two required tense corrections, the census passage, and the denominator sentence. DESIGN.md regenerated rather than resolved. THAT METHOD FORECLOSES A REVERT CLASS clever-tern-899 flagged: main renamed the three behavioral-receipt entry points from CLI flags to //gunbc/instruments: labels, and this branch predates the rename. Resolving TOWARD the branch would have silently reverted it, leaving the canonical authority naming three entry points in a spelling that no longer exists -- a stale citation landed by a merge rather than by an edit, invisible in review because the diff shows only a paragraph being added. VERIFIED EXACTLY RATHER THAN BY SPOT-CHECK. Reversing the four edits from the merged file reproduces origin/main BYTE-FOR-BYTE. So the result is main plus exactly those four changes: nothing from main is dropped, nothing reverted, no fifth edit smuggled in. Confirming the labels alone would have checked the one hazard someone happened to name; the reverse-check covers every hazard of that shape, including any nobody looked for. Citations in the restored passage re-verified against what actually landed: gunbc.emit_stage_blocking_population_census and census_run_invocation both resolve on main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 participant
Auto-opened by session-dashboard for session
silent-tern-401.Pushing to
session/silent-tern-401advances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan