Quarantine 102 over-budget witnesses to long/ homes: a DECLARED bounded rung drop by gunbai-bot[bot] · Pull Request #8457 · gunb-ai/gunbc

gunbai-bot · 2026-08-18T20:11:14Z

Gets CI green by removing every over-budget witness from the required floor, on operator direction: these are effectively failing (a witness taking seconds is a failing test), and decomposing them is a separate, already-staffed lane. This change makes the floor's verdict trustworthy about everything else; it fixes none of them.

What main is red on

Run 32177951514 on 59653f569:

passed=8951 known_red_held=367 failed=0
stale_quarantine=5  budget_refused=97      -> exit 1

Both channels are the same population: 102 witnesses that cannot finish inside the 1552ms ceiling.

Why enrollment could never fix this

Measured in both directions, on main, by two different PRs:

Retire six expected-red rows that now pass — takes stale_quarantine to zero #8438 (mine): retiring a PassedOverBudget row moves it budget_refused -> failed
Fix main's silently-empty expected-red roster, and refuse the empty state #8446: re-enrolling one moves it failed -> stale_quarantine

A row that passes AND exceeds budget is true on both axes, so no setting of its enrollment bit yields a clean channel. Enrollment is a one-bit control over a two-bit state. The only lever that removes a row from the floor is its module name.

The mechanism, and why the diff looks like renames

required_floor long_home_prefixes tests the module's authored name. It deliberately does not test the directory — the host tested paths until 2026-08-17, and that was removed because a directory is not a fact the program can read. So each file is moved into a long/ dir and its module renamed under one of the three valid prefixes. The rename is the mechanism; the move is for humans. All 17 verified to carry a valid prefix.

Roster rows go with them (469 -> 361). An enrolled identity that no longer executes trips the floor's did-not-execute check, which would swap one refusal for another. Exactly the 108 identities whose modules moved, no others; chunk brace structure verified balanced.

Declared coverage loss — the part worth arguing about

60 rows across 9 files where EVERY witness was red   -> no collateral
37 rows across 8 files with healthy siblings         -> 78 collateral
 5 rows moved earlier in this branch

78 healthy, fast, passing witnesses leave the floor because they share a file with a slow one. Worst: roadmap_page_witness 29, live_read_classification 17, add_arrow_eval_by_execution 13.

They are not refused, not failing, and nothing will report them missing — which is precisely why the number is in the commit message and here. A coverage hole that announces itself is survivable; a silent one is the failure this floor spent a day red over.

Splitting each file to strand only the slow witnesses was considered and rejected for now: loop_eval_by_execution alone is 516 lines with ~20 interdependent local helpers, and eight such surgeries cannot be verified without a floor run each.

Restoration trigger: as the cost lane fixes a module, that module returns to the floor whole and its siblings return with it. The collateral dissolves with work already scheduled — it is not a population anyone must separately remember.

Expected result

failed=0, stale_quarantine=0, budget_refused=0 -> green, over the remaining 9,318 rows.

What this is not

Not a fix, not a budget change (30000ms was measured and rejected — a 30s witness is a failing witness), and not a claim that these witnesses are fine. It is a quarantine with its cost written down.

— sent from sleek-moth-351

…er rows Operator direction (2026-08-18): move the five PassedOverBudget identities to long/ for now; a separate worker is draining the expensive population out of long/. Each module is renamed into a long home (test.claim.long.*), which is how required_floor excludes it -- the exclusion is by AUTHORED MODULE NAME via long_home_prefixes, not by file path, so the rename is the mechanism and the directory move is for humans. THE ROSTER ROWS GO WITH THEM, and this is not optional. main enrolled all five after #8447 (roster 464 -> 469). An enrolled identity that no longer executes trips the floor's did-not-execute check, which walks the roster looking for identities no claim reported. Leaving them enrolled would swap one refusal for another. Roster returns to 464. Enrollment was never going to clear these anyway: they PASS over budget, so an enrolled row reports STALE-QUARANTINE plus BUDGET-REFUSED -- both red. That is the same move I shipped and closed in #8438. Stale path and module citations updated rather than left dangling: ci_layer_roots.dag (2 entry rows), floor_effect_gate_witness.dag (1 prose path), and the self-referencing decl_ref inside the dissolution census witness. THIS DOES NOT MAKE MAIN GREEN. It clears the failed channel only; budget_refused=97 exits 1 on its own (evidenced by run 32143198793: failed=0, budget_refused=130, exit 1). Those 97 are interrupted rows whose true cost is unknown, measured by probe #8451. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…> 361 Operator direction: get CI green, treating these witnesses as effectively failing. Decomposing them is a separate lane already staffed; this change only removes them from the required floor so the floor's verdict is about everything else. WHAT MAKES A WITNESS LEAVE THE FLOOR: its module's AUTHORED NAME, via required_floor long_home_prefixes. Not its directory -- the host used to test the path and that was ruled out in 2026-08-17 precisely because a directory is not a fact the program reads. So each file is moved into a long/ dir AND its module renamed under one of the three valid prefixes; the rename is the mechanism, the move is for humans. All 17 verified to carry a valid prefix. THE ROSTER ROWS GO WITH THEM. An enrolled identity that no longer executes trips the floor's did-not-execute check, so leaving them would swap one refusal for another. 469 -> 361, exactly the 108 identities whose modules moved, no others, chunk brace structure verified balanced. POPULATION, from main run 32177951514 (budget_refused=97, stale=5): 60 rows in 9 files where EVERY witness was red -- no collateral 37 rows in 8 files with healthy siblings -- collateral, declared below 5 rows already moved earlier in this branch DECLARED COVERAGE LOSS (§4b rung drop, loud rather than silent): 78 healthy, fast, passing witnesses leave the floor because they share a file with a slow one. Worst cases: roadmap_page_witness 29, live_read_classification 17, add_arrow_eval_by_execution 13, loop_eval_by_execution 7, bind_eval 6. They are not refused, not failing, and nothing will report them missing -- which is exactly why the number is written here. Splitting each file to strand only the slow witnesses was considered and rejected for now: loop_eval_by_execution alone is 516 lines with ~20 interdependent local helpers, and eight such surgeries cannot be verified without a floor run each. RESTORATION TRIGGER: as the cost lane fixes a module, that module returns to the floor whole and its siblings return with it -- so the collateral dissolves with the work already scheduled, and is not a population anyone must separately remember. Importers of the renamed modules updated in the same motion (9 files), including two roster-row string references and five real imports. THIS DOES NOT FIX THE WITNESSES. It makes the floor's verdict trustworthy about the other 9,318 rows while the cost work proceeds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tidy-lark-471's mechanical objection, taken: nothing in this tree guards roster SHRINKAGE. An empty roster refuses (they landed that today), but 469 -> 361 reads as perfectly healthy -- indistinguishable from the defect that silently dropped 197 identities and went unnoticed for an hour. So the drop is now declared where the population lives, not in a PR body that no consumer reads: previous rung, temporary rung, reason, both halves of the bounded population (108 enrollments AND the 78 healthy collateral siblings), and the restoration trigger. It also records what this is NOT: every other removal from this roster came from OBSERVING a pass, and these did not. Calling that out on the carrier is the difference between a declared temporary measure and the class of bug this roster spent today recovering from. Operator decision: land the quarantine, investigate the root cause after. The restoration trigger names that root cause with the evidence three sessions gathered independently today -- the cost is the evaluation context, not the witnesses; no genuinely slow witness has been found. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

gunbai-bot · 2026-08-18T20:47:08Z

OPERATOR DECISION: land this, investigate the root cause after. Restating the change honestly before it does.

The rung drop is now declared on the carrier itself (floor_expected_red.dag header), not in this PR body — a PR body has no consumer, and the population lives in that file:

previous rung 469 enrolled, every one executing
temporary rung 361
reason 102 witnesses cannot finish inside the 1552ms ceiling and report across two exit-nonzero channels
bounded population, both halves — 108 enrollments removed, AND the 78 healthy, fast, passing witnesses that leave as collateral because a module is the unit of relocation
restoration trigger the cost lane; a repaired module returns to the floor whole and its siblings return with it

tidy-lark-471's objection was mechanically right and is taken. Nothing in this tree guards roster shrinkage. An empty roster refuses (they landed that today); 469 -> 361 reads as perfectly healthy, and is therefore indistinguishable from the defect that silently dropped 197 identities and went unnoticed for an hour. The carrier now says explicitly that every other removal from this roster came from OBSERVING a pass, and these did not.

