Skip to content

The floor's 500ms per-claim budget refuses TWO independent near-ceiling families, each sufficient alone, and both are tipped by position-dependent inflation rather than by their own cost — own the charge subject, not the threshold - #10238

Closed
briansrls wants to merge 2 commits into
mainfrom
pr10234work

Conversation

@briansrls

Copy link
Copy Markdown
Contributor

Auto-opened by session-dashboard for session jolly-ferret-412.
Pushing to pr10234work advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

  • Title describes the change (not the session id or branch).
  • PR body summarises what and why (replace the TODO below).
  • Tests run: name the command (e.g. npm test, cargo test) and the result.
  • If this closes a work item, the body contains a Closes #N directive.
  • No commits on this branch are surprises (no fork/cherry-pick I did not make).
  • No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

  • TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

gunbc-ci-auto-heal and others added 2 commits September 3, 2026 02:56
…, and it passes

The row was enrolled on measured recompute AND measured sharing before this file's
serve-below-recompute criterion existed, so it stood on two of the three tests the
header now requires. gunbc#10141's carrier-overlap wall refused it on a NEIGHBOUR's
null: it serves v2.test.manual.rust_add_emit_translate, a carrier of the refused
rust_target_model_core_edges, whose refusal was NoMeasuredEffectOverItsConsumers. A
null about a different producer is evidence neither of a cost here nor of its absence,
so the state was UNMEASURED rather than fine.

Two present-vs-absent pairs, dispatched on branches because CI builds refs/pull/N/MERGE
and a PR pair measures two different trees the moment main moves. The arm is verified to
have varied rather than assumed: 148 fills over 60 consumer modules in both present arms,
the key wholly absent from both absent ledgers, and the other five keys carrying identical
fill counts in all four runs.

The control correction is the transferable part. eval_steps is in the cost receipt and is
host-independent, so the subject's own rows split into those the serve reached and those
whose step counts are byte-identical across arms. The second group is a control the change
provably cannot have touched, and it moves almost as much as the first -- so most of the
~12% that the roster-external control reports is composition, not serving. Against the
within-population control the serve still beats the recompute in both pairs, by roughly a
tenth on the rows it reaches, with neither bootstrap interval admitting 1.

Comment-only: annotations are erased from the semantic projection, so no roster row, no
emitted byte and no resolution result changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3j1sSKhCsKjuiAfpYQeG
…d it not firing

The note asked #10141's carrier-overlap wall to stop refusing this key. It already
does, and by the same reasoning rather than by an exemption: the overlap join is
narrowed to refused rows whose verdict records a MEASURED cost, so
refused_row_carriers_transfer answers false for NoMeasuredEffectOverItsConsumers and
core_edges' carriers never transfer.

Recorded as observed rather than designed, which is the distinction that matters for a
wall: floor run 33703215821 is FloorClean with this key enrolled and core_edges in the
refused roster -- same roster, same carriers, no refusal.

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

gunbai-bot Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Closing this as a DUPLICATE — not as a judgement on the work, which is good and is landing through #10234.

MEASURED, not inferred from the titles: this PR's head and #10234's head are the SAME COMMIT.

Two branches (pr10234work and session/merry-deer-84) point at one sha, and the dashboard auto-opened a PR on the second one. So this is one piece of work wearing two PR numbers, which is the §3 single-authority violation at the PR layer.

#10234 is the one that survives, because it carries the identity: a real title naming the change, and the review history (codex review 59321 at this exact sha). This PR carries the auto-opened boilerplate — title is the session's, body is the unedited TODO template. Keeping the one with the review history and closing the one without is the only ordering that loses nothing.

THE HAZARD THIS AVOIDS is not hypothetical and has fired three times in this repo today (#9950, #10221, #10223): when one of a pair of same-sha PRs squash-merges, the other's branch survives, its merge-base goes stale, and its three-dot diff then reads as ordinary pending work while actually re-injecting already-landed content. Closing the duplicate now is one command; catching the duplicate injection later needs a multiset check and only works after it lands.

Closed by the XL-N manager. The branch pr10234work should be deleted too — a surviving branch re-arms the same hazard.

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