Repository navigation
The required-lane axis was a hardcoded pair; make it a roster, with the emitted YAML byte-identical - #10036
Merged
Conversation
…he emitted YAML byte-identical
PR A of the two-part promotion item. Behaviour-identical §2 dedup, landing on its
own so the promotion row (PR B) waits on the fleet condition without holding this.
WHAT WAS FORKED. The aggregate's lane axis was `build_var` beside `floor_var`,
threaded through four functions and spelled 28 times in gunbc.required_lanes_gate
(`grep -c 'build_var\|floor_var'`). That is one concept -- a required lane --
given one name per instance, which is the fork §2 horizontal exists to delete.
THE TELL WAS THAT A CLAIMED ONE-ROW EDIT WAS NOT ONE. gunbc.witness_floor_workflow
at `rust_unit_tests_job_id` says promoting a third job into the aggregate is "a
one-row edit to `required_lanes_aggregate_job`". That was true of the shape the
aggregate had when it was written and had since gone stale: promotion was a
signature change in four places plus a step-name rewrite. Worse, the obvious
reading of it -- add the `needs` edge -- would have added the WAIT while granting
NO AUTHORITY TO BLOCK, because the gate's verdict reads named shell variables and
a lane whose result it does not read cannot fail it. A promotion that looks landed
and gates nothing is worse than no promotion, because the roster would then cite
it as coverage.
WHAT THE ROSTER IS. `RequiredLane { job_id, label, var_name }` -- three genuinely
distinct strings (`required-witnesses-build`, `build`, `BUILD`), each read by a
different surface, so collapsing any two would make one surface derive its
spelling from another's. FIVE surfaces now derive from the single
`required_lanes_roster()`: the verdict's or-folds, the receipt line, both refusal
messages, the step's `env` block, and the job's `needs` edge. Those last two were
previously hand-kept lists whose agreement nothing checked -- a lane in the env
but not in `needs` reads an unset variable, a lane in `needs` but not the env is
a job that runs and cannot block, and both are silent.
NON-EMPTY BY CONSTRUCTION, and this is the safety half rather than a shape
preference. The verdict is an OR-fold over the lanes, and an or-fold over nothing
is FALSE -- an empty roster would publish the required context GREEN over a gate
that read no lane at all. `FreeSemigroup` has no empty representation, so that
state is UNWRITABLE rather than validated: §4b(4) rather than §4b(2), and no
refusal arm is owed because there is no arm to write. Deliberately NOT a fresh
NonEmptyRequiredLanes carrier -- `free_semigroup_grounding_note` already names
five monomorphised copies of that shape as convergence debt and a sixth would be
the re-invention §2's own test forbids.
ACCEPTANCE TEST: THE EMITTED YAML IS BYTE-IDENTICAL. Producer, not transcription:
gunbc run --source-root dag --source-root src/v2 \
--entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet
then diff .github/workflows/witnesses.yml against its pre-change bytes. No
generated artifact in the tree changes; only the two authority files do.
AND THE BYTE-IDENTITY IS SHOWN NOT TO BE A STALE ARTIFACT, because a diff of zero
is readable only beside a nonzero. Two controls, both executed:
- mutate ONE roster field (label "build" -> "REDCTL") and regenerate: the diff
fires in THREE places -- the receipt line and both refusal messages -- proving
the emission reads this roster rather than surviving bytes.
- add ONE row to the roster (the rust-unit-tests lane) and regenerate: the
verdict fold grows a third `|| [ "$UNIT" != success ]` conjunct AND a third
`= failure` conjunct, the receipt grows ` unit=$UNIT`, both refusal messages
grow it, and the env block grows `UNIT: ${{ needs['rust-unit-tests'].result }}`.
That is the forward receipt that PR B really is one row, measured rather than
promised. Both probes were reverted; neither is in this diff.
The `rust_unit_tests_job_id` annotation is corrected to say what is now true, and
to record the two conditions that actually gate the promotion -- main green AND
the fleet toolchain fault fixed, the second because a host fault that evicts the
toolchain becomes a merge block on every PR the moment this lane gates.
NOT IN THIS PR, deliberately: the aggregate step is still named "Both required
lanes must have succeeded". "Both" becomes wrong only when a third lane lands, and
changing it now would break the byte-identity that is this PR's whole acceptance
test. It belongs to PR B.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct
…than asserted
Review caution: "unwritable in the ACCEPTED CORPUS" and "unwritable as SOURCE
HANDED TO THE COMPILER" are different claims, and section 4b says only the second
decides whether a RED is authorable. The previous note stated the guarantee
without saying which boundary it held at, which reads as stronger than it is.
MEASURED, NOT REASONED. A fixture module authoring `FreeSemigroup { tail: [] }`
was handed to the compiler and refused:
error[...empty_roster_probe.dag:9:3]: missing required field 'head' in literal
of type 'FreeSemigroup'
1 blocking error(s)
So the empty roster IS authorable as fixture source and IS refused there, located
at the literal -- the stronger of the two boundaries, established by execution.
The probe was deleted after the run and is not in this diff.
WHAT THAT DOES NOT ESTABLISH, and this is the half the caution was really about.
The refusal is the compiler's GENERAL record-completeness wall, not anything this
roster authored, and the roadmap node `floor-record-construction-wall`
(rn_ILWLG34LVL5SAS6QPN5GZDPMFY) records that wall's own evidence as not yet
enrolled -- a construction wall "currently rests on record-completeness
enforcement that is itself unmeasured". So the rung is honestly 4b(4) CONDITIONAL
ON that wall, and the next-rung trigger is that node's probe-pairing rather than
anything in this file. That is a tracked stall, not a permanent ceiling.
NO PER-CONSUMER FIXTURE ADDED, deliberately. Enrolling a local probe that asserts
the same corpus-wide refusal would be one more monomorphised copy of a general
property -- the same duplication that declining a sixth NonEmpty carrier avoids,
and it would attribute to this roster evidence that belongs to record
construction.
Emitted YAML unchanged: annotation only, re-verified byte-identical against the
same regeneration.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct
Contributor
Author
|
Two additions since the approving review, both from the manager's review of the same diff. The non-empty guarantee now states its boundary, and it is measured§4b distinguishes unwritable in the accepted corpus from unwritable as source handed to the compiler, and only the second decides whether a RED is authorable. The note stated the guarantee without saying which boundary it held at, which reads stronger than it is. So I handed the forbidden state to the compiler as a fixture: The empty roster is authorable as fixture source and is refused there, located at the literal — the stronger boundary, established by execution. The probe was deleted after the run. What that does not establish, which is the half worth reading: the refusal is the compiler's general record-completeness wall, not anything this roster authored — and the roadmap node I deliberately did not enroll a local fixture asserting the same refusal. That would be one more monomorphised copy of a corpus-wide property — the same duplication that declining a sixth The add-a-row control is PR B's forward receiptNaming it explicitly, since it is what retires the stale — sent from sunny-gull-270 |
…te it rather than restate it
Follow-up to the boundary statement. The manager's ruling: do not enroll a local
probe -- it would assert a corpus-wide property from one consumer and attribute
to the lane roster evidence that belongs to record construction -- but DO give the
receipt to the node where the class lives, one line each way.
roadmap_authority `floor-record-construction-wall` (rn_ILWLG34LVL5SAS6QPN5GZDPMFY)
now records in `red_control` that its RED arm has an executed specimen: a fixture
authoring `FreeSemigroup { tail: [] }`, refused with `missing required field
'head' in literal of type 'FreeSemigroup'`, located at the literal, 1 blocking
error. Stated with what it does NOT establish -- the every-corpus-literal-compiles
arm and the probe pairing remain unmeasured, so this node stays the trigger for
anything resting on this wall.
`red_control` is the right field and the budget does not reach it: the ~100-word
page budget is on `brief`, and `roadmap_ticket_brief_violations` walks
`declared_roadmap_nodes()` rather than the projection precisely so a long
red_control cannot price a derived node's brief a second time.
gunbc.required_lanes_gate's annotation now CITES that receipt instead of carrying
it, so the measurement has one home.
TWO THINGS VERIFIED RATHER THAN ASSUMED, both cheap and both nearly wrong:
- red_control has a real consumer -- `disclosure_field(label: "red control", ...)`
in roadmap_presentation -- so this is a receipt in a typed carrier, not prose
in a String field.
- the braces. `{ ... }` in a .dag string can interpolate, and neighbouring rows
in this same file escape as `\{cause\}`. Measured with a two-arm probe before
trusting it: `"FreeSemigroup { tail: [] } end"` and its escaped twin render
IDENTICALLY, so interpolation needs a bare identifier immediately after the
brace and escaping here would have emitted a literal backslash.
witnesses.yml re-verified byte-identical; no generated artifact changes (the
roadmap ticket fields are not projected into committed markdown).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct
Contributor
Author
|
Merged main ( Why this was not optional. Since this branch's base, main landed #10024, which changed Result, on the merged tree with a rebuilt This is a stronger receipt than the original, not merely a refreshed one: the refactor now reproduces an emitted file that a foreign change materially rewrote underneath it. If the roster projection disagreed with the hand-kept form anywhere #10024 touched, this is where it would have shown. The control was re-run too, since a pre-merge control proves nothing about the tree that ships: mutating one roster field ( Also note — sent from sunny-gull-270 |
briansrls
pushed a commit
that referenced
this pull request
Sep 2, 2026
… names the TREE it holds of Third roster row from this session, and the manager confirmed no other lane is carrying the class. Checked both neighbours before minting, since the last two findings belonged to rows that already existed: execution_provenance_loss asks whether the observation RAN. Here it ran, was valid, and then STOPPED being valid because its subject moved underneath it. positional_citation is a decaying HANDLE -- a pointer that no longer names what it named. Here the handle is fine; the EVIDENCE BINDING decayed. Different invalid states, different repairs, so a third row rather than an append. THE CLASS. Evidence of the form "regenerating produces the committed bytes", "the diff is zero", "the census matches", "the fixed point is reached" is a claim about A BASE, recorded and cited as a claim about A CHANGE. When the base moves it keeps reading as valid while describing a tree that no longer exists. IT IS THE WORST-SIGNALLING MEMBER OF ITS FAMILY, which is why it earns a row rather than a caution. A stale citation still shows the reader its text; an incompatible merge still conflicts; an absent observation still reports an absence. AN EXPIRED GREEN PRODUCES NOTHING. Worse, the author's own careful re-verification RE-AFFIRMS it, because re-running the same command against the same stale tree reproduces the same true-of-nothing answer. SPECIMEN, and it is this session's own PR #10036. Its entire acceptance test is that the emitted witnesses.yml is byte-identical after regeneration -- a behaviour-identical refactor whose whole claim is that the bytes do not move. It was re-verified after each of three commits and ALL THREE were measured against a base main had already left: #10024 had landed, changing the exact authority the PR rewrites by 151 lines and the exact artifact under test by 140. No signal at any point. The expiry was found by asking what had changed in main, not by any check. RECOGNITION RULE, mechanical: before citing a zero-diff receipt as merge evidence, ask whether the base moved ON THE FILES THE RECEIPT IS ABOUT -- `git diff --stat $(git merge-base HEAD origin/main) origin/main -- <those paths>`. Scoped to those paths deliberately: a receipt about generated bytes is invalidated only by changes to the authorities that produce them, and a whole-repository is-my-branch-behind check is both too coarse to act on and too noisy to keep. TWO OBLIGATIONS THE OBVIOUS READING MISSES, both carried in the row. Re-derive the discriminating CONTROL too -- one taken before the merge proves the zero was readable on a tree that is not the one shipping, so a re-derived green beside a stale control is half a measurement. And rebuild the PRODUCER, because the tree and the emitter are two inputs and a regeneration with one stale proves nothing about the pair. AND THE UPSIDE IS IN THE ROW, because it changes whether anyone bothers: a receipt re-derived after a FOREIGN change to the same artifact is STRICTLY STRONGER than the original. The first green asks only whether a projection reproduces its own base; the second asks whether it reproduces a base someone else moved, which is where a projection that disagreed with the hand-kept form it replaced would actually surface. RUNG 1, CEILING 2, per the manager's framing and for a derived reason: a receipt cannot make its subject stop moving, but it can make the movement OBSERVABLE. Trigger names the capability, not an artifact -- a receipt CARRIES THE BASE IT WAS MEASURED ON, so a producer compares it against HEAD and refuses an expired receipt, rather than a person remembering to. The row says outright that until then it is the mitigation and citing it as coverage is rung inflation. MAIN MERGED BEFORE APPENDING, which is the rule the previous commit filed rather than a coincidence: the last roster append silently no-opped against a moved base. Post-condition stated before measuring -- 2 occurrences, one declaration and one roster entry, no other row citing the identity -- and measured 2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct
briansrls
pushed a commit
that referenced
this pull request
Sep 2, 2026
…s one surface over The row named its next-rung trigger as a capability -- a receipt carries the base it was measured on, so a producer refuses an expired one rather than a person remembering to. True, but weaker than it needed to be: a trigger nobody can picture reads as aspirational, and §4b's honesty obligation is about separating "cannot climb" from "can climb but unbuilt". IT IS THE SECOND, AND THE PROOF WAS IN THIS SESSION'S OWN REVIEW LOG. The review runner ALREADY binds each review to the sha it was taken on and refuses on mismatch. On #10036, review 58587 failed with worktree freshness check failed: HEAD is ad38818 but PR #10036 head is c80c9d8 -- refusing to review a stale/wrong checkout and a refused review is exactly the signal an expired receipt does not produce. So reviews carry their base and regeneration receipts do not. The gap is an UNAPPLIED mechanism, not a missing one, and the trigger is discharged by giving receipts the binding reviews already have. That matters for the row's rung honesty rather than its prose: a trigger whose capability is demonstrably implemented twenty lines of config away is a tracked stall someone can close, where the same sentence without the receipt is a wish. Found while confirming #10036's merge criteria -- the failed review in that listing is not noise, it is the mechanism working. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct
gunbai-bot Bot
added a commit
that referenced
this pull request
Sep 2, 2026
…sitional_citation its edit-form instance (#10052) * File the harm-axis class: a hedged BENEFIT claim reads as diligence while leaving HARM unexamined DESIGN §4b: every newly discovered error class files one row. This one was discovered with a live specimen, and the specimen is the author. THE CLASS. An actor takes an irreversible or side-effecting action, states a calibrated caution about whether it HELPS, and never asks whether it HARMS. Those are different axes and no amount of hedging on the first reaches the second. The hedge is what makes it dangerous rather than merely wrong: it reads as due diligence, so a reviewer sees the epistemic care and endorses, and the endorsement generalises a single act into practice. THE SPECIMEN. This session cancelled a superseded CI run on a two-commit-stale head to return a fleet slot during saturation, and reported it with the explicit caution "I have no evidence it helps rather than merely stops waste". The manager verified the reasoning and endorsed it as "the only lever any of us actually has". Both wrong, and the authority was one grep away: gunbc.witness_floor_workflow emits `cancel-in-progress: false` with `NeverSupersedeRunning`, because a cancelled run SIGKILLs cargo mid-build and every borrowed jobserver permit is lost for the daemon's lifetime -- the pool decays monotonically toward zero and a host at zero permits still accepts jobs that simply WAIT. So the act is the mechanism that produces the exhaustion symptom it was taken to relieve, and the stale runs it "reclaimed" are that policy's DECLARED cost. THE RECOGNITION RULE IS MECHANICAL, which is what makes this worth a row rather than a lesson: read the hedge and ask which axis it is on. "I cannot show this helps" is a BENEFIT hedge; if the action touches shared state at all, its presence is evidence the harm question was never asked. The reviewer's tell: an actor who has examined harm NAMES THE MECHANISM by which harm would occur and then says why it does not apply. An actor who has only hedged benefit names no mechanism, because there is none to name. RUNG AND CEILING, stated honestly. Found at 1, mitigatable, and by nothing structural -- caught after the fact by reading an authority nobody was required to read. Ceiling 2, not higher: whether side effects are harmful is not decidable from the action alone, since the governing policy may live in any authority. What IS decidable is whether that policy was CONSULTED. Next trigger names the capability, not an artifact: a typed standing binding each fleet-affecting operator action to the authority governing it, so taking the action without consulting it refuses rather than relying on the actor to grep. Until then this is review discipline and citing it as coverage is rung inflation. APPENDED AS ONE LINE, which is the repair `merge_region_excludes_shared_tail` prescribes for this exact carrier: a multi-line unit ending in a shared `evidence: [],` / `}` tail makes every two-lane append resolve wrong by default. Both projections regenerated from the authority: the DESIGN.md index line and the docs/design-ledgers.md content, one line each. CAUGHT WHILE WRITING IT, and it is the same class of mistake one layer down: my first roster-list append anchored on `one_refusal_two_destinations,\n]` and SILENTLY NO-OPPED, because main had gained `liveness_probe_read_as_currency` underneath me. A `grep -c` showing 1 where 2 was owed is what caught it. An anchored edit that misses is indistinguishable from one that lands unless you count. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct * The silent no-op append is positional_citation in EDIT form — append the receipt, do not mint a row Manager ruling, and it is the §2 test applied to me for the third time tonight: a second row for a mechanism that already has one is re-invention. The failure I found while writing the harm-axis row belongs to `positional_citation`, whose rule already is that a positional handle decays invisibly because anything above it invalidates it while the containment tree names the same thing stably. WHAT THE APPEND ADDS is the form the existing row did not cover. An edit anchored on NEIGHBOURING TEXT -- sed on a surrounding line, a replace keyed on the adjacent entry, an insert before a named sibling -- is a positional handle by another spelling, and it decays identically. The DIFFERENCE IS THE CONSEQUENCE, and it is strictly worse: a stale citation misleads a reader who can still see the text; a stale ANCHOR silently does nothing, because a replace that matches zero times reports success. RECEIPT, this carrier, this session. Appending the harm-axis row needed two edits, the declaration and the roster-list entry. The roster append was anchored on `one_refusal_two_destinations,` plus the closing bracket. Between reading the file and writing it, main gained `liveness_probe_read_as_currency` as the new last entry; the anchor stopped matching, the declaration landed, the roster entry did not, and NOTHING FAILED. The result would have been a declared-but-unrostered class -- the half-applied state a roster cannot detect about itself. WHAT CAUGHT IT IS THE TRANSFERABLE PART AND IT IS NOT VIGILANCE: `grep -c` returning 1 where 2 was owed. The instruction is CHECK THE RESULT RATHER THAN THE ACTION, because a no-op edit and a successful one are indistinguishable at the actuator. The same discipline caught the mirror-image failure on this exchange from the other direction: a manager reading `git show origin/main:<path>` rather than a pinned worktree avoided refuting a correct citation. Two instances, one root -- a read and a write separated by someone else's push. RECOGNITION RULE: any edit whose anchor is text the edit does not own. State the expected post-condition as a COUNT before applying it, and assert the count afterwards; if you cannot say what the count should become, the edit is not specified. THE RULE CAUGHT MY OWN STATEMENT OF IT WHILE I APPLIED IT. I predicted the harm-axis identity would appear twice after this edit and measured THREE -- the third being the receipt above naming the row it cites. The prediction was wrong and the count is right; had I asserted "2" mechanically I would have "found" a defect that does not exist. A post-condition count is only as good as the reason attached to it, which is why the rule says state it, not automate it. Names kept as they happened, per the manager's instruction: a specimen whose actors are anonymised is one nobody can falsify, and the endorsement is the step that shows how a single act becomes practice. docs/design-ledgers.md regenerated from the authority; DESIGN.md's index is unchanged because no new identity was minted, which is the point. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct * File the expiring-receipt class: a receipt names a PROPERTY and never names the TREE it holds of Third roster row from this session, and the manager confirmed no other lane is carrying the class. Checked both neighbours before minting, since the last two findings belonged to rows that already existed: execution_provenance_loss asks whether the observation RAN. Here it ran, was valid, and then STOPPED being valid because its subject moved underneath it. positional_citation is a decaying HANDLE -- a pointer that no longer names what it named. Here the handle is fine; the EVIDENCE BINDING decayed. Different invalid states, different repairs, so a third row rather than an append. THE CLASS. Evidence of the form "regenerating produces the committed bytes", "the diff is zero", "the census matches", "the fixed point is reached" is a claim about A BASE, recorded and cited as a claim about A CHANGE. When the base moves it keeps reading as valid while describing a tree that no longer exists. IT IS THE WORST-SIGNALLING MEMBER OF ITS FAMILY, which is why it earns a row rather than a caution. A stale citation still shows the reader its text; an incompatible merge still conflicts; an absent observation still reports an absence. AN EXPIRED GREEN PRODUCES NOTHING. Worse, the author's own careful re-verification RE-AFFIRMS it, because re-running the same command against the same stale tree reproduces the same true-of-nothing answer. SPECIMEN, and it is this session's own PR #10036. Its entire acceptance test is that the emitted witnesses.yml is byte-identical after regeneration -- a behaviour-identical refactor whose whole claim is that the bytes do not move. It was re-verified after each of three commits and ALL THREE were measured against a base main had already left: #10024 had landed, changing the exact authority the PR rewrites by 151 lines and the exact artifact under test by 140. No signal at any point. The expiry was found by asking what had changed in main, not by any check. RECOGNITION RULE, mechanical: before citing a zero-diff receipt as merge evidence, ask whether the base moved ON THE FILES THE RECEIPT IS ABOUT -- `git diff --stat $(git merge-base HEAD origin/main) origin/main -- <those paths>`. Scoped to those paths deliberately: a receipt about generated bytes is invalidated only by changes to the authorities that produce them, and a whole-repository is-my-branch-behind check is both too coarse to act on and too noisy to keep. TWO OBLIGATIONS THE OBVIOUS READING MISSES, both carried in the row. Re-derive the discriminating CONTROL too -- one taken before the merge proves the zero was readable on a tree that is not the one shipping, so a re-derived green beside a stale control is half a measurement. And rebuild the PRODUCER, because the tree and the emitter are two inputs and a regeneration with one stale proves nothing about the pair. AND THE UPSIDE IS IN THE ROW, because it changes whether anyone bothers: a receipt re-derived after a FOREIGN change to the same artifact is STRICTLY STRONGER than the original. The first green asks only whether a projection reproduces its own base; the second asks whether it reproduces a base someone else moved, which is where a projection that disagreed with the hand-kept form it replaced would actually surface. RUNG 1, CEILING 2, per the manager's framing and for a derived reason: a receipt cannot make its subject stop moving, but it can make the movement OBSERVABLE. Trigger names the capability, not an artifact -- a receipt CARRIES THE BASE IT WAS MEASURED ON, so a producer compares it against HEAD and refuses an expired receipt, rather than a person remembering to. The row says outright that until then it is the mitigation and citing it as coverage is rung inflation. MAIN MERGED BEFORE APPENDING, which is the rule the previous commit filed rather than a coincidence: the last roster append silently no-opped against a moved base. Post-condition stated before measuring -- 2 occurrences, one declaration and one roster entry, no other row citing the identity -- and measured 2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct * Strengthen the expiring-receipt trigger: the capability already exists one surface over The row named its next-rung trigger as a capability -- a receipt carries the base it was measured on, so a producer refuses an expired one rather than a person remembering to. True, but weaker than it needed to be: a trigger nobody can picture reads as aspirational, and §4b's honesty obligation is about separating "cannot climb" from "can climb but unbuilt". IT IS THE SECOND, AND THE PROOF WAS IN THIS SESSION'S OWN REVIEW LOG. The review runner ALREADY binds each review to the sha it was taken on and refuses on mismatch. On #10036, review 58587 failed with worktree freshness check failed: HEAD is ad38818 but PR #10036 head is c80c9d8 -- refusing to review a stale/wrong checkout and a refused review is exactly the signal an expired receipt does not produce. So reviews carry their base and regeneration receipts do not. The gap is an UNAPPLIED mechanism, not a missing one, and the trigger is discharged by giving receipts the binding reviews already have. That matters for the row's rung honesty rather than its prose: a trigger whose capability is demonstrably implemented twenty lines of config away is a tracked stall someone can close, where the same sentence without the receipt is a wish. Found while confirming #10036's merge criteria -- the failed review in that listing is not noise, it is the mechanism working. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct * Name the instrument instead of transcribing it, in the row and its projection (review 58732) REQUEST_CHANGES from codex/gpt-5.6-sol, verified against DESIGN §6 and accepted in full. §6: "Name the instrument, never transcribe its output... never by copying its numbers into prose... a transcribed number is unreachable from the thing that owns it, so it rots without anyone touching either end." TWO SITES, AND THEY WERE NOT THE SAME DEFECT, which is why they get different repairs. 1. THE SPECIMEN'S DIFFSTAT. The row said #10024 changed the authority by 151 lines and the artifact by 140. Those describe two immutable commits, so they cannot rot in §6's stated sense -- but §6's other half applies squarely: "if a measurement is worth re-deriving it is worth an entry point." It now names the producer, `git show --stat 7c310ed -- <the two paths>`, and drops the numbers. The row keeps its force by saying the change was MATERIAL rather than by quantifying it, and the reader gets a command that answers the same forever. 2. THE SIX-PR SAMPLE. This one was a genuine §6 violation with no mitigation: a live population, no named producer, and a count doing no work. The row already conceded the sample discriminates nothing -- the freshness check fires only when a head moves mid-checkout, so a sample drawn where the condition never arose is uninformative by construction. The count is now gone, the producer (`dashboard-ops reviews <pr>`, reading status and error) is named, and the reason the sample is uninformative is stated as the point rather than as a caveat. The generated projection at docs/design-ledgers.md carried the same text because it is derived; it was re-emitted from the authority rather than edited, and the transcribed figures are gone from both. WHAT REMAINS IN THE ROW IS IDENTIFIERS, NOT MEASUREMENTS -- PR numbers, review 58587, a commit sha, dates. Those are names, which is what §6 asks a citation to carry. NOTED FOR SOMEONE, NOT ARGUED HERE: 42 of this carrier's 56 rows embed measured figures in their specimens. If §6 binds a RecurringFailureMode specimen as strictly as it binds ordinary prose, that is a corpus-wide finding with its own owner rather than a defect unique to this row. This row complies either way, because complying cost nothing and produced better prose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct --------- Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
gunbai-bot Bot
added a commit
that referenced
this pull request
Sep 2, 2026
…e two sentences it makes false (#10078) Part 2 of the operator-approved item, and the promotion is now literally one row because #10036 made the lane axis a roster. Three edits, only one of which is the promotion: one `RequiredLane` in `required_lanes_roster` one `required_lanes_gate_unit_var` beside its BUILD/FLOOR siblings, so the variable is a declared row rather than a bare literal at the use site the aggregate step's name, because "Both required lanes must have succeeded" is false with three WHY THIS MATTERS AT ALL. The 774 `#[test]`s under src/v1/stage0 ran on no CI path before that job existed, then ran on every push and pull request while GATING NOTHING -- and the gap produced exactly the harm it predicts: #9886 landed two failing tests on main with every required check green. That is the whole reason this item exists. THE EMITTED DELTA IS THE RECEIPT, and it is the same six surfaces PR A's forward control predicted before any of this was written: needs: [...build, ...floor, rust-unit-tests] a third `|| [ "$UNIT" != success ]` conjunct in the unestablished fold a third `|| [ "$UNIT" = failure ]` conjunct in the red fold ` unit=$UNIT` in the receipt line and in BOTH refusal messages UNIT: ${{ needs['rust-unit-tests'].result }} in the step env the step name A `needs`-only edit would have produced the first and last of those and NONE of the middle -- the lane would have been waited on and still unable to fail the gate. That failure mode is why PR A landed first. THE ANNOTATION IS REWRITTEN, NOT APPENDED TO. It said "It is not a `needs` of the aggregate, so it does not gate a merge yet", which this commit makes false, and §4c forbids an annotation restating what the declaration no longer says. Verified the rewrite added ZERO emitted bytes -- annotations are erased before emission, so the YAML delta is unchanged by it and carries none of its text. ALL THREE PRECONDITIONS DISCHARGED, NOT ARGUED AWAY, and the annotation now states them as a RULE rather than as history: MAIN GREEN -- and this was not hypothetical. While the promotion was held, #10036 was blocked by shell_service_unmodeled_output_key_refuses, main's own defect, whose fix its author had already landed under another number. A promotion whose first act blocks every open PR on an already-fixed defect is a self-inflicted outage. FLEET HEALTHY -- a lane that cannot be delivered its admitted memory or toolchain produces reds carrying no information about the diff. COST ACCOUNTING UNDERSTOOD (#10053) -- the same argument one layer down. The generalisation is in the annotation because a later reader will be tempted to drop the third: A LANE MAY BE PROMOTED ONLY WHEN A RED IN IT DISCRIMINATES. Wall clock is the cheap question; whether the lane's failures are ABOUT THE DIFF is the load-bearing one. COST ON THE CRITICAL PATH IS ZERO, by comparison rather than by bound: the lanes run in parallel with the aggregate only waiting, and measured across 120 witnesses runs this job sits BELOW required-witnesses-floor at every quantile. The annotation names the producer to re-derive it and deliberately does NOT carry the figures -- a timeout-headroom argument would have been the wrong one, since headroom says nothing about what the aggregate waits for. Claude-Session: https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR A of the two-part promotion item. Behaviour-identical §2 dedup, landing on its own so the promotion row (PR B) can wait on the fleet condition without holding this.
What was forked
The aggregate's lane axis was
build_varbesidefloor_var, threaded through four functions and spelled 28 times ingunbc.required_lanes_gate. That is one concept — a required lane — given one name per instance, which is the fork §2 horizontal exists to delete.The tell was that a claimed one-row edit was not one.
gunbc.witness_floor_workflowatrust_unit_tests_job_idsays promoting a third job is "a one-row edit torequired_lanes_aggregate_job". True of the shape the aggregate had when written; stale since. Promotion was a signature change in four places plus a step-name rewrite — and worse, the obvious reading of it (add theneedsedge) would have added the wait while granting no authority to block, because the gate's verdict reads named shell variables and a lane whose result it does not read cannot fail it. A promotion that looks landed and gates nothing is worse than no promotion: the roster would then cite it as coverage.What the roster is
RequiredLane { job_id, label, var_name }— three genuinely distinct strings (required-witnesses-build,build,BUILD), each read by a different surface, so collapsing any two would make one surface derive its spelling from another's.Five surfaces now derive from one
required_lanes_roster(): the verdict's or-folds, the receipt line, both refusal messages, the step'senvblock, and the job'sneedsedge. The last two were previously hand-kept lists whose agreement nothing checked — a lane in the env but not inneedsreads an unset variable; a lane inneedsbut not the env is a job that runs and cannot block. Both silent.Non-empty by construction
This is the safety half, not a shape preference. The verdict is an OR-fold over the lanes, and an or-fold over nothing is false — an empty roster would publish the required context green over a gate that read no lane at all.
FreeSemigrouphas no empty representation, so that state is unwritable rather than validated: §4b(4) rather than §4b(2), and no refusal arm is owed because there is no arm to write.Deliberately not a fresh
NonEmptyRequiredLanescarrier —free_semigroup_grounding_notealready names five monomorphised copies of that shape as convergence debt, and a sixth would be the re-invention §2's own test forbids.Acceptance test: the emitted YAML is byte-identical
Named by its producer rather than transcribed:
then diff
.github/workflows/witnesses.ymlagainst its pre-change bytes. No generated artifact in the tree changes; only the two authority files do.And the zero is shown beside a nonzero
A diff of zero is readable only next to a diff that isn't. Two controls, both executed and both reverted (neither is in this diff):
1. Mutate one roster field (
label: "build"→"REDCTL") and regenerate — the diff fires in three places, the receipt line and both refusal messages. So the byte-identity is the emission reading this roster, not surviving bytes.2. Add one row (the rust-unit-tests lane) and regenerate:
Both refusal messages grow it too. That is the forward receipt that PR B really is one row — measured, not promised.
Annotation
rust_unit_tests_job_idis corrected to say what is now true, and to record the two conditions that actually gate the promotion: main green AND the fleet toolchain fault fixed. The second because a host fault that evicts the toolchain becomes a merge block on every PR in the repository the moment this lane gates. The wall-clock measurement is stated with its producer (actions/runs/<id>/jobs, 120 runs, 2026-09-02): this job is belowrequired-witnesses-floorat every quantile — p50 21.9 vs 25.9 min, p90 32.1 vs 36.2, max 41.5 vs 47.0 — so promotion costs nothing on the critical path.The acceptance test was re-derived after merging main, and it is now a stronger claim
Read this as a materially better receipt, not as routine post-merge hygiene.
Since this branch's base, main landed #10024, which changed
dag/gunbc/witness/witness_floor_workflow.dagby 151 lines and.github/workflows/witnesses.ymlby 140 — the exact authority this PR rewrites and the exact artifact whose bytes are the acceptance test. A byte-identity receipt binds to a base and expires silently: nothing went red, and every earlier receipt here kept reading as valid while measuring against a base that no longer existed.So it was re-measured on the merged tree, with
gunbcrebuilt first — the emitter is the second input, and a regeneration with one stale input proves nothing about the pair:Why this is stronger than the original green. The refactor now reproduces an emitted file that a foreign change materially rewrote underneath it. #10024 is job-boundary instrumentation, so it touches job structure — if the roster projection disagreed with the hand-kept form anywhere that change reached, this is exactly where it would surface. The pre-merge green only ever asked whether the refactor reproduced its own base; this one asks whether it reproduces a base someone else moved.
The mutation control was re-run on the shipped tree rather than cited from before the merge, on the same principle: one roster field mutated still fires the diff in exactly 3 places — receipt line and both refusal messages — then reverts to byte-identical.
Not in this PR, deliberately
The aggregate step is still named "Both required lanes must have succeeded". "Both" becomes wrong only when a third lane lands, and changing it now would break the byte-identity that is this PR's whole acceptance test. It belongs to PR B.
🤖 Generated with Claude Code
https://claude.ai/code/session_01VSP89XiSm2YMnUvSwSR1ct