Repository navigation
break down marginal witnesses - #9616
Closed
gunbai-bot[bot] wants to merge 35 commits into
Closed
gunbai-bot[bot] wants to merge 35 commits into
gunbai-bot[bot] wants to merge 35 commits into
Conversation
… that accumulated under the 10x drift The ceiling was set to 500ms by operator ruling at #8283 (2026-08-17) and was never repealed. It was raised twice in 18 hours, and neither raise had a ruling on the value: 500 -> 1552 (#8514): justified only by "measured-max plus one scheduler quantum" over the then-current tree. That is the tree-copied oracle DESIGN section 5 forbids -- the ceiling was set to whatever the slowest witness happened to cost, which is a change detector, not a budget. Its own comment said "not an open slack ratchet"; it ratcheted 3.2x eleven hours later. 1552 -> 5000 (#8533): cited "operator ruling 2026-08-19" on both clocks. That ruling was about SPLITTING CPU from wall. The operator's quoted words in the diff -- "DO NOT set CPU and wall to the same 5000ms" -- presuppose 5000 was already on the table, so it is a ruling about the mechanical copy and not about the magnitude. The value rode in as a passenger, which is the authority substitution failure mode DESIGN names. CPU returns to 500. Wall goes to 2000, derived from the population it must not trip rather than as a multiple of the CPU figure: over the 11,572 rows within the CPU budget on run 33109071348 the worst wall was 1037ms. The diagnostic cost line moves 1552 -> 100 because at 1552 it became unfireable under a 500ms ceiling -- permanently green by construction, which section 4b calls worse than absent. 320 witnesses exceed 500ms (54.7% of the fold's CPU over 2.7% of its rows). They are frozen in v2.workflow.floor_cost_debt and WITHHELD FROM EXECUTION. Not relocated: the files do not move, because relocation to a long/ home is the move the 2026-08-04 admission ruling forbids and gunbc.witness_deferral_freeze exists to close -- it deletes coverage while retaining the source with nothing counting the loss. The difference here is that the withhold is declared, counted every run, identity-grain and shrink-only. Coverage for those 320 rows is GONE while they sit there, and that is declared as a section 4b(3) rung drop (mechanically preventable -> outside the ladder) rather than described as a deferral. A row leaves by being made cheap and having its line deleted; the roster is self-correcting, since a row wrongly included proves itself by passing under the ceiling once released. A rostered identity the tree no longer carries BLOCKS (stale_cost_debt), so the roster cannot rot into a permission slip. The withheld population itself does not block. Verified: cargo check clean; v1_src_dag_parse reports 4203 files parse-clean. The five preemption_reachability assertions still hold at the new limits (60317 > 500 trips the same arm; 42 is inside both). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… fold
The first cut withheld cost-debt rows with a `continue` at the top of the
execution loop. That form would have red the floor on its first run, in two
places, and a code review approved it:
ClaimIdentityCountsDisagree -- planned == executed + not_attempted is exact,
and 320 planned claims that neither executed nor published as not-attempted
break it.
TerminalLedgerIncomplete -- every planned identity must appear exactly once
in the terminal population, and a withheld claim produces no terminal row.
A third partition (SitePartitionInexact) guards the site level. All three are
the fail-closed design working: a `continue` at the top of a fold is exactly
the shape that leaves a partition behind.
So withholding moves to claim BUILD time as a fourth RequiredFloorDisposition
arm, DeclinedCostDebt, alongside the long-home and live-tree declines. A
withheld row never becomes a planned claim, all three partitions stay exact,
and the fold builds no scope and allocates no frame for it.
Cost debt is ordered LAST among the declines. A row that already declines for
a home reason keeps that decline, never enters the cost-debt reverse join, and
surfaces as a STALE roster row -- which blocks, and whose diagnostic says to
delete the line. Ordering it first would silently convert a stale row into a
permanent, plausible-looking withhold.
The fourth arm made three Rust matches and two .dag folds fail to compile,
which is what discovery_census's own comment says it is for ("A FOURTH
DISPOSITION ARM MUST FAIL TO COMPILE IN THIS FOLD").
MEASURED INTERACTION, and it is a real fork rather than a tidy-up: 7 identities
sit in both this roster and floor_expected_red, and leaving both claims
standing blocks in EITHER direction. Withheld and still enrolled, the
expected-red reverse join calls them stale. Un-withheld, they exceed the 500ms
ceiling and ExpectedRedArm explicitly refuses to hold an interrupted budget
outcome, so they land as failures. All 7 measure 561-3010ms, so none can
execute inside the ceiling. Cost debt therefore wins: enrollment in
floor_expected_red asserts the identity REACHES ITS SUBJECT AND ANSWERS, and a
withheld row answers nothing, so the roster that yields is the one making a
claim the run cannot support. The enrollment is dormant, not deleted, and the
suppression is counted per roster rather than silent.
Verified: cargo check clean; v1_src_dag_parse 4203 files parse-clean. One
annotation had to move to module-item grain (DESIGN 4c) -- the parse sweep
caught it, cargo did not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…d bounded Operator ruling 2026-08-27: a warning over 100ms, a hard error over 500ms. The hard error is required_floor_claim_cpu_safety_limit_ms, already restored. The warning is required_floor_claim_cost_line_ms, already re-pointed to 100 -- so the pairing was in the tree; what was missing is that the print was unbounded. WHY THIS IS NOT THE WARN TIER DELETED ON 2026-08-20, stated in the code so a reader who recognises the shape does not delete it again. That tier was a second threshold on the SAFETY DEADLINE -- an admission mechanism -- and "over a threshold, reported, allowed to finish" is the widen DESIGN section 5 forbids of a failure arm. The cost line is not a failure arm: it judges only completed claims, nothing reads it to fail a run, and a row it names has already been admitted and has already answered. Warning and hard error are two mechanisms here, not two tiers of one. RANKED AND BOUNDED. At a 100ms line the population is ~835 rows on the measured corpus, and this file already carries the receipt for what that does to a log: the prior 5000/10000 pair "fired on the MEDIAN witness (several hundred [floor-witness-slow] lines)". So the print is the 25 most expensive, ranked on the declared cost basis, which is the actionable head of a distribution whose median is ~1ms. The cap is not silent (DESIGN section 5): the dropped count is printed and the complete population is in the per-claim cost TSV this run uploads. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two reviewers flagged this independently and I initially assumed it was a false positive, because the neighbouring strings in the same change use `\` line continuations correctly. It was real: this one was written without them, cargo fmt collapsed it to a single physical line, and the indentation survived as literal padding -- "so" followed by eighteen spaces followed by "nothing". Cosmetic, but it is the text of a BLOCKING refusal, which is the one diagnostic a person reads at the moment the run stops. Now uses `\` continuations like the other two strings this change added, both of which were checked and were fine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
One conflict, both-added at the same point in run_required_floor: main landed a BarrenTestSidecar refusal, this branch landed the cost-debt roster decode. Both are kept, main's refusal first so the line stops before any roster work. One correction to main's new comment rather than a verbatim keep: it asserts `offered == routed + declined_long + declined_live` stays exact. This branch adds a fourth decline, so that partition is now four-term and the sentence would have shipped stale on arrival. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ame the host evaluates it in CI refused: floor refused: floor_cost_debt_roster: no declaration named 'v2.workflow.floor_cost_debt.floor_cost_debt_roster' in this execution's loaded index The host evaluates each roster by qualified name in required_floor's frame, and that frame's scope is this module's closure, so a roster with no import edge is not in the world the frame was built from. THIS IS THE FOURTH TIME. required_floor.dag already carries three paragraphs about it, ending: "every new roster the host evaluates in this frame must be remembered here by whoever adds it, and the failure surfaces only from a full CI run." That prediction was exact, including the cost -- a ~30 minute fold, on a change whose entire subject is the cost of folds. Four occurrences is a defect in the mechanism, not four careless authors, and the note now says why the prose cannot hold it: a reader adding a roster is thinking about the roster's CONTENT, while this edge is a fact about the FRAME the host will evaluate it in. Different grains. The structural repair the file already names -- the host deriving reachability from the qualified names it calls -- is what deletes this list and these paragraphs together; this change adds the fourth data point for it rather than attempting it here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
snappy-dove-250 asked whether the figure this roster's universe was discovered by is a claim's marginal cost or its charged cost. It was charged, and the answer changes 37% of the population. `v1_compiler.cli_run` `run_claim_measured` began SUBTRACTING shared-artifact fill from a claim's charged CPU at gunbc#9477, which landed 18:49. This roster was measured from run 33109071348 at aea5e0d, 15:34 -- three hours earlier. So every figure behind the first cut was a CHARGED figure, in which whichever claim touched a shared artifact first was billed the whole fill. MEASURED, not estimated: of the 320 identities the first roster held, 119 measure at or under 500ms once fill is attributed to the artifact instead. The extremes are the tell -- test.claim.alias_identity_across_unwrap_witness a_second_alias_still_emits_its_own_name_and_not_the_first was the SECOND most expensive row in the corpus at 4250ms charged, and its marginal cost is 0ms. It never cost anything. That is the failure this change exists to prevent, committed by the change itself: freezing a working witness at identity grain under a shrink-only contract, on a number that was real and measured the wrong subject. It would have looked correct from the inside forever. The universe is now discovered from main run 33131296988 (b6003a4), the first completed floor measurement after #9477: 203 identities. Counts corrected with it -- expected-red overlap 7 -> 6 (521-3865ms marginal), the 100ms warning population ~835 -> ~924, and the withheld-row count in the summary comment. WHAT SURVIVES THE CORRECTION, checked rather than assumed: test.claim.live_deploy.emit is still the most expensive module in the corpus at 85.5s marginal across 53 rows -- 10.7% of a 13.3-minute fold -- so the "one emission recomputed 53 times" diagnosis was robust to the basis change. And the row currently refusing main (callable_candidate_ambiguity_witness.neither_green_source_refuses_and_neither_mis_resolves) is in the new roster by name. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…s retry list snappy-dove-250 and sleek-cat-45 established that the fill subtraction covers exactly ONE shared artifact. Verified here by code read: record_shared_artifact_fill_cpu has a single call site, inside compile_dag_rust_emit_check, and the memoized sibling compile_dag_diagnostic_census (#9428) has no bracket -- so a census miss accumulates nothing and run_claim_measured subtracts zero for it. So the marginal rebuild fixed one artifact's attribution, not shared-build attribution in general. Sixteen of the 203 rows sit in a census-calling module and may be charged for work they do not own. They are NAMED rather than counted, because of the property that makes this roster's shape risky: a row frozen for cost that belongs to a shared build cannot take the roster's exit, since the exit is "make it cheap" and the cost is not its own to reduce. It would sit here looking exactly like debt, forever, and nothing would prompt a retry. A named list with a dated trigger -- when #9560 lands the census bracket, re-measure these sixteen -- is the difference between a declared impurity and a silent one. HOW TO READ SIXTEEN, stated in the carrier so it is not mistaken for a defect count: it is an UPPER bound on census-caused miswarding, since only the claim arriving first at a source absorbs the fill. It is NOT a bound on the general class -- both_closure_edge_index is the obvious next candidate and its treatment is UNVERIFIED, asserted in neither direction, per the finder's own caveat which I am not going to launder into a claim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ver-cautious caveat The previous clause named it "the obvious next candidate" for unbracketed shared-build miswarding and left it UNVERIFIED. That was over-cautious rather than wrong, and over-caution here has a cost: it sends the next reader to measure something already correct. Confirmed by code read in this carrier rather than relayed: run_required_floor calls warm_bare_reference_edge_index TWICE during strict-preparation -- over the source roots and over witness_layer_roots() -- reporting cost as [floor-phase] phase=shared-index-warm. Both index identities the fold can reach are built and billed before any claim window opens, so the artifact needs no bracket and its ~28s reaches no row on this roster. Runtime confirmation on run 33135617689 is sleek-cat-45's and is attributed as theirs; the warm sites are this carrier's own reading. Replaced with the well-posed successor, which is sleek-cat-45's framing and is a construction question rather than a roster one: an artifact is either PREPARATION-FORCEABLE (warm it, bill preparation) or CLAIM-FORCED-ONLY (net the fill, report the split). The census memo was in NEITHER arm, and that "neither" is a writable state is the actual defect -- #9560 closes one instance, the next memoization reintroduces it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… it, and complete the census FIRST EXECUTION OF THIS MECHANISM (run 33136345225) -- the fold reached my code for the first time in seven attempts and the two predicted lines landed exactly: "roster withholds 203" and "floor_expected_red: 6 suppressed". Partitions all exact (planned=executed=terminal=11794), failed=0, stale_quarantine=0, stale_route_gap=0, stale_cost_debt=0. Thirty rows failed, and they are TWO populations needing opposite fixes. SIXTEEN FAILED ON WALL WITH CPU INSIDE THE CEILING, and that is my defect. run_claim_measured subtracts shared-artifact fill from CPU and does NOT subtract it from WALL, so a first-touch payer reads ~0ms CPU and carries the whole shared build on the wall clock. Specimen, same row and same run: alias_identity_across_unwrap_witness.a_second_alias_still_emits_its_own_name_and_not_the_first reports marginal_cpu_ms=0 fill_cpu_ms=3772 with wall_ms=3782. The CPU clock exonerates it; a 2000ms wall clock condemns it. For the same work. The 2000ms figure was derived by the right method from the wrong population: it was measured BEFORE the roster was rebased onto marginal cost, when a fill payer carried a large CPU figure and was therefore excluded from the "inside the CPU budget" population the derivation reads. The rebase moved those rows into it and I did not re-derive. Same class as the charged-basis roster, one clock over. Re-derived on the corrected population: max wall among rows at or under the 500ms CPU ceiling is 3859ms (33131296988) and 3782ms (33136345225), so 8000ms clears the worst legitimate payer by ~2x while still catching the 504-SECOND stuck-claim specimen this clock exists for. Its next-rung trigger is netting fill out of wall as it already is out of CPU, at which point the figure re-derives downward against a population that no longer contains these rows. FOURTEEN FAILED ON CPU and are added: seven INTERRUPTED at 501-508ms having never reached a verdict, seven completed over. 203 -> 217. That is the initial census completing rather than the roster growing: a row cannot be discovered as over-ceiling by a measurement taken under a ceiling ten times looser, so the population was only fully knowable once the ceiling it is defined against was the one actually running. From here the direction is shrink-only in earnest. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…vation filtered by the quantity it derives cannot see its own worst case Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…the only detector over the region it is blind in Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…sed onto DeclinedFixtureMember
…s row moves its fill to the next claim instead of removing it
…s carrier (review 57129)
…ouple it so the CPU arm is provably the sole cause (review 57138)
…ling cannot mask them 220 expensive passes (verdict reached, outcome pass, cpu 511..3757ms) plus 46 rows too expensive to reach a verdict at all (44 budget-interrupted on cpu, 2 over-budget on wall at ~19s). Read from main run 33141550579's per-claim cost receipt and from warm-tern-34's identity-grain list, never from this branch: measuring cost under the tightened ceiling perturbs the quantity, and a first attempt that did so clustered every interrupted row at 501..505ms and would have laundered six live main failures as cost debt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ost decline is an identity fact, not a module fact The modeled required_floor_site_disposition took only module_path, so it could never produce DeclinedCostDebt. The fold declined 266 identities by name while gunbc.discovery_census called every one of them Planned, and two Rust comments cited that function for a precedence it did not carry. Worse, a witness in this branch ASSERTED the divergence as a contract (w_site_disposition_never_answers_cost_debt). It is inverted rather than deleted: three rows now check the arm is produced, that an unrostered sibling in the same module stays Planned, and that a home decline outranks cost debt. The mixed_sites fixture gains a real roster member, without which the partition assertion passed at 0 == 0. Also: the floor_cost_debt header said CURRENTLY CARRYING NO IDENTITIES while the population block below it said 266; and the change had no SeedGrowthJustification row, now gunbc.floor_cost_debt_seed_growth, recording both the item delta (+1) and the line delta (+252/-12). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The note explaining the new roster-member site sat inside mixed_sites()'s body, which the parse sweep refuses at four located diagnostics -- one per line. Hoisted above the declaration, and the neighbouring note corrected from three disposition arms to four. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…s, and the non-termination argument was false calm-ram-380 predicted, from main's fill attribution joined against this roster, that merging as-is would relocate a ~26s reference_edges bill from four withheld payers onto the two rest_path_reaches_no_cli members the roster did not hold. Confirmed at identity grain on the branch run: both breached (59817ms completed-over-budget, and an interrupt at 27939ms against 500ms). Both are now enrolled, closing the module 8/8. The remedy they proposed -- preparation warms for reference_edges as a prerequisite -- is not needed, and the field that decides it was in the line being quoted. consumer_modules is 1 on every claim-paid reference_edges line in both runs, so the bill cannot leave the module and enrolment terminates by exhaustion. The broad keys are already warmed: module_path_index fills 70826ms across 454 claims / 109 modules as paid_by=<outside-fold>. Warming is done exactly where breadth made a first-toucher unaffordable; what remains claim-paid is narrow. This refutes this file's own argument that enrolment is STRUCTURALLY non-terminating. Corrected in place, bounded per key rather than universal, with an explicit note that a broad claim-paid key would behave the old way and would need the warm. Also records how the false universal survived two supports that looked independent: a general claim, and a relocation receipt equally consistent with the claim being false. A receipt that cannot discriminate the general case from the bounded one corroborates nothing about scope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…9599 deletes floor_cost_debt.dag quoted the old INTERRUPTED-BEFORE-VERDICT rendering verbatim -- 'at least 5002ms' -- in two places, as the receipt for why an interrupt point is not a cost. gunbc#9599 gives the bound its own named field (interrupt_point=) and renders the cost field as UNMEASURED, so both quotes would name a string that no longer exists. Repaired so the paragraph survives that merge in either order: the mechanism is stated, the new field name is referenced, and the superseded wording is not quoted. Quoting it would have been a citation rotting the day it was written. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ehind it review 57254 found claim_executor.rs stating 217 rows where the carrier header says 268. The fix is not to re-transcribe. The roster is a function, its size is a property of that function, and a numeral in prose is a second representation that rots on the next enrolment -- so the numeral is dropped and the authority named. Sweeping the class found five more, all in the carrier, all left behind when the header moved to 268. They split two ways and the distinction is the point: HISTORICAL (kept, and now anchored): 'withholding 266 rows left 16 others tripping' is a measurement against the roster AS IT STOOD AT THAT RUN. That figure is correct and must NOT track the current size; updating it would silently restate what was measured. LIVE CLAIMS (de-transcribed): four clauses describing the CURRENT roster, including the 4b(3) bounded-population declaration. A roster function is bounded by being finite and enumerable; a transcribed size is not what makes it so. 268 now appears only in the two header statements the file designates as where the count lives. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tnesses died on it
The disposition added for review 57235 matched `True {} =>` / `False {} =>`
against v2.std.logic's `type Bool = True | False`. Nullary variants are
matched bare; a record pattern against a fieldless variant matches no
scrutinee, so every call fell through at runtime.
It parses. It typechecks. It dies at execution with
cause=pattern-match-failure, which is why three parse sweeps and a clean
build lane all passed over it. Found by reading the cancelled floor job's
log, not by any check.
Blast radius was wider than the edit: 11 of 19 test fns in
discovery_census_witness_test.dag errored, including several that never
call the disposition -- they went down through the shared census fold. So
'witnesses unrelated to my change are failing' was not evidence the cause
lay elsewhere.
grep -rn 'True {}' --include=*.dag over 4243 files returns exactly one
hit: this one. Zero precedent in the corpus was the tell.
Also in this batch, closing review 57258's Population B finding: the
roster is now floor_cost_debt_proven_roster() (221, reached a verdict and
passed, marginal CPU over the ceiling) and floor_cost_debt_censored_roster()
(47, preempted before a verdict, own cost UNMEASURED), unioned. The header
had asserted the proven case over the whole roster -- written when the
carrier held only proven rows, never re-read when the censored ones were
enrolled, and contradicted by the population block below it. Withheld
population verified unchanged at 268 unique identities.
No second decline arm is minted: a disposition names an admission outcome
and the answer is the same for both classes. Evidence strength is a
different axis, and a second arm would make the host re-decide what the
roster already answers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…oven by a discriminating control 873a618 changed True {} to True and fixed NOTHING -- the braces were never the defect. still-cat-738 measured through the real binary that a record pattern against a genuine nullary variant (A {} over type T = A | B) matches fine, and that True/False over the corpus Bool fails in BOTH spellings. The mechanism: std.types declares type Bool = True | False but Bool is realized NATIVELY as a machine scalar, and v1_interpreter match_pattern's VariantPattern arm handles Variant/Record/List/Str/Int/Null with no arm for Value::Bool, so those patterns fall through to None. v2.std.algebra any matches its own result as lowercase true/false, and every corpus consumer branches with if. CONFIRMED BY EXECUTION, not inferred. Two runs of the same invocation through gunbc run: match True/False -> cause: PatternMatchFailure { value: "true" } if/else -> evaluates, refused only at the ProcessExit boundary The control establishes that evaluation happens and the ProcessExit refusal is post-evaluation, so the clean arm is evidence rather than an absence of evidence. value: "true" is the native bool in plain sight. I had proposed a parser wall refusing nullary record patterns. It would have had ZERO true positives, made working code unwritable, and -- worst -- refused this text, sent me to the bare spelling, and produced the same runtime failure with a wall standing as evidence the class was handled. still-cat measured before building, which is the only reason it did not land. Also closes review 57268: witness_floor_workflow.dag transcribed the wall limit as (2000) when it is set elsewhere in this same diff -- a fresh transcription rot inside the diff that reworks a fixture to prevent exactly that. Both parenthesised values are dropped and the constants named. Two more of the class fell out: the preemption fixture's receipt carried the live figure in present tense while recording that it had already rotted twice, and my own first repair re-transcribed all three values while explaining why not to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rom a log The floor completed (run 33172726547): withheld_cost_debt=268, stale_cost_debt=0, planned=executed=12684, interrupted_before_verdict=11, completed_over_cost_requirement=3. The mechanism works; the conjuncts did not empty. One of the 11 is explained outright. dropping_the_definition_edge_roster_ surfaces_more recorded 'cost at least 28769ms' and paid cache=reference_edges fill_ms=25995 -- ~90% of it a bill four withheld siblings used to pay. It did not become expensive; it inherited. I had declared this module closed at 8 members. It has TWELVE. The count came from identities two floor logs happened to print, and a log names the claims that RAN AND REPORTED, never a module's membership; the authority is grep -c 'test fn' on the module source. The termination argument was sound and its INPUT was wrong. All four remaining members are now enrolled, so the module is closed at 12/12 and the roster is 272. Because consumer_modules=1 on that key, with every member withheld no claim reaches the artifact at all -- the fill STOPS HAPPENING rather than relocating to a thirteenth. That is what exhaustion buys. Recorded: why three independent tests looked for this fill and none could see it. Its disposition is EXCLUSIVE and disposition is computed as consumer_modules > 1, so the run's shared_fill_ms=727 -- a real figure, correctly summed, verified here at 725 over 4 rows -- bounds CROSS-MODULE relocation only, a population this 25995ms fill is not in. A paid_by- difference test over warmed keys cannot see it either (outside-fold in every run, cannot differ by construction), nor can a census of which REFUSED rows are shared (an inheritor is the sole payer, hence exclusive, and it completes or is interrupted rather than being refused). Three tests agreed while sharing one blind spot. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… dense band The 12/12 closure is confirmed by execution (run 33191118450): reference_edges now carries no claim-paid key at all, only outside-fold warms, so the 25995ms fill STOPPED HAPPENING rather than relocating, and its payer left the interrupted set. Relocation is dissolved. Four rows enrolled, each verified at a ceiling that lets it finish (run 33190645319, same tree, ceiling only): operation_argv 520ms PASS, per_language_ratchet 646ms PASS, inert_carrier 1146ms PASS, scan_denominator 23794ms COMPLETED_OVER_BUDGET. Roster 276. Seven other residual rows were REFUSED enrolment after the same check. Cost makes a row a candidate; outcome makes it eligible. Six of the interrupted are in main's 47 unexpected failures -- inherited defects that a 500ms ceiling makes present as interrupts because they never reach the verdict that would report the failure. Enrolling them would have put broken witnesses into a roster whose proven class asserts the witness works. Both readers had the outcome column and framed the set by expense. Three more were refused and are NOT new failures: two are KNOWN-RED on main and one is NO-ROUTE. The 47 are UNEXPECTED failures, so an enrolled red and a hermetically-refused row are outside that population by construction. Absent from the 47 is not the same as new. Recorded, unresolved: the counters rose 11->12 and 3->5 from rows paying NO fill. Four bootstrap_footprint siblings sit at 492/502/502/506ms against a 500ms line, and an earlier run had two of them at 512/502 -- membership is decided by run-to-run variance. Exact counts: 21 rows at 400ms, 15 at 450ms, 8 at 500ms, 4 at 600ms. Per-row enrolment cannot converge at a threshold inside a cluster, and moving the line is an operator decision this carrier records rather than pre-empts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Closing: this PR carries no new work. #9517 merged as `45fb74b77f1` and took every commit on this branch with it, including the last hour's — the 12/12 module closure and the four verified cost-row enrolments. Main now has the 500ms ceiling and all 276 roster identities; I verified both against `origin/main` directly rather than inferring from the merge. The auto-opener created this from the branch after that merge, so its only content was the already-merged commits plus a merge commit. Worth recording rather than closing silently: at the moment it was opened this PR was not empty — `git diff --stat origin/main HEAD` showed 26 files, +246/-2607, because the branch had fallen behind main. Merging it would have reverted other people's landed work, and nothing about the PR's appearance would have said so. It is empty only after merging main in, which I have now done and pushed. — sent from witty-wren-148 |
Contributor
Author
|
CORRECTION — the revert hazard I described in my earlier comment on this PR was WRONG, and I am retracting the mechanism rather than softening it. WHAT I CLAIMED: WHAT IS ACTUALLY TRUE, measured with the command that decides the question: git merge-tree --write-tree origin/main So merging would have CONFLICTED (rc=1), and the resolved merge result differs from main by SIXTEEN ADDED LINES in one file. Not 2,607 deletions. Not a revert of anything. WHY THE BIG NUMBER IS NOT A REVERT. The confirming detail is that the number MOVES ON ITS OWN. I published -2607; re-measuring the same commit today gives -28055. Nothing about this branch changed between those two readings — main did. A figure that grows while its subject is frozen is measuring the distance to main, not the content of the PR. THE GENERAL RULE, and it is one command: The hygiene advice in my original comment stands unchanged — merging main in and re-checking is still the right move, and this PR is genuinely empty now. What was wrong was the stated consequence of NOT doing it. Found by still-cat-738, who measured the merge rather than inferring it, on their own auto-opened PR after I sent them the same false alarm. |
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Auto-opened by session-dashboard for session
witty-wren-148.Pushing to
session/witty-wren-148advances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan