Tombstone gate breach at production width: classified — NOT a regression; prune can't keep up; measuring stick discredited [SPEC-355] - #132
Merged
Conversation
…zed runner Freezes the classification contract BEFORE any measurement run exists, so the rule that decides "regression" vs "width-scaled prune math" cannot be chosen after seeing the numbers. git can be asked to prove the ordering: this commit precedes every spec355-*.soak.json. spec355-manifest.md (pre-registration, sections 0-9): - the settled SPEC-349c2 inputs, carried as inputs and not re-derived - the confound ledger, incl. the root UNRECOVERABLE one: SPEC-345's positive-control flag set is not recorded anywhere, so its matrix is reconstructed from Config::default() at 68d0d25 and seven knobs differ under that assumption (crash_interval 120s vs none and churn 16 vs 6 are the load-bearing two). Cell B therefore reproduces the control's DIRECTION and bound-compliance, never its number. - the cell-A re-attestation, executed: d6922f0..bd41ccf over '*.rs' returns exactly the four already-adjudicated paths, so the "any fifth path re-runs cell A" trigger does not fire - the 2x2 identification matrix (width x binary) with its five-row decision table plus the conditional E-row, because a single-axis width-100 predicate cannot separate a width-DEPENDENT regression from width-scaled prune math - the provenance pre-flight as IDENTITY checks: the census witness (orDeltaFrames == 0; nonzero => cell INVALID, never a table row) and fail-closed binary resolution - the verified serialized-key schema table, with the per-struct derive cited file:line (MemoryReport is snake_case; the confirm-apply counters are nested in soak.json and FLAT in progress.jsonl) - R3.2's plateau and width-scaling tests, and R4.1's three candidate shapes, frozen before the data exists spec355-width.sh: the width-parameterized runner. Every rate/shape literal is spec349c2-plateau.sh's verbatim; only R0.1's permitted knobs vary, each echoed into the run's committed matrix.txt. It carries the fail-closed SOAK_SERVER_BINARY guard on the provenance path (hard exit 3 before the clock starts) because the Rust resolver fails OPEN and would silently make cell C a second cell A. Sited in the runner so closing that hole costs no .rs file and puts no .rs edit into a measurement lineage. Wave-1 gate, all four assertions PASS, and both paths smoked to a scratch dir: the HEAD path proves the width axis reaches the child (epochWidth: 100), and the provenance path proves the half-swap actually swaps (orDeltaFrames: 0, orSnapshotFrames: 2367) before 1800s is spent on it. Neither smoke is evidence and neither is cited in any determination.
…lock starts All four paths returned by d6922f0..bd41ccf over '*.rs' adjudicate emission-only, so cell A stands and is NOT re-run at 3600s. Clause (2)'s enumeration is genuinely two-sided on rows 1 and 2 -- it lists "the CSV/report population of a gated field" as a consuming read and "add a field to a report struct" as an emitting one, and these hunks sit between the two. The ruling is recorded rather than glossed: the governing text is the clause's closing sentence, which names the hazard (a hunk that changes what a gate or a sampler READS), and it is then verified mechanically rather than argued -- monitor.rs is absent from the interval entirely, no main.rs hunk touches the scrape/sampler/assess call site, and the server-side prune path (tombstone_frontier_impl.rs, crdt.rs) is untouched. So cell A's slope and cells B/C's slopes are computed by the same arithmetic over the same sampler; only the serialization of an already-computed verdict changed. That is the property the re-attestation exists to establish.
The width-100 replay. Result, stated plainly: SPEC-345's width-100 PASS does
NOT still hold at HEAD on this matrix. The gate FAILS.
harness in-process 1524.96 B/h (360 samples, last-half window 896s)
tombstones.passed = false
CSV fit, last_half 7938.86 B/h (15 points, span 840s, se 14268, r2 0.023)
Both instruments exceed the 512 B/h bound, and both land in the SAME
decision-table band, so the instrument difference does not move a row. They are
also statistically compatible rather than contradictory: the CSV's standard
error is 9.4x its own point estimate and comfortably contains 1525 B/h. The
difference is statistical power (180 vs 15 last-half points), not disagreement,
and it is recorded rather than averaged away.
confirmApply confirms=865 lastConfirmedEpoch=600 confirmErrors=25 (2.9%), so
the low-water mark advanced and the prune was licensed to run throughout --
this is not the stalled-cursor cause a climbing gauge can otherwise have.
matrix.txt records dirty-tree = yes. That flag is self-inflicted by the run's
own untracked artifacts (it tees its matrix.txt into the tracked evidence dir
before the echo completes); `git diff --name-only HEAD` at the recorded SHA
7b2a3da is EMPTY, so no tracked source file was modified and the PRE-CHANGE
build lineage is intact.
The regression discriminator, and it is VALID: the identity witness fired on a real pre-family run -- orDeltaFrames = 0 with orSnapshotFrames = 41509. The pin (181723d) precedes the OR-delta emitter (7142d4d), so a nonzero count would have meant the swap was botched and the cell INVALID; it is zero, read by the HEAD decoder over pre-family-written frames. harness in-process 175367.59 B/h tombstones.passed = false CSV fit, last_half 176954.34 B/h (se 25261, r2 0.79) The breach REPRODUCES on the pre-family binary: both readings sit far above the "reproduces" threshold of 0.1 x S1000 = 24814.89 B/h, at the same order as cell A's 248148.9 B/h. Two corroborations worth keeping: - The instruments agree here to within 0.9%, against a 5.2x gap in cell B. That is the honest explanation of cell B's discrepancy: at r2 0.79 the two converge, at r2 0.023 the low-power 15-point CSV fit scatters around a slope it cannot resolve. It is a power difference, as recorded, not two instruments disagreeing about the gauge. - lastConfirmedEpoch = 59 here at width 1000 vs 600 in cell B at width 100, over the identical duration and matrix -- a ~10x ratio matching the width ratio exactly. The epoch clock scales with width as assumed, measured rather than asserted. Only the SERVER is pre-family; the harness, gauge scrape, CSV column, fit and assessment are all at HEAD. This is a deliberate half-swap, not a run at the old commit.
… 5, INDETERMINATE The pre-registered table returns INDETERMINATE, and that is recorded as the determination rather than nudged toward a clean fork. S100 (cell B) = 7938.86 B/h -> 512 < S100 < 24814.89 = ambiguous middle Spre (cell C) = 176954.34 B/h -> >= 24814.89 = reproduces Row 5's first disjunct is satisfied. Rows 1/2 need S100 <= 512 (the gate fails); rows 3/4 need S100 >= 0.1 x S1000 (S100 is 3.1x below it). So S100 ALONE forces row 5 and no value of Spre could have changed it -- stated explicitly rather than presenting five cells as if each were load-bearing for the call. Cell C was still run because R1.2 makes it mandatory and it seeds the tie-break and any later bisect. Recorded separately from the determination, because they are measurements and not a branch call: - SPEC-345's width-100 PASS does NOT still hold at HEAD on this matrix (-1707.5 B/h then, +1525 B/h now). This is NOT yet evidence of a regression: SPEC-345's control ran a matrix whose flag set is recorded nowhere, and seven knobs differ under the defaults reconstruction. - The width-1000 breach is NOT new since the pin -- cell C reproduces it at 181723d at the same order as cell A (ratio 0.71). Scoped to 2026-07-27. - Width matters by 22x-115x, far beyond the bound's slack. Cell E is NOT-APPLICABLE with its ruling-out measurement: its firing condition is conjunctive on row 1 having been taken, and it was not. Routing per R0.4: cell D next. Section 5 motivates it for an ambiguous cell C, but it is the right probe here for a sharper reason -- cell B's width-100 breach is what forced row 5, and cell D is the only run in the design that says whether that breach is NEW since the pin, holding width fixed and varying only the server, with cell B's matrix confound held fixed by construction.
…s (R0.4 step 1)
Identity witness PASSED: orDeltaFrames = 0, orSnapshotFrames = 2650.
harness in-process -791.28 B/h tombstones.passed = TRUE, harness exit 0
CSV fit, last_half -16797.00 B/h (se 14581, r2 0.093)
The gate PASSES on the pre-family binary at width 100, where it FAILED on HEAD
at the identical width, matrix, duration and instrument (cell B, +1524.96 B/h).
It also reproduces the SIGN of SPEC-345's -1707.5 B/h control, which is what
section 3.1 said cell B should have reproduced and did not.
That completes the 2x2:
width 100 width 1000
HEAD +1525 FAIL +248149 FAIL (cell A)
pre-family -791 PASS +175368 FAIL (cell C)
Read across: the width-1000 breach is present in BOTH binaries (not new since
the pin), while the width-100 breach appears ONLY on HEAD.
Deliberately NOT concluding "regression" on this pair, for a reason the numbers
themselves supply: peakBytes is 28138 (B) vs 27448 (D), 2.5% apart. The two
binaries reach essentially the SAME equilibrium residency at width 100; what
differs is the last-half OLS trend on a bounded, oscillating series, which is
exactly the quantity cell B's r2 of 0.023 says is poorly resolved. A window
-placement artifact and a real regression are not yet distinguishable, and one
run per cell cannot separate them.
Repeatability at width 100 is therefore the next thing the evidence needs, and
R0.4 step 2's sweep supplies it.
…judication
Cross-vendor gate at a decision point, run adversarially: glm-5.2 was asked to
REFUTE the regression reading, not confirm it. 13 findings, each marked applied,
partially applied, or refuted-with-reason. Every quantitative claim it made was
recomputed from this spec's committed artifacts before being accepted; all five
check out.
It caught a real error of mine, and the correction is recorded rather than
quietly dropped:
A. The cell D commit argues from peakBytes near-identity (28138 vs 27448) that
both binaries reach the same equilibrium. That argument does not survive: a
leak of exactly the reported magnitude (1524.96 B/h over 0.5h = 762 B)
PREDICTS a peak gap of that size (690 B observed), so peakBytes is not
evidence for the artifact reading. And it is the statistic that flatters
that reading while lastBytes -- 5148 B apart, 27% of the level -- points the
other way. That is selection bias in the presentation. WITHDRAWN; both
statistics now travel together.
Sharper than my own read, and adopted:
B/E5. The width-100 slopes are 0.56 and -1.15 SE from zero and 1.21 SE from
EACH OTHER. My "power, not disagreement" note was right but stopped short:
the consequence is that S100's band assignment rests on a number
indistinguishable from zero. This does NOT overturn row 5 -- row 5 is
exactly where an underdetermined S100 belongs, so the pre-registered rule
behaved correctly -- but it forbids reading cell B as a positive finding.
E2. SPEC-345's -1707.5 B/h width-100 PASS may ITSELF have been noise-driven,
since 512 B/h sits below the noise floor just measured. That is a stronger
claim than this spec's premise, which assumed the width-100 PASS was solid
and only the width-1000 extrapolation unverified. sweep100 is its first test.
E1. The width-1000 row is the dominant fact: both binaries breach with a real,
well-resolved trend (r2 0.79), which neither fork's framing foregrounded.
D. The last-half-slope estimator is arguably wrong for a bounded oscillating
series regardless of the fork -- recorded as an R4.1 input for shape (iii),
explicitly NOT as licence to choose a shape before section 7's data exists.
Refuted: E7 ("cell A is 3600s vs 1800s -- protocol violation?") is row 1 of the
confound ledger, written before any measurement, and is the stated reason cell C
is read as a binary rather than compared numerically to A.
Scope correction on C: the model prices replication at k=784 runs to resolve the
fork by averaging, which is obviously not on the table and was never the plan.
sweep100 answers a different question -- is the gate's width-100 PASS/FAIL
verdict stable across two runs of an identical config -- which is precisely what
its own finding E2 needs.
…tles the fork
Same binary, same width, same matrix, same duration, same PRE-CHANGE lineage as
cell B. The only difference between these two runs is the run itself.
cell B harness +1524.96 B/h CSV +7938.86 B/h gate FAIL
sweep100 harness +7048.07 B/h CSV -7330.71 B/h gate FAIL
The harness slope moves 4.6x between identical configurations, and the CSV
estimator FLIPS SIGN. That is the noise floor measured directly rather than
estimated, and it is what the /xask finding E2 predicted.
Consequences, all measured rather than argued:
1. The width-100 regression reading is NOT supported. HEAD's two runs are
{+1525.0, +7048.1}, giving sd(n=2) = 3905; the pre-family cell D is -791.3.
Difference of means 5077.8 with SE 4783.2 -> t = 1.06. Within-group variance
EXCEEDS the between-binary difference, which is the signature of an effect
that is not resolvable at this duration.
2. The gate's width-100 verdict is close to a coin flip. Every width-100 slope
ever measured, across both binaries and both specs, spans 8756 B/h:
SPEC-345 -1707.5 | cellD -791.3 | cellB +1525.0 | sweep100 +7048.1
against a bound of 512 B/h -- a spread 17x the bound it is being tested
against. So SPEC-345's -1707.5 B/h "positive control" sits comfortably inside
the noise, and the width-100 PASS it recorded never demonstrated
bound-compliance. That is a stronger statement than this spec's premise,
which assumed the width-100 PASS was solid and only the width-1000
extrapolation was unverified.
3. LEVEL is the stable statistic where slope is not. Across the same two
identical runs: peakBytes 28138 vs 25476 (9.5% apart), lastBytes 24134 vs
20504 (15% apart) -- against a slope that moved 4.6x and a CSV estimator that
changed sign. This is measured support for R4.1 shape (iii), the residency
-ceiling clause, and it is now evidence rather than the /xask's argument.
Note the harness gate returned FAIL on both HEAD runs, so the VERDICT happened
to be stable here even though the statistic behind it was not. A stable verdict
drawn from an unstable statistic is not a working gate; it is a gate that has
not yet been asked the question at a width where it can answer.
…tonic in width harness -7106.77 B/h gate PASSES peak 30096 last 15202 CSV -16330.29 B/h (se 15735, r2 0.077) Width 300 PASSES with a strongly negative slope, while width 100 FAILED on both HEAD runs and width 1000 breaches by two orders of magnitude. The gate's verdict is therefore NOT monotonic in epoch width: FAIL(100), PASS(300), FAIL(1000). No physical model of tombstone residency predicts that ordering. It is what the sweep100 repeat already showed from a different angle -- at these durations the last-half slope is dominated by where the fit window lands relative to the prune oscillation, not by the width. Read together, the two results say the same thing: at 1800s the slope estimator carries no width signal at the low end. The epoch clock, by contrast, scales exactly as assumed. lastConfirmedEpoch over identical durations and matrices: width 100 -> 600, 588 width 300 -> 191 width 1000 -> 59 giving 600/191 = 3.14 and 191/59 = 3.24 against a predicted 3.0 and 3.33. So the epoch machinery is behaving; it is the SLOPE STATISTIC over a 840s window that is not, which is the distinction that matters for choosing a re-derivation shape.
…s refutes the width-100 regression reading outright harness +87413.90 B/h gate FAIL peak 63420 last 62012 epochs 58 last/peak = 0.978: at width 1000 the series is still CLIMBING at run end, so 1800s has not reached equilibrium there. That is not a defect, it is section 7.3(b)'s ramp prediction (ramp duration ~ width) coming true -- at width 100 and 300 the same duration ends mid-oscillation well below peak. Last-half MEAN of the committed tombstone_bytes column, the stable level statistic (computed from the CSVs; the instrument is not forked): width 100 HEAD 20765 / 18961 (two identical runs, 9% apart) width 100 pre-family 20771 width 300 HEAD 20981 width 1000 HEAD 38715 width 1000 pre-family 56898 Two things follow, and neither needed an argument: 1. At width 100 the HEAD mean (19863 over two runs) and the pre-family mean (20771) are 4.6% APART. The two binaries reach the SAME residency. Taken with the t = 1.06 slope result, the width-100 regression reading is refuted on the stable statistic as well as on the noisy one. Note this is the honest version of the peakBytes argument the /xask demolished: same conclusion, but from a last-half mean over 15 samples rather than from a single order statistic. 2. Residency does NOT scale linearly with epoch width. 100 -> 300 is a 3x width change for a 1.06x level change; 100 -> 1000 is 10x for 1.95x. Section 7.3(b)'s prediction of ~10x fails numerically -- but the width-1000 leg is still ramping, so its level is a LOWER BOUND and its equilibrium is not yet measured at all. Consequence for R0.4 step 2, stated rather than glossed: the rule asks whether "the three slopes and equilibria" are consistent with the prediction. This spec has now measured that at 1800s the slopes carry no signal at widths 100/300 and the width-1000 EQUILIBRIUM does not exist yet. Two of the three inputs the rule needs are unavailable at the duration I ran, so the rule has not fired in either direction. R0.4 step 2 permits ">= 1800 s"; the missing input is obtained by running long enough, which is exactly what R3.1's >= 4h width-1000 run is.
…ts correction I proposed that R0.4 step 2's rule "had not fired" because two of its three inputs did not exist at 1800s, and planned to obtain them via the >=4h R3.1 run. Put to glm-5.2 adversarially -- the prompt named my incentive explicitly and asked it to attack the reading -- that argument was substantially rejected, and I am withdrawing it: "You set the duration. You pre-registered it knowing your own prediction said ramp scales 10x with width. If 1800s was too short for width 1000, that is a defect you wrote into the rule, and you do not get to exploit your own defect to avoid a verdict you dislike." It is a floor condition retroactively reread as a quality gate. WITHDRAWN. The gap that IS real is a different one, and stronger: R0.4 step 2 tests HEAD against a model that ALSO fails on the pre-family baseline. Verified from this spec's own artifacts -- width-1000/width-100 level ratio is 1.95x on HEAD and 2.74x on PRE-FAMILY, against a predicted ~10x. The model is wrong universally, not as a HEAD-specific symptom, so "inconsistent with the prediction" cannot discriminate a regression, which is exactly what the rule assumes it does. The rule's dichotomy has no branch for "model wrong, no regression". It also named the number I had been under-weighting: at width 1000 the OLD binary is WORSE than HEAD on both statistics -- level 56898 vs 38715 (47% worse), slope 175367.59 vs 87413.90 (2.01x worse). That points away from regression. Acted on its recommendation, which corrects a real ordering error of mine: the >=4h run refines a model violation already known and does NOT discriminate the branch, while the branch gates everything and R3 is branch-(2)-only. The 4h run was STOPPED ~15 min in and its partial artifacts deleted (no partial series is committed), and the discriminating experiment is run instead: replicate the width-1000 comparison on both binaries for n=2 vs 2. Adds two cells for that, cellC2 and sweep1000b. The edit is provably additive -- git diff shows ZERO removed lines, so no existing cell's literals moved and no committed run's provenance is disturbed. One point where the paired design is stronger than the model credits: a paired comparison does not need either arm at equilibrium, it needs both arms at the SAME point on their ramp, which duration-matching supplies by construction. DEVIATION, recorded rather than silently re-read: the pre-registered rule fired and its literal verdict is (1). I am not following it, on the coverage-gap ground above. Falsification condition fixed BEFORE the runs: if HEAD remains no worse than pre-family across n=2 vs 2, declare (2) because the rule's dichotomy is unsound here; if HEAD is worse, accept (1) and bisect.
…ily, decisively
n=2 vs n=2 at the production epoch width, duration-matched, identical matrix,
identical HEAD instrument. cellC2's identity witness PASSED (orDeltaFrames = 0).
slope B/h level (last-half mean)
HEAD 42684, 87414 (mean 65049) 36624, 38715 (mean 37670)
pre-family 175368, 208555 (mean 191961) 54676, 56898 (mean 55787)
Both statistics separate the binaries with DISJOINT ranges -- no HEAD run
overlaps any pre-family run on either measure:
level pre-family higher by 18118 B (48%), SE 1526 -> t = 11.88
slope pre-family higher by 126912 B/h (2.95x), SE 27848 -> t = 4.56
The falsification condition fixed in e3ce61a BEFORE these runs was: "if HEAD
remains no worse than pre-family across n=2 vs 2, declare (2); if HEAD is worse,
accept (1) and bisect."
HEAD is not worse. It is substantially BETTER on both statistics. The condition
resolves to BRANCH (2) -- no regression -- and it resolves that way on data
collected after the condition was committed, not before.
This also lands in the direction OPPOSITE to a regression: whatever the
SPEC-349 family did to the OR path, it roughly halved resident tombstone bytes
and cut the growth slope threefold at the production width.
Incidental confirmation of the estimator finding, now measured at both widths:
the level statistic's run-to-run spread is 5.4% (HEAD w1000) and 9.0% (HEAD
w100), while the slope moved 2.0x, 4.6x and changed sign across identical
configurations. The 48% between-binary level gap is far outside that noise; the
2.95x slope gap is real but rests on a statistic whose own repeatability is
poor, which is why the level comparison is quoted first.
… REGRESSION Resolved by the falsification condition committed in e3ce61a BEFORE the deciding runs, on data collected after it. At the production width, n=2 vs n=2, disjoint ranges on both statistics: level HEAD 37670 vs pre-family 55787 -> pre-family 48% worse, t = 11.88 slope HEAD 65049 vs pre-family 191961 -> pre-family 2.95x worse, t = 4.56 HEAD is not worse; it is substantially BETTER. The condition resolves to (2). The four legs of the determination: 1. The breach reproduces on the pre-family binary at the production width (175368, 208555 vs cell A's 248149) -- it PRE-DATES the pin. 2. HEAD is better than the pre-family baseline there, decisively. The SPEC-349 OR-delta work moved resident tombstone bytes OPPOSITE to a regression. 3. At width 100 the binaries are indistinguishable (levels 4.6% apart, t=1.06). 4. SPEC-345's second disjunct was an unverified extrapolation, as TODO-630's fork (2) proposed -- and beyond that fork, its FIRST disjunct's width-100 PASS was itself inside the noise (all width-100 slopes ever measured span 8756 B/h against a 512 B/h bound; -1707.5 sits inside that). Two things recorded rather than glossed: - The deviation. R0.4 step 2's literal verdict is (1). I am not following it, and NOT on my first argument ("its inputs were unavailable"), which is withdrawn as rationalization -- ">= 1800 s" is a floor, and rereading it as a quality gate exploits a design defect I wrote myself. The real ground is a coverage gap: the rule tests HEAD against a model that fails on the pre-family baseline too (1.95x vs 2.74x against a predicted 10x), so "inconsistent" diagnoses model-wrong, not regression-landed, and the dichotomy has no branch for that. - The correction. Cell D's commit argued from peakBytes near-identity; that is withdrawn (a leak of the reported size PREDICTS a 762 B gap and 690 B was observed), and the conclusion is now carried by the last-half mean, whose run-to-run spread is 5.4-9.0% against a slope that moved 4.6x and flipped sign. Cell E is PENDING R4.1a, not dismissed. Its conjunct (i) is treated as satisfied in substance -- dismissing the 2026-07-13..2026-07-27 gap because the branch arrived via the tie-break rather than via row 1 would be the exact evasion cell E exists to prevent. Recorded in advance: the width-scaling model fails on BOTH binaries, so R4.1a is likely to FIRE cell E. Branch (1) recorded NOT-APPLICABLE with its ruling-out measurements. No bisect, no prune-path .rs file touched.
…oduction width
14401s at width 1000, 2878 in-process samples, 458 epochs, instrument sound.
lastBytes == peakBytes == 646306: the series ends AT ITS MAXIMUM.
The 8 windowed fits, produced by the pre-registered mechanism (CSV sliced into 8
header-bearing segments by one committed awk one-liner, each fitted with the
UNFORKED spec349c2-fit.awk at window=full; all 8 segments committed):
W1 113657 +- 13941 r2 0.70 W5 118189 +- 9703 r2 0.84
W2 244197 +- 7573 r2 0.97 W6 132689 +- 10152 r2 0.85
W3 151076 +- 9213 r2 0.90 W7 133598 +- 9652 r2 0.87
W4 166532 +- 8971 r2 0.92 W8 155726 +- 12100 r2 0.88
R3.2(a)'s plateau predicate fails on BOTH disjuncts:
(i) no Wi..W8 is within the bound -- the SMALLEST window slope is 113657 B/h,
222x the 512 B/h bound; the largest is 477x;
(ii) there is no monotone decay to an asymptote at or below the bound -- the
series is not monotone (W1<W2, W3<W4, W5<W6<W7<W8) and W8 is +37% ABOVE
W1. Growth is sustained at ~152 KB/h with r2 between 0.70 and 0.97, i.e.
the trend inside every window is real and well resolved, not oscillation.
Total growth 646306 B over 4h = 161576 B/h sustained, which extrapolates to
~11.6 MB over a 72h soak.
CORRECTION to a mid-run observation I reported: from the coarse 1200s samples I
said the growth was decelerating and looked like a ramp approaching an
asymptote. The proper windowed fit refutes that -- the apparent deceleration was
sampling noise, and there is no decay. Branch (2)'s premise ("the 60-min window
measured a ramp") is REFUTED at the production width.
Per R3.2(a) this is a legitimate, reportable outcome and it escalates to R5b,
the branch-(2)-UNBOUNDED disposition -- deliberately NOT to R4, because there is
no bound to derive from a series that does not bound.
…tchet, in this commit
R3.2(a)'s pre-registered plateau predicate fails on BOTH disjuncts over a 4h run
at width 1000 (14401s, 2878 samples, 458 epochs, series ENDS AT ITS MAXIMUM at
646306 B):
(i) no suffix Wi..W8 is within the bound -- smallest window slope 113657 B/h,
222x the 512 B/h bound; largest 477x;
(ii) no monotone decay to an asymptote -- not monotone, and W8 is +37% ABOVE
W1, with r2 0.70-0.97 inside every window, so this is sustained growth
and not oscillation around a level.
R4 is therefore NOT-DERIVABLE: there is no bound to derive from a series that
does not bound. All three candidate shapes are disposed of as PREMATURE rather
than chosen, Assumption 8's prior for shape (ii) is recorded unresolved rather
than quietly carried, and the Rust ceiling consumed by this spec is 0 of 5 --
neither monitor.rs nor main.rs is touched.
The claim is HORIZON-SCOPED, not a refutation. Finite observation cannot prove
unboundedness, and "REFUTED" in a catalog invites a future reader to stop
looking for the real bound. Applied from spec355-xask-unbounded.md finding 1.
That same review produced a FREE check that changed the finding's character. The
gauge decrements on 80 of 239 steps, freeing 299349 B over the run -- the prune
FIRES, and was never unlicensed. What degrades is its RECLAIM FRACTION, with
both width and elapsed time: ~95-98% at widths 100/300, ~80-92% at width 1000
over 1800s, and 33.1% at width 1000 over 4h. "Tombstone bytes are unbounded"
becomes "the prune progressively falls behind" -- a defect with a mechanism and
a testable next step.
R5b disposition, none of it a manifest note:
- TODO-634 spun off (prune fix-or-redesign at width 1000, NOT a bound
re-derivation), owner = the TODO-566 / SPEC-345 tombstone-GC line, pre-soak
blocker; sequencing 630 (resolved) -> 634 -> 586 -> 484; TODO-630 RE-POINTED
at it, not closed out.
- TG-OR-005 added at Status: open (TODO-634), NAKED unconditionally, with both
literals inside the grep -A3 window check-invariants.sh:38 reads (verified by
running that exact extraction, not the checklist's).
- TG-OR-004 NOT flipped -- it is gauge FIDELITY, not BOUNDEDNESS, and this
measurement depends on it holding. The row sites that distinction in its own
body so it survives this spec's archival.
- NAKED_BASELINE 3 -> 4 in THIS commit. check-invariants.sh: 20 entries, 4 NAKED
(baseline 4), exit 0.
Also corrects an interim observation I stated aloud mid-run: from the coarse
1200s samples I said growth was decelerating toward an asymptote. The windowed
fit refutes it -- that was sampling noise.
Records a checklist defect, not a row defect: Validation Checklist item 10's own
awk range is self-terminating (TG-([A-Z]+) matches TG-OR in the start line), so
its greps return 0 on a correct row.
…at it does not Sequencing after this spec: TODO-630 (resolved) -> TODO-634 -> TODO-586 -> TODO-484. Nothing this spec produced unblocks the 72h soak; it converts an unexplained red into a named, owned defect with a mechanism, which is what section 0 said it set out to do. - TODO-630 RESOLVED and RE-POINTED at TODO-634, not closed out. - TODO-484 still blocked, now on TODO-634 -- it would red on the tombstone clause by construction, exactly as before; the difference is the cause is now measured and owned. - TODO-586 re-pointed, and carries a finding of its own: it proposes to add a SECOND hard conjunct beside the slope clause, so it must be designed against the level estimator TODO-634 owes, not tolerance-tuned against a rate detector this spec measured to be unreliable. - SPEC-348's disk gate restated as unaffected -- a one-line restatement from the 349c2 manifest's 7.2, not a re-derivation. No .rs file was touched, no 349c2 artifact altered, and the finding is confined to the gauge-backed clause. Also records the three findings this spec produced that were NOT in its brief: the gate estimator's unreliability (and its consequence -- SPEC-345's FIRST disjunct was as unverified as its second), the prune reclaim-fraction mechanism, and a self-terminating awk range in this spec's own Validation Checklist item 10. The 90s smoke and this spec's own two instrument smokes all carry the WEAK label and are used in no determination.
…nadmissible [n/a] Review v1 M1: cell E's NOT-APPLICABLE rested on a third ground AC3c does not enumerate (procedural: 'R4.1a is a step inside R4'), and the interval it existed to own was left with no tracker. - 10.5.4: disposition restated as NOT RUN - DEFERRED WITH A NAMED OWNER (TODO-634). Both of AC3c(a)'s admissible measurements are shown unavailable rather than stretched: row-not-1 was refused on the merits in 10.4.5, and R4.1a's magnitude pair is unconstructable once R4 is not-derivable. - The 'improved upon twice over' argument is WITHDRAWN in place - it is a non-sequitur for localization (HEAD < 181723d says nothing about 181723d vs 68d0d25). - 10.4.5's forward pointer now says the trigger is honoured, not un-fired. The tracker side (TODO-634 gains the interval as diagnostic-on-demand with 4.6's protocol and its own acceptance checkbox) and the spec side (AC3c checkbox, Deviations 5/6) land in .specflow/, which is gitignored by project policy.
…tered statistic Review v1 M2: 7.3(b) (frozen at 7b8ba1d) pre-registers TWO observations - peakBytes/lastBytes ratio AND ramp duration. 10.5.3 recorded one ratio pair on a SUBSTITUTED statistic (last-half level mean) and no ramp observation at all, so the pre-registered test read as silently re-specified. - Limb (i) now recorded on the pre-registered statistic, like-for-like at 1800 s: peak 2.18x HEAD / 3.36x pre-family, last 2.25x / 3.72x, all against ~10x. The substituted level statistic stays, reported BESIDE it (1.90x / 2.69x), declared as a presentation change for the deciding comparison rather than a re-specification. Reporting peakBytes beside lastBytes is what 10.4.0's own finding requires. - Limb (ii) recorded as RIGHT-CENSORED: the width-1000 ramp never terminated (no window plateaued over 4 h; peakBytes == lastBytes == 646,306), so no ratio is formable. Censoring bound >14,400 s vs a predicted 600-1,800 s already excludes the prediction - this limb fails in the OPPOSITE direction from (i). - Carries the caveat that follows: the 1800 s ratios compare a levelled w100 run against an unconverged w1000 one, so they are lower bounds and 'fails low' is NOT sub-linear scaling. The 4 h figures (24.1x/29.0x, duration-mismatched) are stated rather than hidden, and 10.4.3's discriminating-power argument is shown untouched (both binaries equally unconverged). No conclusion moves: the prediction fails on both limbs on both binaries.
Review v1 minor 3: the 1.95x / 2.74x width ratios paired a single width-1000 run against an n=2 width-100 mean, and were never refreshed after sweep1000b and cellC2 landed. Recomputed consistently: 1.90x / 2.69x, with the arithmetic now shown in the table rather than recoverable only from the xask transcript. The committed transcript is deliberately NOT retro-edited; a pairing note in 10.4.3 records that it carries the superseded figures and why. No verdict moves - both are far below the predicted ~10x. Review v1 minor 4: '74 -> 161 KB/h' mixed KiB (73.6) with decimal KB (161.6). Now 75 -> 161 with the convention stated and both quotients shown (10.5.3, in the M2 commit). Ratio 2.14 either way.
…record Review v1 minor 5: '(the falsification condition was) committed before the deciding runs' is falsifiable by an ls -T - sweep1000b's matrix.txt, written at run start, is 17:04:49 and e3ce61a is 17:05:31, so that run was 46 s in flight. Restated to the property that actually holds and is checkable: committed before either deciding RESULT existed (sweep1000b 17:34:49, cellC2 18:06:03). Review v1 minor 7: AC14's 'repo gate green (section below)' pointed at nothing. New 11.2a records the three commands and their exit codes as actually run, and states what the gate does NOT assert - the AC's '.rs change' antecedent never fired, so a green gate on a branch with no Rust is evidence of nothing but that nothing was broken.
…630 wording
Review v1 minor 9: Validation Checklist item 10's awk range was left in the spec
in its known-broken form - self-terminating, because TG-([A-Z]+) matches TG-OR in
the range's own start line, so it returns 1 line and every downstream grep
silently reports 0. Fixed in place to
awk '/^### TG-OR-005/{f=1;print;next} f&&/^### TG-[A-Z]+-[0-9]+/{exit} f'
which consumes the start line before testing and requires the full heading shape.
Executed against the committed INVARIANTS.md: 47-line row, grep -c NAKED = 1, the
4-line window matches (TODO|SPEC)-[0-9]+, Status open (TODO-634). The self-report
in 10.5.5 / 11.4 is kept and now records the correction. Item 10's stale
'open (TODO-630)' literal corrected to TODO-634 (Deviation 6).
Review v1 minor 8: TODO-634.md's banner said 'TODO-630 (CLOSED by SPEC-355)'
against TODO-630's own frontmatter (status: resolved, re_pointed_to: TODO-634),
11.1 and the Execution Summary, all of which say re-pointed NOT closed out.
Aligned. (That file is under gitignored .specflow/.)
…'s final disposition Surfaced while applying M1: 10.3.2's interim table still recorded cell E as NOT-APPLICABLE on the 'row 1 was not taken' ground that 10.4.5 had already overturned on the merits. Left alone it would contradict 10.5.4's new disposition and hand a future reader the exact dismissal 4.6 exists to prevent. - 10.3.2: the row is marked SUPERSEDED in place, with what overturned it and a forward pointer to 10.5.4. The interim reading is preserved, not rewritten - the staged record is the point. - 11.1: the handoff table gains the interval as its own row, so R6's 'what now unblocks the soak, and what still does not' names it rather than leaving it implicit inside TODO-634's body.
…' unconverged withdrawn Two documentary corrections from Review v2, no measurement and no data file touched. - 10.5.3's censoring caveat claimed both binaries were *equally* unconverged at 1800 s. 10.4.2's own width-1000 slopes say otherwise: pre-family 191,961 vs HEAD 65,049 B/h. The argument only needs 'neither arm has levelled', so the caveat now states the 2.95x asymmetry and notes it runs the conservative way - pre-family sitting higher AND climbing faster can only strengthen 'HEAD is better'. - The spec-side Deviation 1 still quoted the superseded 1.95x / 2.74x pairing that the previous round replaced everywhere it carried an argument. Now 1.90x / 2.69x with a pointer to 10.4.3's consistent n=2 pairings. Gate: cargo fmt --all --check 0; scripts/check-invariants.sh 0 (20 entries, 4 NAKED, baseline 4); pnpm lint 0. git diff --stat main...HEAD -- '*.rs' still empty.
…probed interval absorbed in the catalog row Cross-vendor adversarial review (glm-5.2) against the manifest's reasoning. Three findings confirmed against the committed artifacts and fixed; one rejected on a false premise. - The two-duration rate pair divided the 1800s runs' last-half MEAN (37,670 B) by the 4h run's ENDPOINT (646,306 B). For a still-climbing series the endpoint exceeds the mean, so 'roughly doubled, 75 -> 161 KB/h' was inflated on one side only. Like-for-like on lastBytes at both durations: 100 -> 161 KB/h, ratio 1.61. Restated as ~60%, with the superseded pair named. The determination is unaffected - it rests on the eight windowed fits, not on this two-point comparison. - TG-OR-005 closed its no-regression bullet with a bare 'The behaviour is long-standing.' The manifest scopes that claim to the pin's own date and hands 2026-07-13..27 to TODO-634, but INVARIANTS.md is what survives after the manifest is archived - and there the scoping was gone. The bullet now carries the stop date, the un-probed interval and its owner. - The reclaim-fraction ranges were HEAD-only while reading as binary-agnostic: pre-family sits outside every one of them (86.7% at width 100 vs '95-98%'; 66.4% at width 1000 vs '80-92%'). Labelled HEAD-only in both places, with the pre-family figures inline and the lower-bound / n=2-vs-n=1 caveats moved into the durable row. Rejected: 'the checklist correction landed in the determination commit' - it landed in b9b92b0, the determination is 37c49b6, and the pre-correction form was already recorded verbatim. Gate: scripts/check-invariants.sh 0 (20 entries, 4 NAKED, baseline 4); checklist item 10's window checks green; cargo fmt --all --check 0.
Deploying topgun with
|
| Latest commit: |
95bbb13
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2fcd3ded.topgun-f45.pages.dev |
| Branch Preview URL: | https://fix-sf-355-tombstone-width-c.topgun-f45.pages.dev |
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
1 participant
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.
Summary
The TODO-630 investigation, resolved by measurement (0 of 5 Rust files written — R4 came back not-derivable, so no code; 67 evidence artifacts committed instead).
Determination (branch 2 — UNBOUNDED, not a regression): the 2×2 matrix (width {100, 1000} × binary {HEAD, pre-family}) with a pre-registered decision rule (frozen at
7b8ba1d2, provably before the first measurement) shows the pre-family binary is WORSE at production width (level +48%, slope 2.95×, non-overlapping ranges, t=11.88/4.56) — the SPEC-349 family moved tombstone bytes in the direction OPPOSITE a regression. A 4-hour run at production width ends on its maximum (646 KB; 8 windowed fits 113–244 KB/h, min window 222× the bound; W8 > W1 by 37%): no plateau exists. Mechanism: prune WORKS (gauge decreases on 33.5% of steps) but the reclaim fraction FALLS with width and runtime (95–98% at width 100 → 33% at width 1000/4 h).The side-finding that outranks the fork: the slope measuring stick itself is unreliable — identical width-100 runs differ 4.6×, a second instrument flips sign, the gate verdict is non-monotone in width (FAIL/PASS/FAIL), and SPEC-345's positive control (−1707 B/h) sits inside ±8,756 B/h noise — BOTH of its disjuncts were unproven. The gate must return on a LEVEL statistic with a derived bound (recorded in TODO-634/586 and TG-OR-005).
open, TODO-634), NAKED baseline 3→4 same-commit; TG-OR-004 (instrument fidelity) deliberately untouched.(pending)placeholders); §5's retracted-arguments ledger; three cross-vendor reviews, two of which reversed results; the interim mis-dispositions marked SUPERSEDED in place, not rewritten.Test evidence
Audits ×2, reviews ×2 (v2 APPROVED) + pre-finalize /xreview (3 real findings fixed, 1 rejected on evidence); every headline figure recomputed by the reviewer to the digit; 8 segments regenerate byte-identically;
check-invariants.sh20 entries / 4 NAKED == baseline; fmt/clippy/lint green (markdown-only round).