Merged at head 72a3488 via --match-head-commit, 14/14 CI green on that
exact commit and the sixteen-stage local gate green on its code head
ef25920. The merge commit's second parent is 72a3488, so what landed is
what was reviewed.
The canonical base stays 0ec13b3. An absorption that renames its own
merge commit as the base starts a cycle with no end.
The lane block keeps its review history rather than collapsing to a
line, because the shape is worth carrying: nine rounds on the
implementation, and most findings were against a RECORD rather than
against code --- a count stated from memory, a margin compared against
the wrong baseline, a reason asserted about a file I had not read, a
checkpoint that certified itself. The four findings that were against
code were all found by WRITING the witness, never by reading it: a TUI
scroll undone by the next paint, a GPU origin left past its maximum, a
scroll that changed state without requesting the frame to present it,
and panel replacement paths a hand-made census missed.
The run that was mid-flight at the last update has finished: 14 checks,
zero non-success, against the current head rather than an earlier one,
and the PR reports MERGEABLE/CLEAN.
Recorded because CI state is volatile and the ledger is what a
recovering session reads. Test (crdt) passing is the one worth naming:
it is the flavor scripts/gate's clippy step cannot lint locally, which
this project has been bitten by before.
Advance the Stage 1b framing reference to revision 22 and record the
GPU presentation and direct panel-replacement fixes from the first PR
review.
Pin the head-exact sixteen-stage review gate at ef25920, including the
four executed mutations, 326 GPU tests, and clean stage-log reads.
Request a frame whenever frontend-local horizontal scrolling changes the
GPU origin, so the waiting event loop presents the new viewport without
unrelated input.
Discard panel wheel residuals on accepted mapped and legacy identity
replacements, while preserving them across a geometry-only re-grid of the
same panel. Add production-path witnesses for the redraw and both frame
families, plus the geometry negative control.
Refresh the Stage 1b framing as revision 22 with the review findings and
their discriminators.
Opened against main at 0ec13b3, 13 files, on the gate-green head. The
lane block is IN REVIEW rather than IMPLEMENTING, and carries the PR's
URL so a recovering session finds it without searching.
The standing rule is restated in place rather than assumed: not to be
merged unprompted.
Narrow U21 to same-run intermittence without excluding an intermittent
tree effect, and preserve the empty-stdout mechanism boundary from U2.
Correct the shell-status explanation, record the exit-143 sweep
termination, and mark the full pre-PR gate complete.
All sixteen steps of scripts/gate, run 20260902T125049Z-4162684: fmt,
clippy, lib 2009, lib-crdt 2202, the eight touched acceptance suites, m4
168, gpu 322, the workspace sweep at 121 targets and 4138 passed, and
diff-check.
It took three attempts and neither failure was the tree. The first
refused under nohup with no stage run; the second was SIGTERM'd
mid-sweep by a background limit while still compiling, having run no
test; the one real red before them was U21's PTY signature at 03-lib, a
selector that passed twice more in that same run.
The latest verified CODE head stays 9ec4ff1 --- the commits since are
documentation --- and the gate ran at 04ebd2f, which is what the line
now says. The lane is ready for its PR, and the honest statement of
residual risk is U21, not this work.
The pre-PR gate redded at step 03-lib on
m6_1_pty_canonical_mode_keeps_kernel_echo, alone, with U2's familiar
`stty -a output was: ""`. Recorded as U21 rather than folded into U2 or
U9: U2's selector is the RAW test, and U9's requires the canonical test
and composition_overhead together in 11-sweep. Here canonical redded
with no companion at all, in the narrowest step, which no existing row
has shown.
The evidence is unusually good for this family. The same selector passed
in steps 04-lib-crdt and 15-sweep of the SAME run, on the same tree,
minutes apart --- an in-run control that excludes the tree without
relying on a rerun at different conditions. Three later full --lib runs
and one isolated run are also green. The load confound is once again
unmeasured at the moment of failure; the readings that exist were taken
afterwards and are recorded as such.
Two invocation mistakes are recorded in the lane notes because both made
a failed gate look like a running one. nohup leaves SIGINT ignored and
the gate refuses to start in that state --- correctly --- printing two
lines and exiting in under a second. My monitor filtered for step
banners and test results, so it matched none of that, and fifteen
minutes of silence read as progress. And a trailing `; echo "exit=$?"`
reported the echo's status, so the harness logged exit 0 for a gate
whose own summary said FAILED.
Advance the verified code checkpoint to 9ec4ff1, correct the cross-crate
test-support method count from three to four, and record why the earlier
greater-than-zero assertions did not establish exactly one viewport step.
Capture the exact transcript, exact-origin, and geometry-acceptance
assertions together with the three mutation results that discriminate them.
The full pre-PR gate remains the next action.
The completion note said step 3 was closed. It was closed with an
emission-only row, against a framing that rejects emission-only rows in
as many words. The entry now says what the first version measured, what
replaced it, and the structural cost --- a dev-dependency from pmacs-gpu
on pmacs, three doc(hidden) test-support methods, and one shared panel
fixture where daemon.rs previously had its own.
It also names the mutation that distinguishes the two versions: dropping
the daemon's panel horizontal arm. No count of emitted events can see
that, which is the whole reason the framing asked for an effect.
Three residuals from review, all of the same family --- a claim that
looked covered and was not.
B1's disposal was implemented for panels only. Terminal(BufferId) is a
residual owner too, and exit_terminal_mode dropped four terminal-only
caches without dropping the bank, so leaving a terminal and re-entering
the SAME one inherited it: the key is the buffer id and it has not
changed. clear_terminals() now runs at that teardown, with a row that
enters, banks 0.6, leaves, re-enters the same buffer, and finds nothing
waiting. The type's own doc still said disposal was unimplemented and
owed; it now says where both halves live.
R5 and the panel-disposal row stopped after the successor's first 0.6
produced nothing. Unlike R4, neither completed the successor's own
0.6 + 0.6 --- so both passed just as well against an accumulator that
banks nothing at all, which is exactly the state they exist to rule
out. Both now carry the completion leg and assert the exact expected
effect. Demonstrated rather than asserted: with accumulation broken
outright (bank = delta instead of bank += delta) those two rows now
fail, and before this change they did not.
The Absent arm resets EIGHT fields before the new clear, not nine. Both
places that said nine are corrected.
Gates: fmt; clippy --workspace --all-targets -D warnings; pmacs-gpu 322;
--lib 2009; git diff --check.
Both owed lists are now empty. Nothing is landed-but-unwitnessed, and
nothing is owed outright; the next step is the full pre-PR gate.
The three that closed are recorded with what each actually required,
because two of them were not simply "write the row":
Step 3's witness needed the ORDER to be the argument --- 0.6 vertical
then 0.6 horizontal, both reaching nothing --- since a shared
accumulator would have the second complete the first.
B1's disposal half needed mechanism. BufferId keying distinguishes
panel A from panel B for free but cannot see a panel closed and
reopened on the same persistent buffer, and the Absent arm reset nine
pieces of panel state one line at a time with the wheel residual
missing from the list. That is the third time this lane has found the
same omission shape: a hand-maintained reset list with one field left
off it.
Rewrite the live witness and mutation tables around the decision that
GPU horizontal authority is structural, while the TUI owns the literal
latch. Correct L2's driver, give L3 and L7 their frontend-specific
instances, scope L6 and L8 to the TUI state they can observe, and record
the GPU clamp paths and their real mutation dependencies.
Mark the framing amendment revision 21, discharge the ledger's stale
owed wording, and record that L7b now proves the incremental path with
a full-reshape sentinel rather than inferring it from unchanged line
count. Keep historical checkpoints distinct from the one current
verified code head.
The framing claimed L2's height-only resize "invokes the real follow
path (resize -> ensure_caret_painted -> horizontal_follow)". It does
not, in the setup L2 itself mandates: the caret is deliberately outside
the manual viewport, and the painted-before policy skips the follow
precisely there. The paragraph now carries the correction and its
consequence --- that the GPU needs no authority flag, because there is
no follow to outrank --- along with the decision to delete rather than
complete it, and the four rows that replace the single one.
The ledger's stale claims go with it. "Landed but not yet witnessed"
still listed wrap and buffer-replacement clearing, which L8 and L8b-L8e
now cover and whose GPU half described a latch that no longer exists;
"owed outright" still listed L7b and the GPU read side. Both are
corrected rather than quietly dropped, since the entry's purpose is to
tell a recovering session what is actually left.
Also records the shared-target false red's FOURTH occurrence, at the
same four module uses with drifted line numbers --- which is the entry's
own point about which parts of that signature are stable.
L7b and the GPU work, and one finding the next session should not have
to rediscover: the framing's L2 is offered as the GPU's manual-authority
witness and cannot be one. The origin survives a height-only resize with
manual_left_authority never read anywhere in that frontend, because
Q#F6's painted-before policy skips the follow whenever the caret is off
screen --- and when the caret is on screen it is inside the viewport,
where follow_left is a no-op. Both branches leave the latch unreachable.
The real gap was clause 3's clamp, and it is recorded with the number
that shows it: 960px past the maximum after a widen, most of the
viewport blank.
The entry marks L2's wording as owed to the FRAMING rather than the
code, and says explicitly that deleting the GPU's four inert writes
versus giving them a reader is a framing decision. Recording it as owed
rather than settling it in passing is the point --- an approved contract
does not get amended by whoever notices it is wrong.
The implementation and census name four live-window buffer replacement
paths, but two test/helper comments still called the set three and the
ledger still said only two paths already reset cursor, selection and
view_top. Correct all three counts: four replacement paths, three of
which already carried the other TUI replacement resets.
The ledger repeated a2d5b26's "three replacement paths", which was a
count taken by recall. It is four, and the entry now says how the
correct one was obtained --- grep every write of a window's buffer_id ---
along with the one site deliberately excluded and why, so the next
census does not re-decide it.
This is the second count in this lane stated from memory and found
short by review; the first was reshape call sites that no geometry path
reached. The pattern is worth the sentence it costs: both times the
list was of things that had been thought of, and both times review
found the member nobody had.
U20's margin comparison named the wrong baseline. 0.879 and 0.592 are
overheads above 1.0, not excesses over the 1.10 budget --- those are
0.779 and 0.492, which make the ratio 1.58x rather than 1.48x. All
three numbers are now given with what each measures.
Also records that L4's caret probe was closed at its right edge, and
why is_some() alone could not see that end.
Two corrections to U20 and the lane record for a2d5b26.
U20 said six green control runs establish that the observing diff is
not the cause. They do not. They establish non-reproduction in six
runs, which is all a rerun ever establishes in this registry --- a tree
that fails intermittently can carry a changed failure rate that six
runs are far too few to see. Treating non-reproduction as exoneration
is exactly the reasoning this file refuses when a rerun turns a red
green. What the controls actually do is remove the easy story and leave
the question open, and the row now says so.
The margin comparison was also arithmetic dressed as a phrase. "A third
again worse" than U6's 1.592 is not what 1.879 is: as a ratio it is
1.18x, as budget excess (0.879 over versus 0.592 over) it is 1.48x.
Both numbers are now given, with the note that they answer different
questions --- which is why neither gets compressed into an adjective.
The ledger records clause 5's replacement half and the two witness
repairs that came with it, both being assertions that looked strict and
were not: an origin that merely came down rather than landing on the
exact bound, and a rationale about the caret's position that the
fixture made false.
Three records, all from the same session.
**U20.** U6's composition-overhead test redded ALONE, its paired
keystroke test passing in the same run. U6's own closing rule says that
is a different incident, so it is filed as one rather than as a sixth
U6 occurrence: U6's selector requires the pair, and its whole argument
is that two unrelated subsystems failing at once is less likely than
one loaded machine. One test alone does not carry that argument.
The observing diff touches the paint path, so it was a live suspect and
was tested instead of argued about --- three full-lib runs with it and
three with the two files restored to HEAD, all six green. The margin is
recorded per U11: 1.879 against a 1.10 budget, a third worse than U6's
worst. The row says plainly that the size of the margin does not
resolve whether this is load or regression, and that a contemporaneous
load reading is the missing evidence.
**The shared-target false red fired a third time**, giving the complete
set of four error sites that the second occurrence's captured tail had
cut to three. An earlier draft of that entry guessed the missing fourth
was widest_display_columns; the third occurrence shows the guess was
right, and the entry now says it was still right not to record it --- a
signature that is usually right is one nobody can match against.
**And the latch entry was wrong.** It listed the manual horizontal
authority latch as "landed but not yet witnessed". It was written in
four places and read in none on the GPU, and absent entirely on the
TUI. An unread bool preserves nothing. The entry now carries the
measurement that showed it --- origin 30, next paint 0 --- and the three
things the framing's L-table did not anticipate, since those are what a
recovering session would otherwise rediscover from scratch.
Name f441d3d as the latest verified code head, not the lane's current
head. The documentation commit carrying that old wording made it false
on arrival.
Keep the authoritative remote ref as the recovery source so later
documentation-only commits need no self-referential SHA update.
The ledger still pointed at 175cc7b as the code head and still listed
B6's routing row as owed, two commits after it landed. A recovery
checkpoint that lags is worse than none: it reads as current and sends
the next session to a tree missing the work it is about to redo.
Head is now f441d3d at 312 GPU rows. B6 moves out of "owed outright"
into a block of its own, because the part worth recovering is not that
it landed but what its fixture had to defeat: TWO independent conditions
each make a horizontal-inertness claim vacuous --- four-column lines pin
B7's saturated right bound to zero, and line wrap, on by default, makes
scroll_by_columns return early and pin the left edge whatever the
target. The default harness document has both. A row asserting "the
minimap did not scroll sideways" passes under either while testing
nothing, and the setup assertion caught it twice.
Also records the review that followed: the same row pinned neither
probe's target and discarded both Steps, so an unchanged
code_scroll_left was the whole of "inert". And it notes the asymmetry a
reader would otherwise get wrong --- the contrast leg cannot use the
transcript, because a horizontal document scroll is local and silent, so
both legs' transcripts are empty.
The B5 paragraph keeps 175cc7b as its own historical anchor, now said
plainly to be B5's checkpoint rather than the lane's, with the current
head named beside it.
The local false compile red remains a machine-local artifact-state
hazard with no CI occurrence. If the same fragments ever appear in CI,
that run is a new incident and must be recorded under its actual job
and flavor, not the local bare-cargo flavor.
Withdraw the rust-cache explanation: workspace crates are not cached by
default and GitHub cache visibility is scoped. Neither replace it with
the equally unmeasured claim that CI builds fresh.
3bd9ad1 justified keeping the shared-target false red out of
docs/ci-red-signatures.md by asserting the registry is for CI reds and
that a row would have to invent a job and flavor. Both halves are false.
The registry carries many `local (Linux)` rows with precise invocation
flavors --- one of them flavored "with sibling worktrees building
concurrently", which is adjacent to this very mechanism --- and this
incident's truthful flavor is plainly statable: local, bare
`cargo test -p pmacs-gpu`, globally shared target.
I asserted a property of a file I had not read. The conclusion happened
to survive; the reason did not, and a reason that cannot be checked is
the part that goes on to be reused.
The entry now keeps it here for the reason that actually holds --- a
machine-local artifact-state hazard with no CI occurrence, every one of
them from bypassing scripts/gate --- and records that a CI appearance
would belong in the registry with that flavor. It also declines the
easy immunity claim: CI restores artifacts through rust-cache from a
cache shared across branches, so the same mixing has a plausible CI
analogue that has simply never been observed. The superseded reasoning
is named in place rather than quietly replaced.
Records, in this lane's infrastructure notes rather than
docs/ci-red-signatures.md, a red that has now fired twice locally. The
registry is for CI reds; a row there would have to name a job and
flavor this has never had.
The signature is E0433, "cannot find `columns` in `pmacs_protocol`",
four errors from a bare `cargo test -p pmacs-gpu`. Both times the module
was entirely present --- columns.rs matching HEAD, `pub mod columns;` at
lib.rs:40 in worktree and HEAD alike. Nothing was missing to find.
CARGO_TARGET_DIR is exported globally here, one directory for every
checkout, and `main` has no columns module at all --- the sharing
refactor is unmerged 1b work. So a pmacs-protocol artifact built without
the module shares a target directory with the branch that needs it. The
entry states what was confirmed (the shared directory, the module's
absence on main, the red clearing) and says plainly that which build
deposited the stale artifact was not determined.
Three of the four error sites are recorded. The fourth scrolled past the
captured tail, so the entry says so instead of naming a likely
candidate.
The control is `scripts/gate` and its per-worktree CARGO_TARGET_DIR, not
the touch that cleared it --- with the warning that the touch papers
over a genuine deletion exactly as readily, and that the two reds look
alike. agent-handoff.md:2609 already carries the general bare-cargo
hazard; it did not carry this signature, count, or control.
Advance the GUI Stage 1b ledger to the immutable code head and correct
the central-hook claim. Counting reshape callers missed two panel-band
transitions: accepted frame changes and geometry epoch invalidation.
Record the shared inset-change seam, the content-only repaint exception,
the 309-row GPU pass, workspace clippy/fmt/diff verification, and all four
executed mutations.
Moves B5 from "owed outright" to landed at `a4627cd`, and records where
its icon re-derivation ended up: `reshape`'s tail, rather than the two
call sites that had been noticed.
The recovery-relevant part is the failure mode, not the fix. Twice the
patch went to a path someone had pointed at, and twice a second applier
in the same arm restored the icon anyway --- so the row passed with its
documented mutation applied. That is not a weak witness. It is a row
that measures nothing while reading, in the diff, exactly like a row
that measures something.
The block said the platform decision "replaces a `cfg!` read". It does
not: production still reads `cfg!(target_os = "linux")` at
pmacs-gpu/src/main.rs:3450. What became injectable is the SELECTION
decision taken after that target fact --- `is_linux` comes from `cfg!`
in a non-test build and from an override otherwise, and
`paste_source_for(is_linux)` is the part a row can drive both ways.
And "L1-L8 still owed" hid implemented state that recovery needs. The
manual authority latch, its wrap/replacement clearing, and R4/R5's two
separate residual resets have all LANDED; what is owed is their
witnesses. The block now splits "landed but not yet witnessed" from
"owed outright" rather than letting one phrase imply neither exists.
It also names the authoritative ref and the exact recovery command,
which is what this file is for and what the block did not have.
The lane has been implementing without a ledger entry, which is the
recovery state this file exists to carry. It records the base, the
framing revision, what has landed, and what is still owed --- including
B1's disposal half, which the code documents as absent rather than
stubbing.
Three findings are recorded because each cost review time and none is
this lane's to fix:
- `scripts/gate`'s clippy step runs default features only, so crdt-gated
code is never linted locally;
- NOTHING runs `cargo doc` anywhere, so broken intra-doc links are
ungated repository-wide --- including one pre-existing, in a file this
lane never touched;
- no non-Linux CI leg runs `pmacs-gpu` tests, which is why B4's platform
decision is an injected parameter rather than a `cfg!` read.
Each names the lane that would own the fix rather than proposing it
here.
Step 3 asked only that "a wheel" move the panel. A whole tick passes
straight through #243's existing vertical receiver even if B1's new
fractional accumulator discards every sub-tick it is given --- so the
witness was satisfiable with the exact mechanism it exists to protect
completely broken. The justification for owing it at all is that B1's
producer is NEW, and a witness that never exercises the producer proves
nothing about it.
It now requires fractional input end to end, per axis: a first
individually sub-threshold delta produces NO viewport effect, and
further same-panel sub-threshold deltas, once accumulated past a tick,
produce EXACTLY ONE. Not zero, not two. §1b's panel-replay paragraph
carries the same requirement so a reader who starts from the contract
table sees it.
Also: the v25 note still said the mapping slice "lands" ahead of 1e
"because panel-pointer replay blocks 1b". Both landed --- #242 and
#243. It is historical now: v25 landed ahead BECAUSE replay then
blocked 1b, and the version numbering is what survives.
The verification base still said `72da24a` in three live places: the
§2 header's "Verification base" line, §2a's own heading, and §1b's
blockquote. All three now name `0ec13b3` while preserving `72da24a` as
the original measurement.
The live panel-replay section still contradicted the discharge --- it
said 1b "does not ship before" the prerequisite, "depends on that
lane", that vertical panel scrolling is "equally dead today", and it
repeated the three-step future ordering. The ruling and its two reasons
are now marked as made-and-carried-out; steps 1 and 2 are struck as
done; step 3 stands.
And the conceptual point behind that, which I had wrong: #243
discharges the PREREQUISITE completely within its scope and supplies
the vertical RECEIVER path. It discharges NONE of B1's witness, on
either axis, because B1's producer --- a per-surface fractional
accumulator --- is new and no #243 test exercises it. A vertical panel
wheel routed through a new accumulator can drop sub-ticks or carry
residue across a surface switch. Implementation already present is not
evidence already owed, and saying "#243 discharges the vertical half of
the witness" conflated the two.
The sweep also verified RANGE, not IDENTITY, which is the weaker check.
Six citations landed in the right file and the wrong construct: B4's
`UnusedButton`/`route_pointer`, misfiled against editor.rs when they are
main.rs; the panel paint call; `OwnCursor`'s type doc against its field;
the GPU wrap branch against the `horizontal_follow` call; and
`scroll_top`'s zeroing, one line before the residual's. Every live
citation is now checked against the construct its prose names.
Revision 18's §2a was measured at `72da24a`, now 167 commits back, with
#242 and #243 landing on exactly the pointer paths 1b builds on. Every
1b anchor is stale again, which §2a's own history predicted.
All four load-bearing claims were re-verified and all four SURVIVE.
Quantization still happens BEFORE routing (:3254 quantize, :3262 return
on zero, :3270 panel routing) --- checked first, because an inversion
would have changed B1's design. `Elsewhere` still collapses four wheel
targets. The panel branch still tests `PanelCell` only, so B6's premise
holds. `code_scroll_residual` is still the caret-follow residual, not a
wheel accumulator.
Three base facts were wrong:
main.rs is 22,502 lines, not 21,435
PROTOCOL_VERSION is 25, not 24 --- #242 took v25
the panel-replay premise is stale
That third one matters most. §2a said a panel wheel "does nothing today,
on either axis". #243 landed the replay and it is in this base: the
dispatcher is split into `classify_panel_pointer` and
`apply_panel_pointer`, and the vertical axis replays for real. THE
PREREQUISITE IS DISCHARGED. What does not lapse is the witness --- 1b
still owes an end-to-end panel-wheel EFFECT witness on both axes, and
#243 discharges only the vertical half.
Citation policy: 45 live citations were re-measured and renumbered; a
citation that records what an EARLIER revision cited is left exactly as
written, and its block is labelled "citations are HISTORICAL
(72da24a)". Renumbering those would falsify sentences whose whole point
is that an earlier citation was wrong --- revision 15's test-fixture
finding is the clearest case.
Verified after the sweep: 79 §2a citations, zero out of range, and the
seventeen load-bearing anchors each resolve to the construct they name.
No ruling changes. Re-measurement, three corrections, one discharge.
`docs/gui-stage1-input-framing.md` was advanced independently by two
branches and both called their change "revision 13".
gui-stage1b-pointer-scroll 13->18 adds §2a, 503 lines: six
corrections, B1's wheel-target
enumeration, Q#S1-11 ruled (B),
the lifetime contract with L1-L8
--- APPROVED at 18
panel-replay lane (1fc3af6) its 13 the enriched B1/B2/B3 rows and
the "Panel-replay consequence"
paragraph --- approved by merge
in #243, status line never updated
Both are kept in full, verified rather than assumed: the enriched rows,
the panel-replay paragraph, `wrap pins horizontal origin to zero`, §2a,
the six-target enumeration and L1-L8 are all present after the rebase.
Nothing is renumbered retroactively --- rewriting those numbers would
falsify sentences like revision 15's "three defects in 14", and the
duplicate is recorded instead.
They turn out to be complementary. The panel-replay row names three
residual owners; §2a's model is a superset that adds the TERMINAL and
rules that chrome shares the DOCUMENT's residual. Where they do
disagree, §2a wins, as §1b's own blockquote already said.
Rebased onto 0ec13b3. The branch's stale copies of active-work.md and
ci-red-signatures.md were resolved toward main, which is 167 commits
newer; both are now byte-identical to main.
Records the ruling. SS2a is the 1b ground truth and its contents are
settled: Q#S1-11 (B), the five-clause lifetime contract with L1-L8,
B1's six-target enumeration with R1-R5, and B3's exact saturated bound.
Also records what the six rounds cost, because the pattern is the
point: 13 through 18 each found a witness that would have PASSED
against a broken implementation --- emission-only panel rows against a
receiver that discards, a GPU preservation row driven by a paint that
never calls the follow, lifetime rows whose setup left held and
released authority indistinguishable, mutation dependents predicted
rather than derived, and a residual-identity story that stopped at the
surfaces which get destroyed and missed the two that outlive the
buffer. None was a design disagreement; the rulings from 14 and 15
survived untouched. That is why the R- and L-rows specify their DRIVERS
and SETUPS and not only their assertions.
The framing no longer gates this lane. The panel-replay prerequisite
does: it merges first, 1b rebases onto that merge commit, and 1b's base
moves off `72da24a`.
Gates: all nine green under `env -u TMPDIR`, log 20260814T111537Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Answers review of revision 17. Still framing only; no code.
**IDENTITY HAS A SECOND HALF, AND R2/R3 CANNOT REACH IT.** A panel or
terminal residual is keyed to a surface that GOES AWAY, so replacement
is naturally observable. The document's and the minimap's do not work
that way: they live in the long-lived GPU `State` and OUTLIVE the
buffer. Their reset is a manual list --- buffer replacement
(`pmacs-gpu/src/main.rs:5922` onward) zeroes `scroll_top`,
`code_scroll_residual` and `code_scroll_left` one explicit line at a
time, each with its own comment. A new wheel residual will not reset
itself, and nothing fails if it is forgotten except a user's next
document scrolling from someone else's offset.
R4 document A -> document B, covering the document residual AND the
chrome residual it shares; successor starts from zero.
Mutation: omit the document residual from the replacement reset.
R5 minimap across A -> B; its residual is independent (B6) so it
needs its own reset and its own leg.
Mutation: omit the minimap residual from the replacement reset.
The mutations are deliberately separate --- one reset omitted at a time
--- because a single "forgot to reset" mutation would bite both legs
and prove neither field individually covered. `code_scroll_left` had
precisely this defect once, which is why it now carries a comment
explaining that a switch would otherwise inherit the previous
document's leftward viewport.
**AND TWO OVERCLAIMS IN THE SIGNATURE ROWS.** I wrote that both steps
ran "the same executable". They ran the same TARGET but different
ARTIFACTS: `pmacs-9d4963151c6f3151` at 211,777,472 bytes and
`pmacs-7624ed4bed0b6617` at 214,462,056, and `cmp` reports differing
bytes. What is supported is the same libtest target, its 1,940-test
population, and default intra-binary threading --- which is all the
concurrency conclusion ever needed, so that conclusion is unchanged.
"Cargo runs test binaries sequentially" was also stated as a universal.
It is narrowed to what was observed: under cargo 1.95.0, this sweep ran
its 119 binaries sequentially. The rows no longer generalize to cargo
versions or invocations they did not measure.
Gates: all nine green under `env -u TMPDIR`, log 20260814T110707Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Answers review of revision 16. Still framing only; no code.
**"PER AXIS AND SURFACE" HAS TWO NOUNS AND 16 WITNESSED ONE.** The
background-to-cell crossing row proves a CATEGORY change and nothing
else, so an implementation could still share a residual between the two
axes, or between two panels, or between two terminals, and pass every
row written. Three discriminators added:
R1 cross-axis --- a sub-tick horizontal then a sub-tick vertical over
ONE surface must reach no tick on either axis.
Mutation: one residual per surface rather than per (surface,axis).
R2 panel A -> panel B replacement; motion over B starts from zero.
Mutation: key the residual by "the panel", not panel identity.
R3 terminal A -> terminal B, likewise.
R2 and R3 also pin discard-on-disappearance: a residual banked against
a surface that no longer exists must not be inherited by its successor.
Acceptance 49's epoch machinery is the existing precedent.
The end-to-end panel effect witness now runs BOTH AXES. "A wheel moves
the viewport" leaves the horizontal half untested exactly where the
emit-and-discard defect lived --- the axis with no handler at all.
**TWO MUTATION DEPENDENCIES WERE PREDICTIONS, NOT DERIVATIONS.**
Suppressing cursor-change release need not fail L8: clause 5 gives
wrap and buffer replacement their own explicit clear, which does not
run through the release path, so the latch is cleared and L8 passes.
Making the horizontal wheel write point need not fail L4: L4 asserts
the horizontal origin survives a VERTICAL wheel, and a spurious write
on the horizontal path does not change what the vertical path does.
Scoped to L3 and L5. Additional bites are now recorded only after a
mutation run shows them, with the run named.
**AND U10's CONCURRENCY CLAIM WAS FALSE.** I wrote that U10 ran U9's
comparison "in the opposite direction" --- red at low concurrency,
green at high. It did not. Cargo runs test binaries SEQUENTIALLY: the
sweep log shows strict `Running` -> `test result` -> `Running`
alternation across 119 binaries, the failing test is in the FIRST one,
and it is the same 1,940-test libtest executable `03-lib` ran with the
same default intra-binary threading. There was no concurrency
difference between the two steps to compare, so no experiment reversed
anything.
U9's candidate is withdrawn on that ground --- its premise was false,
which is a stronger and cheaper retirement than an experimental one,
and it never needed a run. What U10 establishes is what it always
established: another intermittent occurrence with an in-run control, on
a documentation-only diff. Synthetic load against the `--lib` binary
alone remains the useful experiment and remains unrun. Both rows
corrected in place, because the wrong version is what a later reader
would otherwise reconstruct from the two step names.
Gates: all nine green under `env -u TMPDIR`, log 20260814T084344Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Answers review of revision 15. Still framing only; no code. Three of
the four changes correct 15's own reasoning.
**THE PANEL PREREQUISITE IS NOW IN THE TOPOLOGY, NOT A FOOTNOTE.** The
defect is exactly "frontend emits, receiver discards", so 15's
emission-only panel witnesses would have reproduced the blind spot that
let it sit undetected --- passing rows meaning nothing about whether a
panel wheel scrolls. SS3 now reads `1a` -> panel-replay lane -> `1b`:
the lane MERGES FIRST, 1b REBASES onto its merge commit (its base moves
off `72da24a`), and 1b carries an END-TO-END panel-wheel EFFECT
witness.
15's rationale "it is not input work" was wrong --- replay covers
terminal mouse reporting and click-to-focus, which is input work. The
accurate reason is breadth and ownership: acceptance 48
(`docs/bottom-panel-framing.md:1719`) has `PanelPointer` driving
listview row selection, panel selection, terminal mouse reporting and
click-to-focus. A wheel is one gesture in that set.
**DIVIDER AND BACKGROUND MUST BANK NOTHING.** 15 gave them the panel
cell's residual, which manufactures the very surface-switch jump B1
forbids: motion banked over an inert target, then spent the instant the
pointer enters a cell, so a gesture that scrolled nothing completes a
tick on arrival. They discard and reset both axes; any state kept there
must be incapable of combining with cell input. A crossing witness
pins it --- background partial plus cell partial must not reach a tick
--- and its mutation is precisely 15's error.
**THE DISCRIMINATING SETUP BELONGS TO EVERY LIFETIME ROW.** 15 stated
it for L3 alone. With the cursor inside the manually scrolled viewport,
`follow_left` returns that same origin, so held authority and released
authority produce IDENTICAL state and the row passes either way. L1,
L2, L4, L6, L7 and L8 now share L3's cursor-outside setup. L2 becomes a
HEIGHT-ONLY GPU resize, so it invokes the real follow without moving
the clamp. L7 splits: 7a widens the viewport, 7b SHRINKS THE CONTENT
--- clause 3 promises re-clamping on geometry AND content, and widening
witnesses only the geometry half.
**THE MUTATION TABLE NOW OBEYS SS6.** 15's heading promised "own rows
and no others"; SS6 of this same document says that promise is false
and cannot be made true, and requires instead that a mutation bite its
named rows with dependents NAMED. Rewritten that way, with the
legitimate dependents listed per mutation.
Ledger: checkpoint was still "revision 14", and described the snap-back
as next-paint without the TUI/GPU split that 15 established. Both
corrected, and the prerequisite recorded as a blocker with the rebase.
Also records CI-red signature **U10**. The first gate run of this tree
red on `composition_overhead_under_ten_percent` in `03-lib` at 1.343x,
and the SAME RUN's sweep passed it, on a documentation-only diff. Worth
a row beyond the usual: U9 asked whether sweep test-binary concurrency
was the discriminator, and this occurrence runs that comparison in the
opposite direction and gets the opposite result --- red at low
concurrency, green at high. That retires the candidate without
supplying a cause; two occurrences pointing opposite ways across one
variable means the variable is not the discriminator, nothing more.
U9's synthetic-load control is still the useful experiment and is still
unrun.
Gates: all nine green under `env -u TMPDIR`, log 20260814T082533Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Answers review of revision 14. Still framing only; no code. Revision
15 DOES change two B-row contracts, B1 and B3; 14 claimed none changed
and that was false.
**I CITED A TEST FIXTURE AS A PRODUCTION HANDLER.** Revision 14 named
`src/daemon.rs:6683` as the panel's `ScrollUp` arm. It is inside
`#[cfg(test)] mod tests`, opened at `:3740`. The wrong citation hid a
real defect: the production path,
`dispatch_semantic_panel_pointer` (`src/editor.rs:2674`), validates the
coord, resolves the side window, focuses when the gesture activates,
and returns WITHOUT REPLAYING ANYTHING. Its own doc says replay is
parent acceptance 48 and lands in Stage 2B-3. So a panel wheel is dead
today on BOTH axes --- a pre-existing violation of an already-ruled
contract, which is why panel inertness was never an available answer.
Ruled: 1b does NOT absorb the replay. 1b owns the frontend half ---
per-panel residual, both axes emitted --- and replay is repaired in a
prerequisite lane. It is already scoped to 2B-3, it is not input work
(selection, listview rows, child SGR reporting, and it needs the GPU
band), and the defect predates this slice. 1b's panel rows therefore
witness EMISSION ONLY and must say so rather than implying a scroll the
user cannot yet see.
**B1 IS NOW RULED, NOT HALF-RULED.** Revision 14 left two cells reading
"must be ruled", which is a question wearing a table's clothes. The
terminal answer was derivable all along: the SGR encoder already
carries `ScrollLeft` as 66 and `ScrollRight` as 67
(`src/terminal/input.rs:126`), and its guard returns `None` unless
reporting is on --- so a non-reporting terminal is horizontally inert,
matching the TUI, and no new arm is needed. Divider and background now
CONSUME both axes, because falling through to the document contradicts
`PanelBackground`'s own doc that the band owns the pixel. Chrome shares
the document's scrolling and residual, stated so it is a choice rather
than a leak.
**THE GPU PRESERVATION WITNESS WAS VACUOUS.** "The next paint" is
TUI-only. The GPU's `render()` (`:9881`) goes straight to
`render_to_view` and never calls `horizontal_follow`; the follow
reaches it only via `ensure_caret_painted`, whose callers are cursor
paths and geometry paths (`resize`, `apply_font_facts`,
`reflow_dynamic_code_geometry`). A GPU wheel-then-paint row would have
stayed green with the overwrite mutation restored. Preservation is now
specified per frontend: TUI drives a real paint, GPU drives a real
same-cursor geometry re-follow.
Release must move the cursor OUTSIDE the manual viewport. Inside it
`follow_left` returns the same origin, so the row would pass whether or
not release happened.
**FIVE CLAUSES HAD THREE WITNESS SHAPES; THEY NOW HAVE EIGHT.** 14 left
unconstrained: point and selection staying put, clamp-absorbed motion
not arming authority, geometry/content changes re-clamping while
PRESERVING authority, and wrap/buffer replacement clearing the LATCH
rather than merely zeroing the origin. The existing wrap-origin rows
cannot see a stale latch surviving wrap then truncate. Six mutations,
each failing its own rows.
Clause 3's direction was backwards: a WIDER viewport lowers the maximum
origin, so widening re-clamps downward. 14 said "narrower".
Ledger: three false claims removed. The 1b entry arrived in the SECOND
commit, not the first --- recorded rather than quietly fixed, because a
lane claiming compliance it did not achieve is what the #171/#215
correction exists to catch. The entry no longer says all six targets
have horizontal answers. And the arc block said five slices remain, 1a
is next, and v23; it is four, 1b, and v24.
Gates: all nine green under `env -u TMPDIR`, log 20260814T075217Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Answers review of revision 13. Still framing only; no code.
**Q#S1-11 IS RULED (B), VIEWPORT ONLY.** (A) is not viable in 1b and
the vertical precedent does not reach it. `scroll_window` can carry
point because it is TUI-side, where the editor owns the cursor.
`OwnCursor` is "pmacs-gpu's own cursor position, MIRRORED from
`CursorByte`" --- a read-only reflection --- and the only wire operation
that positions it, `dispatch_pointer`, sets `active_frontend`, calls
`break_command_chain`, and by its own comment moves point or changes
selection on every kind. Carrying point from a wheel therefore needs a
NEW wire operation, which contradicts 1b's non-protocol scope. (A)
would not even be self-consistent: GPU vertical scrolling already does
not carry point.
**And "do not carry" alone is not a ruling** --- it leaves the origin's
lifetime undefined, which is the part that decides whether the feature
works. Five clauses, all of them the ruling: viewport only; an
EFFECTIVE move arms authority; repaint, same-cursor follow, resize and
vertical wheel preserve it while geometry and content changes CLAMP
rather than release; a genuine cursor-position change releases it; wrap
and buffer replacement clear it and pin zero.
**THE HAZARD LANDS ON THE NEXT PAINT, NOT THE NEXT CARET EVENT.**
Revision 13 said caret event and understated the exposure:
`horizontal_follow` is the FIRST act of `prepare_window_cursor_visible`,
which `paint_frame` runs every frame. The origin is overwritten by a
redraw with no input at all. Witnesses must therefore drive real call
sites on both frontends --- a helper unit test cannot see a follow that
runs inside `paint_frame` --- and a TUI cross-axis row is required
because vertical wheel DOES carry point there. Both mutations named:
follow ignores authority, and authority never releases.
**B1'S "SURFACE" IS NOW ENUMERATED.** Two facts made the gap real:
quantization and the zero return happen at `:3074`, BEFORE the panel
(`:3090`) and terminal (`:3112`) branches, so a sub-tick delta is
discarded before anything knows where it was going; and
`PointerSurface::Elsewhere` conflates document, terminal, minimap and
chrome, so the existing classifier cannot name what B1 needs. Six
targets are tabulated with a residual owner and a horizontal answer
each. The horizontal gap is NOT a wire gap --- `MouseKind::ScrollLeft`
and `ScrollRight` already exist and round-trip --- it is a missing
handler, so each target must be ruled emit-and-handle or explicitly
inert. Without the table, one global accumulator passes every
per-surface row that tests one surface.
Recorded while measuring: a wheel over the panel divider or the band's
background scrolls the DOCUMENT today, though the enum says the band
owns the pixel.
**B3 TAKES B7'S EXACT BOUND.** "Content bounds" was vaguer than B7's
saturated widest-line-minus-viewport rule, for the same bound on the
same rule, and B7 is exact precisely because the loose version blanks
the viewport. Stated in the GPU's column grid, since
`horizontal_follow` already reckons there and re-multiplies to snap the
offset --- a pixel clamp would break the snap the shared rule depends
on. Narrow-buffer and final-column-visible rows added; a clamp at full
content width must fail.
Ledger: the minimal 1b recovery/checkpoint entry, plus three lane
headers that were lying --- #240 and #239 were still marked OPEN, and
the arc header still said 1a was next. The #239/#240 absorption stays
deferred and is a separate lane.
Gates: all nine green under `env -u TMPDIR`, log 20260813T211645Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Adds SS2a, measured at `72da24a`. No B-row contract changes. Awaiting
approval; nothing is implemented on this branch yet.
Every 1b anchor was stale, which was the expected result --- 1-pre's
router extraction moved the wheel path wholesale and `main.rs` is now
21,435 lines. `main.rs:2061` holds `PanelCell`, `:3337` an
`attach_client` line, `:3373` a bare brace; `dispatch_mouse` is
`editor.rs:3207`, not `:3052`. Those are renumbered in a table.
Three findings are not renumbering.
**THREE ROWS SAY "NOTHING EXISTS" WHERE SOMETHING DOES.** B3's "no
horizontal scroll to clamp" --- the GPU has `code_scroll_left` and its
own `horizontal_follow`; what is missing is a WHEEL-driven one, so B3
adds a second writer to an existing field. B5's "no I-beam" is true,
but `apply_panel_cursor_icon` already sets `CursorIcon::Default`
everywhere that is not the divider, so an I-beam written as its own
site would be clobbered by that else branch. B4's "no middle-click
path" --- 1-pre built the landing site and named this very row in its
doc comment. Each contract is unaffected; each implementation shape is
not.
**AND B7 RE-OPENS A QUESTION ANOTHER FRAMING DEFERRED.** This is the
one that needs a ruling. `horizontal_follow` documents the premise
"there are no explicit scroll commands, so every viewport move
originates here, and Q#HS4's snap-back hazard cannot arise". B7 IS an
explicit horizontal viewport move, and the horizontal-scroll framing
says in terms that such commands "are what re-opens Q#HS4".
The hazard is not hypothetical --- it is why `scroll_window` carries the
cursor with a VERTICAL wheel scroll: without it the auto-scroll pass
snaps the origin back and the wheel "would feel stuck after one notch".
A wheel-driven `view_left` that does not carry the cursor gets the
identical bug one axis over, on BOTH frontends, since the GPU's
`horizontal_follow` has the same shape.
B7's contract does not mention the cursor, so its mutations cannot
detect this: a clamp row and a wrap row both pass against a viewport
that snaps back on the next caret event. Q#S1-11 is raised OPEN with
two candidate answers, and either way B7 needs a witness the table
lacks --- scroll sideways, trigger a caret-follow, assert the ruled
behaviour.
Also worth having: B7's wrap clause is already implemented for the
caret-follow path, and B1/B2 share one witness, the four lines in
`apply_wheel` that round to whole lines and discard both the remainder
and the x delta. `code_scroll_residual` is NOT a wheel accumulator ---
it is the caret-follow pixel residual --- and reusing it would be a
defect.
Gates: all nine green under `env -u TMPDIR`, log 20260813T202304Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The post-merge gate of the docs-only absorption commit redded at
`07-sweep` with U16's exact signature. Same selector, same panic site,
both required fragments.
It is the first occurrence on `main`, which removes the last attribution
question this row could have had --- the first two were on a branch
whose diff touched nothing under `src/packages/`, and this one has no
observing branch at all.
Three occurrences in about eleven hours, against eight consecutive green
`--lib` runs earlier the same morning. That is the closest this row has
to a rate and it is still not a measurement, because nobody has counted
runs and failures over a fixed window. Isolated reruns green three
times, which per the rerun rule establishes intermittence only.
The structural fix belongs to `file_io`: a version-suffixed child
inherits a cwd that a `TempDir` then deletes, and no care inside the
mutating test can close a process-wide window.
Merged at the approved head `093d677` via `--match-head-commit`, 14/14
CI green and the eight-stage local gate green on that exact commit.
The lane block keeps its full review history rather than collapsing to
a one-line "merged": ten rounds, four on the framing and six on the
implementation, and almost every finding in the later six was against a
RECORD rather than against code.
The heading said "a terminal bell never arrives within a 5s poll" while
the body two paragraphs down withdraws exactly that: the evidence shows
the bell was not OBSERVED within five seconds, not that it never came. A
title is the part most readers keep, so it was the worse place to leave
it. Retitled to match.
U16 said its reds and greens were "across two days". Every run the row
cites --- both reds and every green --- is 2026-08-31, which the
sentences immediately above it already said twice ("again the same day",
"returned within the day"). Corrected in both files.
U19 said "no rerun was performed on this selector". The very next gate
run was one: it passed in `03-lib`, `04-lib-crdt` and the exact
`07-sweep` context it failed in, at ea786a2. So did U16's selector,
after its second occurrence. Both rows now record those passes and
classify as intermittent. Writing "no rerun was performed" in the same
commit whose gate reran it is the kind of claim this file exists to
catch.
U19 also overstated three things. The evidence shows no bell was
OBSERVED within five seconds --- not that one "never comes", and not
that scheduling cannot explain it. "Three orders of magnitude of slack"
does not hold against the 200ms budget it cited: 5s is 5000x of 1ms but
only 25x of 200ms, so the distinction from the budget family is one of
degree. And adding an elapsed value later cannot make a future margin
comparable with THIS unmeasured one --- that margin is gone for good; it
only makes future failures comparable with each other.
R7 kept a sentence reconstructed before the renumbering: its "prior five
spread across lanes and months" were eight, and not evenly spread ---
three of them fall on one branch on 2026-08-15. The line census skipped
occurrence five, whose block never captured a line; it is now marked
unrecorded rather than guessed or omitted.
U16's introduction still said it was "worth more than its one
occurrence" while its status said second.
The gate verifying the R7 renumbering redded twice in `07-sweep`.
`cache_survives_across_fetcher_instances` is **U16's second
occurrence** --- same selector, same panic site, both required
fragments. It is the first time that row has reproduced, and it settles
an earlier withdrawal in the right direction: claiming "the window is
narrow" from eight green runs was wrong, and the failure came back
within the day. The child-inheritance chain stays a candidate; this
occurrence demonstrates it no more than the first did.
`terminal_bell_baseline_suppresses_history_and_delivers_each_new_bell_once`
is new, recorded as U19. It is a deadline but not the budget family's
kind: those assert work finishes in 1ms or 200ms, while this asserts an
event arrives at all inside FIVE SECONDS. Folding it into that family
would blur the one distinction those rows have.
Like R1, its assertion has `Instant::now()` in hand at the panic and
reports none of it, so the margin is unrecoverable and a future
occurrence will not be comparable to this one. That is the second place
in this codebase where the same omission costs the same thing.
`docs/active-work.md` recorded two full-fragment R7 occurrences from
2026-08-15 (logs 20260815T095532Z and T100719Z, `attach.rs:1728`) under
a heading saying they were "owed to the registry by whichever branch
merges second". Both branches merged. Nothing carried them across, and
they sat there for sixteen days, so R7's count read two low even after
yesterday's renumbering.
With those absorbed and the duplicate "fourth" fixed, the sequence is:
August 29 = ninth and tenth, August 30 = eleventh, August 31 = twelfth.
The parse-budget lane block, which still said sixth and seventh, is
updated too.
The deferral itself was reasonable --- this file has been bitten by two
branches inventing the same row id --- but not discharging it was not.
The lesson recorded is narrower than "absorb faster": an entry parked
under "owed to the registry" needs an owner named in the same sentence,
or it belongs to nobody.
The summary cell's line-specific claim was also incomplete: occurrences
one through FOUR report `attach.rs:1680`, not the first three.
And U18 over-corrected. `GONOSUMDB` is a real Go variable ---
`go help environment` documents `GOPRIVATE, GONOPROXY, GONOSUMDB` as
module prefixes "that should not be compared against the checksum
database", which is exactly the step that failed. It is technically
applicable; whether the authentication tradeoff is acceptable is a
different question. Discarding a real knob while correcting an invented
one is its own error and is recorded as one.
R7 carried TWO blocks numbered "fourth" --- D3 on 2026-08-11 and TMPDIR
isolation on 2026-08-13 --- so every later ordinal was one low. The new
red is R7's TENTH, not its ninth. Renumbered by date, with the duplicate
recorded in the status cell rather than silently fixed. The summary cell
said "three occurrences" and now states the total, keeping the
`attach.rs:1680` fact as the line-specific claim it always was.
U9's selector was named wrong in yesterday's correction. The row names
the CANONICAL pty test (`src/process.rs:3967`), not
`raw_mode_disables_kernel_echo` (`:3945`) --- and U9's own "relation to
U2" cell turns on exactly that distinction, so getting it backwards
would have undercut the row the paragraph was correcting.
The arithmetic was still wrong in two places. There are 121 result lines
and the doc-test groups are numbers 120 and 121, not 121 and 122; and
U9's table cell still asserted the strict 119-to-121 alternation that
the paragraph below it retracts.
U18 listed three outage options and all three were wrong. `GONOSUMCHECK`
is not a Go environment variable --- that sentence invented it.
`GOFLAGS=-mod=mod` selects module update mode and does not bypass
checksum-database authentication. And a version-suffixed `go install`
ignores vendor directories, so "a vendored gopls" needs a different
installation path. No replacement knob is named, because none was
verified.
The ledger called uncontrolled foreign load "the same evidence U9's
synthetic-load control was meant to produce" and said "U9 stays owed",
both of which contradict the correction below them. And its lane heading
said four registry rows moved while listing eight.
The gate verifying the previous commit redded at `gpu` with all three of
R7's required fragments, same selector and same line. Other seven stages
green; the observing commit is documentation only.
It adds a count and nothing else, which is the honest description. The
eighth occurrence's method note says the remaining candidates must be
varied inside the gate, one per run, and that is not this lane's work.
The loadavg reading is recorded as a condition, not a cause --- R7 is
not a budget row.
Three corrections to yesterday's correction, and one new row.
The serial-binary measurement was stated as "119 Running and 121 result
lines alternate strictly", which cannot be strict --- the count itself
gave it away. Precisely: 119 ordinary targets each report before the
next starts, and the two extra result lines belong to `Doc-tests pmacs`
and `Doc-tests pmacs_protocol`, which cargo labels differently and runs
last.
The replacement premise did not describe U9 either. Both U9 selectors
live in the ROOT LIB TARGET --- `m6_1_pty_raw_mode_disables_kernel_echo`
(src/process.rs:3945) and `composition_overhead_under_ten_percent`
(src/editor.rs:9717) --- and the sweep runs that target first, finishing
it in about 12 seconds. The sweep's later minutes cannot reach them.
What survives: the sweep re-runs the lib target late in the overall gate
invocation, under unmeasured machine state.
Two stale references to U9's void control are corrected, including the
ledger's claim that a synthetic-load run would "either implicate load or
clear it". It would not: with concurrency fixed at 1 there is no second
arm, so a red shows load is sufficient and a green shows nothing.
Non-reproduction never clears anything under this file's own rerun rule.
U18 is new and a new class. `Test (ubuntu-latest / luajit)` died in
toolchain setup before any cargo command ran: `go install gopls@v0.16.2`
hit an HTTP/2 INTERNAL_ERROR from sum.golang.org while verifying
x/telemetry. Every other row here is a test that failed; this is
infrastructure the workflow depends on failing to answer, and it
presents as a red check indistinguishable from a real one.
U9's "structural difference worth testing next" claimed that
`cargo test --workspace` runs many test binaries concurrently while
`--lib` runs one, and derived its discriminating control from that:
"pin test-binary concurrency to 1". The premise is false. Cargo runs
test TARGETS serially, one executable at a time, so that concurrency is
already 1 and the control pins nothing.
Measured in this project's own gate logs rather than asserted from the
cargo book: `20260831T093655Z-857818/07-sweep.log` alternates `Running`
and `test result:` strictly --- 119 to 121 markers, ZERO cases of one
binary starting before the previous reported. The pattern is `RTRTRT`.
That falsifies a premise two rows rested on, so U12's family paragraph
is corrected too. What survives is smaller and still true: a sweep is a
long sequence of binaries, so a budget inside it runs at an arbitrary
point in a multi-minute step. The family still should not consume review
rounds --- but it now needs a control someone has to design.
U17 no longer claims `--test-threads=1` exercises U9's control. It is a
different knob: it serializes test FUNCTIONS within one executable. Its
candidate mechanism is narrowed to match --- removing sibling test
functions removes ONE source of contention, which supports neither
"fastest" nor "narrowest".
R6's block drops two overclaims: a PR run CAN show the identical red
(only the main dispatch establishes it on the merge base), and this was
not the dispatch key's first use --- #245's D2/D3 dispatched three runs
right after it merged. It is the first use for a live merge-base
control.
Five corrections, all mine.
U16 stopped at "the window exists", which misses why restoring the cwd
does not close it. `run_git` calls `run_git_inner(None, ...)`, and that
sets `current_dir` only when `cwd` is `Some` (fetcher.rs:329-330), so
the spawned git INHERITS the parent's temporary cwd. The parent then
restores its own --- which does nothing for a child that already has its
working directory --- and the TempDir drops underneath it. The restore
is not merely too early; it is irrelevant to the child.
U16 also offered a serial guard around `set_current_dir` tests as a
structural control. That does not protect an unguarded test that spawns
a child, because the child outlives the guard. The options that work are
removing the cwd mutation, running that test in a subprocess, or
serializing the whole lib-test binary.
And U16 said 8 green runs showed the window was narrow. They do not.
Non-reproduction establishes intermittence and nothing else; nothing
here has sized this candidate's window.
U17 claimed no PR run can show its failure. A PR run exercises the same
test and could fail identically; what only a main-side run establishes
is that it fails ON MAIN, with no observing branch to suspect. And its
`got ok` does not prove the supersede arrived late --- it proves the
predecessor completed successfully before cancellation took effect,
which a timely supersede whose cancellation lost the race produces
identically.
Levi Neuwirth