Skip to content

Floor refuses on main: callable_candidate_ambiguity marginal-vs-total cost attribution - #9570

Closed
gunbai-bot[bot] wants to merge 2 commits into
mainfrom
session/sleek-cat-45
Closed

gunbai-bot[bot] wants to merge 2 commits into
mainfrom
session/sleek-cat-45

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Auto-opened by session-dashboard for session sleek-cat-45.
Pushing to session/sleek-cat-45 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 August 28, 2026 02:26
… for two compiles the roster shares

gunbc#9477 made a shared memoized compile's fill a preparation cost rather than
the first payer's, because a merge-blocking per-claim ceiling charged with an
order-dependent number is a fact about discovery order and not about the tree.
It wired that rule into `compile_dag_rust_emit_check` and not into its census
sibling, which gunbc#9428 had memoized for exactly the same reason. One
accounting rule, two homes, applied in one of them.

MEASURED, not inferred. On main run 33131296988 (b6003a4) the floor refuses
with `completed_over_cost_requirement=1` and `failed=0`:
`test.claim.callable_candidate_ambiguity_witness.neither_green_source_refuses_
and_neither_mis_resolves` at 5812ms against the 5000ms fail-stop. That run
carries 259 per-claim `[floor-shared-fill]` lines and NOT ONE of them names any
row of this file -- while the row demonstrably paid two shared compiles, being
the first claim to reach both `green_named_authority_source` and
`green_own_declaration_source`, each of which a later claim then reads free.
Zero reported fill beside a charged total that is almost entirely fill is the
discriminating evidence that the charged figure is the TOTAL term, not the
marginal one the limit is specified against. Its two siblings show the same
shape from the other direction: 1652ms and 3130ms, each the first to reach one
further source, and the two claims that read those sources second appear on no
over-cost line at all.

THE FIX IS THE ONE THE RECEIPTS ALREADY RULED FOR. No limit is raised, no row
is grandfathered, no witness is withheld: the missing bracket is added, so a
census MISS records its fill through the same accumulator the sibling memo
writes and `run_claim_measured` performs the same split it already performs.
Nothing is exempted -- the fill is still measured on the enforcing clock, still
counted, and now still REPORTED, as a `[floor-shared-fill]` line these rows
have never emitted. Their absence in the next floor run would mean this change
did not execute; their presence is the arm-ran control.

The two forward-freeze receipts are corrected in the same change. The census
one asserted that the split is "reported, never subtracted from what a claim is
charged", which was true of this memo and is the sentence that describes the
defect; the attribution one said the accumulator is written "only on an
emit-check MISS", which was the whole of it. No declaration is added, so
neither receipt's hand-item delta moves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…rd state as the one that must not exist

The bracket in the previous commit fixes ONE instance. What made that instance
authorable is that the two treatments for a shared artifact are two
hand-written call sites with no carrier relating them, so "claim-forced and
unbracketed" is a writable state that nothing refuses.

THE DISCRIMINATOR IS WHEN THE ARTIFACT CAN BE FORCED.
Preparation-forceable -- every identity it can be asked for is knowable before
the fold -- is warmed ahead and billed to preparation; `both_closure_edge_index`
is this arm, and the run reports `provenance=built-by-preparation` for both
index identities the floor's resolves can reach. It correctly carries no fill
bracket, which matters because absence of a bracket was read as evidence of a
defect during this investigation and was the wrong instrument.
Claim-forced -- what it will be asked for is a property of the claim, so it
cannot be warmed ahead -- must record its fill, because a witness's synthetic
source is not knowable before the fold.

THE THIRD STATE IS THE DEFECT, and it is invisible because the number it
produces is REAL: a true measurement of something, charged to a row that does
not own it. Worse than a wrong number, it can become permanent -- gunbc#9517
would freeze rows above the line under a shrink-only contract, and a row frozen
for cost it does not own can never be made cheap, so it can never leave.

PROSE IS NOT A WALL AND THE ROW SAYS SO. Rung: mitigatable, on review
diligence; the third state stays writable and this paragraph will not stop the
next memo. Next-rung trigger: a memoized host artifact DECLARES its forcing
class and the warm-or-net treatment is DERIVED from it, at which point the
third state has no spelling. That construction is not made here and is not
claimed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gunbai-bot

gunbai-bot Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor Author

Closing: this is an auto-opened duplicate of work that already merged as #9560, not an unfinished change.

WHY IT LOOKS UNMERGED. #9560 was squash-merged, so this branch's two commits are not ancestors of main by SHA and the three-dot diff still renders them as new (+56/-3). The two-dot diff tells the real story: every one of those changes is already on main, and this branch is 10 commits behind it.

Verified on origin/main rather than assumed — all three pieces are present:

  • the census-memo fill bracket in v1_compiler.cli_run (record_shared_artifact_fill_cpu now has 4 call sites, was 3),
  • the forcing-class carrier in gunbc.shared_fill_attribution_seed_growth,
  • the corrected gunbc.census_memo_seed_growth boundary sentence.

WHY IT SHOULD NOT BE FLIPPED TO READY, which is the reason this is worth more than a tidy-up. Re-applying an accumulator bracket is not an idempotent change. If this landed a second time, record_shared_artifact_fill_cpu would be called twice per memo miss, the fill would be double-counted, and cpu_nanos = measured - fill would saturate to zero — making every census-calling claim read as free. That is the exact measurement this PR's content exists to make honest, corrupted in the opposite direction, and it would look like a success (rows getting cheaper) rather than a failure.

cli_run.rs has also moved by ~509 lines on main since this branch was cut, so the diff would not apply cleanly in any case.

No action needed. The subject is closed: the row that was refusing the required floor at 5812ms has a marginal cost of 17ms, and 15 rows across 6 modules drained with it.

— sent from sleek-cat-45

@gunbai-bot gunbai-bot Bot closed this Aug 28, 2026
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.

0 participants