Third occurrence of the same process failure, and the one I had already
written the lesson for twice. ab43132's message said the ledger no
longer claims implementation-absent or mechanism-unknown. The ledger
script died on a stale anchor, and because I separated the steps with a
newline instead of chaining them, `git commit` ran regardless. Gating
one step is not enough when the next step is not gated too.
The ledger now records what the framing does: mechanism KNOWN, remedy
SELECTED as R-b + R-d via the portable probe, A3/D0b satisfied by the
controlled explanation so D0b is not owed, revision 12 awaiting
approval, D1/D2 done rather than "the next step", and the diagnostic
instrument named as the only implementation so far.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two record defects plus the remedy decision.
1. Withdrawn claims were still asserted elsewhere. The header and §4c's
consequences still said bet 1 FALSIFIED, A5 STRUCK, and that a real
pmacs --gpu "behaves correctly" --- none of which D4 established,
since D4 never ran. Both now say withdrawn/retired BY SCOPE, with
the explicit note that nothing here shows a real session is correct,
only that no observed evidence of a user-facing defect survives.
§4c's pre_exec-implies-assertion conclusion is replaced by a pointer
to §7b/§7c. A3/D0b are marked SATISFIED by the controlled
explanation --- D0b is not owed and will not run. §9's "Beyond step
12(a)" is gone, since no journey step is touched. The ledger no
longer says implementation-absent, mechanism-unknown, or D1/D2-next.
2. Provenance made portable. Both arm commands are fully expanded
rather than delegating to a machine-local arms.sh. Full SHA-256 of
the two executed binaries are recorded; the 16-character log values
are relabelled PREFIXES and carry no claim. The standalone
foreground/background SigIgn table is labelled UNRECORDED
CORROBORATION --- read ad hoc, no head, no log, no digest --- and the
portable probe supersedes it as the recorded check.
Remedy selected, §7c: R-b + R-d through one checked-in helper wrapping
a behavioural probe --- sh -c 'trap "exit 23" 2; kill -INT $$; exit 0' ---
which exits 23 when SIGINT is deliverable and 0 when inherited as
ignored. Verified here in both contexts. POSIX shell only, so it answers
§7b's portability criterion: no /proc, so not Linux-only, and no
sigaction, so no unsafe. scripts/gate fails immediately with the
explicit diagnosis; the target test reports the same precondition
failure if run directly; no override, because a gate under ignored
SIGINT cannot produce valid evidence. R-c rejected. The Linux-only
D1/D2 instrumentation is removed once its evidence is portable.
A1-A5 are replaced for the new work --- guard bite, direct-test
diagnosis, foreground success unaffected, mutation, and an otherwise
unchanged gate --- with the old teardown criteria kept in §8b, marked
non-binding, so the change of target is visible rather than silent.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Four findings on revision 11, all upheld.
1. The operative contract still said the opposite of §4c. Bet 1 read as
open; §7 said the mechanism was unknown with D3/D4 pending; §8 kept
the old criteria and a conditional A5; §9 claimed a journey-12(a)
product repair; the ledger and the revision-10 paragraph still said
D1/D2 had not started. Each is now rewritten as executed, withdrawn,
discharged or superseded --- §9 in particular now records journey
steps touched: NONE, for the stated reason that no product behaviour
changes, with gate trustworthiness named as what the lane does
affect.
2. The causal evidence is now portable and cleanly reproduced. The
first capture came from d12.log, which finished five minutes BEFORE
afe3631 committed the diagnostic code and ran in the reused d0a-B
target --- inadmissible provenance, now marked as the first sighting
only. Replaced by controlled arms on committed head 38f2af4,
dirty=0, in this worktree's own target, with BYTE-IDENTICAL binary
hashes across arms (0890b78cca22ac1e, ef6ff1c15e11062a): foreground
exit=0 ok=2, background exit=101 failed=2 SigIgn=0x1007. The outer
invocation is recorded as a first-class column, since it is the
causal variable and every earlier "exact command" omitted it. The
historical foreground/background mapping is marked RECONSTRUCTED
from the transcript, not captured --- no pre-existing row carries an
outer-invocation field, which is precisely why the matrix stayed
confounded for nine revisions.
3. D4 was never executed, so bet 1 is WITHDRAWN BY SCOPE rather than
falsified, and A5 is RETIRED BY SCOPE rather than struck. Nothing
here shows a real wgpu session behaves correctly; what is shown is
that no observed evidence of a user-facing defect survives. The lane
is now gate/test correctness only.
4. The remedy is not selected. §7b evaluates four candidates --- runner
normalisation, an early gate guard, fixture isolation via pre_exec,
and a test-local precondition assertion --- with portability as a
selection criterion, noting /proc is Linux-only while the suite is
cfg(unix) and sigaction querying is unsafe. Likely R-b + R-d, but
nothing is chosen or implemented here. Revision 11's leap from
"pre_exec is unsafe" to "therefore an assertion" did not follow.
Also renames the meaningless african_close() helper (38f2af4).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
afe3631's message described revision 11 in detail. The commit contains
only the test file: the script that was to write the framing died on a
stale anchor --- the approval commit had reworded the header --- and the
shell chain ran `git commit` regardless of its exit status.
This is the SECOND time in this lane, and I recorded the lesson for it
in ea0f3bf: "asserting the edit is not enough if the commit does not
depend on it". I then repeated it. This commit gates `git commit` behind
the editing script's exit status, which is what the earlier note should
have changed and did not.
The framing is now actually at revision 11, AWAITING APPROVAL, carrying
§4c: SIGINT ignored group-wide (SigIgn=0x1007, signal 2), zero SigPnd
and zero per-thread SigBlk so ignored rather than blocked delivery,
shared pgid so nothing escaped the group; the foreground/background
SigIgn comparison; the controlled two-arm experiment; the invalidation
of the subset-vs-full matrix as confounded with my own invocation
method; and the consequences --- bet 1 falsified, A5 struck, the §7/§8
remedy withdrawn in favour of a runner practice and a precondition
assertion.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 10 is approved at 4fba9f6 after aligning A3 with the D0b
contingency. The demonstrated D1/D2 mechanism may account directly for
the subset/full difference; otherwise D0b remains mandatory before the
lane closes.
Record that diagnostic-only D1/D2 are authorised but have not started.
No mechanism or fix is claimed yet.
Revision 10 retires D0b only as a precondition: a demonstrated D1/D2
mechanism may account directly for the subset/full difference, while a
mechanism that does not account for it triggers D0b before closure.
A3 still stated the old unconditional rule that D0 must recreate the
comparison in every case. Make the acceptance criterion match the
diagnostic decision: record the direct explanation when it exists;
otherwise run D0b under captured provenance and explain or explicitly
leave its result unexplained. Either path remains mandatory before the
lane can close.
Three statements survived the narrowing and contradicted it, plus one
ellipsed path in the supposedly exact command block.
- §4b's heading still read "the source hypothesis is eliminated" ---
the exact claim the section body withdraws. It now reads "the
commits do not discriminate today".
- §4a said the endpoints settle whether 7599661..724b785 contains a
regression. They do not: they settle only whether a BISECT IS
CURRENTLY JUSTIFIED. Those are different questions, and D0a's
both-uniform-red answers the first while leaving the second open.
- §4b claimed execution "under the approved contract" while the same
revision acknowledges uptime was never captured. The departure is
now stated up front, before the results rather than after them:
uptime is UNKNOWN for all ten runs, everything else held, no
classification depends on the missing field, and D1/D2's harness
must capture the full list.
- The manifest's <TD> definition still abbreviated the second target
directory as .../d0a-B inside a block labelled exact. Both paths
are written out; no ellipsis remains in it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two findings, both upheld.
1. The portable provenance was corrupted and incomplete --- worse than
the machine-local pointer it replaced, because it looked verifiable
and was not. Every log digest had lost its leading hex character
(A#1 recorded as 1c0fe47d55d8f5e... where the value is
e1c0fe47d55d8f5e): the extraction started one byte late in
`logsha=<value>`. The captured /tmp and MemAvailable columns were
dropped, and the command block used ellipsed paths. All ten digests
are corrected, both columns restored, and the command is written out
in full with only two named placeholders.
Separately: `uptime` was NEVER CAPTURED. §7's condition list names
it; the harness kept the load averages from it and discarded the
elapsed time. It is now recorded as UNKNOWN for all ten runs, with
the condition list marked as only partially satisfied rather than
implied met. The classifications stand --- none depends on uptime ---
and D1/D2's harness must capture the whole list.
2. Retiring D0b materially changes the approved diagnostic sequence,
which made D0b mandatory before every other diagnostic. The document
still claimed revision 9, approved at 15c25ec, for a decision that
approval does not contain. Promoted to revision 10 and marked
AWAITING APPROVAL; D0a's execution and result are reported under
revision 9, and D1/D2 do not begin until revision 10 is approved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
18b74d7's message said the framing was corrected on all three findings.
It was not. That script asserted its anchors and died on the second one
--- the endpoint-table rows carry a two-space indent my anchor omitted ---
and since it writes only at the end, NONE of the framing edits landed.
The manifest and ledger edits in that commit are real; the framing ones
were not, and I pushed the claim anyway.
The assertions worked exactly as intended and I ignored their verdict:
the shell chain ran `git commit` regardless of the script's exit status.
Asserting the edit is not enough if the commit does not depend on it.
Now actually applied to the framing:
- §4b: "source hypothesis is eliminated", "the interval cannot contain
the transition" and "not reachable by source" are withdrawn. What
survives is that the two commits DO NOT DISCRIMINATE UNDER CURRENT
CONDITIONS, so no bisect is justified now. A historical regression
could be masked by a later environmental effect or a source/
environment interaction; failing to discriminate is not the same as
not differing. The onset window is deprioritised, not excluded.
- §7 endpoint table: both uniform-same rows now say the commits do
not discriminate under current conditions, rather than that the
interval does not contain the transition.
- §7 D0b: retired as a precondition, with the reason recorded and the
obligation preserved under A3 --- if D1/D2 do not account for the
subset-vs-full difference, D0b runs before this lane closes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three findings, all upheld.
1. The causal conclusion overreached, in the same way this lane has
overreached before. Uniform-red at both endpoints today proves only
that the two commits DO NOT DISCRIMINATE UNDER CURRENT CONDITIONS.
"Source hypothesis eliminated", "the interval cannot contain the
transition" and "unreachable by source" are withdrawn from the
framing, the manifest and the ledger: a historical regression could
be masked by a later environmental effect, or by a source/environment
interaction under which both commits now fail. Failing to
discriminate is not the same as not differing. "No bisect is
justified under current conditions" is what survives, and the
approved endpoint table's two uniform-same rows are corrected to say
the same thing.
2. D0b was still mandatory, and going to D1/D2 would have skipped an
approved step. It is now RETIRED AS A PRECONDITION with the reason
recorded: it existed to make the reduction matrix trustworthy so the
subset-vs-full comparison could locate the mechanism indirectly,
and D0a has since produced a reliable direct reproduction that D1/D2
measure against. Re-running ten reduction rows to sharpen an
indirect instrument while a direct one is in hand is the wrong order
of work. The obligation is NOT discharged: A3 still binds, so if
D1/D2 fail to account for why every subset passed, D0b runs before
this lane closes.
3. Provenance is now portable. The exact per-run command and a
transcribed ten-row table --- start time, class, red bins, load,
freeMB, daemon count, log digest --- are committed, rather than
delegated to a machine-local results.tsv. Raw logs stay local by
design. The transcription also surfaces something the delegation hid:
the leaked-daemon count climbs 72 -> 108, four per run, monotonically
while every run classifies identically. Recorded, not implicated.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Ten runs under the approved contract: counterbalanced A B B A A B B A A
B, N = 5 per endpoint, clean detached worktrees at 7599661 and 724b785,
isolated target directories, the gate's build-crdt precondition then its
sweep-crdt command, dirty=0 verified per run. Zero voids, zero splits.
A (7599661) uniform-red. B (724b785) uniform-red. By the approved
endpoint table that is the both-endpoints-uniform-same row: the
difference is NOT captured by those two commits.
What it settles:
- No bisect of 7599661..724b785 is justified, and none will run.
7599661 passed inside sweep-crdt on 08-15 and fails 5/5 clean today,
so the interval cannot contain the transition.
- The onset window is demoted --- still a true observation, but not
reachable by source.
- A RELIABLE REPRODUCTION now exists: 10/10 today across two commits
at ~4 minutes per run. This is D0a's most useful product, because
D1/D2 no longer depend on catching a rare event.
What it does not settle: anything about the mechanism. One cheap
negative on "what else changed" --- no package activity in the window per
pacman.log, nearest on 08-18 --- and it is not pursued further, because
with a reproduction in hand direct measurement dominates archaeology.
A's three extra failing binaries are recorded rather than swept up:
a54_real_daemon_real_pty_and_headless_gpu_render..., a v21/v20 row
expected to differ at that older commit, and m6_1_pty_mode_lifecycle.
Two of the three are process/PTY-spawn rows, the same family as the
target. None affect classification, which reads only the two target
copies.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 9 is approved at 15c25ec after the portable manifest and compact
ledger summary preserve the endpoint direction required by D0a.
Record that approval durably before diagnostic implementation begins. The
mechanism remains unknown, no fix is proposed, and panel-mapping-generation
remains held until this teardown lane closes.
The portable manifest collapsed the two clean-split directions even though
the governing endpoint table permits a bisect only when 7599661 is uniform
green and 724b785 is uniform red. Preserve that direction explicitly, and
carry the same distinction in the compact active-work summary.
The inverted split remains a real difference, but it contradicts the onset
reading and therefore requires that reading to be re-examined before any
bisect.
74dbd34 corrected the framing so that "the difference is not captured"
attaches to the uniform-same endpoint verdicts rather than to mixed ---
mixed means intermittency --- but the manifest kept the wrong pairing.
The edit's anchor did not match and the script reported success anyway,
so the commit touched only active-work.md and the framing.
The manifest now defers to §7 D0a for the governing contract and states
the three verdicts with the conclusions that actually belong to them:
clean split permits the bisect, mixed means intermittency under fixed
source, both-uniform-same means the difference is not captured by those
two commits.
Process note, since this is the third silent no-op of its kind in this
lane: an unasserted string replace that misses its anchor is
indistinguishable from one that succeeded. Every edit here now asserts
the anchor before writing and re-asserts the result afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two D0a findings on revision 8, both upheld.
1. The classifier was not total. "Clean split" and "mixed" left five
outcomes unprescribed, and two of them are in the historical logs
already: 20260815T182846Z-708693 died compiling pmacs so neither
copy executed, and ...-2839374 / ...-830195 were red on unrelated
rows while both ctrl_c copies passed.
A run is now classified from THE TWO COPIES OF THE TARGET TEST and
nothing else --- green (both ok), red (both FAILED), split (copies
disagree), void (either did not execute). A sweep red only on
unrelated tests is therefore a green run, with the unrelated
failures recorded as evidence about environment stability. A split
STOPS the procedure, since two copies of one source disagreeing
within a run is its own defect. Voids are discarded and re-run on a
budget of 3, after which the environment is too unstable to classify
anything and D0a stops.
Endpoint verdicts are uniform green, uniform red, or mixed, and a
six-row table prescribes every combination: clean split permits the
bisect; an inverted split is a real difference that falsifies which
endpoint was believed good; both-uniform-green and both-uniform-red
each mean the difference is not captured by those commits; mixed at
either endpoint means intermittency under fixed source and forbids a
bisect. The manifest had attached "difference is not captured" to
the mixed case --- that conclusion belongs to the uniform-same rows,
and is moved.
2. Strict A/B/A/B does not make drift "hit both arms equally": B always
follows A and owns the final time point. Runs are now counterbalanced
AB BA AB BA AB, which removes systematic order confounding; the
residual last-slot asymmetry is accepted and stated rather than
claimed away.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Four findings on revision 7, all upheld.
1. The old one-run D0 rule survived in three durable places --- the
manifest, this branch's ledger, and the framing's own §4a --- each
still permitting a bisect when the endpoints merely "differ". That
contradicts the N = 5 clean-split contract added in revision 7. All
three now defer to that contract, and §4a's "needs only that the two
clean endpoints differ now" is marked as the superseded rule it is.
2. D0a still overstated its evidence, in three ways now fixed:
- "context-sensitive by construction, appearing only in the full
sweep" is downgraded to what has been OBSERVED so far;
- the historical 7/7 and 13/13 are stated as NOT endpoint-specific
rates --- of seven reds only F6 ran at 724b785, of the greens only
the last at 7599661, both with unknown cleanliness;
- five runs are named a PREDEFINED EVIDENTIARY THRESHOLD chosen so
the outcome cannot be argued after the fact, not something that
mathematically separates intermittency.
And the bisect now specifies its own classifier: every intermediate
commit uses the identical N = 5 protocol, and a mixed classification
ABORTS the bisect rather than being guessed, skipped, or rerun until
it agrees. A bisect with cheaper steps than its endpoints would
inherit the weakness the contract exists to remove.
3. The artifacts column is now exact per run, read from each log:
R1/R2 UNKNOWN (no log preserved), R3 -5d9105cb/-d4dae4f0, R4 and R5
-6b4b8223 only, R6 -91f51d0b/-6b4b8223. R8's citation was half2.log:1;
the executable lines are 438 and 459. The framing's last "not same
binaries" is now "not the same compilations".
4. (Held ledger, 5274d6b.) It named a stale ledger tip and two different
framing revisions on consecutive lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Five findings on revision 6, all upheld.
1. The ancestry pair supports nothing causal. Revision 6 had already
retreated to "outcome is not determined by commit alone"; that is
withdrawn too, because different commits CAN deterministically
produce different outcomes --- this document's own fix-then-regression
scenario is an example. The two observations differ in commit AND
environment AND time, so they are simply NON-COMPARABLE. The held
ledger's "no source-monotonic cause does that" goes with it.
2. D0a was not a valid decision procedure: one unspecified run per
endpoint cannot establish a regression for a failure that only
appears in the full sweep. Now specified --- N = 5 full sweep-crdt
runs per endpoint, INTERLEAVED A/B/A/B so session drift hits both
arms, identical captured conditions including uptime/free//tmp/
leaked-daemon count, and a bisect permitted ONLY on a clean split.
A mixed result means intermittency under fixed source, and no bisect
is justified at all.
3. "Neither binary contains signal-handling code" is FALSE. The pmacs
binary does: install_signal_handlers (src/daemon.rs:628) registers
SIGINT and SIGTERM; it is simply not on run_gpu's path. A grep of
project sources also cannot exclude a runtime or dependency
installing a disposition. The established fact is narrow --- no
explicit installation on run_gpu's path --- and "whatever disposition
they hold was inherited" is restored to a HYPOTHESIS that D2 must
measure.
4. Artifact wording finished: no "artifact family", "reduction/
workspace artifacts" or "different binaries" remain. Every manifest
row now carries its exact Cargo suffixes read from its log, with a
stated caveat that those logs are machine-local and this manifest is
the portable transcription of them.
5. Held ledger pointed at revision 5; it now points at revision 7.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three findings on revision 5, all upheld.
1. The ancestry argument overreached. 72da24a failing today while its
descendant 7599661 passed on 08-15 shows exactly one thing: outcome
is not determined by commit alone, since the observations come from
different environments at different times. Revision 5 said a source
cause was "positively discouraged", that the ancestry "says to
expect" equal endpoints, and that the change was environmental.
None follows. It cannot discriminate an environmental change, a
source/environment interaction, or a fix before 7599661 with a
regression before 724b785 --- and an ancestor OUTSIDE the interval
is irrelevant to whether the interval regressed, since a bisect over
7599661..724b785 needs only that the clean endpoints differ now.
D0a is unchanged as an action but is now stated as a decision
procedure with NO predicted outcome: endpoints differ -> bisect that
interval; endpoints agree -> ask what else changed across the window.
2. The byte-identity withdrawal was incomplete in both ledgers. This
branch's said the artifacts "are byte-different" and then withdrew
it two lines later, still said R9 ran "different binaries", and
still promised an "artifact family". The held ledger still said
"byte-different" and still called the window a bisect target with
revision 4's onset conclusion. Both now say "different Cargo
suffixes/compilations" throughout; historical byte identity is
UNKNOWN and is never claimed.
3. Provenance slips: R9's observation-table row listed only -6b4b8223
although it executed both -91f51d0b and -6b4b8223; R10's suffixes
are at log lines 3 and 24, not 3 and 4; R9's are at 3066 and 3087,
not 3066 alone. All corrected against the logs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Four findings on revision 4, all upheld. The third changes what the
lane should do next.
1. Section summaries still carried revision-3 language while the
manifest carried revision 4's. Framing and ledger now agree: seven
red runs (F1-F7), not five; the observation table is keyed on
compilation set rather than an invented "workspace artifact family";
and it is labelled an observation, not an isolated interaction.
2. The onset count was wrong. Per test copy across the 17 sweep-crdt
logs: 13 with both copies ok, 1 where NEITHER executed because the
stage died compiling pmacs (error[E0308]), and 3 with both failed.
Revision 4's "14 runs, 11 green, 3 red on other tests" mis-stated
both the count and the kind --- one of those runs never reached the
test. The two genuinely red-on-other-tests sweeps did execute
ctrl_c, and it passed.
3. D0a cannot be a source bisect, and the evidence argues against one.
Reflog and commit times put HEAD at 7599661 during the last green
(3c06176 landed 40s after it finished) and at 724b785 during the
first red (5174f73 landed 08:45:41, after that run ended 08:42:01;
the manifest had recorded F6 at 5174f73, which was wrong).
Cleanliness was captured at neither endpoint. And 72da24a is an
ANCESTOR of the passing 7599661 yet fails today --- no
source-monotonic cause produces that. D0a now reproduces the two
endpoints CLEAN, in isolated target directories, and a bisect is
justified only if they differ.
4. Manifest completed: R9 carries full argv rather than a recipe; R7
lists only gpu_invocation-6b4b8223, since R7 does not select
gpu_initial_target; R10 lists both -5d9105cb and -d4dae4f0.
Also withdraws "byte-different" everywhere. The bytes a historical run
executed are not knowable --- target dirs have been overwritten, and a
hash computed today is the current occupant's. Three levels are now kept
apart in the manifest: suffix (known), today's bytes at a path (known),
and the bytes a past run executed (UNKNOWN). Differing suffixes mean
differing Cargo metadata hashes, which is enough to void the comparison
and is all that is claimed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Four findings on revision 3, all upheld. Answering finding 1 turned up
something that reframes the lane.
THE ONSET. sweep-crdt appears SEVENTEEN times in this target directory's
gate logs. The ctrl_c failure appears in exactly the LAST THREE, and the
test passed --- both copies, "... ok" --- inside the stage before them.
Last green 20260815T185708Z, first red 20260816T063330Z, no reboot
between. The three earlier red sweeps failed on unrelated rows. So
"pre-existing on main" holds (F1 at 72da24a reproduces it) but "always
broken" was never established and is now contradicted. D0 gains a first
part: bisect that window. A test that passed fourteen times in this
stage and then failed three times running has a change behind it, and
that is worth more than further reduction --- which has isolated
nothing.
1. Both ledgers still carried the falsified R9 conclusions. This branch
listed --workspace unification and preceding tests as ruled out
while the section above described an interaction; said "five call
sites" immediately before correcting to six; and labelled the
framing revision 2. The held branch was worse: --workspace refuted,
R9 "same binaries", later packages not implicable, cause cumulative
across 37 binaries. All corrected and pushed (5b9abd8). §11 no
longer asserts the held lane is clean; it records a re-verified
checklist, since asserting that prematurely is what went wrong.
2. Manifest now carries complete argv for R7-R9 and F5 --- abbreviations
are not reconstructable invocations. F5 is disambiguated: the
framing cited gate ...-2144707 while the manifest cited ...-2375685,
two distinct real runs. Enumerating them gives F1-F7: the red count
is SEVEN, not five, each with its own log digest. F5 also carries an
extra failing binary the others do not.
3. "Workspace artifact family" conflated Cargo suffix with byte
identity and is withdrawn as a grouping. Demonstrated: F1 in the
main worktree executed the same suffixes -5d9105cb and -d4dae4f0,
but the bytes there are e0578039/00f06aeb versus the panel
worktree's 1b3cc86c/ede0c07d. Each run now records the suffix its
log shows and byte identity as UNKNOWN, since target dirs have been
overwritten and a hash computed today is not the hash that ran.
4. The interaction table is demoted to a description of what was
observed. Revision 3 disclaimed its inputs and then asserted a
finding from them, which cannot both hold. A3 no longer speaks of an
established "R9 paradox" --- there is none to explain, because the
comparison was never made; it requires D0 to recreate it first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Five findings on revision 2, all upheld. The first invalidates its
strongest claim.
1. R9 executed gpu_initial_target_acceptance-91f51d0b and
gpu_invocation_acceptance-6b4b8223; the failing sweeps executed
-5d9105cb and -d4dae4f0. Verified byte-different by sha256. Cargo's
target selection changes the fingerprint, so command shape changes
the executable. "Same binaries" is now "same target names and
order". What the evidence supports is an INTERACTION --- prior
targets alone green (R9), workspace artifacts alone green (R10),
both together red (F1-F5) --- so --workspace selection is not
sufficient by itself and NOT ruled out. The claim that other
packages "cannot be implicated" because their targets run after the
failure is withdrawn: later-selected packages can affect the build
graph and fingerprints before their tests ever run.
2. Both ledgers made internally consistent and portable. This branch's
asserted default-disposition death and then withdrew it further
down; the assertion is gone. panel-mapping-generation still carried
"119 binaries green one red", the >=8s arithmetic, the default-action
claim and the >6s selector --- corrected on its own branch and pushed
at 779a6bd.
3. Provenance is now a pushed document, docs/probe-sigint-evidence.md:
exact command, worktree, HEAD, cleanliness, artifact family, result
and log digest per physical run. R1 and R2 have no preserved log,
and revision 2 double-counted one log as both R2 and R6. Cleanliness
is UNKNOWN for every pre-manifest run and is not inferred. R1-R10
ran in the panel-mapping-generation worktree, not at main. D0 now
precedes every other diagnostic: re-run the matrix at main under a
harness capturing provenance AND the artifact hashes executed.
4. "The probe never blocks indefinitely" narrowed to "the event loop
wakes at least every 50ms". The stdin reader blocks in read_to_end
(:1109) and, once ready, the loop leaves only when stdin closes
(:1212), so the process is not bounded.
5. Launcher call sites: six under --features crdt (:509 :534 :544 :574
:725 :1097, inside #[cfg(feature = "crdt")] mod crdt). The other two
--gpu arguments are under #[cfg(not(...))] and compiled out.
Revision 2 said five while citing eight.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 1 rejected on five findings, all upheld.
1. The >6s selector could not have captured the failure. Both
reproducing binaries finish in ~5.19s INCLUDING the 5s timeout
(:3097, :3131), so the failing launcher lives about 5.1s. This also
falsifies my earlier retraction, which had argued the instance "must
live >=8s" --- so the "mechanism located" claim is NOT refuted by
that argument. It stays unproven for a different reason: the suite
spawns launchers from five call sites, so command line alone cannot
attribute one to this test. Key on the PID the test records.
2. Diagnostics rewritten to DISCRIMINATE blocked delivery, inherited
ignore, and an escaped process group: before-and-after snapshots for
test parent / launcher / probe, per-thread SigBlk from
/proc/<pid>/task/*/status, SigPnd/ShdPnd, and PID/PPID/PGID/SID.
Relatedly, "two processes with default disposition" is withdrawn ---
SIG_IGN is inherited across fork and survives exec, so absence of
handler code says nothing about runtime disposition, and inherited
ignore is the leading hypothesis precisely because the source is
silent. Revision 1 contradicted its own hypothesis.
3. Counts corrected: 119 green result summaries and TWO red binaries,
not "119 binaries green, one red". Reductions are now enumerated
R1-R10 and F1-F5 with command, run count and log each, preserved off
the tmpfs --- /tmp is a tmpfs and these were nearly lost mid-lane.
4. Acceptance contract corrected: A2 now requires three consecutive
green runs on the reviewed fixed head of this branch, not on main,
which is unobtainable before approval and merge; journey step 12(a)
"closing is clean" is named, since revision 1 reasoned from grade
movement which §20 warns against; and A5 is explicitly conditional
on D4, with bet 1 restated as a bet --- the witness uses a wrapper
and headless probe, not the real GUI path.
5. Portability closed: this branch now tracks
githubsucks/gpu-probe-sigint-teardown, and panel-mapping-generation
was pushed to 16cf3a2 so its retraction travels.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
`ctrl_c_on_launcher_group_does_not_reach_spawned_daemon` fails in gate
stage `sweep-crdt` with "child did not exit within 5s". It is
PRE-EXISTING on main --- 72da24a fails it in a clean worktree with its
own target dir --- so while it reds, no branch can present a green
sixteen-stage gate, main included. §5b is held behind this lane.
Framing revision 1, and it proposes NO FIX, because the mechanism is not
known. What it does instead is fix the shape of the problem so the next
attempt is not another guess:
- Ground truth, cited: neither binary handles signals. `run_gpu`
(src/main.rs:324) blocks in `command.status()` with no handler, and
grepping all of pmacs-gpu/src for signal machinery returns nothing.
The probe polls at 50ms. Two processes with default SIGINT
disposition should both die at once --- this deepens the puzzle
rather than explaining it, and the framing says so.
- Ruled out by measurement, with the method for each: load, tmpfs
(tested by experiment, not argument), leaked daemons, inotify,
--workspace feature unification, and any specific preceding test.
- The reduction paradox stated as the problem's real shape: 5/5 in
the full sweep, 0/N in every reduction, including all 37 preceding
targets plus the suite.
- One retracted claim kept as a warning, because it was mine: the
"mechanism located" report described a healthy teardown. The
sampler behind it caught 394 launchers with a 5s maximum lifetime
while the failing instance must live 8s or more.
The first step is diagnostic only: an instrument keyed on the FAILING
instance --- launchers outliving ~6s --- capturing /proc/<pid>/status
signal masks, since SigIgn survives fork and exec while handlers do not.
Acceptance criteria are written now so the fix cannot quietly become
"make the test pass": a demonstrated mechanism with a mutation-tested
witness, sweep-crdt green three consecutive times, the reduction paradox
explained or recorded as unexplained, and no deadline raised or test
skipped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Records only. No behaviour change; the focused suite stays 27/27 and
the full gate stays green.
**THE WITHDRAWN CAUSAL CLAIM WAS ASSIGNED TO THE WRONG ROUND.** The
framing credited it to round 4. It was round 3 --- whose subject line
says so plainly, "canonical ancestry, guard witnesses, and a withdrawn
claim". Round 4 was the four discriminators: it added the
canonical-traversal WITNESS (round 3 had fixed the traversal and
verified it by hand, which is the evidence that does not survive the
next edit), moved the guard rows onto the exact boundary, and covered
both managed areas on cleanup.
Rounds 1 and 2 were re-checked against their commits in the same pass,
and round 1 was also wrong: it carried ONE reserve finding, not two.
The nested-reserve ruling is round 2's. Each round is now described
from what its commit actually did.
**AND THE GATE CLAIMED A TMPFS QUOTA THAT WAS NEVER ESTABLISHED.**
`scripts/gate` said a build here "hit tmpfs quota mid-compile". Nothing
measured that, and it contradicts what was measured later: `/tmp` was
at 24G of a 30G tmpfs with 6G free --- NOT out of space. What actually
happened is worth keeping precisely because it is subtler than a quota:
24G of tmpfs is 24G of RAM, free memory fell to ~4G of 61G, process
spawning became unreliable, and eleven rows failed with EMPTY output.
That reads like a code defect. The comment records the measurement and
the symptom now, and drops the quota story.
The independent reason for a disk-backed TMPDIR is unchanged and is
still the measured one: tmpfs fixtures compete for memory.
Gates: all nine green under `env -u TMPDIR`, log 20260813T190456Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
CI went red on three Test jobs with the helper's own panic. That is the
loud failure working as designed --- and the design was wrong.
`${#x}` counting characters is a property of the SHELL first and the
locale second. `bash` counts characters under a UTF-8 locale; `dash`
counts bytes under EVERY locale, having no multibyte handling at all.
`/bin/sh` is `bash` on Arch and `dash` on the Ubuntu runners, so
probing `/bin/sh` and naming a locale established nothing there: no
pair could qualify, and the row could not run.
The helper now probes `(shell, locale)` pairs and the row invokes the
gate THROUGH the qualifying shell. `/bin/sh` is tried first so the real
interpreter is used wherever it qualifies. This is not a contrivance to
get green: `#!/bin/sh` resolves to `bash` on Arch and on macOS, which
is precisely where a `${#VAR}` guard would miscount, and it is the
configuration the guard exists for.
Renumbered, because `M-G-8` was taken. Round 3 assigned it to the
canonical-traversal mutation and the ledger never recorded it, so the
locale exercise reusing the ID was a collision. Canonical `M-G-8` is
restored to the ledger; the locale legs are `M-G-9a-c`. Nine total.
9a mutant gate, probed pair -> row fails, boundary row still passes.
Re-run with /bin/sh EXCLUDED, covering the dash/CI fallback
path -> still fails.
9b SAME mutant gate, pair forced byte-counting -> row passes.
The defect reproduced rather than argued.
9c no pair qualifies -> panic naming shells and locales tried
Record corrections review asked for:
- framing said three rounds and revisions 6a-6c; history is rounds 1-4
plus this follow-up, and each round is now named for what it fixed
- framing SS2a claimed `${#var}` counts characters under UTF-8 with no
qualifier --- the same error as the helper's. It now states the shell
dependence and why the guard measures bytes explicitly.
- the helper's prose said every candidate comes from `locale -a` while
the code also tried two hardcoded spellings; the doc comment now
describes what the code does
Gates: all nine green under `env -u TMPDIR`, log 20260813T183646Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Review found the byte-versus-character witness asserting something
adjacent to its contract. It set `LC_ALL=C.UTF-8` and assumed the
locale took effect. Locale names beyond `C` and `POSIX` are
implementation-defined, so where that one is absent the shell falls
back to byte semantics --- and then the character-counting mutant
counts bytes too, agrees with the fix, and the row passes while
proving nothing. M-G-6 was killable here and unkillable elsewhere,
which is the same as not having it.
The locale is now chosen by BEHAVIOUR. Candidates come from `locale -a`
so the set reflects what is installed, and each is probed through the
same `/bin/sh` the gate runs under, asking `${#x}` on a two-byte
character and requiring `1`. No qualifying locale is a loud panic
naming what was tried, never a skip: a skip would be indistinguishable
from a pass, which is the failure mode this replaces.
M-G-8 proves the fix in three legs, because the hazard lives in the
environment rather than the code:
8a mutant gate, probed locale -> the row fails, and the
exact-boundary row still passes
8b SAME mutant gate, locale forced to `C` -> the row passes.
The defect reproduced rather than argued.
8c no candidate can qualify -> panic naming the candidates
Also marks framing revision 6 approved and records M-G-8 in the ledger.
Gates: all nine green under `env -u TMPDIR`, log 20260813T182020Z.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Every item here is the same failure in a different place: a property
fixed or claimed, and a suite that would stay green without it.
**CANONICAL ANCESTRY WAS UNWITNESSED.** Round 3 fixed word-splitting
and lexical traversal and verified both BY HAND, which is exactly the
evidence that does not survive the next edit --- reverting to the
`for _anc in $(... dirname ...)` loop left all 26 rows green. There is
now a row driving a **space-containing root** (an unquoted expansion
tears it into fragments and the real ancestor is never tested, so the
guard passes on the path it must reject) and a **symlinked root** (a
marker visible only after `pwd -P`, which is what `detect_project`
sees). `M-G-8` restores the old loop and fails it. The traversal is
encoded in framing §2a rather than left as an implementation detail.
**THE SOCKET GUARD MISSED ITS OWN BOUNDARY.** The rows generated ~51-
and ~71-byte paths against a 55-byte cutoff, so they constrained the
guard's EXISTENCE and not its VALUE: raising the budget from 103 to 118
would have kept both green. They now hit **exactly 55 accepted and 56
rejected**, assert the measured byte lengths, and check that the
refusal reports precisely one byte over.
**REJECTION-CLEANUP CHECKED ONE AREA OF TWO.** Only `<root>/tmp` was
inspected, so leaking AMBIENT alone would have passed --- and AMBIENT
is created before the guard can measure anything, which is the whole
reason the trap moved earlier. Both areas are inspected now, the
ambient one under the derived per-worktree target whose hashed name the
test does not compute.
**THE MULTIBYTE ROW DEPENDED ON THE INHERITED LOCALE.** Under
`LC_ALL=C`, `${#var}` already counts bytes, so the character-counting
mutant passed and the row's verdict was a property of the environment
rather than of the code. It sets `LC_ALL=C.UTF-8` explicitly;
`M-G-6` now fails even when the harness itself runs under `LC_ALL=C`.
Stale test prose corrected, including one claim that was the very
inference the ancestor check exists to refute: **placement under a
managed root does not make a path marker-free**. Also, the tmp parent
is SHARED between worktrees and untouched by `--prune` (unlike the
ambient root, which is per-worktree), and the module header named
framing revision 4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
**THE ANCESTOR WALK WAS WRONG TWICE OVER.** `for _anc in $(...)`
word-splits on IFS, so a gate root containing a SPACE was torn into
fragments and the real ancestor never tested --- the check passed on
exactly the path it should reject. And `dirname` walks LEXICAL
ancestry while `detect_project` canonicalizes, so a symlinked root hid
a marker the editor plainly sees. The walk resolves with `pwd -P` first
and iterates a quoted `while`; both shapes are verified by hand
(space-containing root refused, symlinked root refused at its real
path).
**THE 103-BYTE GUARD HAD NO WITNESS AT ALL** --- every other row runs
with a short root, so the guard is silent and a broken one looked
identical. Three rows now aim at it deliberately: boundary rejection
and acceptance, a MULTIBYTE root (each `é` is one character and two
bytes, so it is rejected only if the guard measures bytes), and
**rejection must reap both created areas**, which is the leak the early
trap exists to prevent.
**The `Cargo.toml`-DIRECTORY case was claimed and not covered**, and
the consequence is exactly as review predicted: reverting only the
language-marker arm to `[ -e ]` stayed green. The marker-type row now
drives all three shapes, and `M-G-5` --- that precise revert --- fails
it.
**Prose brought level with the implementation.** The framing, the
handoff and the ledger all said 108; the supported floor is **103
usable bytes**, Darwin's 104-byte array minus its NUL. The ledger also
still said `<pid>`, the superseded 21/30 reserve, and `M-G-1`.
**And the ruling said nested gates "do not pay" the reserve, which is
false and would have licensed exempting them.** They pay it in full;
the short layout merely gives them the headroom to satisfy an unchanged
production guard. Reworded, because the wrong version is the one a
future reader would act on.
**THE btrfs CAUSAL CLAIM IS WITHDRAWN.** The draft argued that a
one-second deadline plus a slower filesystem was a plausible new
mechanism for the fourth `managed_retry` occurrence. It does not
survive inspection: the deadline bounds the connection RETRY loop, not
the socketpair handshake that returned `BrokenPipe`, and the filesystem
work happens before it is armed --- the tempdir is created and never
bound. The environmental change is still recorded, as a CHANGE rather
than a mechanism, so a later occurrence can compare like with like.
Recording a mechanism the code does not support is worse than
recording none: the next occurrence gets measured against a story
instead of the evidence. TMPDIR stays disk-backed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
**108 IS LINUX'S NUMBER, NOT THE FLOOR.** Darwin's `sun_path` is 104
(xnu `bsd/sys/un.h`) and pmacs supports macOS --- CI runs a
`macos-latest` leg --- so a Linux-derived limit passes on the machine
that writes it and bind-fails on the other. **The usable PATH length is
one less than the array**, because the stored value is NUL-terminated:
103 on Darwin, 107 on Linux. The script takes **103**, and the
diagnostic says which platform's floor it is quoting.
**THE NESTED CASE IS NOW RULED, NOT ACCOMMODATED BY LOOSENING THE
GUARD.** The reserve exists for fixtures that bind sockets under
TMPDIR; this script's own behaviour suite runs nested gates whose plans
are synthetic and bind nothing, so charging them the fixture reserve
rejects a configuration that cannot suffer the failure it guards
against. Exempting nested runs was rejected --- it makes the guard
untestable in the very configuration the tests exercise, and "this run
is nested" is not reliably knowable. **The suite roots its gates at a
short base instead**, so a nested TMPDIR is ~24 bytes rather than ~71
and clears the real reserve. Recorded in revision 6 with the rejected
alternative, and with the obligation that a future row which DOES bind
a socket must move off that base and take the reserve with it.
**MIRRORING THE MARKER NAMES WAS NOT ENOUGH; THE TYPES ARE PART OF THE
CONTRACT.** `match_marker` requires `.git` to be a DIRECTORY and the
seven language markers to be FILES, so `[ -e ]` rejected ancestors
project detection walks straight past. The case is not exotic: **a git
WORKTREE has a `.git` FILE**, so every worktree in this repository
would have tripped the guard. It tests `[ -d ]` for `.git` and `[ -f ]`
for the rest, with a witness covering all three shapes --- `.git` file
accepted, `.git` directory refused, `Cargo.toml` directory accepted.
That witness keys on WHICH marker the gate named rather than on whether
a refusal happened, because the ancestors of any base a test can create
are outside its control; "no refusal" is not a claim it can make
anywhere, while "the refusal did not name MY file" is. `M-G-4` reverts
the guard to existence-only and the row fails.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
**The gate's own run reproduced a REGISTERED signature**, and it is
recorded as a fourth occurrence rather than waved through: same
selector, same `gpu`-step flavor, all three required fragments verified
against the durable log. Three isolated re-runs were green, which this
file's rule says establishes intermittence only.
**This lane is code-neutral for `pmacs-gpu` but NOT
environment-neutral**, and that distinction is the entry's point.
Occurrence 3 excluded "the added GPU test is the mechanism"; this
occurrence adds nothing to that binary at all, which corroborates the
exclusion independently. But the lane moves `TMPDIR` off `/tmp`, taking
every `tempfile::tempdir()` in the run from **tmpfs to btrfs** --- and
the failing test runs a handshake against a **one-second deadline**. A
slower filesystem under a timing-bounded test is a plausible mechanism
that did not exist in occurrences 1-3. Booking this as "the usual
flake" when the observing lane changed the conditions the flake is
sensitive to is exactly the reasoning this registry exists to prevent.
Also: the suite's own roots move to a short base. Rooting them under
the ambient `TMPDIR` put a NESTED gate's TMPDIR near 70 bytes, which
legitimately tripped its own SUN_LEN guard --- the suite failing on a
configuration it created rather than on the behaviour under test. And
the marker row's `.then(..).unwrap_or_else(..)` chain is gone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
**THE PROPAGATION WITNESS DID NOT OBSERVE INHERITANCE.** The runner's
`eval` expanded `$TMPDIR` in the PARENT before `sh -c` ever started, so
the child received an already-substituted literal --- and an unexported
`TMPDIR=` would have passed the row unchanged. Single-quoted inside
`sh -c` now, so the CHILD expands it. **M-G-1b keeps the assignment and
removes only `export`: the row fails.** That is the mutation the
previous version could not catch, and the reason to prefer it over
M-G-1's blunter deletion.
**THE RESERVE WAS NOT THE MAXIMUM.**
`/.tmpXXXXXX/directory-target.sock` is 33 bytes
(`tests/gpu_invocation_acceptance.rs`), so paths of 76-78 passed the
30-byte guard and still blew the 108-byte limit during the CRDT sweep.
Reserve is 48 now --- the measured maximum plus ~45% headroom. And the
length is counted in BYTES: `${#var}` counts CHARACTERS under a UTF-8
locale while `sun_path` is byte-limited, so a multibyte path measured
short and passed a check it should fail.
**A MANAGED ROOT IS NOT INHERENTLY MARKER-FREE**, and assuming it was
rebuilt the original defect one directory up: a `.git` in `$HOME`, a
marker above `$HOME/build`, or a contaminated
`PMACS_GATE_TARGET_ROOT`. Placement under a directory the gate owns is
NECESSARY, NOT SUFFICIENT, and the old test proved only placement. The
gate now walks the ancestors and refuses, naming the marker it found.
`PMACS_GATE_ALLOW_ANCESTOR_MARKER` is the documented test-only escape,
beside `PMACS_GATE_TARGET_ROOT` in kind and risk: the behaviour tests
run under a tempdir whose ancestors they do not control, on a machine
whose `/tmp` carries this very marker, and their plans are synthetic so
no markerless fixture exists to re-root. **The check is witnessed by a
row that deliberately does not set it**, and M-G-3 (check removed)
fails that row.
**The guard leaked what it exists to manage.** It created both
temporary areas and exited before the trap was armed, so every
rejection left an AMBIENT and a TMPDIR behind. The trap is installed
first now; verified by rejecting a run and finding neither.
**`tmp/$$` with `mkdir -p` was not fresh.** PIDs are reused, so after a
SIGKILL it silently ADOPTS a leftover directory and the run inherits
another run's fixtures. `mktemp -d` fails rather than reuses.
**Prose corrected to match.** The handoff described
`<target>/gate-tmp/<stamp>-<pid>`; the implementation uses
`<gate-root>/tmp/<mktemp>`. Comments called the shared parent
per-worktree and pruned --- it is neither: `--prune` only considers
directories carrying an ownership marker, so the parent is skipped and
each run removes its own leaf.
**AND THE LANE CLAIMED A FRAMING EXCEPTION THAT DOES NOT EXIST.**
`AGENTS.md` says framing -> approval -> branch -> implement,
unconditionally; "the fix was already recorded as standing" is not an
exemption it grants. `docs/gate-script-framing.md` is amended as
**revision 6, AWAITING APPROVAL** --- a widening of §2's existing
isolation responsibility rather than a new feature, which is why it
amends that document instead of opening another. **This PR must not
merge before that revision is approved.**
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Discharges the standing fix recorded in `docs/agent-handoff.md` §1 and
assigned to this lane. Every gate invocation now gets a fresh,
disk-backed `TMPDIR` at `<gate-root>/tmp/<pid>`, exported once so every
stage and every process they spawn inherits it, reaped by the same exit
trap as the ambient root. **A gate run no longer needs a `TMPDIR=`
override.**
**A CHILD OF `/tmp` WOULD NOT HAVE WORKED**, which is why the obvious
cheaper fix was not taken. The hazard is an ANCESTOR marker: project
detection walks upward, so a fresh subdirectory of `/tmp` inherits
`/tmp`'s ancestors and the same stray `.git`. The directory had to move
somewhere the gate already owns.
**`SUN_LEN` shaped the layout, and the fix's own gate run is what found
it.** A Unix socket path cannot exceed 108 bytes, and the suites bind
sockets INSIDE `TMPDIR`. The first placement --- `$TARGET/gate-tmp/$STAMP-$$`
--- produced a 114-byte socket path and failed SIX daemon and attach
tests with "path must be shorter than SUN_LEN". It hangs off the gate
root (36 bytes) rather than the per-worktree target (60) now, with a
short name: 47 bytes, leaving 61 for fixtures. Running the real gate
rather than only the witnesses is what caught this.
**A startup guard turns that failure class into a named one.** Six
socket failures deep in a suite name a LIMIT, not a CAUSE; the guard
fails immediately with the path, its length, and what to shorten.
**Its reserve is measured, not round, and the first value was wrong in
the more embarrassing direction.** The longest suffix a fixture appends
is `/.tmpXXXXXXX/test.sock`, 21 bytes, so 30 leaves ~40% headroom. An
earlier "generous" 45 FIRED ON THE GATE'S OWN BEHAVIOUR TESTS: they run
the gate inside the gate, so their root sits under the outer run's
TMPDIR and the nested path reaches 71 bytes. A guard that rejects a
legitimate configuration is worse than the failure it prevents, because
it fires on every run instead of a rare one. Verified both directions:
still catches an 87-byte root, silent on the real one and on the nested
tests.
**Two witnesses, each mutation-checked.** `M-G-1` removes the export ->
the propagation row alone; `M-G-2` stops the reaping -> the cleanup row
alone. Propagation is observed in a SPAWNED CHILD --- the self-test's
first step reports its own `$TMPDIR` into its log --- because asserting
the variable inside the script would only prove the script can set a
variable. The cleanup row runs against the self-test, which FAILS on
purpose, so it also pins that the trap fires on the failure path, which
is the path a leak would actually happen on.
One witness of mine needed correcting twice, both times because it
asserted something adjacent to the contract: first `!starts_with("/tmp/")`,
which tested where the FIXTURE put its root and failed on correct code;
then `contains("/gate-tmp/")`, stale after the directory was shortened.
It now asserts the exact parent, `<root>/tmp`.
**Proved against the live hazard:** `/tmp/.git` is still present on this
machine, and `m4_24_bare_string_glob_stays_relative` --- one of the two
tests it reddened --- passes with no override.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Sixteen gates green with --protocol, under an isolated TMPDIR.
The crdt-gated wire suite is verified to have RUN --- 2 tests in the
crdt sweep, 0 in the default one --- rather than assumed, because a
suite that compiles to nothing reports ok and that is the shape this
project has been caught by before.
The mutation inventory names which row each one fails, including
M-1a-6: a mutation that targeted the wrong side of the append boundary
and so reported a sound pin as vacuous.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Docs only, and the first commit on the 1a branch. **No ruling changes.**
**1a needs no framing of its own** ---
`docs/gui-stage1-input-framing.md` already governs every Stage 1 slice,
and A1-A9, the eight Q#S1-9 precedence rules, §8's wire contract and
§11's gates are ruled there. What 1a does need is §2 to be TRUE, and it
was measured at `a994f37`, before 1-pre moved almost every GPU-side
coordinate in it. A framing whose ground truth points at the wrong lines
is how an implementation ends up arguing with the tree.
Re-measured at `4f77491`, and split by kind rather than renumbered
wholesale, because the two are not the same claim:
STILL TRUE `FrontendEvent`'s sixteen variants, `PROTOCOL_VERSION =
23`, IME's zero occurrences, the TUI wheel arms (1-pre
touched only `pmacs-gpu`), the handshake preceding the
window, and `Outbox::enqueue`'s closed-return.
MOVED `window_event` `:2734`/655 lines -> `:4450`/FOUR lines;
`translate_key` `:10975` -> `:12053`; "eight arms, rest
fall to `_`" -> three family decision functions over nine
variants. **1a edits `apply_keyboard` and
`translate_key`, not `window_event`.**
**TWO CLAIMS WERE WRONG AT BOTH ANCHORS, so they are corrections rather
than drift.**
**"`KeyEvent.text` is never read" is false, and was false at `a994f37`
too** (`:2800` there, `main.rs:3251` now): the AltGr rule reads it via
`is_layout_text(key.text.as_deref(), pmods)`. The true claim is
narrower and is the one that matters --- **`text` is never read as the
text a keypress INSERTS**, only as a discriminator separating AltGr from
a command chord.
That is load-bearing for A5 rather than cosmetic. §5's rule 2 already
exempts "printable Ctrl+Alt recognized by the existing AltGr rule", so
the precedence table depends on code the section claimed did not exist.
**1a widens `text` from discriminator to payload, and that is the actual
change of kind** --- which "text is never read" hid, along with the one
place the new payload must leave undisturbed.
**A4's exit site moved without its behaviour changing.** 1-pre routed
the idle-Escape quit through `EventOutcome`, so **A4 edits a branch and
a return type in `apply_keyboard` (`main.rs:3219`) and does not touch
`window_event`**, which holds the crate's only executable
`event_loop.exit()` (`main.rs:4452`). And **`EventOutcome` survives
A4**: a native close still returns `Exit`.
The lane records the v24 serialization constraint and the bump's blast
radius up front --- eight version-sensitive failures across six suites
on the last bump, of which CI showed one, because cargo stops at the
first failing target --- together with the rule for sorting them and the
pin that must never fire, `ADVERTISED_PROTOCOL_VERSION == 20`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The lane recorded this PR while it was under review, because an open PR
without a lane is the #171 defect: it drifted 153 commits while
invisible in the ledger. Review is done, so the lane goes.
**It had to go in a commit rather than "at merge".** GitHub merges the
tree as it stands, so leaving it would have landed the words *PR #238
OPEN* on `main` --- a lane advertising an open PR that closed in the
same commit, which is the exact staleness class this absorption exists
to clear.
Rule 4 takes it **outright** rather than rewriting it: a lane is
rewritten when its ARC survives its PR, and this one describes a docs
pass with nothing left behind it. Every reference to #238 and to the
`docs-absorb-237` branch lived inside the lane, so the deletion is
self-contained and leaves no dangling pointer.
What the lane recorded that outlives it is already elsewhere: the
recovery rehearsal and its floor checks are in "Repository authority",
and the GUI arc's state is in the Stage 1 lane and the handoff anchor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
**The absorption was incomplete, and the two holes were Stage 0's.**
`docs/agent-handoff.md` §6 still called Stage 0 "READY FOR PR (not yet
opened)" and the ledger's Stage 0 lane still handed out branch-recovery
instructions and called itself pre-PR --- for work that merged as #236.
A merged lane that still says "checkout the branch" sends a reader to a
tip that no longer moves. Both rewritten; the recovery lines are removed
rather than updated, because there is nothing left to recover.
**A LANE CANNOT REMOVE ITSELF AT MERGE, and saying so was wrong in a way
that would have shipped.** GitHub merges the tree as it stands, so
"removed at merge" would have landed the words *PR #238 OPEN* on `main`
--- a lane advertising an open PR that closed in the same commit. It
stays while the PR is under review, because an open PR without a lane is
the #171 defect, and **a final pre-merge commit on this branch takes it
out**. That obligation is now written into the lane itself.
**Q#GA5 was recorded backwards.** The P2 row said P2 was "gated by the
GUI arc reaching Stage 4b". The ruling is the reverse: **P2 is blocked
by nothing and may start now**; when the arc reaches Stage 4b, P2 must
already have started, and **no later GUI stage begins** until it has an
approved framing and an opened lane. The gate is on STARTING P2, not on
finishing it, and it binds the GUI arc rather than P2. Corrected in both
the P2 row and the GUI row, which had inherited the same inversion.
**`9a26ac8` was the previous last-EXERCISED anchor, not the previous
declared FLOOR** --- that was `e67ad07`, and the two had drifted apart.
Checking the exercised anchor in the floor's place verifies the wrong
claim, so the check is re-run and re-stated against `e67ad07` and
`d038f71`; `9a26ac8` is retained only under its own correct label.
**1-pre did not ADD the idle-Escape local quit.** The docs said "no
behaviour change" and then called the Escape quit a "1-pre change" and
"the one thing 1-pre added" --- which contradict each other and the
diff. It is **pre-existing behaviour that 1-pre preserved and isolated**
behind an `EventOutcome` return; **1a removes it**. Fixed in both files.
**§1a called the board current at `d038f71` while most of it dates from
2026-08-01**, and P5 still described #217 as a held PR although it had
merged. The board is now labelled **MIXED-ANCHOR and explicitly not
current as a whole**, with the drift named as evidence and a pointer to
`git log --first-parent`; the P5 row is corrected. Refreshing the rest
is a separate pass, deliberately not folded into a GUI absorption.
**The exact-head accounting was wrong --- one commit and 34 lines, when
it was two and 38 --- and the fix is to stop counting.** A count goes
stale on the very next commit, including the one carrying the fix, which
is how it broke in the first place. Both the lane and the PR body now
state the standing property instead: every commit after the gated tree
is markdown-only, checkable with `git diff --name-only 502308d..HEAD`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
This file's standing rule is 'when a PR is opened, give it a lane', and
the correction behind that rule --- #171 drifted 153 commits while
invisible here --- applies to a docs PR as much as a code one. Written
with the branch's own commit rather than after the fact, which is also
what keeps a lane from re-conflicting on every other merge.
Records the eight-stage gate result, states the docs-only scope as
something verified with `git diff --name-only` rather than intended,
and notes that the lane is REMOVED at merge: it describes a docs pass,
not an arc, so rule 4 takes it outright instead of rewriting it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Docs only. No `src/`, no `pmacs-gpu/`, no 1a implementation.
**The recovery procedure was RE-RUN, not SHA-swapped, and that is what
licenses the rest of this commit.** Every documented step, from an empty
directory, on git 2.55.0: clone the canonical URL (which names it
`origin`, and `git remote get-url githubsucks` errors with `No such
remote`, exactly as the section anticipates); add the alias; fetch;
`git log -1 --oneline githubsucks/main` -> `d038f71`; confirm BOTH the
old floor `9a26ac8` and the new `d038f71` are ancestors, so advancing
the floor is valid rather than merely plausible; recover with the
three-argument `git worktree add <path> -b <local> githubsucks/<branch>`
form and confirm the upstream is actually set. The documented TRAP was
reproduced too: the two-argument form succeeds and leaves
`## HEAD (no branch)`, so that correction still holds on 2.55.0.
**This discharges a debt rather than inheriting one.** The previous
absorption advanced the base to `e67ad07` WITHOUT re-running the
procedure and recorded that as an outstanding obligation. It is settled
here, by the run above.
Canonical base, recovery floor, the `git log` threshold and the
last-exercised record all move to `d038f71` together --- a floor that
accepts an older commit than the base it declares passes on a tree the
rest of the file does not describe.
**The GUI lane is REWRITTEN, not removed.** Rule 4 removes a lane when
its ARC is done; the arc is Stage 1 as a whole and **five slices
remain**. The lane now records 1-pre as merged, names 1a as next and
NOT STARTED, and keeps the fact that 1a (v24 `TextInput`) and 1e (v25
`OpenTarget`) are the two protocol-bearing slices and are serialized.
Open-PR and branch-recovery wording for 1-pre is gone --- a lane that
still says "recover with `git checkout`" for a merged branch is how a
reader ends up on a stale tip.
The handoff anchor absorbs both merges, and §1 gains the arc bullet the
anchor promises. Its durable facts are the ones that will bind future
slices rather than the diff: a route carries the DECISION and only the
body gives the EFFECT; a harness that re-implements what it tests
witnesses its own copy; winit's `KeyEvent` is non-constructible outside
winit and this will bind every GUI input slice; the sentinel is the
success condition and the timeout only an error ceiling; four test
defects that were all one shape --- witnessing an absence the harness
had manufactured; and `cargo metadata`, not intuition, decides which CI
job runs a member's unit tests.
**One judgement beyond the stated scope, flagged rather than slipped
in.** §1a's board had no GUI-arc row at all, which would have
contradicted the anchor two sections above it. A row is added at the
position `COHERENCE.md` §20 Q#GA5 gives it --- after Priority 1, running
alongside P2-P5, interacting only at the P2 start gate --- and the P2
row now names that gate. The section's own dateline is corrected in the
same breath: the table was written 2026-08-01 and claimed zero open PRs,
so it now says which row is current and which are as-of that date.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
M24 makes the total 24 mutations, not 23. Stated as M1-M24 with the
split named --- twenty-three fail their own rows, and M6 is the P3
exception check, which must STAY GREEN. Writing it as a bare total was
what let the count drift twice: an exception check and a failing
mutation are both 'mutations' in the ledger's usual sense, so the
sentence has to say which is which.
'Gate passes on the final tree' contradicted the very next sentence,
which records that prose and doc comments changed after the run. It now
says final EXECUTABLE tree and explains why the distinction is drawn ---
'the gate was green' and 'the gate was green on exactly this tree' are
different claims, and only the weaker one is true here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two review findings, one of them a real defect.
**THE SENTINEL READ COULD HANG FOREVER.** `read_until_sentinel` blocked
with no bound, so a writer or encoder that regressed after `enqueue`
would WEDGE THE GATE rather than redden it --- and a hang is the worst
failure shape there is, because it looks like slowness until the job is
killed. A 30 s `READ_CEILING` is armed on the daemon socket.
The distinction is kept explicit in the code, because collapsing it is
how this fix would undo the design it protects: **the sentinel remains
the success condition and the ceiling is only an error ceiling.**
Arrival is still decided by the sentinel, so the harness never infers
"nothing was sent" from a duration --- the core-count assumption behind
PR #235's CI red is not reintroduced. The ceiling sits far above any
plausible drain, so reaching it means broken, never busy.
M24 proves it fires rather than trusting it: drop the sentinel enqueue
entirely and the row fails in under a second with a diagnostic naming
both candidate causes and the partial transcript, instead of hanging.
**THE STAGE 1a CONSEQUENCE WAS WRONG IN FOUR PLACES.** Every record
claimed A4 would leave `EventOutcome` with one variant, so the type
should go with the Escape branch. It will not, and it should not.
`LifecycleRoute::Exit` --- a native window close --- returns
`EventOutcome::Exit` too. A4 removes the KEYBOARD producer only, leaving
one `Exit` producer.
And **one producer is not one variant**: the type survives because
`dispatch_window_event` must still distinguish `Continue` from `Exit` on
every event it handles --- nearly all must not exit, and the close must.
What A4 actually changes is `apply_keyboard`'s signature. Corrected in
the `EventOutcome` doc, the Escape-branch comment, the framing and the
ledger; the framing's superseded paragraph is deleted rather than
patched, since it also carried the stale "two `event_loop.exit()`
call sites" count. **There is exactly one executable
`event_loop.exit()`**, in `window_event`.
Also: the sentinel-tag comment claimed four modifier bits and used
three. It now says three, wrapping every eight steps, and why that
suffices --- each sentinel is read before the next is issued, so a tag
only has to differ from its immediate predecessor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Checked with `cargo metadata`, not assumed: `workspace_default_members`
is the root `pmacs` package alone, so the `test` matrix and
`crdt-test` --- both bare `cargo test --all-targets` --- never compile
pmacs-gpu's unit tests. Only `gpu-render` runs them, and it installs
lavapipe, proves the adapter with vulkaninfo, and sets
PMACS_REQUIRE_GPU=1.
That matters because the harness's adapter assert is UNCONDITIONAL
rather than env-gated: it cannot be turned into a quiet ok anywhere, and
a future job that runs -p pmacs-gpu without an adapter fails loudly
instead of silently covering nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 10 argued a route-classification transcript satisfied P2
because a route 'names its local effect'. The wheel falsifies it: a
wheel route carries a delta, and whether that becomes a viewport
update, a panel event, a terminal event or nothing at all depends on
State. The route names the family; only running the body names the
effect. Retracted rather than quietly amended, since it was an argument
this document made and review overturned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
None changes a decision; all four were claims a reader would check and
find false.
**The durable diagnosis command did not run the pair it claimed.**
`m4_24_` is a PREFIX matching **18** tests, so the recorded invocation
would report roughly 16/2 contaminated and 18/0 clean --- not the 0/2
and 2/2 beside it. A reader following it would see a mostly-green run
and conclude the hazard was mis-diagnosed. Replaced with **four literal
`--exact` invocations, one test each**, every one of them executed
before being written down: `running 1 test`, `171 filtered out`,
contaminated `0 passed; 1 failed` panicking at `:5668:5` and `:6615:5`,
clean `1 passed; 0 failed` with no panic. The block now also says to
read the `running N tests` line, pointing at the libtest-filter bullet
two entries below --- which is the trap that produced this defect in the
first place.
**"The diff touches only `pmacs-gpu/src/main.rs`" -> "the whole
EXECUTABLE diff".** The branch changes six files, five under `docs/`.
The structural argument was always about linkage, not file count, but as
written it was simply false and the first `git diff --name-only` would
say so. Fixed in both the ledger and the handoff.
**"a headless test can drive every family"** contradicted the keyboard
exception three paragraphs below it. Now says every family whose event
winit lets a test construct --- all of them except keyboard --- and
points at `route_keyboard` for how far that reaches.
**`[KeyboardRoute::Press]` names a type that does not exist.** It was
renamed to `KeyAction` when the payload moved onto `Route::Keyboard`,
and this doc link was left behind pointing at nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
An open PR gets its number in the ledger at the moment it opens, per the
standing correction from #171 and #215 --- #171 drifted 153 commits while
invisible here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The `/tmp/.git` diagnosis, finished properly.
**Compared on SIGNATURE, not test name**, which is what the ledger's own
CI-triage rule requires. The contaminated leg panics at
`m4_acceptance.rs:5668:5` and `:6615:5` with `.received = ""` ---
byte-identical to the gate red's own signature --- and the clean leg has
ZERO panics. Same binary, same commit, one variable.
**All nine gates pass under an isolated `TMPDIR`**: m4 168/0/3 by the
mandated command, and the 117-target `--workspace --no-fail-fast` sweep
with zero failures anywhere, `m4_acceptance` running all 171 inside it.
**The marker is left in place.** It is foreign, isolating is sufficient,
and deleting it is not this lane's call. Recorded with the constraint
that matters: the isolated `TMPDIR` must be outside `/tmp` AND outside
every git worktree, because a child of `/tmp` is not isolated ---
`/tmp/.git` is still its ancestor.
**One hazard this cost a round, worth the bullet it gets.** A libtest
filter that matches nothing prints `0 passed; 0 failed; N filtered out`
and exits ZERO. This shell is zsh, which does not word-split unquoted
parameter expansions, so `NAMES="a b"; cargo test -- $NAMES` passes one
argument, matches no test, and reports green. The contaminated leg
"passed" that way and briefly looked like the hypothesis collapsing.
The fix is to read the `running N tests` line, which is the only place
a filter's actual reach is stated --- the same family as the
`feature-census` trap already recorded two bullets above, and the same
lesson as "a probe must fail loudly".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three documents, one finding each.
**`docs/gui-stage1-input-framing.md` -> revision 10.** Revision 9 is the
approved design and revision 10 changes none of it. It records ONE scope
correction that could not be seen from the design: P1 has a second
structural exception, for the keyboard family alone, and it is winit's
rather than this seam's. `KeyEvent` carries a `pub(crate)
platform_specific` field, so no `WindowEvent::KeyboardInput` can be
constructed outside winit. Bounded three ways rather than accepted
whole --- it does not reach the pointer families (`DeviceId::dummy()`
exists for exactly this, checked BEFORE writing the exception down), the
family's only decision is factored into `route_key_action` and witnessed
directly, and what stays uncovered is one pattern arm with no logic.
Also records that P3 is now MEASURED: deleting the whole delegation
leaves all 256 `pmacs-gpu` tests green, not merely the 13 new rows.
**`docs/active-work.md`** --- the lane moves to IMPLEMENTED with the
four commits, the shape, the verbatim-move method, and the gate result.
**`docs/agent-handoff.md`** --- the stray-marker hazard gains what this
run earned: `scripts/gate` DOES NOT ISOLATE `TMPDIR`. It isolates the
target directory and five ambient roots, so `tempfile::tempdir()` still
lands under whatever `/tmp` happens to contain, and the hazard therefore
reproduces INSIDE a gate run --- which is how it surfaced here, on a
lane that touches only `pmacs-gpu/src/main.rs`. The bullet now carries
the discriminating command pair (`TMPDIR=/tmp` 0/2 versus a marker-free
root 2/2) rather than only the narrative, because a rerun establishes
nothing about this and the pair establishes everything. Isolating
`TMPDIR` is assigned to the gate lane, not to whichever feature PR trips
over it next.
One code change rides along: `EventOutcome`'s doc comment said
`event_loop.exit()` is called in "exactly one place", which is true of
the function and false of the call sites --- there are two, both inside
`window_event`. Stated precisely now, since the whole point of the
sentence is that a reader can check it by grep.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The obligation this PR owes, discharged before any code lands so the
scope Stage 1 is implementing is the scope both records describe.
Meta/Super forwarding was mapped to Stage 1a. Forwarding it there would
turn platform Command/Super shortcuts into daemon Meta chords BEFORE
capability-aware and local-binding policy exists --- so the OS
reservation currently in the tree is a deliberate, tested decision
rather than an omission, and Stage 1 keeps it.
Both records are amended, not one. The arc's §2.5 mapping table and the
standing backlog's input bullet each claimed Stage 1a, and a mapping
that lives in two files drifts unless both move together --- which is
the failure class the Stage 0 lane spent seven review rounds retiring.
The same row also recorded command/minibuffer chord forwarding as
outstanding when `bc32332` shipped it. Marked shipped rather than left
to imply work that does not exist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The framing and the lane are this branch's FIRST commit, which is the
arc's §5 rule for every PR in it and the reason this branch exists
before any code: revision 9 was approved as an untracked file, and an
approved framing that lives in one worktree is not portable.
Revision 9 landed after EIGHT rejected revisions. The through-line of
those rounds is worth carrying: each early draft turned a fresh source
audit into SCOPE LABELS --- "DroppedFile", "translate_key completion",
"no behaviour change" --- and review kept asking the same question,
which is what the label means when someone has to test it. Revision 9 is
a contract/witness/mutation matrix over every numbered clause, split
into CHANGE clauses that fail today and PRESERVATION clauses that pass
and must keep passing.
Several findings only existed because the contracts were written down.
"Send Detach before exit" was unexecutable against an outbox whose
`enqueue` rejects once closed. A one-slot terminal reservation
contradicted the FocusLost-before-Detach ordering two sections above it.
"Terminal result after the commit resolves" was not total over a
pipeline with three legitimate exits that never commit --- a claimed
listener, a cleared handler slot, and the default handler's `open_async`
returning immediately. None of those are visible from a scope label.
This branch is 1-pre ALONE: the input seam, no behaviour change. Its
evidence is a headless routing harness recording routing decisions,
outbound events AND local effects, with production `window_event` as a
thin call-through. P3 is recorded as an accepted structural exception:
a headless test cannot construct `ActiveEventLoop`, so the delegation
itself is a code-review invariant rather than a tested one, and saying
so is better than a mutation that cannot exist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The governing pre-PR gates apply to documentation-only branches too.
Replace the reduced fmt-and-diff declaration with the complete suite,
while recording that there is no touched acceptance suite for this lane.
The recovery authority contradicted itself in the direction that
matters: the floor said `9a26ac8` while the operative check said
`e67ad07`, so the stated floor would have ACCEPTED a tree missing
everything since 2026-08-08. Floor and check are now both `e67ad07`.
The exercise claim is corrected rather than quietly inherited. That
paragraph argued its own value --- advancing the base is exactly when
the procedure must be re-run --- and then presented a 2026-08-08 run at
`9a26ac8` as if it covered today's base. It is now marked as the LAST
exercise, with the advance to `e67ad07` recorded as an OUTSTANDING
obligation. What is unverified is the procedure against the new base,
not the SHA.
The grading rule was not total. `Weak` required a non-empty blocker list
and `Partial` named blockers, which left a real state ungraded:
criterion 1 passing, blockers empty, criterion 3 failing or unassessed.
The rule now turns on criterion 1 alone --- pass is `Partial`, fail is
`Weak`, all-pass is `Strong` --- so every usable state is covered by
exactly one grade. Criterion 1 is the right discriminator because it is
the only one measuring the GPU AGAINST THE TUI; the others measure it
against its own goals. Today's grade is unchanged and now derives.
The listview counts were wrong because I used `grep -c`, which counts
comment mentions. Four executable calls in `lsp.lua`, one in `git.lua`
--- not five and four. The claim those numbers support is untouched:
listview is no longer LSP-only.
Two status claims corrected: the lane understated its own commits (15,
actually 16), now stated AS OF a SHA so it cannot rot on the next
commit; and the handoff said "Stage 0 in PR" when no PR exists ---
"ready for PR (not yet opened)".
The inference ruling is recorded where the flags live: they do not block
this docs PR, they must be closed before the table is first enforced as
a gate, 3(c) and 9 can change the deficit set, and 6(c) cannot change
step 6 today but still owes evidentiary closure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
P1, and the worst of them: the AUTHORITY BLOCK was stale in four ways
while this lane's whole purpose was retiring stale ledger state. The
canonical base said `122b8e8` (actual: `e67ad07`), protocol said
`v6..=v22` (actual: v23, #228), the recovery threshold accepted
`9a26ac8` --- far older than the base above it, so the check it defines
would pass on a tree missing everything since --- and this lane's own
entry named base `0e4c58d` and declared itself PARKED beneath a heading
saying ready-for-PR. A ledger that contradicts itself defeats its own
cross-machine purpose. All four corrected; the park bullet is replaced
by what actually happened.
"Exactly two journey deficits" was stronger than the evidence permits,
and the table said so three paragraphs below itself: GPU 3(c) and 9 are
INFERRED, so a third failure cannot be ruled out. Now "known failures at
two steps; exact set pending verification". GPU 6(c) is inferred too and
is noted as unable to change step 6, which 6(e) already floors.
The product subgrade had criteria but no GRADING RULE --- three closure
conditions distinguish closed from not-closed, which does not derive
`Weak` rather than `Partial` or `Missing`. A rule is now stated, and the
distinction it turns on is worth having: `Partial` would mean the GPU is
merely unfinished; `Weak` means it is BEHIND a frontend shipping in the
same binary. Criterion 3 is marked NOT ASSESSED --- §3.2's register is
seeded empty --- rather than being quietly counted as a pass.
The framing REQUIRED a handoff §6 cross-reference and there was none;
only the Lean 4 numbering note existed. Added, carrying the facts a
cross-machine reader needs first: the product subgrade, the P2 start
gate, and that "Arc 8" means Lean 4.
Three more scorecard-versus-ground-truth drifts, the same class this
lane exists to close: row 14 said listview has 4 call sites "all LSP
panels" (it has 5 in `lsp.lua` and 4 in `git.lua` since #227, so it is
no longer LSP-only); row 15 said "no git integration at all" while §15
records status and diff; and §9's plane table said no builtin opens
`*lsp*`, though `M-x lsp.status` does (`lsp.lua:3533`) --- it has no
BINDING, which is the distinction this document now draws everywhere
else.
Finally, §20 physically placed the arc after Priority 5 while its prose
said after Priority 1. In a *Recommended Priority Order* position is the
schedule, so the block moves to sit directly after P1, and now states
its interleaving with P2-P5 explicitly rather than leaving it to
position alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The three remaining Stage 0 items, and the first is the one that
justifies the arc existing.
§16 now carries TWO subgrades. Architectural stays Strong; Product is
Weak. The single grade was true and was answering the wrong question ---
the protocol is excellent AND the GUI is not yet a daily driver, and one
cell could not hold both, so the product half was invisible. That is how
a frontend the reporter would not choose came to sit inside the
healthiest concern in this document.
The product subgrade has criteria, not adjectives: GPU >= local TUI at
every journey step (currently FAILS at 5 and 12, per §2b); the
daily-driver blocker list empty (currently nine); every surviving
divergence declared. The GUI arc is what moves it, and it should be
re-graded when the arc closes, not before. The scorecard row now POINTS
at §16 instead of carrying a grade, which is the "no orphan scorecard
row" ruling from revision 3 --- criteria and ground truth first, pointer
second.
§20 places the arc: Half A after Priority 1, with reaching Stage 4b as a
P2 START GATE. No later GUI stage begins until P2 has an approved
framing and an opened lane; the gate is on STARTING P2, not finishing
it, so the arc is never blocked on work nobody has begun and cannot
outrun the model it depends on.
Arc 8 retires as a GUI label (Q#GA4). "Arc 8" now unambiguously means
the LEAN 4 arc, which is the numbering that stays; the roadmap's "Arc 8
--- GPU structural parity" scope is Half B of the GUI arc, which is a
name and not a number. Recorded in `docs/agent-handoff.md` beside the
Lean 4 entry too, because that is where a cross-machine reader meets the
number first. Landed framings that say "Arc 8 adjacent" keep their text
--- they are dated records, and this is the disambiguation for anything
written from here on.
Also swept while in §16: its ground truth still said
`SUPPORTED=[6..=21]`. Same stale-range class as the scorecard row fixed
earlier in this lane, one section deeper, and found only because the
subgrade work required reading the section rather than the row.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
"`*workers*` has no binding at all" was false. The view carries a
buffer-local `C-c C-k` for `workers.cancel-at-point`
(`builtin/runtime/async.lua`, documented at `docs/keybindings.md:282`).
Corrected at all four sites it had spread to: the table row, the
contract paragraph, the summary, and the framing's historical example.
The absent thing is narrower and is now said precisely: NO BINDING
OPENS `editor.list-workers`. A binding that only works once you are
already inside the view cannot satisfy a discoverability subclaim ---
which is the same shape as the route-versus-binding distinction the
previous commit drew, one level further in. A route reaches the view
but is not a binding; `C-c C-k` is a binding but does not reach it.
11(c) asks for the conjunction, and neither half alone supplies it.
The Missing grade is unchanged, and so is the two-step GPU deficit. What
changes is that the row now states a fact about the tree rather than an
overstatement that happened to point at the right grade --- which is the
distinction this table exists to hold, since a grade resting on a false
premise is not falsifiable, it is merely unfalsified.
Left alone deliberately: the audit quote at COHERENCE.md:562, where
"no bindings at all" refers to opening a file, opening a terminal and
running a build. That is a historical observation about OTHER commands,
and the paragraph immediately below it already records that all three
were answered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three findings, one of which is a retraction.
GPU 3(c) is inferred again, in BOTH halves. The previous commit called
its rendering half "verified" on gpu_invocation_acceptance.rs:706. That
test runs `--headless-managed-probe`, which connects, receives and
DECODES a `BufferSnapshot` into text; it never constructs GPU render
state and never calls `render_offscreen` (pmacs-gpu/src/main.rs:1065).
It witnesses delivery and decoding, which is real and is not rendering.
Retracted rather than softened: "verified" was the word doing the
damage, and this file is where a reader goes to find out what has
actually been measured.
The discoverability contract said the four welcome key entries decide
every discoverability grade --- while the table two paragraphs below it
graded steps 4 and 7 on welcome PROSE and on the help graph. A standard
cannot carry both. The contract now states what it actually applies:
advertisement includes the welcome's prose (`M-x`, `M-x help` at
welcome.lua:61) and is TRANSITIVE through the help graph, which is how
`help.list-keybindings` carries browse and symbol.
That transitivity forced the distinction 11(c) was already resting on
without saying so: a BINDING is a stronger claim than a ROUTE. Step 7
passes because its commands are bound and a listing names them; step 11
fails because `*workers*` has no binding for any listing to name. So the
summary's "no advertised route at all" was FALSE --- the route is
`M-x help` -> `help.list-commands` -> `editor.list-workers` --- and the
Missing grade survives on the binding, exactly as 11(c) is worded.
The framing's worked examples are marked HISTORICAL, with COHERENCE.md
§2b named authoritative. A framing and the standard it serves were
handing a reader two different grades for step 7. Both examples keep
their point: the head-grade rule would have graded BOTH `Works`, which
is what makes it unsound. Step 7 moving on better evidence is the system
working; step 11 not moving is the defect surviving contact with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Rule 4 retires a lane only once its durable facts have reached
`docs/agent-handoff.md`, so that was CHECKED per lane rather than
assumed. Four of the five were already covered --- the `commit_to`
capture-at-request-time lesson (#231), per-worktree gate target dirs
(#225), the `build-crdt` step and the `gpu_invocation` signature
(#228/#229), the v23 frozen-variant lesson (#228). One was NOT:
`texlab` appeared ZERO times in the handoff, so #230's lane could not
be retired yet and its facts are added first --- LaTeX is served by
texlab, its root comes from an upward `.texlabroot` walk verified in
texlab's own source, and `.git` is deliberately excluded because a
repository root is the wrong answer for a multi-file document.
The handoff's Fake LSP mode list was stale in the same breath: it named
four modes when the binary has twenty-eight. Enumerated from the binary
and grouped, because a stale mode list is precisely how a test ends up
covering the shape next to the defect --- which is the failure this
lane has now watched happen twice in the file-watcher work.
Retired: #224, #225, #228's PR-specific block, #230, #231. That is 737
lines of ledger describing work that has shipped.
#228 is the one that is NOT a deletion. Its PR block is retired INTO
the standing Discovery lane, which is rewritten to "Stages 1 and 2
merged; later work remains" --- deleting that lane on the strength of
one merged stage would have dropped four named pieces of open work.
While rewriting it, its first open item turned out to be what Stage 2
actually shipped (richer M-x rows over v23), so it is removed and the
rest renumbered: a completed item sitting in an open list is the same
staleness this commit exists to clear, one level down.
Left deliberately: #229's and #232's lanes, which are already labelled
MERGED accurately. They are Rule 4 candidates but not STALE, and
widening this commit to them would mix "the ledger lied" with "the
ledger is verbose".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Rebased onto e67ad07; the framing commit replayed with no conflict.
Three corrections, each verified against the tree rather than against
this lane's own notes:
COHERENCE.md said `v6..=v21` schema support. The ceiling moved TWICE
since: #221 to v22 for `LineWrapFacts`, #228 to v23 for
`MinibufferPromptRows`. Now v23. The same row's "production attach
remains v20" is correct --- `ADVERTISED_PROTOCOL_VERSION` is 20 --- and
is deliberately left alone.
Journey step 11 read "Works but undiscoverable --- no statusline
spinner/progress indicator anywhere". #232 shipped exactly that
indicator on 2026-08-09, so the row went stale the day it landed. Now
Partial, with what actually exists and what does not: the indicator is
there, the `*workers*` view still has no keybinding.
§9's "No progress indicator exists anywhere" carried the grep that was
the evidence for opening worker identity in the first place. Corrected,
with the part that did NOT change stated as plainly: a purpose says
what a job is doing, never who asked, and attribution is what §9
grades. THE SECTION'S GRADE IS LEFT UNTOUCHED pending a re-audit ---
moving a grade is an audit act, not a documentation correction, and
Stage 0 is docs-only.
U9's row claimed "whatever this is, it is not the tree" about a
same-tree green. This file's own rerun rule forbids that: a same-tree
green establishes intermittence only, and a tree can raise an
intermittent failure RATE without making it deterministic. Replaced
with "not deterministic on this tree; causation and rate effect
unresolved", and the wrong claim is quoted rather than deleted, because
it is the one a later reader would otherwise reach for.
Also corrects this lane's own earlier claim that `add0ba1` had done
half of Stage 0's absorption. It absorbed #227 and #234; five stale
lanes and both COHERENCE corrections remained.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Opens the GUI arc. The framing and the lane are this branch's FIRST
commit, which is both the arc's own rule for every PR in it and the
reason this branch exists today rather than after #227: the document
spent two review rounds as an untracked file in one worktree, and
uncommitted work does not travel between machines.
Revision 3 closed two blocking findings from the second round.
The closure comparison is falsifiable now. Revision 2 ordered its
grades but never said how a cell acquires one, and its "normalize to
the head grade" rule mis-graded exactly the rows it was written for:
journey steps 7 and 11 both read "works but undiscoverable" and would
both have graded `Works`, with the undiscoverability demoted to prose
that cannot block closure --- while discoverability IS the substance of
steps 4, 7 and 11. Grades now have observable criteria, a compound step
takes the minimum over declared subclaims, and the table carries three
columns (local TUI, attached TUI, GPU) compared against the local TUI.
Half B's dependency graph was inverted. Viewport facts are ABOUT a
window, and whether a semantic window is a daemon projection or a
frontend-local object is what the model stage decides --- so the facts
cannot be designed first. Revision 2 also had a framing-only stage
handing the sidebar geometry no stage shipped. The order is now model
framing, then the viewport/identity substrate, then splits plus
IMPLEMENTED side geometry, then the sidebar.
Q#GA4 through Q#GA12 are ruled and closed.
Four claims this revision inherited were wrong and are corrected with
their sources rather than quietly dropped: the daemon has always
emitted `InstanceSignal::Bell` (daemon.rs:1373), so Bell is
consumer-only; the GPU NEVER consumes daemon `view_top`, which the
backlog states in as many words; Q#DS9 scopes save AND restore, so
Stage 4b owns both; and the protocol ceiling is v23, not v22 --- #228
raised it after #221, and revisions 2 and 3 both read the range at the
audit anchor without re-reading it afterwards.
The three-column claim is narrowed to what it can support. The attached
TUI handshakes `semantic_render: false` and never consumes the
SemanticFrame family, so a shared GPU/attached gap cannot implicate the
semantic wire. The columns separate local from daemon-attached, and
attached-grid from semantic; source tracing still assigns ownership.
Q#GA6's citation is corrected to the one site that matters: local and
attached document events converge on the document handler, whose only
wheel arms are Up/Down at editor.rs:3189. The sites revision 3 cited
were terminal-content paths.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The arc completed at 122b8e8, so per rule 4 the lane comes out of the
ledger: durable facts move to the handoff section-1 arc bullet (the
pool-thread cost of sleep jobs, the loops-that-never-run cancellation
lesson, the group state machine and its double-enforced retirement,
the server-owned scan root with its reachable deterministic fallback,
the core-count-assumption CI lesson and the taskset rehearsal, probe
and witness-bound discipline, the stray-marker re-rooting hazard, and
the deliberately unbuilt kernel-notification option). The handoff
anchor and the canonical-base line move to 122b8e8.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The four-blockers bullet kept its own copy of the round-one claim that
round two disproved; both copies now point at the manual-spawn
adoption path. The facts-list heading no longer counts itself.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Review round three on PR #235, plus the diagnosis of its first CI run:
all five test legs failed on one test, deterministically, while
sixteen local cores stayed green.
The mid-walk cancellation bound could not bite the per-entry poll
alone. The cancel lands two files into a 41-file directory --- root
contributes three dir entries --- so with the per-entry poll deleted
the directory finishes and the per-DIRECTORY poll catches at seen ==
44, under the old bound of 60. The bound is now 40 against an expected
exactly-35 (3 + one 32-entry poll stride), and the entry-poll-only
bite goes red at 44. Verified both ways.
The retirement helper observed a REQUEST, not settlement: it returned
as soon as an active row showed cancel_requested, which a worker that
ignored the token and completed successfully would satisfy. It now
waits for a completed row with status == "cancelled", making the
lane's "settles cancelled" claim true at the witness, not just at the
Rust layer.
The CI red: d3_pump(1600) between the mid-walk join and the late.bbb
write assumed the held walk would complete within 1.6 s. On a 3-thread
CI pool, 8 sleeps of 1200 ms drain in ~3.6 s of waves, so the file
landed before the held walk even STARTED and folded into the joiner's
baseline --- exactly the fold the test exists to assert for mid.bbb,
applied to the wrong file. Deterministic on every 2-4-core runner,
invisible on 16 cores. The drain is now an observable condition ---
at least one post-join walk completed and none active --- with the
saturation sleeps at 800 ms, and the three saturation tests plus the
whole eighteen-test family re-run green under taskset -c 0-3, the CI
pool shape reproduced locally.
A fixed-duration pump against pool-dependent timing is a core-count
assumption in disguise; the lane records it as such.
Superseded round-one text in the lane (the fallback "unreachability"
claim round two disproved) is corrected in place.
One gate run also hit the live attach-retry BrokenPipe row --- fourth
occurrence, all three required fragments verified against the durable
sweep log, recorded in docs/ci-red-signatures.md. This lane touches no
pmacs-gpu code, no wire, and no protocol; the same sweep passed twice
earlier the same day on materially the same tree. The retirement bar
(mechanism, not rate) is unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Implements docs/lsp-file-watch-d3-framing.md revision 4, approved
2026-08-11 with the four rulings adopted as proposed: the honest bar
(absent at idle, one attributable job per concurrently due group), no
exclusions by default, server root_uri -> cwd -> attachment fallback,
and constants rather than config keys.
pmacs.fs.walk_tree: the whole recursive tree as ONE cancellable job
(JobKind::FsWalkTree, reply reuses ReplyKind::ReadDir --- identical
payload shape, so the Lua boundary needs no second conversion). Names
are base-relative; symlinks recorded, never traversed; an unreadable
subdirectory skips its subtree (scan_tree's pcall behaviour); only the
root failing to open fails the walk; the cancel token is polled once
per directory. Eight Rust unit tests, including flat-directory entry
parity with read_dir_blocking and the two review-round cancellation
cases (empty-tree pre-cancel; mid-walk via the cfg(test) entry hook).
The watcher itself is rewritten as the framed group scheduler. No
sleeps anywhere: one process.after-tick subscription (installed once
and guarded --- pmacs.hook.remove does not exist) drives every
(server, base) group's deadline off monotonic_ms, autosave's Q#AS2
idiom. The old design held one pool thread per sleeping watcher and
allocated 1 sleep + D read_dir jobs per watcher per tick --- 1,326
per tick for rust-analyzer's six watchers on this 220-directory
checkout. At idle there is now NO running job, which is also the
strongest witness in the suite: activity_summary settles to None, and
that assertion is unwritable under the old design.
The scheduler is the framing's state machine, all three review rounds
included: single-flight per group with generation-checked completions;
deadlines advanced from completion; the round-3 three-arm completion
partition (success / stale-or-retired / live non-success, with the
failure latch and quiet cancellation); joins wake the group, queue
exactly one follow-up mid-walk, and never reset the backoff curve;
per-watcher baselines --- the first snapshot whose WALK STARTED after
the join; membership captured at scan start; per-member cancellation
recheck at emit through the preserved _after_scan_for_tests seam;
backoff 250ms x2 to a 4s cap, reset by any emitted change; retirement
cancels the in-flight walk cooperatively.
Verification: eighteen acceptance tests. The six #234 tests are
byte-unchanged and green. Ten witnesses cover the framing's plan (the
review rounds added the fallback-determinism and root-boundary pair,
making twelve):
idle absence (and never a sleep purpose), one walk job per scan on a
twelve-directory fixture, join-wakes plus the registration epoch,
queued baseline for a mid-walk join (driven by saturating the worker
pool so the walk genuinely queues), single-flight under a withheld
completion pump, retirement and rebaseline through the fake's
unregister/re-register triggers, live cancel via pmacs._async._cancel
on the queued job, live failure with the once-per-error latch and the
preserved-snapshot recovery (DELETED for the pre-failure file is only
derivable from the retained snapshot), backoff shape from seam
timestamps, and the configured-root base.
Every witness was mutation-tested. Two findings from the bites:
- Retirement is DOUBLE-ENFORCED (unregister path and post-scan sweep)
and biting either copy alone is masked by the other; only biting
both goes red. Kept deliberately: the sweep covers seam-cancelled
members, the unregister path covers idle groups whose next deadline
is seconds away.
- The first idle probe was VACUOUS: it read pmacs.async instead of
pmacs._async, errored, and the unwrap_or_default made every sample
read as "absent". The probe now expects rather than defaults, so a
broken probe is a red test, not a green lie.
One environmental fact, recorded in the lane: an empty stray /tmp/.git
(since removed) made project detection root every markerless tempdir
fixture at /tmp, which under Q#D3-3 the watcher then faithfully
watched. A markerless-fixture red that looks like a watcher bug may be
an ancestor marker.
A pre-commit review round found four blockers, all fixed here:
- walk_tree checked cancellation only inside its entry loops, which an
EMPTY tree never enters --- a pre-cancelled queued walk returned an
empty SUCCESS, which the success arm would commit and diff into a
deletion storm. Cancellation is now checked before opening and
before returning, cancellation outranks a missing-root error, and a
unit test pins both.
- The neither-root-nor-cwd attachment fallback was still pairs-order
nondeterministic --- the exact accident D3 set out to remove, behind
a comment claiming otherwise. It now takes the lexicographically
smallest attachment directory. Verified at the spawn sites: every
server spawned with an attached file gets cwd = root, so the arm is
defensive and unreachable through production spawning --- which is
also why it carries no through-the-server witness.
- A base at the filesystem root joined as //path (and file:////path in
URIs). Both join sites now go through join_under, the root-aware
idiom dired's handler already uses, and the dir-of capture for a
root-level file ("" from the match) normalizes to "/".
- The walk-count and scan-times probes defaulted on error, so two
broken probes could compare equal and pass the retirement witness.
Every probe now expects --- a broken probe is a red test, the same
correction the vacuous idle probe forced.
A second pre-commit round found three more, all fixed here:
- Mid-walk cancellation was UNWITNESSED: both Rust cancel tests
pre-cancelled and the acceptance test cancelled a queued walk, so
deleting the internal polls left every test green. A cfg(test)
entry hook now flips the token at an exact entry boundary and the
witness asserts the walk stopped NEAR it (bound on entries
processed), which is what discriminates the polls from the
entry/exit checks. The retirement witness now holds a walk in
flight across the unregister and asserts the job settles cancelled.
- The "unreachable fallback" claim was WRONG: pmacs.lsp.spawn may
omit both cwd and root_uri, and ensure_server adopts such a live
server for markerless files (root_uri and key_uri both nil). The
lexicographic-minimum fallback now has a through-the-server
witness: five sibling directories, the minimum opened last ---
five, because with two the build's hash order coincided with the
lexicographic answer and the first-pairs bite survived.
- The root-boundary joins gained a witness through exported
production functions (the _deliver_status pattern): the matcher and
URI builder driven at base "/", where reverting either join_under
call makes the anchored glob refuse //hit and the URI grow a fourth
slash. No fixture can walk / for real.
Verification totals after both rounds: eight walk_tree unit tests,
eighteen acceptance tests (six byte-unchanged, twelve witnesses), all
mutation-verified.
No wire change, no PROTOCOL_VERSION bump; walk_tree is an fs binding.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Revision 4 absorbs review round 3. A live walk cancellation or failure
now has an explicit group-state transition: no snapshot, epoch, or emit;
the prior state and backoff survive; in-flight clears; queued joins run
immediately; otherwise the group reschedules. Distinct failures report
once until a successful scan clears the latch.
Correct the queued-baseline latency bound and add live-cancel and
live-failure witnesses. Record the round in the active-work lane; the
four user rulings still block implementation.
Review round 2: two P1 design gaps and one P2 overclaim, all in the
cadence revision 2 introduced.
A join now wakes the group: next_scan_at pulls to now, an in-flight
walk queues exactly one immediate follow-up, and a baseline is only a
snapshot whose WALK STARTED after the join --- an in-flight walk may
have passed a directory before a pre-join file appeared there, so its
snapshot as a baseline would turn that file into a false CREATED.
Without the wake, a backed-off group folds post-registration files
into the baseline and never reports them; today registration scans
immediately and the coalesced design must not regress that.
The group is now a defined state machine: single-flight per group
(overlap unrepresentable, not avoided), deadlines advanced from
completion (a walk outliving its interval degrades to back-to-back
scans, never overlap), stale completions rejected by generation
(#234 P2 at group scope), and retirement --- last member gone or
server death --- that cooperatively cancels the walk. Cancellation
therefore enters walk_tree contract and tests; polling the cancel
token between directory reads is the established job shape. The
after-tick subscription installs once and guards, because
pmacs.hook.remove does not exist (the P3 gap).
Q#D3-1 restated honestly: groups key on (server, base), so several
can be due on one frame and per-group single-flight still permits N
jobs. The bar offered is absence at idle plus one attributable job
per concurrently due group, with a global scan queue as the
alternative if one-at-a-time must be guaranteed.
Six round-2 witnesses join the plan: join-wakes, no-overlap,
retirement, queued-baseline, plus the round-1 epoch and idle pair.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Review round 1 (five findings, four P1) and revision 1 did not survive
it. The findings are recorded in the document; three are cases where
the framing reasoned from the wrong mechanism.
The promised idle state was impossible: pmacs.workers.sleep is a
RUNNING job for its whole duration --- dispatched onto the worker
pool, sleeping in 1ms slices on one of available_parallelism - 1
threads --- and activity_summary counts every running job. A 4s
backoff sleep renders as a constant "sleep 4000ms", and filtering it
would touch the instrument. Revision 2 removes the sleep from the
design: one process.after-tick subscription owns every group's
schedule via monotonic_ms --- autosave's Q#AS2 idiom, whose own
comment names the pool-thread hazard. Waiting now allocates no job
and no thread; the indicator is absent at idle by its None-at-zero
contract, which also becomes the strongest witness in the plan.
The scan root is the server's, not a guess: root_uri then cwd then
the attached-file fallback. project.detect was wrong by the tree's
own testimony --- server rooting honors configured strings and
resolvers first, and texlab's Q#LX2 documents a root that detect can
never produce.
Coalescing gained delivery semantics: shared snapshots, per-watcher
baselines (the first snapshot completed after join), membership
captured at scan start, cancellation rechecked per watcher at emit
(#234's P2 rule, per member). Two epoch witnesses join the plan; the
six existing tests do not cover this and were never claimed to.
Exclusions default to NONE. Any unconditional skip deviates from the
registered glob contract (**/-leading globs can match under .git/,
and a server may register .git/HEAD outright), and walk_tree removes
the job-count economics that made skipping look necessary: 80% of
jobs becomes readdir syscalls inside one job.
Arithmetic corrected to this checkout: D = 220, so 221 jobs per
watcher per tick and 1,326 for rust-analyzer's six --- six of them
pool-thread-holding sleeps. Revised steady state: zero jobs at idle,
one walk_tree job while a scan runs.
Q#D3-1..4 rewritten accordingly; all four still block implementation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Framing and lane update at the branch's first commit, portable during
review. Revision 1 is a DRAFT and no implementation may start from it.
The remainder of issue #233 after #234: the watcher is correct and
still walks everything. The framing re-verifies the cost model at
add0ba1 and adds two facts the issue does not carry:
- On this checkout .git alone is 177 of 220 directories --- over 80%
of every walk --- and the machine does not even have an in-tree
target/ (external CARGO_TARGET_DIR). The issue's 187/46 numbers were
measured with one.
- The string-form base is NONDETERMINISTIC: resolve_watcher takes the
directory of whichever attachment pairs() yields first, so which
tree a bare-string watcher can see depends on table hash order. #234
made matching correct per base; which base is still accidental.
Design space A-E with the trade-offs stated: coalesce per (server,
base); a Rust walk_tree primitive (one job per scan instead of one per
directory --- no new crate, no wire change); an ignore list, with the
target/ staleness hazard named (rust-analyzer's **/*.rs covers
OUT_DIR outputs, so an aggressive default trades churn for staleness
in exactly the server the issue is about); idle backoff; and kernel
notification, deliberately staged separately because A-D are pure wins
it does not obsolete and a new-crate decision deserves its own
framing.
Proposed Stage 1: walk_tree + coalescing + backoff, VCS-only skip
default, project-root base preference. At rest on this repo: from
~1,100 jobs per scan-bound tick to one job every four seconds, named
for its root.
Four rulings block implementation (Q#D3-1..4): the acceptance bar
(one attributable blip at idle, not silence --- silence is Stage 2),
the skip-list default and where it lives (a list-valued setting is
not expressible in today's ConfigValue), the string-form base change,
and knobs vs constants.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The absorption pass after the two merges of 2026-08-11: the LSP
file-watcher fix#234 (ae84d58) and git integration Stage 1 #227
(b867f64), landed in that order so the 2026-08-10 hold on #227 was
discharged rather than overridden.
The handoff anchor moves 9a26ac8 -> b867f64 and lists the ten-merge
first-parent chain between them. Only #227 and #234 are absorbed into
section 1 at this anchor; the eight between keep their facts in their
ledger lanes, several of whose headers still say OPEN --- the anchor
paragraph says so explicitly and repeats the ledger's own rule: trust
the canonical-base line over any lane header.
Both lanes are rewritten to their remainders per rule 4's arc test:
- LSP file watcher: the arc is issue #233 and it stays open until D3
closes it. The lane now carries the D3 start-state --- the walk
still recurses into everything every 250ms, no notify dependency in
the tree, no ignore-list infrastructure to reuse --- and the user's
ruling that D3 is next.
- Git integration: Stage 2 (gutter markers) is the remainder, and the
lane preserves the one scheduling constraint that matters: it needs
new DecorationKind variants, a PROTOCOL_VERSION bump, so it must run
alone. The five-round review history stays in the PR and framing;
what the handoff absorbs is what the next lane needs: the
capture-at-invocation census and its single-mechanism fix, the macOS
EILSEQ portability fact and its latent crdt-module sibling, the
root-parsing byte lessons, and the copy/rename presentation ruling.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Review of the #233 implementation found two correctness defects. Both
are cases where the FIRST fix for #233 was itself wrong, which is worth
naming: this lane repaired absolute globs and, in the same change, broke
a case that had worked since May.
P1 --- `resolve_watcher` returned "absolute" for EVERY string, so the
form was carried but derived from the union arm rather than from the
pattern. A bare `*.txt` is a valid relative pattern (LSP 3.17 defines
`Pattern` relative to a base path; VS Code treats string watchers as
applying across workspace folders), and classifying it absolute matched
it against `<base>/foo.txt`, which `^[^/]*%.txt$` can never match. A
leading `/` is what makes a pattern absolute. The `filewatchflat` test
could not catch this: it sends the RelativePattern OBJECT form, so it
constrains the object arm, never the string arm the regression lived in
--- the framing's own F1 finding, repeating inside the lane that named
it.
P2 --- `scan_tree` awaits `read_dir` once per directory, so the watcher
coroutine sits suspended for most of a tick with `_sleep` already
cleared. A cancel arriving there sets `cancelled` and has no sleep to
interrupt, and the resumed scan ran on to `did_change_watched_files`:
one stale batch under the superseded pattern, which is a wrong-pattern
notification the server acts on. Cancellation and liveness are rechecked
after the scan.
Both tests are mutation-checked and each bite fails only its own defect.
Reverting P1 fails the bare-string test alone --- the absolute test
still passes, so the two readings are independent. Deleting P2's recheck
reproduces the defect verbatim: `.received = "1 file:///…/foo.txt"`,
a batch from a watcher that was already cancelled.
P2's witness needs a seam. The race is a cancel landing during one of
the scan's suspensions, which no arrangement of real timing produces on
demand --- the same situation, and the same device, as `git.lua`'s
`_deliver_status`. `pmacs.lsp._after_scan_for_tests` is nil in
production and is handed the SCAN RESULT deliberately: a test that
cancels on any other scan passes with the recheck deleted, because the
loop would break at the post-sleep check and emit nothing anyway.
Gates: 9/9 green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The lane header carries the PR number and the ref it was opened at, so
the next machine can find the review without searching GitHub.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Implements D1 and D2 from docs/lsp-file-watcher-framing.md (revision 1,
approved 2026-08-10). The user ruled that the walking survives this
lane; D3 gets its own framing.
D1. resolve_watcher now returns (base, pattern, form) and the watch
record carries the form. Per LSP, a plain-string glob matches the
file's ABSOLUTE path while a RelativePattern's pattern is relative to
its base --- and resolve_watcher discarded the distinction, so every
downstream consumer matched relatively. Real servers send absolute
globs: rust-analyzer was never told about any file change (all six of
its globs absolute), and gopls saw go.mod but never a .go edit. The
match subject is chosen in start_file_watcher --- form "absolute"
matches base .. "/" .. rel, form "relative" matches rel unchanged.
scan_tree still walks in relative terms; only the string handed to the
matcher changes.
D2. register_file_watchers now cancels the outgoing record list before
file_watchers[skey][reg.id] = recs drops the only reference to it. The
cancel loop is factored into cancel_watch_records, shared with
unregister_file_watchers, so the two paths cannot diverge.
rust-analyzer registers the same id twice with no unregister between
--- previously 12 concurrent pollers, 6 permanently uncancellable.
Verification, per the framing's plan. Three new fake-LSP modes and
tests beside m4_24, each mutation-tested against the defect it names:
- filewatchabs registers a plain-string absolute glob whose relative
reading matches nothing. Red before D1 (reverting the match subject
fails exactly this test), green after.
- filewatchflat registers a RelativePattern without a leading **/
(*.txt at the base) --- F2's guard. Matching every form absolutely
fails exactly this test, so the obvious wrong fix cannot land green.
It also pins that a base-level pattern does not match into
subdirectories.
- filewatchrereg registers the same id twice (rust-analyzer's shape).
The witness is observable polling, not table shape: f.old exists on
disk before either .new event lands, so a leaked watcher at the same
250ms cadence reports it before the second positive. Reverting D2
fails exactly this test, the leaked .old event visible in .received.
m4_24 stayed green under all three mutations --- the framing's F1
finding (the existing test is insensitive to D1 in both directions),
confirmed rather than assumed. It is kept unchanged.
The framing doc records the approval and the answered ruling; the
active-work lane moves to IMPLEMENTED with the verification results.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Framing and lane at the branch's first commit, so the document is
portable while it is reviewed. The GUI arc framing spent two review
rounds as an untracked file in one worktree; that is the lesson being
applied, not a preference.
Revision 1 is a DRAFT and no implementation may start from it.
Scope is D1 and D2, the two bug-shaped defects. Every claim in the
framing was read or executed against `0e4c58d` rather than carried from
the issue --- including re-running the tree's own `expand_braces` /
`glob_one_to_pattern` / `glob_matcher` under LuaJIT, which reproduces
the issue's glob table exactly, compiled patterns included.
#232 is NOT at fault and nothing about it should be reverted. The
activity indicator renders real in-flight jobs; what changed is
visibility, not behaviour, and the watcher has polled since 1c25730 in
May. Quieting the indicator would delete the instrument that found this.
Two findings the issue does not carry, both of which change the fix:
The existing test cannot discriminate this fix IN EITHER DIRECTION. The
fake LSP registers `**/*.txt`, which compiles to `^.-[^/]*%.txt$`, and
`.-` spans `/` --- so it matches relative and absolute subjects alike
and `m4_24` passes whether D1 is fixed or broken. The issue calls the
tested and exercised paths disjoint; the sharper statement is that the
one existing test is INSENSITIVE.
And "match the absolute path" alone would break `RelativePattern`:
measured, `*.txt` matches `a.txt` but not `/base/a.txt`.
`resolve_watcher` returns `(base, pattern)` and discards which form it
came from, so its CONTRACT has to change, not just the match subject. A
fix that misses this trades six broken rust-analyzer globs for every
RelativePattern that does not begin `**/`. The verification plan
includes a test that fails against exactly that wrong fix.
The framing also records what this lane does NOT fix, so the report is
not mistaken for closed: neither D1 nor D2 stops the walking, because
`walk` recurses unconditionally and `matches` gates only recording. The
modeline will keep flipping at roughly half the rate. Whether that meets
the acceptance bar is an open ruling for the user, stated as one rather
than assumed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The async completions rendered through whichever frontend was ambient
when git exited. Run `M-x git.status` in frontend A, let B become
active while `git status` runs, and A's panel opened in B. The
generation and the root were already captured at the keypress; the
frontend was the one input still read late.
Captured at invocation in all four entrances --- `git.status()`,
`_on_refresh`, `_deliver_root`'s hand-off, and the `git.diff-file`
command --- and threaded on the request table exactly as this module
already threads the generation and root. Committed under the profile
each surface actually takes: `"panel"` for `*git-status*`, `"document"`
for `*git-diff*`.
`set_status` moved INSIDE the status commit. Rows and message are now
computed first and emitted together, because a failure message
announcing a panel that the commit then refuses is the same misrouting
in its most confusing form.
A refused commit DROPS the render, which is the answer the
`expect_buffer` rule already gives when the panel a refresh belongs to
was killed. `commit_to` refuses before the body runs, so there is no
partial render to undo.
THE FIRST VERSION OF `g6_25` WAS WORTHLESS AND PASSED ITS OWN MUTATION.
`panel_text` finds `*git-status*` by NAME, which is global --- it
answers "does this buffer exist", not "which frontend is showing it"
--- so a render into the competitor satisfied it. Rewritten against
`side_window_for` and each view's active window, it now fails both
bites: removing the status commit grows a `*git-status*` panel in the
competing frontend; removing the diff commit hands it the document
window.
The merge also surfaced a cross-lane break invisible until the suites
ran: #232 made `purpose` required on `pmacs.process.spawn`, and this
module's spawn is on this branch, so it was never among the 11 sites
#232 updated. Each spawn now carries its own purpose and NOT the label
--- all three are labelled `git`, and only the purpose separates
resolving a repository from reading its status from diffing one file.
Existing tests that drive `_deliver_status` / `_deliver_diff` through
the internal seam now supply a captured destination. That includes the
one place it is load-bearing rather than uniform: `g6_23` reuses its
"stale" request table at the CURRENT ticket as its positive control,
which is the only one of those three deliveries that reaches a render.
Gates: 12/12 green --- git_status_stage1, destination_capture, journey
and worker_identity acceptance, plus the full sweep.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Merged rather than rebased, for the reason #231 was: nineteen commits
replayed against a ledger four lanes had rewritten is nineteen chances
to lose a lane entry, and the reviewed commits keep their SHAs. One
file conflicted.
The conflict was diff3-style with an EMPTY base --- both sides added
lanes at the same offset --- so it resolved by keeping both, this
branch's #227 lane ahead of main's. Worth noting because an empty base
section is exactly what produced the stray `|||||||` markers found
committed in this file earlier today: the base half of a diff3 conflict
reads as content if it is resolved by hand in a hurry.
This unblocks the lane. `pmacs.window.capture_destination` now exists
on the branch (`src/lua_bindings/window_panel.rs:638`), which is what
#227's review found missing and what #231 was split out to provide.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The merge gate for this lane failed at `11-sweep` on two selectors, and
both had already passed in `03-lib` and `04-lib-crdt` of the SAME gate
invocation, minutes earlier, on the same tree and machine. U6 and U7
could only ever compare a red run against a different run; this is the
first occurrence in the family where the control is inside the run, and
that is what the row is for.
Both are near misses against existing rows, and neither is folded in:
- The PTY failure carries U2's exact fragment, but U2's selector field
names only the *raw* selector. U2's occurrence 2 had raw and canonical
failing together; here canonical redded ALONE and raw passed, which
U2's evidence has never shown.
- `composition_overhead_under_ten_percent` is one of U6's two selectors,
and U6 instructs in its own text that one-without-the-other is a
different incident. It redded without its pair, in a different step,
at 1.613x against U6's 1.297x. Judged as instructed.
The row also records the first checkable candidate this family has had.
`cargo test --workspace` runs many test binaries concurrently while
`--lib` runs one, so the passing and failing steps differ in kind and
not merely in load average --- with a stated control that separates
load from concurrency. U6 and U7 both left the confound atmospheric
and unmeasured; this does not measure it either, but it names something
that can be.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Merged rather than rebased. Eighteen commits replayed against a ledger
that three other lanes had rewritten meant eighteen conflict
resolutions in `docs/active-work.md`, each one a chance to lose a lane
entry; merging resolves it once, against the state that actually ships,
and leaves the reviewed commits' SHAs intact. Only one file conflicted.
`docs/ci-red-signatures.md` auto-merged **without a conflict** — the
same silent path that produced duplicate U4/U5 ids when #232 rebased.
Verified by hand afterwards: ids U1-U8 are disjoint. They are out of
numeric order (U6/U7 sit ahead of U4/U5) and are left that way rather
than moved, since the note at the U6 row explains the history and
relocating sixty lines inside a merge commit hides real changes.
Three leftover conflict markers were sitting in `docs/active-work.md`
on `main`, committed by an earlier lane's resolution. `git diff --check`
flags them — but only for a working-tree diff, which is why the gate's
`diff-check` step never saw them and they survived several merges.
Removed here.
The U4 row is corrected on evidence this lane produced:
- **Flavour was wrong as a matching key.** The row was filed from
#229's `lua54` red and put the flavour in the key; #231 reddened the
identical selector with the identical three fragments twice on
`luajit`. Matching as filed would have missed both.
- **A fourth sighting was a deliberate bite, not an occurrence** — the
defect reintroduced on purpose during the test's own development. It
is recorded for what it proves instead: the genuine defect and these
CI reds are signature-indistinguishable, same message class and same
full-timeout duration.
- **The control experiment is written down with its own bounds** — five
green base observations against 0/2, 4.8% under an equal-rate model,
and the two facts that bound it: attempt 5 reddened a different
selector, and the branch side was never resampled.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Attempt 5 of the merge-base control at 0190102 failed on
acc28_child_input_and_the_c_c_escape_work_unchanged_in_a_panel, a
selector in no registry row. I then reran that job before reading its
log, and GitHub keeps only the latest attempt logs for a rerun job, so
the assertion text is gone. Recovery was attempted through the jobs API
and the attempt-scoped endpoint; it is not recoverable.
That leaves the row in U2 original condition --- a selector with no
fragments, unmatchable --- produced by exactly the mistake U3 is named
for. This is the fourth time this project has lost fragments this way,
and the first time I did it while holding the correction in my own
hands: I had corrected two other lanes for it earlier in the same
session.
Numbered U8, not U6, deliberately. U6 and U7 are reserved for the two
wall-clock rows on worker-identity-stage1, which renumbered into that
range when #229 took U4/U5. Taking U6 here would recreate the
duplicate-id collision that rebase already produced once, through the
same mechanism --- two lanes appending rows with no textual conflict.
The row is kept despite being unmatchable because of what it implies
together with U4 and U5: three distinct macOS selectors reddening in
one session points at a background failure rate on that platform rather
than three independent test bugs. That matters beyond bookkeeping,
because it undermines the equal-rate assumption behind any argument
about which branch a failure happened to land on --- including the one
currently being used to weigh #231.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The pre-rebase warning was right, and the mechanism is worth recording
because it is the quiet kind.
gate-protocol-build landed its own U4 and U5 in #229. On this rebase
git merged docs/ci-red-signatures.md WITHOUT A CONFLICT --- the two
lanes appended their rows in different places, so there was nothing
textual to resolve --- and produced two ### U4 and two ### U5 headings
describing entirely different incidents. No marker, no complaint.
That is the failure the matching rule exists to prevent, arriving
through the one path a careful conflict resolution would never catch:
there was no conflict to resolve.
Renumbered across all four sites the warning enumerated: both headings,
the prose relation-to-U4 field inside what is now U7, and the
active-work.md reference. Ids verified unique afterwards rather than
assumed.
The warning block itself is retired in place, replaced by a note saying
what was done and why, so the next reader sees a completed action
rather than an outstanding one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
gate-protocol-build independently defines its own U4 and U5 --- a macOS
lua54 PTY-resize failure and a Ctrl-C-as-SIGINT failure --- and it
merges first, so on main those ids are taken.
A rebase that resolves the textual conflict without renumbering leaves
two different incidents sharing an id, which is precisely the failure
this file matching rule exists to prevent. The registry authority rests
on ids meaning one thing.
The warning enumerates all four sites rather than saying "renumber the
rows", because one of them is a prose cross-reference inside U5
relation-to-U4 field and another is in active-work.md --- both easy to
miss when the conflict presenting itself is two adjacent headings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The header and the mechanism boundary were corrected last round; the
TABLE still numbered two. It called the 2026-08-09 worker run
"Occurrence 2", omitted the 2026-08-06 CRDT occurrence from the
enumeration entirely, and concluded "Two occurrences establish
intermittence" --- in the row I had just rewritten because it omitted
that same occurrence.
That is the head-and-body split this session keeps reproducing, this
time inside a single table, in the row whose whole purpose is to be the
authoritative account of what is known.
The row now enumerates all three, and says which one carries the most
weight: the 2026-08-06 CRDT run, because it shows the failure is not
confined to one feature flavor and can take the raw and canonical
selectors at once. That is a fact neither of the other two supplies.
Also corrected: "what is NOT: any mechanism, still" is now "no
mechanism is ESTABLISHED", because one IS proposed --- read-before-
write on the child output, the R4/R6 readiness family. Proposed is not
confirmed, and the row says so rather than flattening the distinction
in either direction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two corrections, both mine, both the same failure the row exists to
warn about.
First, this is at least the THIRD occurrence, not the second, and the
fragment was not newly captured. docs/active-work.md records a
2026-08-06 loaded --features crdt run failing this selector AND
m6_1_pty_canonical_mode_keeps_kernel_echo with the same stty -a output
was: "" --- and it already proposed a mechanism family, read-before-
write on the child output, the shape of R4 and R6. So the row claim
that no mechanism had been proposed was false of the tree it was
written in. The evidence was in this repository the whole time; I wrote
a registry row without reading the registry neighbour.
Second, the fragment does not show what I said it showed. The test
inspects collect_stdout(&evs) after drain_until --- what the SUPERVISOR
collected. It cannot distinguish stty never writing from the PTY
dropping the bytes from event collection missing them. I wrote "stty
produced no output at all", which asserts a mechanism the test cannot
see, in the same row that says no mechanism is established.
What survives is narrower and still worth having: this is not a termios
failure, since nothing observed shows echo configured wrongly. Which of
child-never-wrote, delivery-lost, collection-missed is open.
The control changes accordingly. Sampling the collected string more
times cannot separate those three however often it fails; the next
occurrence needs the full process event stream and the child exit
disposition captured, cross-checked against the R4/R6 readiness family
that the 2026-08-06 entry already implicates.
The gate conclusion is unaffected: a markdown-only delta cannot cause a
PTY failure, so worker identity code is excluded as a cause.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The worker-identity tip gate went red on step 03-lib with one failure:
m6_1_pty_raw_mode_disables_kernel_echo. U2 already had that exact
selector but no fragments, so it could not be matched. Reading the
durable gate log rather than filtering a rerun supplies them.
The fragment reframes the failure. stty -a returned the EMPTY STRING,
not a wrong mode --- so this is not raw mode failing to disable echo,
it is stty producing no output at all, which points at PTY or spawn
readiness under load rather than termios handling. The assertion own
message is misleading on exactly that point, and anyone diagnosing it
from the message will look in the wrong place.
Occurrence 2 also EXCLUDES the change under test, which occurrence 1
could not. The tree carried zero code change since a 13/13 green run on
this same lane --- the only delta was three lines of markdown. A docs
edit cannot break a PTY test, so the diff is ruled out as a cause
rather than merely doubted. Isolated rerun passes in 0.01s.
Still no mechanism, and the row says so. Two occurrences establish
intermittence and a load correlation; neither establishes cause. The
row now names the discriminating control for a third: loop the selector
under synthetic load logging stty output every iteration, since whether
stty is empty EVERY time it fails is what separates a readiness race
from a termios one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The previous round left the suite at 24 and this round adds one test,
so it is 25. grep -c on the test attribute confirms 25 and the run
reports 25/25. The bullet said 26, and I repeated it upstream without
counting.
The entry now shows the arithmetic --- 24 before, plus one --- rather
than just a corrected number, and names the earlier figure so a reader
who saw it does not treat this as a second suite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The two reds recorded a moment ago were followed by a full green run of
the same command on the same tree — all 13 steps, log
`20260809T200907Z-2672209`. Both the lane entry and U5 now carry that,
because a signature row that records only the reds overstates them: the
green rerun is part of the evidence, not a reason to delete the row.
The row stays live and stays U-classified. Three load-sensitive render
budgets going red one per run and then green is consistent with a loaded
machine and with nothing else in hand; it is not a measurement of one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The lane entry gains round 3: the wrong-surface diagnostic, why the job
and process refusals now say different things, the anti-collapse test
and its three mutation checks. Written here rather than left in the
commit message because this file is what a recovering agent reads.
`docs/ci-red-signatures.md` gains **U5**. Two consecutive `scripts/gate`
runs of the same command, on the same tree, red on step `12-sweep` with
a DIFFERENT wall-clock render-budget test each time — 224ms and 258ms
against a 200ms budget, 114ms against a 100ms budget, at load average
12.9/23.9 with sibling worktrees building. Each passes in an isolated
rerun of its own selector, and no selector reds twice.
The rotating selector is the signature, and it is a stronger one than
any single test name: a regression that moved between three unrelated
render paths on an unchanged tree is far less likely than one loaded
machine. The observing diff is two string literals, their doc comments
and one test, and touches no render path at all.
Kept separate from U4 rather than merged. U4 is two budget tests in
`04-lib-crdt` failing TOGETHER; this is three render-budget tests in
`12-sweep` failing ONE PER RUN. Merging them would assert a shared
mechanism nothing in hand shows, and the load confound stays unmeasured
in both — a rival explanation, not a finding.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two files, no code.
## `docs/active-work.md` — review round 2
The lane's volatile block gains the round-2 record: the three findings,
why P2a's fix is a mapped diagnostic and P2b's is escaping at
presentation rather than rejection at the registry, and the seven new
mutation checks. The gate outcome is recorded with its step counts and
the two stop-signal facts — `journey_acceptance` 47/47 and all three
`#pmacs.process.list()` leak detectors byte-identical to `main`.
It also records what P2a's audit found and did NOT fix:
`pmacs.process.spawn`'s other string fields still convert generically.
That is pre-existing and out of this lane's diff, and it is named so it
is not silently inherited by whoever reads the fixed `purpose` read and
assumes the rest matches.
## `docs/ci-red-signatures.md` — R7's third occurrence, and U4
**R7 reproduced, and the control the second-occurrence note prescribed
finally discriminated — against its own hypothesis.**
Occurrence 2 left exactly one causal path open: the observing lane had
added a GPU-heavy `render_offscreen` test to the same binary, and
contention with a one-second socket handshake was plausible. That note
prescribed the control to run if a third occurrence landed — with the
added test removed, not at the merge base. A third occurrence landed, at
the gate's `gpu` step, with all three fragments verified against the
durable log.
The control was run. **Ten full `-p pmacs-gpu` runs with the added test:
10/10 green. Ten with it `#[ignore]`d, nothing else changed: 1 failure
in 10, all three fragments present.** Removing the suspect made the
failure more frequent, so the concurrent-test path is excluded — no
contention story from that test survives that direction.
The more useful result is the rate. This is the first rerun in R7's
history to reproduce anything at all, and it puts the failure at roughly
1-in-10 under ordinary `-p pmacs-gpu` load. Three sightings were not
enough to bisect a handshake; 1-in-10 is. The row now says so, and tells
the next agent to instrument which side closes the pipe rather than
re-run for green.
The lane is still not attributed — now for a measured reason rather than
an argument from diff shape: the arm without the lane's only
`pmacs-gpu` addition is the arm that went red.
**U4** records the other two reds from that same gate run:
`criterion_1_end_of_line_typing_completes_sub_frame_per_keystroke` and
`composition_overhead_under_ten_percent`, both wall-clock budget
assertions, failing together in `04-lib-crdt` and both green in
isolation and in the next full run. Fragments captured, so unlike U1–U3
it is matchable — it is a `U` row for want of a mechanism, not for want
of evidence. The signature named is **the pair**: two budget tests
failing in one run and neither in the next is far more likely to be one
loaded machine than two simultaneous regressions, and a future run that
reds only one of them is a different incident.
Neither row claims harmlessness, and the concurrent-worktree load
confound is recorded as a rival explanation rather than as a finding,
because it was not measured.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Review round 2, findings P2a and P2b, plus P3's stale recovery
summaries. Three defects, and the fix is deliberately different in each
place because the constraint is.
## P2a — invalid UTF-8 bypassed the `purpose` diagnostic
`required_purpose` read the field with `value.to_str()?`. Lua strings
are BYTE strings, so `purpose = string.char(255)` is a value a caller
can write, and `?` surfaced mlua's generic conversion error BEFORE this
lane's own diagnostic was ever constructed: the caller was told neither
the field nor the rule.
**This is the third time this project has hit the class** — an unowned
Lua string converted with `?` ahead of the owned message; the
destination-capture lane corrected the same shape two rounds ago. It
refused before spawning and nothing leaked, so the defect was the
message, not the outcome. The conversion failure is now mapped onto
this function's own message, and the new acceptance row asserts on
message CONTENT so retyping the read as a bare `?` breaks the test
rather than silently degrading the error.
Auditing the rest of the lane's diff for the same class turned up
exactly one more: `_push_dispatch_name` took `name: String`, so a
registered handler name that was not valid UTF-8 failed at first
dispatch with mlua's generic message. It now takes `mlua::String` and
maps that failure onto an owned diagnostic naming the argument and the
rule. Those are the only two Lua-string reads this lane added; every
other binding it adds takes `()`.
## P2b — no safe display-text boundary. Two halves, two different fixes
### Handler names are refused at the source
`pmacs.workers.register` type-checked its name and nothing more, which
was defensible while the name died inside `dispatch`. It no longer dies
there: the ambient carries it into every job the handler allocates and
composes it into `purpose`, which `*workers*` and the modeline both
render. So it now gets `purpose`'s meaningful-value standard —
non-empty, not whitespace-only — plus control characters, which have no
legitimate place in a registered identifier.
### Purposes are ESCAPED at presentation, not rejected at the registry
A purpose may legitimately contain a newline: a filesystem path can, and
`pmacs-magit`'s spawn purpose is a whole argv. **This is the shape of
the `#228` decision, and it is consistent with it** — the one-line
constraint belongs to the surface that has it, not to the registry that
does not. There, `Command.description` stays free-form and the two
single-row consumers clip with `description_first_line`. Here the
equivalent is escaping rather than clipping, because a purpose's later
words are load-bearing: an argv's second word says which file, and a
clip would drop it silently.
`purpose_for_one_row` states the property it exists for: **a row must
not be able to forge another row.** It escapes `\n`, `\r`, `\t` and the
rest of the Unicode `Cc` class (which covers ESC, so a purpose cannot
open a terminal escape sequence either), borrows unchanged when there is
nothing to escape — making byte-identity structural rather than
asserted — and deliberately does NOT escape backslashes: no number of
them produces a second row, and doubling them would cost byte-identity
for ordinary text.
Two surfaces call it: the `*workers*` rows, and `ActivitySummary`, which
exists for one consumer that has exactly one row.
`pmacs.workers.snapshot()` is this lane's `describe-command` and stays
raw, which is what makes this a rendering decision rather than data
loss — asserted, not assumed.
## P3 — two stale recovery summaries
`docs/worker-identity-framing.md` still said "Implementation may
proceed"; it is implemented. `docs/active-work.md` still said Stage 1
takes the "first two" of owner/purpose/parent — `owner` was REMOVED in
revision 2, so it takes one of the three, and the claim the whole
`owner` argument overturned was still standing in the volatile state of
record. Both fixed section-locally.
## Verification
`tests/worker_identity_acceptance.rs`, 18 -> 24 tests:
* invalid-UTF-8 purpose refused by THIS lane's message, asserted on
content, alongside the absent / empty / whitespace / wrong-type /
metatable rows;
* a whitespace-only handler name and a control-character one are each
refused AT `register`, asserted on the error and on the handler not
being installed (dispatch reports `unknown handler`);
* a non-UTF-8 handler name is refused before the handler runs, with the
dispatch-name stack left empty;
* a purpose containing a newline renders as ONE row in `*workers*` and
as one line in the modeline — through the real rendering path, the
latter through a painted frame as well as the evaluator;
* **a purpose crafted to look like a row boundary does not produce a
second row** — asserted by counting rows, with the escaped text
asserted present so a renderer that dropped the purpose entirely could
not pass;
* a purpose with no control characters is byte-identical on both
surfaces, fixtured with a literal backslash, a literal `\v`, quotes
and a non-ASCII character.
Mutation-checked, seven guards, each failing its own test and no other:
the purpose UTF-8 diagnostic; the `_push_dispatch_name` one; the
register whitespace guard; the register control-character guard; the
`*workers*` call site; the `ActivitySummary` call site; and
`purpose_for_one_row` itself neutered to the identity, which fails both
surfaces' tests and nothing else.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
`attach::tests::managed_retry_survives_transients_and_uses_the_successful_stream`
failed once at this lane's `scripts/gate` **`gpu` step** on 2026-08-09.
Judged against this file rather than rerun-and-shrugged.
**It matches R7 on all three of its required fragments**, verified rather
than inferred:
transient sequence must attach: Attach(Handshake(Io(Os {
code: 32, kind: BrokenPipe, message: "Broken pipe" })))
**That capture is the point.** U2 and U3 both record the identical loss —
"output was filtered to the `FAILED` line" — and U3 says outright that
the recurring mistake was its author's, twice, with a mechanical fix:
read the durable log, never the live stream. The gate writes
`NN-gpu.log` for exactly this, and reading it turned what would have been
a third unjudgeable `U` note into a second occurrence of a row that had
one.
The flavor is a third one (`PMACS_REQUIRE_GPU=1 cargo test -p pmacs-gpu`,
neither occurrence 1's `--features crdt` sweep nor U3's default-features
workspace sweep). Recorded because this file's own R2 worked example
treats flavor as outside matching.
**The merge-base control R7 asked for was run, and it settles nothing.**
15 runs at `4bc55e8`, green — but the observing branch was green over 30
runs too (15 isolated selector, 15 full suite), so neither side
reproduced and the comparison separates nothing. Logged as a null result,
not as exculpation. Per the rerun rule, all 45 green runs establish
**intermittence only**.
**And one causal path is named rather than dismissed:** this lane adds a
GPU-heavy `render_offscreen` test to `pmacs-gpu`'s test module. It
touches no `attach.rs`, no protocol and no wire — but it does add a
concurrent test to the same binary, and the failing test is a socket
handshake on a one-second deadline. Contention is a plausible
`BrokenPipe` mechanism and 30 green runs do not exclude it. The row now
says what the discriminating control would be if there is a third
occurrence: remove the added test, not go to the merge base.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two section-local edits, no reflowing.
**`docs/worker-identity-framing.md` §2** named the three existing
statusline adopters by FILE — `terminal.lua`, `syntax.lua`, `lsp.lua` —
which is accurate and misleading together: `syntax.lua` registers its
provider under the name **`"mode"`**, so the registry inventory reads
`["mode", "terminal", "lsp"]` and a reader looking for the syntax adopter
by name does not find one. That is what made this lane's change to
`tests/statusline_segments_acceptance.rs` surprising, and the next reader
should not have to rediscover it. Also records that where a fourth
registration sorts is decided by **load order**, not by name.
**`docs/active-work.md`'s lane block** records review round 1: the
`pmacs.process.spawn` blocker and its fix at `2162737`, the five refused
shapes, the eleven updated call sites, the two audit-fixture occurrences
that are deliberately untouched, the three added mutation checks, and the
two acceptance suites the round added to the gate line
(`compile_mode_acceptance` and `m8_6_acceptance`, because the round moved
their spawn call sites and `m8_6` covers the `pmacs-magit` package
fixture).
It also records the breaking-change decision with the reasoning that
justified it, rather than only the outcome: the binding has no
API-reference documentation and no stability promise, `lua_to_spec` has
one caller, and §10/P7 put the third-party population at ~zero — so the
cost of requiring the field is at its minimum now and rises from here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Section-local update to `docs/active-work.md`'s "Worker identity Stage 1
(§9)" block, which was written pre-implementation with the lane's first
commit. It now records what actually shipped rather than what was
planned, because the difference is where the reviewable claims are.
Three things it records that a status flip alone would not:
- **`journey_acceptance` passed UNTOUCHED (47/47).** Q#W-7 edits the
`commit_to` guard family, so that suite was the lane's stop signal: any
established pin needing an edit would have meant the change altered
Journey Stage 1a's semantics rather than closing a gap in them. The
same for all three `#pmacs.process.list()` leak detectors, which are
Q#W-4's preservation claim.
- **One pre-existing assertion did change**, and it is named here so the
change is not mistaken for an accommodation: the builtin statusline
provider inventory in `statusline_segments_acceptance` grows by the
fourth adopter. That assertion exists to grow.
- **Two residuals, stated rather than tested around.** A raw
`coroutine.yield` inside either dynamic scope still leaks the scope,
and Q#W-7's reachability by a real caller is unproven.
Also lists the surfaces that changed shape — the collapsed allocation
funnel, the two grown constructor signatures, the new required fields —
for anyone rebasing a concurrent lane onto this one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two changes, both from review, both about claiming exactly what is
enforced and no more.
Rule 1 said it covered "all yield points". It covers the two supported
pmacs yield APIs. Raw coroutine.yield remains reachable: R46 is a
convention ("package code uses :await() rather than coroutine.yield",
async.lua:26-27), not an enforcement, and the scheduler diagnoses a
non-Handle yield only after the fact --- step() resumes at :197 and
inspects what came back at :212, by which point the coroutine has
already suspended and the enclosing dispatch never returns to run its
pop. No refusal sited in a yield helper can intercept that.
So the property is stated as what it is: the supported ways to yield
are refused inside the scope, and an R46 violation can still leak the
name --- loudly, through pmacs.error into *errors*, but unrestored.
Section 6 says explicitly that this is NOT asserted, because a test
implying coverage the design lacks is worse than the recorded gap.
Q#W-7 is approved into this lane rather than split out. Same supported
helper, same invariant, same async.lua edit family; splitting would
preserve a known hole without reducing integration risk. So
yield_to_next_tick gains both refusals --- the new
_in_dispatch_name_scope and the missing _in_commit_scope --- and the
commit_to gap closes in the same commit as rule 1. Its witnesses are
the same pair as rule 1: the refusal fires AND the scope restores, on
the reasoning that a guard which raises while leaving the scope pushed
trades a silent fault for a loud one and fixes neither.
Reachability by a real caller stays UNPROVEN and the framing says so in
three places, including here. The defect was found by reading; the
tests pin the guard rather than reproducing a user-visible bug. Nobody
should later cite this as evidence the bug was observed.
The causal-extent paragraph and the Q#W-5 comparison were both
re-scoped to match, since both leaned on "non-yieldable" as an
unqualified property.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Review found that revision 2 asserted the property its whole design
rested on. It called the dispatch-name extent "synchronous" and never
checked. A registered handler is arbitrary Lua running inside
pmacs.async and may call Handle:await(), which parks the coroutine with
the name still pushed --- so every tick callback and every other
coroutine allocating a job in the meantime inherits it. The existing
tests already await inside pcall, so this is the ordinary shape of an
awaiting handler, not a corner case.
Rule 1 now enforces non-yieldability instead of assuming it, and the
enforcement was already in this file: Handle:await refuses to run
inside pmacs.window.commit_to (async.lua:87-90), with a comment giving
exactly this reasoning --- yielding "would restore the scope while this
coroutine is still parked". _in_dispatch_name_scope joins
_in_commit_scope in the same place.
Three details decide whether the guard holds, and all three are pinned:
it rejects before the park, not after; it rejects unconditionally
rather than only when the handle is incomplete, because a guard keyed
on whether the job happened to finish first passes under test and fails
intermittently in production; and it covers both yield points.
That last one is a finding. pmacs.async.yield_to_next_tick
(async.lua:243-245) also yields and is public. Guarding only await
would have left the hole open through a second door.
Which exposes Q#W-7: the existing commit_to guard has exactly that gap
today. yield_to_next_tick carries no _in_commit_scope refusal, so
Journey Stage 1a Q#JR14b invariant has a second entrance. Reported
rather than patched, and reachability by a real caller is explicitly
UNPROVEN --- it is a code reading, not a repro. My vote is to fix it in
this lane since the lane already edits that function family, but it is
another lane invariant so it is a question.
Q#W-5 justification is rewritten rather than left standing. It argued
parent was deferrable because its ambient would span asynchronous
lifetimes while this one did not --- an argument revision 2 was not
entitled to make, since its own ambient could be parked by any awaiting
handler. With rule 1 the distinction is real: this extent cannot be
suspended, and parent cannot be rescued by refusing to yield because
yielding is the mechanism it needs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two review blockers, both correct, both about the same failure: a field
or a claim that looks like attribution without being it.
BLOCKER 1 --- owner is not honest before P3. Revision 1 proposed
owner = package-or-builtin while populating it from static
per-subsystem constants at each dispatcher. Those disagree. A generic
dispatcher has no trustworthy knowledge of who invoked it, and
pmacs.process.spawn is callable by any package, so a static "lsp" label
is an origin or category and would confidently misattribute
third-party work to a builtin at exactly the point section 9 wants
attribution.
owner is removed rather than renamed. origin or subsystem would be
honest wording, but a second string field beside purpose, used to group
the view, gets adopted as ownership by the next reader regardless of
its name --- and it would squat on the slot P3 has to fill. Stage 2
needs a grouping key and should get a real one. No P3 alignment is
claimed any more.
BLOCKER 2 --- the handler name needs a mechanism, not a parameter.
Revision 1 said the name was "in hand at the one place that throws it
away". That was wrong about the call chain, and re-reading it is what
showed why: dispatch(name) calls an arbitrary handler, which calls a
Lua wrapper, which calls the Rust binding, and name is a parameter of
none of them. Worse, async.lua:337-345 documents the wrapper layer as
bypassable --- other runtime files are told to call their own raw
_dispatch_* primitives --- so capturing in the wrappers would miss
exactly the callers attribution exists for.
Q#W-2 is rewritten as a contract: a dispatch-name stack owned by the
async runtime and read at allocate, the same single funnel Q#W-1
collapses. Seven rules, including the two that decide whether it is
better than nothing --- unwind-safe popping, because one erroring
handler would otherwise poison every later dispatch with a stale name,
and composition rather than replacement of a caller-supplied purpose,
because replacing recreates blocker 1 in a new place.
It also answers the objection it invites: why is this ambient allowed
when Q#W-5 defers parent for needing one. Because they are different
mechanisms --- this is a synchronous single-threaded extent with a
deterministic pop, and parent needs a lifetime model spanning ticks and
post-settlement callbacks.
Verification takes the reviewer wording fix: presence is a type
obligation now that purpose is non-optional in a private JobSpec, so
the compiler proves it and the tests prove semantics at representative
entry paths. The handler witness must be a registered handler calling a
real dispatcher, not a synthetic funnel test.
The title changed too: "who asked for it" overclaimed once owner left.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
COHERENCE.md section 0 names background-work ownership as one of two
remaining thin ends of the golden journey, and section 20 puts it
outside Priority 1 while conceding it is the last of that priority own
work. Section 9 grades the worker model "mechanism without identity".
The felt gap is narrower than the arc and is checkable: grep -c for
spinner/progress/busy in src/statusline.rs returns 0, so section 3
promise of "visible asynchronous work" is false today unless the user
knows to run M-x editor.list-workers. The git Stage 1 lane in flight
right now records a deliberate negative section 9 impact for exactly
this reason; this lane is the one that repays it.
Two scouting findings shaped the staging rather than confirmed it.
PendingJob carries eight fields, not the seven the audit lists, and the
eighth doc comment cites section 9 by name as the reason identity
belongs on the job and not in a side map. So this extends a merged
decision instead of introducing one.
pmacs.process.list filters to LineOriented, dating to the vterm Stage 1
commit, and three acceptance suites use #pmacs.process.list() as a leak
detector. Widening that accessor to show terminal PTYs would inflate
all three baselines. Making PTYs visible therefore moves to Stage 2
behind a separate accessor, which is a better answer than editing tests
that are correctly detecting a semantic change.
NO WIRE CHANGE, and that is load-bearing for scheduling: discovery
Stage 2 holds the v22-to-v23 bump slot and git Stage 2 is queued behind
it. The activity indicator is a fourth pmacs.statusline.register
provider on the existing StatuslineSegments vector.
The framing also flags a deliberate deviation from the audit rather
than quietly taking it: section 9 names owner/purpose/parent together,
and Stage 1 takes only the first two, because an unpopulated parent
field reads as "no parent" rather than "not tracked".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
fb3974b corrected the ledger --- "eight writes exist; five are
reachable" listed four, the fifth being quit_window's
QuitAction::Restore, proved unreachable and guarded anyway --- but the
framing kept the old count, and the framing is the artifact that
outlives the ledger.
Swept rather than patched at the two known lines. Every count claim
about dedication routes, sites and writes now agrees with the §3 table,
in the ledger's phrasing: four are reachable, a fifth is guarded
defensively, and ALL FIVE ARE GUARDED --- the last being the count the
safety argument actually runs on.
* The section heading said "FIVE WRITES REACH DEDICATION". It now says
four reach it and a fifth is guarded defensively, and the "found
three more" arithmetic is spelled out (two further apply_placement
arms plus the unreachable quit_window site) so the total is legible
as five GUARDED rather than five reachable.
* "all five reachable sites were momentarily unguarded together"
(revision 8's masked contract) --- true of all five GUARDED sites,
which is what that sentence means; the four reachable ones and the
defensive fifth are now named there.
* "Two live guards, five reachable sites" --- two live guards cover the
four reachable sites; site 7 carries a third, defensive guard. There
really are three call sites of panel_commit_dedication_refusal
(editor_core.rs display_buffer and quit_window,
lua_bindings/window_panel.rs set_params), so the old sentence
undercounted guards while overcounting reachability.
* Two "every site in it is still guarded" claims were literally false
of sites 4, 5 and 8 (two harmless Ordinary arms and a unit test).
Narrowed to every site that can dedicate the slot.
* Table row 7's verdict now carries "guarded anyway, defensively", so
the four-plus-one reads off the table itself.
The old count is preserved as history and marked as such --- "not the
current count" --- with the correcting SHA, so a reader who saw the
earlier text knows which way the correction ran.
The miscount had NOT propagated. Repo-wide grep for the phrasing finds
it only here: DEDICATION_ROUTES in
tests/destination_capture_acceptance.rs is a [_; 4] and its doc comment
already said "four and not two"; the framing's own acceptance bullet
already said "which is four and not two"; the ledger was fixed in
fb3974b. No src/ or tests/ comment claims five reachable routes. (The
suite's unrelated "five distinct refusals" of commit_to is a different
count and is correct.)
Documentation only. Gate run twice with --acceptance
destination_capture_acceptance: fmt, clippy, lib-crdt, the destination
capture suite, m4 and gpu green both times; diff-check clean. Each run
had one wall-clock RATIO test fail under load from concurrent gates in
sibling worktrees --- m8_2's 10K-entry render (457ms vs a 200ms budget)
on the first, editor's composition_overhead_under_ten_percent (1.169)
on the second --- a different test each time, and each passes in
isolation on this tree (0.19s and ok respectively). Neither is
reachable from a markdown edit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
panel_commit_dedication_refusal matches on `fid` as well as on the
profile: a nested commit for a DIFFERENT frontend may dedicate that
frontend's own side slot, because resolve_placement consults only the
requesting frontend's panel_capable and its own one side window, so
nothing done to B can change where A's side request lands.
That promise was documented and unpinned. Both revision 9 nesting
tests drive a single frontend, so the comparison is trivially true
throughout them: deleting it, and making any outer "panel" contract
globally restrictive, passed the whole file.
a_nested_commit_for_another_frontend_may_dedicate_its_own_slot runs
two frontends. While an outer "panel" commit for A is in force, a
nested commit for B dedicates B's slot and is ALLOWED --- and B's
slot is asserted really dedicated afterwards, not merely unrefused.
The far side runs in the same test: A's slot stays undedicated and
A's result still lands in A's panel, so the row cannot pass by having
weakened the restriction generally.
This is the suite's only POSITIVE row; every other asserts a refusal,
which is the shape it was thinnest on. An exception only the doc
comment knows about is one review round from being simplified out.
Mutation-checked: deleting `&& contract.destination.frontend == fid`
fails ONLY this test. Both single-frontend nesting tests pass under
it, which is the evidence they are independent of the frontend match
rather than merely looking so. journey_acceptance (47),
dired_acceptance (31) and cargo test --lib (1920) stay green.
Two ledger corrections, both section-local:
* "Eight writes exist; five are reachable" then listed four. The
fifth is quit_window's QuitAction::Restore --- the site proved
unreachable and guarded anyway. It now appears in the list that
justifies it, and the bullet counts what actually matters: all five
are guarded.
* The revision 9 mutation paragraph had the preservation counts
REVERSED (journey 31 / dired 47). It is journey 47 / dired 31,
matching the bullet further up and measured per target. The same
reversal is in 394fa43's commit message; that is left as written
rather than rewriting a pushed commit, and the ledger now says so
where the numbers are, so a reader following the SHA takes the
corrected pair.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 8 refuses, inside a "panel" commit_to, the mutations that
would make its relaxed preflight wrong. A nested commit_to REPLACED
the enclosing contract with its own and restored it afterwards, so
the outer restriction went out of force for the whole inner body:
commit_to(outer, function() -- "panel", relaxed preflight
commit_to(inner, function() -- "document", MASKS the outer
set_params(panel(), { dedicated = true }) -- ...and succeeds
end)
display(result, { side = "bottom" }) -- ...which now FALLS BACK
end, "panel")
Every step is legal on its own, and the outer commit then overwrote
a newer document buffer --- the P1a failure the lane exists to
remove, reached through one extra call.
What this invalidated, precisely: NOT the enumeration of dedication
write sites. Every site in it is real and still guarded. What was
wrong was the claim that the guard was in force for the whole outer
body. So the enumeration is inherited and qualified, not redone.
Contracts now COMPOSE rather than replace. The core holds a stack;
ScopedFrontendGuard pushes on entry and truncates back to its own
depth on every exit path; panel_commit_dedication_refusal consults
every contract in force rather than the innermost. The strictest
active restriction wins. Matching stays per frontend --- a nested
commit for a different frontend may dedicate its own side slot,
which cannot change where this frontend's side request lands.
Nesting itself is NOT forbidden, which was the other candidate fix.
It closes the hole by prohibiting a construction no rule objects to:
commit_to is public Lua API for saying where a continuation's result
belongs, and a body committing to a second destination (a diff
beside a status panel) is where #227's adoption is heading. Only the
restriction needed preserving. Detecting the dedication when the
outer commit resumed was not available either --- that is a late
refusal, which is what revision 7 was rejected for.
Two pins, and they are a pair rather than one test written twice:
* a_nested_commit_cannot_mask_an_outer_panel_restriction drives the
same four write-site rows through a nested, entirely valid
"document" commit, and asserts the attempt is refused, the slot is
still undedicated, and the outer commit's destination is intact.
* an_ordinary_nested_commit_still_runs_and_restores_the_outer_restriction
pins that nesting without dedication is accepted, that the
enclosing restriction is back in force once the nested commit
returns, and that outside every commit dedication is ordinary
again.
Mutation-checked: restoring the guard to the innermost contract
(.last(), exactly revision 8's swapped slot) fails only the first of
those. The other 13 pins, journey_acceptance (31), dired_acceptance
(47) and cargo test --lib (1920) all stay green. The ordinary-nesting
pin deliberately survives it --- it exists to fail the other
candidate fix.
Also sweeps the comments left by revision 7, which revision 8
superseded: no fallback_commit_refusal symbol remains, but six doc
sites still described placement-boundary enforcement as the
guarantee (ViewDestination, CommitProfile::Panel, CommitContract,
capture_view_destination, commit_destination_refusal,
panel_placement_can_fall_back), plus two comment blocks in the
commit_to binding and one stale mutation note in the acceptance
suite. Net rustdoc warnings down three.
Framing to revision 9; the active-work lane entry updated in place.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Levi Neuwirth