What this PR should not be read as claiming. The green it produces is vacancy, not health: 102 witnesses plus 78 siblings stop being observed. The 2026-08-04 admission ruling names relocation-to-long/ as its own specimen (gunbc#7762), the interpreter's refusal text says relocating a file does not discharge it, and gunbc#8456 is open to fix this module's comment for advertising the move. Landing this anyway is a deliberate, operator-directed, bounded trade — it is not an argument that the mechanism is sound.

And the witnesses are probably not slow. Three sessions measured this independently today: a row taking 71s on the floor runs in 70-85ms in isolation; a 12s row in 31ms; dag_arrow_lambda rebuilds a 6,230-line grammar with 134 production constructors once per witness for 3-line sources, because the floor gives each claim a fresh frame by design. My own probe found 76 of the 97 pass at a looser bound. No genuinely slow witness has been found. The cost is the evaluation context.

That is why the restoration trigger is the cost lane and not a threshold change: fixing the context returns modules wholesale, and this quarantine should be short-lived.

— sent from sleek-moth-351

…relocation-as-remedy tidy-lark-471's forward-looking catch, and it is a real risk rather than a stylistic one. #8456 says relocation is not an honest remedy for an over-budget row; #8457 relocates 21 modules. To the next reader those look contradictory, and the cheap wrong conclusion is that required_floor's comment is stale and should be reverted -- which would leave the floor advertising the unsanctioned move again. They are different acts. An author moving their own over-budget witness deletes coverage silently (the gunbc#7762 specimen). An operator-ruled bounded rung-drop with a named population and a restoration trigger is permitted by DESIGN 4b. The distinction is declaration and reversibility, never the directory -- so the carrier now says so where the relocation happened, rather than leaving the distinction in two PR bodies that no consumer reads. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…udget-to-long

… said 469 while carrying 361 Both found by an external reviewer mid-review on this PR, relayed by tidy-lark-471, and both real. I had verified module NAMES after the moves and never re-scanned PATH literals, which is the half that actually broke. (1) STALE PATHS -- 50 literals across 13 files still named a pre-move path. The dangerous one is witness_deferral_freeze.dag (9): its own note says a frozen row naming a witness the tree no longer carries is a StaleFrozenPathDeferral REFUSAL, so those rows would have failed the build, not degraded quietly. commit_workflow (4), ci_layer_roots (22), the three self-host frontiers (7), prose_row_frontier (2) and four others follow the same shape. Zero remain. The opposite failure was possible too and is worth recording: exclusion patterns match by SUBSTRING, and every move changed only the directory, never the filename -- verified, 21/21 basenames identical -- so bare-filename patterns still match and no row silently returned to the floor unannounced. (2) DENOMINATOR -- the header still read 'POPULATION: 469 identities' while the file carried 361. A count that contradicts its own contents is the change detector this project rejects, in the one file whose justification is being visible at identity grain. It now reads 361, states the 469 -> 361 drop, and says explicitly that the 78 collateral siblings are counted by NO number here -- because a half-counted population is exactly how the 78 would later become invisible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tidy-lark-471 verified what the external reviewer reached by arithmetic, and I reproduced it: the roster drops 108 identities, of which exactly 102 are the cost population (identity join against main run 32177951514 -- all 102 removed, none missed) and SIX are not. Those six were known_red_held: enrolled, and behaving exactly as enrolled. They leave because they share a module with a relocated row, not for anything about their own cost or verdict. Five are add_arrow_eval_by_execution rows and one is realization_sweep. The declaration said 108 and explained 102, which is a population described at a grain it is not actually bounded at -- the precise failure this roster exists to avoid, in the file whose whole justification is identity-grain visibility. They are now named individually, and typed as a THIRD collateral class: the 78 are unenrolled and passing, these six were enrolled and correctly red. Both leave for the same reason and both return when their module does. Also recording, so a stale review is not re-litigated later: the companion finding that commit_gate_roster and the live-discovery test retain pre-move bind/loop paths is REFUTED at this head. tidy-lark-471 checked it the general way -- every quoted .dag path on the branch diffed against the branch file list, then asked of each missing one whether it exists on main, which is the signature of a path these moves broke. Zero. The only surviving mentions are two lines in a historical measurement receipt, which is not a consumer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…aggler Operator-directed. Run 32186963581 on the first wave proved the approach and exposed its residue in one motion: stale_quarantine=0 budget_refused=0 <- both channels CLEARED known_red_held=361 failed=8 <- new The 102-row quarantine did exactly what it claimed. The 8 failures are rows that were PASSING under the ceiling and tipped over it once the slow head was gone -- and 7 of the 8 sit in the 1000-1552ms band I flagged as the tip risk before the run, so this is the predicted failure mode arriving on schedule rather than a surprise. This wave moves 16 modules: the 15 measured over 1000ms, plus test.claim.e0308_mechanical_trio_test at 774ms. That last one is BELOW the operator's line and is quarantined anyway because it actually failed on 32186963581 -- evidence beats threshold, and leaving a measured failure in place to honour a round number would red the tree for a rule. Roster 361 -> 358. About 200 further healthy siblings leave under the same module-grain rule as the 78, and the declaration says so. The underlying reason, recorded on the carrier: 1552ms was calibrated as measured-max-plus-one-quantum from a SINGLE 1527ms observation, so anything within a few hundred ms of it is not stably green on a shared runner. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The 1000ms wave took failed 8 -> 1. The survivor is a module that costs 42545ms -- 27x the ceiling -- and it was missed for an instructive reason recorded on the carrier: the cost table it was screened against came from a run where the 30s wall interrupted the slowest rows, so censored rows reported their deadline (30000ms) instead of their cost. The table systematically under-reported precisely the rows most in need of quarantine, and I read those lower bounds as values. 3 witnesses leave with the module. No roster row named it; roster stays 358. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…fication fix alone #8457 landed the long/ quarantine, and its 102-row cost population included the five passed-over-budget identities this PR was also removing from the expected-red roster. They are already absent from main's roster, which is now 358. So the roster half of this change is redundant and comes out entirely: the merge takes main's floor_expected_red.dag verbatim, byte-identical, rather than layering a second account of the same removal on top of #8457's declaration. Two carriers narrating one removal is the duplication §3 forbids, and the one that should survive is the one attached to the PR that performed it. What remains, and what this PR was always actually for, is the classification fix in cli_run.rs: an unenrolled row that exceeds its budget no longer reports into `failures` — the content-defect channel — but into `budget_refused`, split by whether it was Interrupted (no verdict reached, figure is a lower bound) or CompletedOverBudget (verdict reached, figure exact). That is untouched by #8457 and is not delivered by it. The reasoning error that put those five on the roster in #8446 is recorded in this PR's description and in the session's memory rather than in the corpus, since the corpus row that would have carried it no longer exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#8457 moved rust_test_fixtures_import_closure_witness_test.dag to a long/ home and renamed its module test.claim.long.*, which excludes it from the required floor by construction. That refutes this PR's rationale as written: the rows do NOT execute on the floor any more, so - SubstrateInputsOnly is dropped. It declared a live-tree disposition for admission to a fold that no longer reaches this module; a data row with no consumer is not worth landing speculatively against a return from quarantine that someone else will make with their own evidence. - both notes are rewritten again. Main's still said PATH-EXCLUDED from per-PR discovery (FalsifierSubstrateLongLane), which is false in a new way after #8457: the module IS excluded, but by authored name, not by that pattern row. The three deletions stand and are now more clearly correct: the required floor never consults witness_exclusion_frontier at all, and the falsifier cadence the two SubstrateLongLaneRow entries enrolled was deleted outright in the floor cut. Neither mechanism has an executing consumer. Conflict resolved by taking main's file and re-applying the three deletions, so #8457's path rewrites elsewhere in ci_layer_roots.dag survive. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

… either side #8457 landed while this branch was open. One file conflicts, and one row inside it — dag/tools/floor_effect_gate_witness.dag, floor_gate_failure_receipt_note — where both sides are correct about different things in the same string: this branch changes the COUNTS, because the cut deletes the regen gate: eight _passes witnesses -> seven, five companions -> four, and regen_verify_gate_failure_receipt drops out of the enumeration main changes a PATH inside the same string, because #8457 moved the witness to dag/test/claim/long/extdeps_scope_placement_gate_... Resolving to either side alone loses a real change and loses it silently, because both produce a plausible sentence. Taking this branch's side reverts the note to a path whose file no longer exists there — the stale-citation class §3 names, which rots without anyone touching it. Taking main's side leaves the note asserting eight witnesses, five companions, and enumerating a companion this PR deletes. Both halves are kept: seven/four with the regen companion removed, AND the long/ path. Verified by assertion rather than by eye — the resolved row must contain the new path, must contain the corrected counts, and must not contain regen_verify_gate_failure_receipt. The rest of the merge is clean: six other files were touched by both branches and auto-merged, and the RegenVerifyGate enum removal, the tools.regen_verify_gate import deletion and the regen_verify_gate_passes/_failure_receipt pair come through without conflict. Worth recording: this row ends by confessing its own debt — "Frontier counts are hand-authored prose debt — dissolve-on: derived projection from this entry's declarations." This conflict IS that debt coming due. A hand-authored count of the module's own declarations collided with an unrelated path edit in one string, and produced a merge no machine can resolve and a human can get wrong two ways. Derived from the declarations, this side of the conflict would not exist: deleting the gate would change the number. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

main #8457 relocated 108 over-budget witnesses to long/ homes (a declared rung drop) and had already removed 5 of the 57 identities my run named. This resolution takes main's roster and applies the remaining 52 STALE-QUARANTINE removals on top -- both changes are removals for different, non-overlapping reasons, so the merge is their union, not a choice between them. 358 -> 306 rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…d fold into Layer B; the whole-offered-set framing does not generalize sharp-raven-273 measured the real #8457 subject: 429 relocated test declarations, of which 207 (48%) were never floor_expected_red roster members. Corrections 1 and 2 (computed backfill baseline, declared rename succession) fold cleanly into the existing two-layer design plus a fifth Layer-B arm checking membership in the other declared rosters. Correction 3's broader "offered set" framing does not: witness_deferral_ freeze's cheapness is inseparable from diffing one small git-show-able text artifact, and Executed/LongDeclined have no such artifact to diff historically without a per-baseline whole-corpus discovery re-walk (the exact cost-shape class the 2026-08-11 census deletion removed). That finding is reported explicitly rather than stretching the mechanism to fit, per sharp-raven-273's standing invitation to do so. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…e red Run 32196069889 on this branch, 9001 claims, 8 fills, failed=1 on exactly the row every branch inherits. The named-consumer column earns itself immediately. run 32192150969 module_path_index dag+src/v2 51508ms paid_by dissolution_census...unbound_dissolution_empty_literal_refuses 139 claims / 29 modules shared run 32196069889 module_path_index dag+src/v2 45075ms paid_by emitter_nested_refinement_cast...single_refinement_carrier 94 claims / 20 modules shared Same cache, same key, the paid_by field changing hands after #8457 quarantined the first payer. The second payer is main's only failing witness at exactly 45784ms, of which 45075ms is this fill -- 98.5% of the entire remaining red is one build that 20 other modules read for free. The riders are named, so the next hop is a prediction rather than a warning: evaluation order is alphabetical, so quarantining this payer hands ~45s to emitter_optional_payload_cast_witness_test. That would be the fourth hop of a chain that has already run three times. The fix is gunbc#8470, which pays the index in preparation; its self-verifying post-condition is this row reappearing as paid_by=<outside-fold>. Still the only shared fill in the run. The nesting correction is visible in the same receipt: module_graph_facts on dag reports fill_ms=2990 against inclusive_ms=55048, so 52s of it was the scans it triggered -- the term the first receipt's total counted twice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS

…ared (#8464) * Attribute the floor's shared computation to who paid it and who benefited gunbc#8455 established that the floor's per-row wall time is not always the row's cost, and named the repair it did not perform. This is that repair, plus the mechanism root-caused to source. THE MECHANISM. The floor builds a fresh evaluation frame per claim, so the sharing #8455 measured is not an eval memo — one cannot survive between claims. It is the seed's process-global corpus-scan caches, each filled once per process and read free thereafter. The specimen resolves exactly: g2's specimen_projection reaches v2.lens.live_read_classification live_read_selection_manifest_live -> dependency_resolution_facts_live, whose seed realization cli_run.rs reference_resolution_facts performs an O(corpus) parse pass behind REFERENCE_EDGE_CACHE. The first claim pays it (12197ms); the second reads the map (31ms). WHY IT MATTERS. Nothing is computed twice — the caches are correct and the sharing is the saving. The attribution is wrong, in the direction that decides things, because the ceiling refuses per row: a refusal names the first toucher, whose own cost may be milliseconds. Splitting such a row moves the charge to whichever fragment runs first; REMOVING it does not remove the cost either, because the next claim to touch the fill pays the same seconds. WHAT LANDS. cli_run/shared_fill.rs records per fill: the cache, its declared key, what the fill cost, which claim paid, and every later claim and module that read it. gunbc.witness_row_cost owns the model — SharedFillPayer, and a three-state SharedFillDisposition because three remedies: preparation cost no witness can be pared to recover, a fill one module owns, and a fill that outlives any single removal. gunbc.observation_ci_render owns the line; the seed mirrors it and both sides assert one literal, so a format drift reds one of the pair. Eleven caches instrumented. Reporting only: nothing refuses, skips, or greens. unattributed_hits counts reads served by a fill this ledger did not observe, so the shared figure states itself as a lower bound rather than as the whole of the sharing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS * Fix the shared-fill note's backslash-apostrophe: a parse error that unloaded the whole render module dag does not admit \' in a string literal. One character at line 803 col 40 made gunbc.observation_ci_render unparseable, and every function in it then read as not-found across three witness files -- 60+ cascading diagnostics from one escape. Reworded rather than escaped, so nothing depends on which escapes the grammar admits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS * Count a nested fill once: the first receipt's total was an inclusive sum The first floor receipt (run 32192150969, 19 fills) exposed a defect in this instrument. These caches compose — building the module graph builds the reference edges and the path index on its way — so an outer fill's wall contains its inner fills'. Summing them counted every inner scan once per enclosing scan. Measured, in the receipt's own numbers: a 17890ms module_graph_facts fill contained a 12054ms module_path_index fill and a 5141ms reference_edges fill, leaving ~695ms of its own. The reported TOTAL fill_ms=302362 was inclusive; over self time it is ~180s. The per-fill payer, consumer and disposition columns were never affected — only the durations nested. Fills now carry both. fill_ms is SELF and the total sums it; inclusive_ms rides beside it because it is what names the caller that CAUSED the inner scans, which a self-only figure would hide. a_nested_fill_is_not_counted_twice_in_the_total pins the arithmetic on a planted two-level fill, and would have caught this. WHAT THE RECEIPT FOUND, now in the design note. One row's entire measured cost is a fill 29 other modules read: unbound_dissolution_empty_literal_refuses is one of five rows in the corpus with an exact cost (51620ms) and 51508ms of it is a module_path_index fill that 139 claims across 29 modules consume — 99.8%, the run's only `shared` fill. Removing that witness recovers ~112ms and hands 51.5s to whichever of the other 29 goes first. And the opposite, one row away on the same list: the 86741ms red_seed_runner_failure_detail_projects_located_receipt paid a 29017ms module graph fill and a 24965ms reference-edge fill, both EXCLUSIVE — nobody else reads either. Its cost is its own and it is a real paring target. Nothing in the per-row wall time distinguishes the two cases, which is the whole reason this ledger exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS * Name the consumer modules, and bound what `exclusive` establishes TWO CORRECTIONS, both from readers of the first receipt. NAME THEM, DO NOT COUNT THEM. The row line reported consumer_modules=29 and nothing else, so it could not answer the question the relocation raised: did the module that INHERITED a bill read that exact fill before? That is an identity join, and DESIGN section 5 rules a count is not one -- the same rule the floor's own completeness checks are held to. The line now carries the sorted module list, so a relocation is checkable at identity grain rather than by matching magnitudes across two runs on two machines. BOUND THE VERDICT. `exclusive` means no other module in the EXECUTED population read that fill on THIS run. It does not establish that none ever would: remove the payer and a would-be consumer may pay it next run, which is the first-touch trap one level up and is not visible from inside a single run. Two things bound the doubt, and both are now on the carrier rather than left implied. A fill is keyed on its declared inputs, so an exclusive fill on a key no other consumer requests is exclusive by construction rather than by luck. And the residue is decidable by execution -- run the fold with the payer absent and read the ledger again -- so until that run exists a recovery estimated from an exclusive row is an upper bound, stated as one. The design note also records why the ledger measures on the floor path at all: a witness whose subject is the corpus is not made cheap by shrinking the corpus. The 71s row is 70-85ms in a 67-module closure and 71060ms against the floor's 2376-module subject with nothing about the witness changed, so isolation is structurally unable to price that class. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS * Second receipt: the same fill changing hands, and 98.5% of main's sole red Run 32196069889 on this branch, 9001 claims, 8 fills, failed=1 on exactly the row every branch inherits. The named-consumer column earns itself immediately. run 32192150969 module_path_index dag+src/v2 51508ms paid_by dissolution_census...unbound_dissolution_empty_literal_refuses 139 claims / 29 modules shared run 32196069889 module_path_index dag+src/v2 45075ms paid_by emitter_nested_refinement_cast...single_refinement_carrier 94 claims / 20 modules shared Same cache, same key, the paid_by field changing hands after #8457 quarantined the first payer. The second payer is main's only failing witness at exactly 45784ms, of which 45075ms is this fill -- 98.5% of the entire remaining red is one build that 20 other modules read for free. The riders are named, so the next hop is a prediction rather than a warning: evaluation order is alphabetical, so quarantining this payer hands ~45s to emitter_optional_payload_cast_witness_test. That would be the fourth hop of a chain that has already run three times. The fix is gunbc#8470, which pays the index in preparation; its self-verifying post-condition is this row reappearing as paid_by=<outside-fold>. Still the only shared fill in the run. The nesting correction is visible in the same receipt: module_graph_facts on dag reports fill_ms=2990 against inclusive_ms=55048, so 52s of it was the scans it triggered -- the term the first receipt's total counted twice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS * Pin the share to its run, and read what the consumer set losing nine modules cost TWO CORRECTIONS FROM A READER OF THE SECOND RECEIPT. The 98.5 percent was stated as if the denominator were stable. It is not: the same row measured 45784, 45941, 46714, 50532 and 52982 across five runs on one day. The fill FRACTION is the robust part and the total is not, so the share is now pinned to its run and the claim that survives every reading is stated instead -- nearly all of the remaining red is one build that 20 modules read. And the two receipts price the quarantine itself, which I had not read out of my own data. The consumer set went from 139 claims across 29 modules to 94 across 20. A consumer is a FREE RIDER: it reads a fill someone else already built, so its marginal cost for that fill is approximately zero. Quarantining a rider removes coverage and recovers nothing on this axis, while quarantining the PAYER is what handed the bill onward and produced main's sole red. The limit on that reading is stated with it rather than left for someone to find: the first receipt carried consumer COUNTS only, so those nine modules cannot be named retroactively. The delta is consistent with riders having been quarantined; it does not identify which. That is the same count-versus-identity gap the named-consumer column closed, showing up one level out -- from here the question is a set difference rather than an inference. So the 20-module list reads two ways at once: who inherits the bill if the current payer is quarantined, and who is first in line to return once the fill belongs to preparation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS --------- Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…t) (#8469) * Design note: floor_expected_red shrink monotonicity (design-note-first) Scopes a monotone roster contract on floor_expected_red at inverted polarity from witness_deferral_freeze's growth wall: an undispositioned shrink of the roster must refuse, since #8437 showed a row can vanish with nothing distinguishing a legitimate repayment from a silently orphaned witness. Proposes reusing the freeze gate's baseline/coherence core (per the sharp-raven-273 brief's explicit constraint against a second several-hundred-line wall) plus a disposition layer that can only be decided from the current run's claim outcomes. No code lands from this note yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Resolve the three external corrections: LongQuarantined/WitnessRenamed fold into Layer B; the whole-offered-set framing does not generalize sharp-raven-273 measured the real #8457 subject: 429 relocated test declarations, of which 207 (48%) were never floor_expected_red roster members. Corrections 1 and 2 (computed backfill baseline, declared rename succession) fold cleanly into the existing two-layer design plus a fifth Layer-B arm checking membership in the other declared rosters. Correction 3's broader "offered set" framing does not: witness_deferral_ freeze's cheapness is inseparable from diffing one small git-show-able text artifact, and Executed/LongDeclined have no such artifact to diff historically without a per-baseline whole-corpus discovery re-walk (the exact cost-shape class the 2026-08-11 census deletion removed). That finding is reported explicitly rather than stretching the mechanism to fit, per sharp-raven-273's standing invitation to do so. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Correct the future-work framing for the offered-set gap: reuse FloorDiscoverySnapshot, don't mint gunbc.discovery_roster_ledger sharp-raven-273 found that src/v1/stage0/src/cli_run/floor_discovery_snapshot.rs already materializes most of what a run-over-run discovery ledger needs (digested, commit-stamped roster). Verified the retention question myself: target/floor-attempts is gitignored and no CI workflow uploads it, and the snapshot's one former cross-process reader (a coordinated scoped child) was deleted, so the file is currently write-only. Reworded the design note and DESIGN.md to propose persisting and diffing the existing snapshot instead of a new authority. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Correct the write-only claim: FloorDiscoverySnapshot has a live cross-process integrity reader, only the roster content is unconsumed sharp-raven-273 caught an overstatement: claim_executor's verify_floor_discovery_terminal_for_coordinator reads both snapshot files cross-process every run and digest/commit/tree-verifies them with typed refusal on mismatch. The deleted consumer was the roster-walk warm-cache reader documented in the file's header, not this integrity reader. The accurate gap is narrower: the roster field's content has no consumer, and the digest-coherence check a run-over-run diff would need already exists and is already exercised. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…8473) * Derive the quarantine's collateral exactly: 313, not "roughly 200" The rung-drop declaration is the one artifact whose entire job is making the coverage loss loud, and its total was an estimate. Two independent derivations now agree exactly, and both are written down so the figure can be re-checked rather than trusted. ROUTE A -- the two floor runs on main, differenced: pre 32177951514 planned=9420 passed=8951 known_red=367 stale=5 refused=102 post 32193032348 planned=8997 passed=8638 known_red=358 stale=0 refused=0 313 + 9 + 102 + 5 = 429 identities left the floor. ROUTE B -- the source: 429 `test fn` across the 38 modules #8457 relocated. The 6-identity gap against planned (423) is six identities that LANDED between the two runs, stated so the next reader does not read 423 as the answer. Two counts that were circulating at once are settled with it: the module count is 38 (21 + 16 + 1), and the problem population is 107 -- 102 BudgetInterrupted plus the 5 that PASSED over budget. Different observations, different remedies. WHAT IS STILL NOT DERIVED is named rather than assumed: which individual identities make up the 313. The floor reports per-identity outcomes only as log lines, and a scraped log is not an oracle. That needs an identity-grained receipt from the floor, not a better scrape. AND ONE FINDING THE QUARANTINE PRODUCED BY ACCIDENT, recorded because every decomposition PR scheduled on this lane will hit it: a cost figure here is not a property of its witness. emitter_nested_refinement_cast_witness_test single_refinement_carrier_emits_no_unsupported_cast cost 746ms pre and 45941ms post, unchanged in itself, with its own sibling at 763ms -- the relocation took out every earlier caller of compile_dag_rust_emit_check, so the one-time build_module_path_index_from_witness_roots construction landed on the first survivor and made it main's only failure. Splitting or relocating a module MOVES its shared fixed cost onto the next survivor rather than removing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Narrow the fixed-cost law to its class, and label 97/102 as set intersection Operator ruling, 2026-08-18. Three corrections, all to wording this file already carried, none to code. 1. THE LAW WAS STATED TOO WIDE, and that was this note's own error. It said every restoration receipt is confounded until the shared authority is paid in preparation. The true statement is narrower: a restoration receipt is confounded WHEN CHANGING THE POPULATION CHANGES WHICH CLAIM PAYS AN UNREPORTED LAZY SHARED FILL. Preparation is the remedy for that one class, and #8470 has already applied it to the concrete module-path-index instance. It is not the remedy for closure pollution, fixture/live-index coupling, repeated end-to-end crossings, duplicate coverage, whole-tree censuses, or genuine size-scaling cost -- separate classes with separate owning layers. Generalizing one confounder into a universal prerequisite would have serialized four lanes behind one that is already partly done. 2. 97 AND 102 ARE BOTH CORRECT AND NAME DIFFERENT SETS. Writing either as a bare `budget_refused` is what made the earlier accounts read as contradictory, so the intersection is now spelled out: budget-interrupted, global 102 enrolled here AND budget-interrupted 97 unenrolled AND budget-interrupted 5 enrolled here AND completed-over-budget (stale_quarantine) 5 3. TWO CLAIMS THAT READ STRONGER THAN THEY ARE. This block is supporting evidence for the identity-grained receipt, not a substitute for it -- aggregate arithmetic is exact and says nothing about WHICH identities. And `budget_refused=0` on the post run is not the population disappearing; it is the floor no longer executing it. The 116 identities ever observed over budget or failing are still owed a remeasurement against a cause. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Refuted by execution: dag_arrow_lambda's cost is the parse, not the grammar rebuild quiet-bee-353 measured it on gunbc#8478 (remote executor, release claim_batch) rather than reasoning about it. Folding the file from nineteen grammar builds to two did not pay -- 210.9s for the two folded claims against ~208s for the fourteen they replaced -- so the fold was reverted and the file left byte-identical to main. Solving the terms out of those runs: a dag_grammar() construction is ~0.5s and a single three-line parse through the interpreted frontend is ~12s. The apparatus is not the cost. The parse is. Two consequences, both recorded on the carrier that made the claim: The arrow row must NOT be planned as a witness-side repair. Twelve seconds to parse three lines is a frontend cost-shape defect, and it is plausibly the real subject behind several rows in this quarantine rather than an evaluation-context tax. "No witness has yet been found that is genuinely slow" is no longer established. That sentence is corrected rather than deleted because it was load-bearing for how this entire lane was planned -- it licensed treating every relocated row as an apparatus problem. The two measured extremes (71s -> 70-85ms, 12s -> 31ms) remain apparatus. That the residue is apparatus does not follow and is now open. Same class, same session, what DID measure and is green by execution: e0308 nine witnesses 2450ms -> five 1346ms, emitted lib.rs three -> two 561ms. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * The eight tipped in 32186963581, not 32189985063 — verified against the counters tidy-lark-471's catch, handed over rather than pushed by them so that two sessions do not edit one paragraph; #8480 closes into this. I verified it against the run counters rather than taking it: 32186963581 planned=9228 passed=8859 known_red_held=361 failed=8 32189985063 planned=8995 passed=8636 known_red_held=358 failed=1 32193032348 planned=8997 passed=8638 known_red_held=358 failed=1 Only one run observed eight. The straggler attribution to 32193032348 stands. The error was in the text I rewrote and I carried it through unchanged, which is the point worth recording: this file's own SECOND WAVE paragraph named 32186963581 correctly the whole time, so one file gave two accounts of one population and three rewrites -- sleek-moth-351's, tidy-lark-471's, mine -- walked past the contradiction. sharp-raven-273 and quiet-ibex-39 each measured the mismatch independently before it was fixed. The note now says the counters decide it, not the neighbouring sentence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Join this roster against the deferral freeze: 40 enrolled rows can never leave Derived, not suspected. 358 enrolled identities here, 669 frozen rows over 147 entries in gunbc.witness_deferral_freeze, intersection 40 at identity grain. This roster is admissible ONLY because it is temporary, and its only removal path is OBSERVING a row pass. Those 40 sit in files the freeze defers, so nothing executes them, so they can never be observed passing, so the self-emptying rule cannot fire for them ever. Two carriers each behaving correctly compose into permanent residents of a roster whose entire defence is that it is not a skip list -- and neither carrier can see the other, so nothing reported it. The freeze's arms already say a deferred row is NOT covered; this file already says an indefinite row is a defect nobody owns wearing a receipt. The join was simply never taken. The intersection should refuse rather than be counted: enrolment here and path-deferral there are contradictory claims about one identity. Surfaced by quiet-bee-353 chasing two reds in dag_add_emit_round_trip_test and confirming them pre-existing against MAIN's head 5ee2572 -- all seven claims run detached, verdicts identical to their branch, so not caused by their diff. At 2ms and 7ms they are not a cost row at all. They are a real defect nobody has been looking at because nothing runs the file, which is precisely what the deferral was hiding and what the join makes visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Correct my own claim: the deferral-freeze intersection rows DO execute still-wolf-510 refuted it against a live run, and they are right. I asserted that 40 identities enrolled here and path-deferred in witness_deferral_freeze can never leave this roster because nothing executes them. That was an assumption about a mechanism I did not read. The required floor excludes by AUTHORED MODULE NAME via long_home_prefixes. It never consults the freeze. The freeze is an ADMISSION standing -- whether a row may remain without an executing consumer -- and the floor gate tolerates LegacyFrozenPathDeferral. It does not suppress execution. Frozen path and discovered module are independent facts. Verified on green main run 32201531653: planned=9022 executed=9022 passed=8664 known_red_held=358 failed=0, with intersection members present in the output -- test.claim.ci_exclusion_proof.ci_exclusion_proof_sentinel FAILED in 13640ns, a row executing and held exactly as enrolled. They can leave the moment they pass. The defect is real but inverted and much smaller: the FREEZE rows are stale, asserting path-deferral for identities that have an executing consumer. The disposition is to retire those freeze rows with a receipt, not to find the roster rows a cadence. The construction wall still earns its place -- the intersection is a contradiction whichever way it resolves, and nothing detects it today. Kept rather than quietly rewritten, because the error is this file's own subject: I joined two carriers correctly and then read one carrier's meaning off its name instead of its mechanism -- the stale-citation class -- while correcting three other people's counts in the same file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 --------- Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…_red must refuse (instantiate witness_deferral_freeze at inverted polarity; design note first) (#8492) * Design note: floor_expected_red shrink monotonicity (design-note-first) Scopes a monotone roster contract on floor_expected_red at inverted polarity from witness_deferral_freeze's growth wall: an undispositioned shrink of the roster must refuse, since #8437 showed a row can vanish with nothing distinguishing a legitimate repayment from a silently orphaned witness. Proposes reusing the freeze gate's baseline/coherence core (per the sharp-raven-273 brief's explicit constraint against a second several-hundred-line wall) plus a disposition layer that can only be decided from the current run's claim outcomes. No code lands from this note yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Resolve the three external corrections: LongQuarantined/WitnessRenamed fold into Layer B; the whole-offered-set framing does not generalize sharp-raven-273 measured the real #8457 subject: 429 relocated test declarations, of which 207 (48%) were never floor_expected_red roster members. Corrections 1 and 2 (computed backfill baseline, declared rename succession) fold cleanly into the existing two-layer design plus a fifth Layer-B arm checking membership in the other declared rosters. Correction 3's broader "offered set" framing does not: witness_deferral_ freeze's cheapness is inseparable from diffing one small git-show-able text artifact, and Executed/LongDeclined have no such artifact to diff historically without a per-baseline whole-corpus discovery re-walk (the exact cost-shape class the 2026-08-11 census deletion removed). That finding is reported explicitly rather than stretching the mechanism to fit, per sharp-raven-273's standing invitation to do so. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Correct the future-work framing for the offered-set gap: reuse FloorDiscoverySnapshot, don't mint gunbc.discovery_roster_ledger sharp-raven-273 found that src/v1/stage0/src/cli_run/floor_discovery_snapshot.rs already materializes most of what a run-over-run discovery ledger needs (digested, commit-stamped roster). Verified the retention question myself: target/floor-attempts is gitignored and no CI workflow uploads it, and the snapshot's one former cross-process reader (a coordinated scoped child) was deleted, so the file is currently write-only. Reworded the design note and DESIGN.md to propose persisting and diffing the existing snapshot instead of a new authority. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Correct the write-only claim: FloorDiscoverySnapshot has a live cross-process integrity reader, only the roster content is unconsumed sharp-raven-273 caught an overstatement: claim_executor's verify_floor_discovery_terminal_for_coordinator reads both snapshot files cross-process every run and digest/commit/tree-verifies them with typed refusal on mismatch. The deleted consumer was the roster-walk warm-cache reader documented in the file's header, not this integrity reader. The accurate gap is narrower: the roster field's content has no consumer, and the digest-coherence check a run-over-run diff would need already exists and is already exercised. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Add floor_expected_red authored-vs-evaluated coherence check (fixture-scoped) Detects the #8437 incident shape: a chunk_NN function severed from its aggregator's Cons chain still authors identities and the roster stays non-empty, so nothing observes the silent drop. Reads decl_facts skeletons and asserts, at identity/lexeme grain, that every authored chunk identity reaches the evaluated roster and every declared chunk is actually linked into the aggregator body. Landed as an ordinary per-PR witness on synthetic fixtures only, per this lane's own witness_deferral_freeze_witness_test.dag precedent (mechanism on fixtures, corpus census deferred to where it's already paid for). The live join against floor_expected_red.dag's real 20 chunks is not landed here -- it costs ~56s (a fresh whole-workflow decl_facts parse), ~36x the per-PR floor ceiling, and per DESIGN §5/§6 that cost may not be paid inside a claim, relocated to long/, or recorded as an unexecuted-but-honest deferral (the gunbc#7762 shape). It is recorded as OWED in floor_expected_red_coherence.dag, naming its future home: the required-floor run's already-resolved whole-corpus parse during preparation, not a fresh per-claim decl_facts call. decl_facts_skeleton.dag gains node_skeleton_authored_non_construction_atom_lexemes, the two-pass construction-spelling subtraction the coherence check needs to distinguish authored identities from constructor spellings by edge provenance rather than lexeme shape. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Fix CI: dissolve list_append name collision, give the trailing annotation a subject floor_expected_red_coherence.dag declared a local list_append that collided with v2.std.algebra's pre-existing, globally-unique list_append under namespace-only bare-name resolution: with two same-named declarations in the import closure, every unrelated bare list_append(...) call site in the corpus lost its unique binding, producing the CI error flood. Fix is reuse, not rename: the local fn is deleted and v2.std.algebra.list_append is imported and called with named params (left:/right:) at both call sites, leaving one authority for the operation instead of two same-shaped fns under different names. Separately, floor_expected_red_coherence_witness_test.dag had a source-annotation comment with no following declaration -- a parse error under DESIGN §4c, since a standalone `//` block must attach to a module-scope declaration. The first attempt manufactured a commentary-only `data ...: String` row purely to give the annotation a subject, which itself risked violating §4c ("an ordinary String declaration whose sole purpose is commentary is misplaced or dead data"). Corrected: the comment is merged into the existing POSITIVE CONTROL annotation immediately above fixture_linked_only_chunks, a real declaration it was already describing the context for, and no new data row is introduced. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Record the #8460 Repaid specimen for Layer B (not yet built) sharp-raven-273 confirmed the coherence check landing in this PR is a single-snapshot claim with no removal concept, so there was no positive/negative fixture to add there. Instead: record the real #8460 specimen (52 identities removed across only 17 deleted lines, a >3x understatement risk for any line-grain diff, and a required removal undisclosed in the PR body) against the still-unbuilt Layer B disposition design, so its builder has a real case rather than reconstructing one from commit history later. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Restore floor_expected_red shrink-monotonicity roadmap bullet at its correct generated-artifact source DESIGN.md's rendering of this bullet came from a pre-existing, already-on-main generated-artifact-discipline violation (PR #8469 plus three follow-up correction commits hand-edited DESIGN.md directly; dag/gunbc/design_document.dag never carried this bullet at any point in its history). This PR's earlier mechanical regen of a merge conflict therefore correctly dropped a bullet whose true source never contained it, which review 53651 flagged as the roadmap thread silently vanishing while its named work remains open. Fix: source the bullet properly in design_document.dag's open_threads_blocks() and regenerate DESIGN.md mechanically, so the thread survives through the correct authority instead of a hand-edit. * Delete floor_expected_red coherence check's dissolution registration; the fixture witness is finished evidence, not scaffolding review 53651's Finding 1 correctly read floor_expected_red_chunk_coherence_check_dissolve_on (unbound_dissolution) as declaring new debt that DESIGN's 2026-08-10 ruling requires an external operator verdict for. sharp-raven-273 (parent) identified the real defect: the declaration itself, not the scope. Per DESIGN §4b, a climb deletes redundant lower-rung PRODUCTION machinery but never the evidence -- the fixture-scale RED controls in floor_expected_red_coherence_witness_test.dag are the permanent proof the mechanism works, not a temporary stand-in for a later live join. They survive the terminal architecture unchanged and are consumed by it (DESIGN §6's reviewer test). - Delete the DissolutionCondition/unbound_dissolution registration and its import. - Reframe the module note positively: the mechanism is proven complete on planted rosters (witness_deferral_freeze_witness_note's own pattern: a corpus census may be irreducible but a mechanism never is). - Record the live 20-chunk join as a separate, pre-existing, unowned gap this module partially closes rather than introduces -- AcknowledgePreexistingDebt, which needs no approval, per the same 2026-08-10 ruling. * Restore the caller-enumerated-roster limitation as a positive scope note, not a dissolution sharp-raven-273 caught that deleting unbound_dissolution (bbae23f) took a real design fact with it: floor_expected_red_chunk_coherence_check only ever sees the chunks its caller enumerates, so a chunk declared in the checked module but omitted from the call site's ChunkDeclRef roster is invisible and reports coherent -- an empty-observation-narrow blind spot now living inside the mechanism that exists to catch exactly that shape. Restore the fact as a SCOPE comment on the function itself (permanent property, not lifecycle debt) rather than as a DissolutionCondition, name the blind spot explicitly, and cross-reference it with live_floor_expected_red_coherence_join_gap_note: closing the omission face requires the same fresh whole-module decl_facts parse the content face already needs, so there is no cheap naming-heuristic-free fix available at lesser cost -- it is one gap with two faces, not two gaps. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

… hiding v2.test.lens_inert_carrier.inert_carrier_test was itself quarantined to long/ by #8457. While it sat there, the floor cut deleted FloorWitnessRow from the tree entirely -- zero .dag and zero .rs references remain -- so its roster row went stale with nothing executing to say so. Un-quarantining the witness surfaced it: inert_carrier_no_unrostered_or_stale returned false, measured as unrostered=0, stale_roster=1, live=12 against a 13-row roster. Deleted per the row's own dissolution condition. Re-measured after: stale_roster=0, unrostered=0, live=12 over a 12-row roster. This is the defect-the-quarantine-was-hiding case, not data our own restoration invalidated (unrostered=0 means we introduced no new inert carriers).

* RESTORE WAVE A (zero risk): un-quarantine 20 modules / 262 rows WAVE A restoration: restore 20 modules and 262 witness rows from quarantine (test.claim.long.*, v2.test.long.*, v2.test.claim.long.* prefixes) back to their real homes by: - Moving 20 test files out of long/ directories - Renaming modules to remove .long. prefix - Updating path citations in witness_deferral_freeze.dag, prose_row_frontier.dag, ci_layer_roots.dag Wave A modules identified from pre-quarantine floor run 32177951514: those 20 modules whose maximum row cost never exceeded 1552ms ceiling. All modules ranked by worst-case cost (parent session's measurement): 1. emit_test.dag (47 rows, max 1092ms) 2. roadmap_authority_test.dag (46 rows, max 1026ms) 3. roadmap_tactile_witness_test.dag (26 rows, max 1017ms) ... (17 more modules) No floor_expected_red row enrollments added yet. Restored rows will be processed per the parent's disposition logic: those still expected-red need re-enrollment, those now passing must not be enrolled. Expected impact: planned count rises from ~9008 to ~9270 (delta +262 rows). * Wave A: drop the four mis-selected modules and transport_script back to long/ The parent's Wave A join matched a module's tail segment as a substring of the pre-quarantine logged identity, but the quarantine renames replaced dots with underscores, so the join silently missed every row in four modules and scored them worst=0ms. That was "my matcher could not see them", not "under 100ms": the pre-run log carries roster_gate rows at 1555-1581ms, atom_body_discriminator at 1554ms, and live_read_classification at 2233-2399ms. Reverted to long/ (33 rows): src/v2/test/claim/identity_captured_navigation/roster_gate_test.dag src/v2/test/claim/body_lowering/atom_body_discriminator_witness_test.dag src/v2/test/claim/live_read_classification_test.dag dag/test/claim/dissolution_census_witness_test.dag Also reverted, for a different reason (3 rows): dag/test/claim/transport_script_wall_compile_red_test.dag It measured 1394ms pre-quarantine and cost 48963ms in the restore run with nothing about the witness changed. It calls compile_dag_rust_emit_check, whose memo only engages under a floor run, so whichever caller the floor reaches first pays an uncached full rebuild -- restoring modules changed who that is. A real finding for the cost lane, not a Wave A member. Citation carriers reverted in step: prose_row_frontier, ci_layer_roots, witness_deferral_freeze, dissolution_census_mechanism_witness_test. Expected planned delta is now 262 - 33 - 3 = 226 over the 9082 main baseline. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Delete the stale FloorWitnessRow inert-carrier row the quarantine was hiding v2.test.lens_inert_carrier.inert_carrier_test was itself quarantined to long/ by #8457. While it sat there, the floor cut deleted FloorWitnessRow from the tree entirely -- zero .dag and zero .rs references remain -- so its roster row went stale with nothing executing to say so. Un-quarantining the witness surfaced it: inert_carrier_no_unrostered_or_stale returned false, measured as unrostered=0, stale_roster=1, live=12 against a 13-row roster. Deleted per the row's own dissolution condition. Re-measured after: stale_roster=0, unrostered=0, live=12 over a 12-row roster. This is the defect-the-quarantine-was-hiding case, not data our own restoration invalidated (unrostered=0 means we introduced no new inert carriers). * Drop where_refinement_enforcement_witness back to long/: the one budget refusal Floor run 32215787759 @ 447d696: failed=0, but budget_refused=1 -- test.claim.where_refinement_enforcement_witness .where_refinement_cast_literal_oci_other_digest_algorithm_accepts Cpu, cost exactly 1794ms against 1552ms 242ms over, reached its verdict, so it is a measurement rather than a bound: a cost debt, not a defect, and explicitly not expected-red roster material. Wave A's contract is zero risk, so the module goes back to its quarantine home rather than carrying a refusal. Read on the cause: the module is 24 compile_dag_rust_emit_check calls, and that builtin's memo only engages under a floor run -- whichever caller reaches a given compile first pays it uncached. Restoring 20 modules changed who that first toucher is. Same mechanism already measured on transport_script_wall_compile_red (1394ms -> 48963ms with nothing about the witness changed), just two orders of magnitude smaller here. File and module name are byte-identical to origin/main again; the three citations naming the un-quarantined path are pre-existing on main and untouched either way. * Actually re-quarantine where_refinement: the module-name line, not just the path b87eda6 moved the file back under long/ but left the module-name edit uncommitted, so required_floor -- which excludes by authored module name via long_home_prefixes, not by path -- kept executing all 24 rows. Run 32217622345 names it: where_refinement_cast_literal_oci_other_digest_algorithm_accepts, Cpu, 1913ms against 1552ms. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Re-quarantine occurrence_identity and live_deploy.emit: both reproducibly over budget Run 32219605819 (budget_refused=2, failed=0): occurrence_identity_typed_ordinal_boundary_refuses_raw_scalar_holds Cpu, exactly 1792ms against 1552ms (1803ms in run 32217622345) live_deploy.emit twin_and_production_configure_disjoint_tailscale_endpoints Wall, at least 1554ms against 1552ms (1561ms in run 32217622345) Both refused in two consecutive runs, so neither is margin noise. Wave A's contract is zero risk, so both go back to their main homes -- path AND module name together, since required_floor excludes by module name. Their two path citations revert with them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Revert c04008e in full: a censored bound is not a measurement Operator ruling: no row or module is removed on a lower bound, and cost debt is not grounds to remove coverage either. Both drops come back. occurrence_identity_typed_ordinal_boundary_refuses_raw_scalar_holds Cpu, exactly 1792ms -- a real verdict over the line. It stays executing and gets baselined; a row that reached its verdict does not leave the floor for being expensive. live_deploy.emit twin_and_production_configure_disjoint_tailscale_endpoints Wall, at least 1554ms -- censored, so not a measurement at all. 1553ms and 1913ms are the same state (cost >= N), carrying no information about where the row would have completed or whether it would have passed. The gate itself is what was measuring wrong: 1552ms is serving as the cost requirement, the CPU interrupt point and the wall interrupt point at once, so whether a row reads "exactly" or "at least" is partly polling alignment. Two policy cuts land before Wave A runs again -- a completed-cost line evaluated only after a verdict, and a separate safety deadline that interrupts runaways (interruption is NotEvaluated, never green) -- with cost basis selected by witness purpose, so a scheduler-sensitive wall crossing cannot decide whether a SubstrateInputsOnly witness's computation is too expensive. Tree is now identical to 3aed5cc; the restored population is 14 modules again. No rebase and no further drops until the policy cuts land. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

… witnesses Turns PR #8495's hedged "most plausibly the corpus-wide load/index cost" into typed verdicts, grounded in a real --required-floor pass (#8455's shared_fill ledger post-dates #8457's quarantine of these modules by name, so no floor run ever had both simultaneously; a throwaway, never-merged probe PR (#8563, run 32291153434 / job 96192007757) temporarily renamed the three identities for one CI pass to observe them, then was closed without merging). - declared_import_closure_lists_rust_import and ambient_pool_provider_preserves_listed_import: every module_graph_facts/module_path_index/reference_edges fill either row touches is keyed on this witness's own narrow class_b_declared_import_pool_roots, paid_by exactly this module, consumer_modules=1 -> SharedFillExclusiveToOneModule. The run's TOTAL line (fills=17, shared_fill_ms=0) shows zero SharedFillSharedAcrossModules exemplars anywhere in that floor pass. Attributed fill covers ~17.4-18.5s of each row's cost; the remainder is real per-call cost outside the ledger's surface. - red_seed_runner_failure_detail_projects_located_receipt: appears in zero of the run's 17 shared_fill rows, neither as payer nor consumer. The standard-pool fills its own entry resolution would touch are all paid_by=<outside-fold> (pre-warmed during floor preparation before any claim runs) -- refuting the shared-fill mechanism as this identity's cost source entirely. Its ~54-76s cost and RSS growth (worst single claim in both observed runs) sit outside the ledger's instrumented surface. Both notes now report a denominator-honest verdict rather than a plausibility, per DESIGN.md's empty-observation-narrow rule. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ARER4f3NVk6ZwMvHNCBaUb

… witnesses (#8566) Turns PR #8495's hedged "most plausibly the corpus-wide load/index cost" into typed verdicts, grounded in a real --required-floor pass (#8455's shared_fill ledger post-dates #8457's quarantine of these modules by name, so no floor run ever had both simultaneously; a throwaway, never-merged probe PR (#8563, run 32291153434 / job 96192007757) temporarily renamed the three identities for one CI pass to observe them, then was closed without merging). - declared_import_closure_lists_rust_import and ambient_pool_provider_preserves_listed_import: every module_graph_facts/module_path_index/reference_edges fill either row touches is keyed on this witness's own narrow class_b_declared_import_pool_roots, paid_by exactly this module, consumer_modules=1 -> SharedFillExclusiveToOneModule. The run's TOTAL line (fills=17, shared_fill_ms=0) shows zero SharedFillSharedAcrossModules exemplars anywhere in that floor pass. Attributed fill covers ~17.4-18.5s of each row's cost; the remainder is real per-call cost outside the ledger's surface. - red_seed_runner_failure_detail_projects_located_receipt: appears in zero of the run's 17 shared_fill rows, neither as payer nor consumer. The standard-pool fills its own entry resolution would touch are all paid_by=<outside-fold> (pre-warmed during floor preparation before any claim runs) -- refuting the shared-fill mechanism as this identity's cost source entirely. Its ~54-76s cost and RSS growth (worst single claim in both observed runs) sit outside the ledger's instrumented surface. Both notes now report a denominator-honest verdict rather than a plausibility, per DESIGN.md's empty-observation-narrow rule. Claude-Session: https://claude.ai/code/session_01ARER4f3NVk6ZwMvHNCBaUb Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…rect the run id for the eight that tipped (#8634) * Derive the quarantine's collateral exactly: 313, not "roughly 200" The rung-drop declaration is the one artifact whose entire job is making the coverage loss loud, and its total was an estimate. Two independent derivations now agree exactly, and both are written down so the figure can be re-checked rather than trusted. ROUTE A -- the two floor runs on main, differenced: pre 32177951514 planned=9420 passed=8951 known_red=367 stale=5 refused=102 post 32193032348 planned=8997 passed=8638 known_red=358 stale=0 refused=0 313 + 9 + 102 + 5 = 429 identities left the floor. ROUTE B -- the source: 429 `test fn` across the 38 modules #8457 relocated. The 6-identity gap against planned (423) is six identities that LANDED between the two runs, stated so the next reader does not read 423 as the answer. Two counts that were circulating at once are settled with it: the module count is 38 (21 + 16 + 1), and the problem population is 107 -- 102 BudgetInterrupted plus the 5 that PASSED over budget. Different observations, different remedies. WHAT IS STILL NOT DERIVED is named rather than assumed: which individual identities make up the 313. The floor reports per-identity outcomes only as log lines, and a scraped log is not an oracle. That needs an identity-grained receipt from the floor, not a better scrape. AND ONE FINDING THE QUARANTINE PRODUCED BY ACCIDENT, recorded because every decomposition PR scheduled on this lane will hit it: a cost figure here is not a property of its witness. emitter_nested_refinement_cast_witness_test single_refinement_carrier_emits_no_unsupported_cast cost 746ms pre and 45941ms post, unchanged in itself, with its own sibling at 763ms -- the relocation took out every earlier caller of compile_dag_rust_emit_check, so the one-time build_module_path_index_from_witness_roots construction landed on the first survivor and made it main's only failure. Splitting or relocating a module MOVES its shared fixed cost onto the next survivor rather than removing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Narrow the fixed-cost law to its class, and label 97/102 as set intersection Operator ruling, 2026-08-18. Three corrections, all to wording this file already carried, none to code. 1. THE LAW WAS STATED TOO WIDE, and that was this note's own error. It said every restoration receipt is confounded until the shared authority is paid in preparation. The true statement is narrower: a restoration receipt is confounded WHEN CHANGING THE POPULATION CHANGES WHICH CLAIM PAYS AN UNREPORTED LAZY SHARED FILL. Preparation is the remedy for that one class, and #8470 has already applied it to the concrete module-path-index instance. It is not the remedy for closure pollution, fixture/live-index coupling, repeated end-to-end crossings, duplicate coverage, whole-tree censuses, or genuine size-scaling cost -- separate classes with separate owning layers. Generalizing one confounder into a universal prerequisite would have serialized four lanes behind one that is already partly done. 2. 97 AND 102 ARE BOTH CORRECT AND NAME DIFFERENT SETS. Writing either as a bare `budget_refused` is what made the earlier accounts read as contradictory, so the intersection is now spelled out: budget-interrupted, global 102 enrolled here AND budget-interrupted 97 unenrolled AND budget-interrupted 5 enrolled here AND completed-over-budget (stale_quarantine) 5 3. TWO CLAIMS THAT READ STRONGER THAN THEY ARE. This block is supporting evidence for the identity-grained receipt, not a substitute for it -- aggregate arithmetic is exact and says nothing about WHICH identities. And `budget_refused=0` on the post run is not the population disappearing; it is the floor no longer executing it. The 116 identities ever observed over budget or failing are still owed a remeasurement against a cause. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Refuted by execution: dag_arrow_lambda's cost is the parse, not the grammar rebuild quiet-bee-353 measured it on gunbc#8478 (remote executor, release claim_batch) rather than reasoning about it. Folding the file from nineteen grammar builds to two did not pay -- 210.9s for the two folded claims against ~208s for the fourteen they replaced -- so the fold was reverted and the file left byte-identical to main. Solving the terms out of those runs: a dag_grammar() construction is ~0.5s and a single three-line parse through the interpreted frontend is ~12s. The apparatus is not the cost. The parse is. Two consequences, both recorded on the carrier that made the claim: The arrow row must NOT be planned as a witness-side repair. Twelve seconds to parse three lines is a frontend cost-shape defect, and it is plausibly the real subject behind several rows in this quarantine rather than an evaluation-context tax. "No witness has yet been found that is genuinely slow" is no longer established. That sentence is corrected rather than deleted because it was load-bearing for how this entire lane was planned -- it licensed treating every relocated row as an apparatus problem. The two measured extremes (71s -> 70-85ms, 12s -> 31ms) remain apparatus. That the residue is apparatus does not follow and is now open. Same class, same session, what DID measure and is green by execution: e0308 nine witnesses 2450ms -> five 1346ms, emitted lib.rs three -> two 561ms. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * The eight tipped in 32186963581, not 32189985063 — verified against the counters tidy-lark-471's catch, handed over rather than pushed by them so that two sessions do not edit one paragraph; #8480 closes into this. I verified it against the run counters rather than taking it: 32186963581 planned=9228 passed=8859 known_red_held=361 failed=8 32189985063 planned=8995 passed=8636 known_red_held=358 failed=1 32193032348 planned=8997 passed=8638 known_red_held=358 failed=1 Only one run observed eight. The straggler attribution to 32193032348 stands. The error was in the text I rewrote and I carried it through unchanged, which is the point worth recording: this file's own SECOND WAVE paragraph named 32186963581 correctly the whole time, so one file gave two accounts of one population and three rewrites -- sleek-moth-351's, tidy-lark-471's, mine -- walked past the contradiction. sharp-raven-273 and quiet-ibex-39 each measured the mismatch independently before it was fixed. The note now says the counters decide it, not the neighbouring sentence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Join this roster against the deferral freeze: 40 enrolled rows can never leave Derived, not suspected. 358 enrolled identities here, 669 frozen rows over 147 entries in gunbc.witness_deferral_freeze, intersection 40 at identity grain. This roster is admissible ONLY because it is temporary, and its only removal path is OBSERVING a row pass. Those 40 sit in files the freeze defers, so nothing executes them, so they can never be observed passing, so the self-emptying rule cannot fire for them ever. Two carriers each behaving correctly compose into permanent residents of a roster whose entire defence is that it is not a skip list -- and neither carrier can see the other, so nothing reported it. The freeze's arms already say a deferred row is NOT covered; this file already says an indefinite row is a defect nobody owns wearing a receipt. The join was simply never taken. The intersection should refuse rather than be counted: enrolment here and path-deferral there are contradictory claims about one identity. Surfaced by quiet-bee-353 chasing two reds in dag_add_emit_round_trip_test and confirming them pre-existing against MAIN's head 5ee2572 -- all seven claims run detached, verdicts identical to their branch, so not caused by their diff. At 2ms and 7ms they are not a cost row at all. They are a real defect nobody has been looking at because nothing runs the file, which is precisely what the deferral was hiding and what the join makes visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 * Correct my own claim: the deferral-freeze intersection rows DO execute still-wolf-510 refuted it against a live run, and they are right. I asserted that 40 identities enrolled here and path-deferred in witness_deferral_freeze can never leave this roster because nothing executes them. That was an assumption about a mechanism I did not read. The required floor excludes by AUTHORED MODULE NAME via long_home_prefixes. It never consults the freeze. The freeze is an ADMISSION standing -- whether a row may remain without an executing consumer -- and the floor gate tolerates LegacyFrozenPathDeferral. It does not suppress execution. Frozen path and discovered module are independent facts. Verified on green main run 32201531653: planned=9022 executed=9022 passed=8664 known_red_held=358 failed=0, with intersection members present in the output -- test.claim.ci_exclusion_proof.ci_exclusion_proof_sentinel FAILED in 13640ns, a row executing and held exactly as enrolled. They can leave the moment they pass. The defect is real but inverted and much smaller: the FREEZE rows are stale, asserting path-deferral for identities that have an executing consumer. The disposition is to retire those freeze rows with a receipt, not to find the roster rows a cadence. The construction wall still earns its place -- the intersection is a contradiction whichever way it resolves, and nothing detects it today. Kept rather than quietly rewritten, because the error is this file's own subject: I joined two carriers correctly and then read one carrier's meaning off its name instead of its mechanism -- the stale-citation class -- while correcting three other people's counts in the same file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185Q2N7fp1i5WPJLNpMBu47 --------- Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

gunbc-ci-auto-heal and others added 2 commits August 18, 2026 20:10

gunbai-bot Bot changed the title ~~Floor Y fix forward~~ Quarantine all 102 over-budget witnesses to long/ homes so the floor goes green Aug 18, 2026

gunbai-bot Bot marked this pull request as ready for review August 18, 2026 20:41

gunbai-bot Bot changed the title ~~Quarantine all 102 over-budget witnesses to long/ homes so the floor goes green~~ Quarantine 102 over-budget witnesses to long/ homes: a DECLARED bounded rung drop Aug 18, 2026

gunbc-ci-auto-heal and others added 5 commits August 18, 2026 20:49

Merge remote-tracking branch 'origin/main' into floor/move-five-overb…

e0b23c5

…udget-to-long

gunbai-bot Bot mentioned this pull request Aug 18, 2026

Measure what the slow floor witnesses actually cost, before any are pared #8464

Merged

briansrls merged commit 6f3d374 into main Aug 18, 2026
1 check failed

briansrls deleted the floor/move-five-overbudget-to-long branch August 18, 2026 22:30

gunbai-bot Bot mentioned this pull request Aug 18, 2026

Delete three dead Class B bookkeeping rows and correct two stale witness notes #8430

Merged

gunbai-bot Bot mentioned this pull request Aug 18, 2026

Floor: pay the module-path index in preparation, not in an arbitrary claim #8470

Merged

This was referenced Aug 18, 2026

Make the rung drop's bounded population exact: 358, 111, 429, 207 #8472

Merged

Record the first restoration decision: not yet, and the module returns whole #8481

Merged

gunbai-bot Bot mentioned this pull request Aug 19, 2026

One left-corner relation instead of 38 closures; grammar fixpoints converge instead of running a fixed 38 rounds #8487

Merged

This was referenced Aug 19, 2026

RESTORE WAVE A: restore 14 modules / 226 witness identities #8503

Merged

Fabric recut program: the six carriers survive, the layer underneath is replaced #8550

Merged

gunbai-bot Bot mentioned this pull request Aug 19, 2026

PROBE ONLY (do not merge): observe shared-fill ledger for ATTRIBUTION-3 identities #8563

Closed

gunbai-bot Bot mentioned this pull request Aug 19, 2026

ATTRIBUTION-3: decide SharedFillDisposition for three quarantined witness identities #8566

Merged

Navigation Menu

Repository navigation

Quarantine 102 over-budget witnesses to long/ homes: a DECLARED bounded rung drop - #8457

Quarantine 102 over-budget witnesses to long/ homes: a DECLARED bounded rung drop#8457
briansrls merged 9 commits into
mainfrom
floor/move-five-overbudget-to-long

gunbai-bot Bot commented Aug 18, 2026 •

edited

Loading

Uh oh!

gunbai-bot Bot commented Aug 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

gunbai-bot Bot commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What main is red on

Why enrollment could never fix this

The mechanism, and why the diff looks like renames

Declared coverage loss — the part worth arguing about

Expected result

What this is not

Uh oh!

gunbai-bot Bot commented Aug 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

gunbai-bot Bot commented Aug 18, 2026 •

edited

Loading