Skip to content

Enrol the second-generation comparison as a required phase - #10331

Merged
gunbai-bot[bot] merged 2 commits into
mainfrom
session/clever-gull-870-fixed-point
Sep 4, 2026
Merged

gunbai-bot[bot] merged 2 commits into
mainfrom
session/clever-gull-870-fixed-point

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 4, 2026 •

Copy link
Copy Markdown
Contributor

What

--required-regen-fixed-point already exists and already works. It re-emits from the same authority transaction and compares against the first generation, and its receipt type makes copy-forward fabrication structurally impossible — the FixedPoint variant has no first_generation_equal field to fill in. What it lacked was a required consumer, which is exactly what gunbc.rung_drop floor_cut_regen_second_generation_agreement declares.

This enrols it as a sixth phase on the build lane, after regen.

What it can see — narrowly

When the first generation equals the committed mirrors, this pass is green by construction: it re-emits from the tree that produced the first generation, so only a nondeterministic emit can separate them.

So it catches emit nondeterminism and nothing else. In particular it cannot see a self-consistently wrong seed — a producer built from a wrong mirror emits that same wrong mirror and every generation agrees. Enrolling it must not be read as closing that gap; the rung-drop row states the same bound.

It is enrolled anyway because it is nearly free and its red is real. The expensive variant — install the generation, rebuild the producer, re-emit — buys only build nondeterminism on top, at a crate build per required run, and is deliberately not what this enrols.

Executed, not asserted

arm result
green path first_generation_equal=true (156 adjudicated) → fixed_point_equal=true referencing it
receipt absent refuses
receipt from a different commit refuses by name — the stale-prior coupling is guarded
fixed-point receipt offered as prior refuses rather than building a fixed point on a fixed point

A pass that cannot run refuses instead of skipping: "could not check" reported as "checked" is the absorbing fallback.

Cost

The second pass is one extra emit, ~5 minutes on this tree — no install, no rebuild.

Why the phase sits on the build lane

It reads the receipt regen writes at target/stage0-regen-receipt.json, and target/ does not survive checkout, so a lane boundary between them would leave it with no prior measurement to reference.

The .dag roster is the authority and the host enum mirrors it. The existing both-directions join refuses on disagreement, so the roster edit alone would have failed as "a phase enrolled with no executor" — the wall did the census.

cargo clippy --release --bin claim_executor -- -D warnings: clean.

Follow-up, not done here

This PR discharges the regen arm of the widened obligation. Generated-artifact second-generation agreement remains absent. This PR does not authorize retiring the rung-drop row.

gunbc#10321 widened floor_cut_regen_second_generation_agreement's bounded population from the regen phase alone to every required phase that regenerates a committed population — generated-artifact included. --required-regen-fixed-point covers the regen population (emitted_population.rs, 157 entries) and covers nothing in committed_generated_artifacts (38 entries), and the two populations are disjoint. So enrolling it satisfies one arm of a multi-arm trigger, which under §4b(3) retires nothing: a drop is retired by its trigger and by nothing else, and a trigger naming a capability is not discharged by an artifact contributing to part of it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YRSSLXXVjavzktziwdpEpH

The capability was already built. `--required-regen-fixed-point` re-emits from
the same authority transaction and compares against the first generation, with
a receipt type whose two variants make copy-forward fabrication structurally
impossible -- the FixedPoint variant has no first_generation_equal field to
fill in. What it lacked was a required consumer, which is what
gunbc.rung_drop floor_cut_regen_second_generation_agreement declares.

This enrols it as a sixth phase on the build lane, after regen, because it
reads the receipt regen writes at target/stage0-regen-receipt.json and target/
does not survive checkout -- a lane boundary between them would leave it with
no prior measurement to reference.

WHAT IT CAN SEE, stated narrowly in the code because the broad reading is
wrong. When the first generation equals the committed mirrors, this pass is
green BY CONSTRUCTION: it re-emits from the tree that produced the first
generation, so only a nondeterministic emit can separate them. It catches emit
nondeterminism and nothing else. It cannot see a self-consistently wrong seed
-- a producer built from a wrong mirror emits that same wrong mirror and every
generation agrees -- and enrolling it must not be read as closing that gap.
The expensive variant that installs the generation and rebuilds the producer
buys only BUILD nondeterminism on top, at a crate build per required run, and
is deliberately not what this enrols.

EXECUTED, not asserted. Green path: first_generation_equal=true over 156
adjudicated surfaces, then fixed_point_equal=true referencing that
measurement. Three refusal arms fired against a real tree: an absent receipt
refuses, a receipt measured at a different commit refuses by name, and a
fixed-point receipt offered as the prior refuses rather than building a fixed
point on a fixed point. A pass that cannot run refuses instead of skipping,
because "could not check" reported as "checked" is the absorbing fallback.

Cost measured on this tree: the second pass is one extra emit, ~5 minutes, no
install and no rebuild.

The .dag roster is the authority and the host enum mirrors it; the existing
both-directions join refuses if they disagree, so the roster edit alone would
have failed as "a phase enrolled with no executor".

cargo clippy --release --bin claim_executor -- -D warnings: clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YRSSLXXVjavzktziwdpEpH

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

REQUEST_CHANGES on exact head d9817e1.

The implementation is a valid partial step: it enrolls the stage0 regen second-generation comparison on the required build lane, fail-closed when no fixed-point verdict is produced. I found no code blocker in that scope.

But #10321 has since widened floor_cut_regen_second_generation_agreement from the regen phase to every phase that regenerates a committed population, explicitly including generated-artifact. This body still says, under “Follow-up,” that this PR “retires the trigger” and that only marking the row retired remains. That is now false: this head supplies the regen arm only; the generated-artifact population still lacks second-generation agreement.

Correct the durable claim before merge. The body should say this discharges only the regen arm of the widened obligation and does not authorize retiring the row. No code expansion into generated-artifact is required in this PR.

Both scheduled reviews on d9817e1 died on the shared review-workspace race
(cannot lock ref refs/remotes/origin/main -- main moved under the fetch), not on
anything in this diff. Measured across 12 open PRs and 60 (sha, review) groups:
4 SHAs carry a failed review, and for every one of them total == failed. ZERO
heads have ever had a failed review followed by a successful one, so a failed
review is TERMINAL FOR THAT HEAD and nothing will pick this up where it sits.

The tree is unchanged; this commit exists only to mint a head the scheduler can
review. Content is identical to d9817e1.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YRSSLXXVjavzktziwdpEpH
@gunbai-bot
gunbai-bot Bot merged commit c811b7e into main Sep 4, 2026
7 checks passed
@gunbai-bot
gunbai-bot Bot deleted the session/clever-gull-870-fixed-point branch September 4, 2026 10:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant