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
`required_purpose`'s invalid-UTF-8 refusal told the caller that their
process purpose "is displayed to the user in *workers* and in the
modeline". Neither is a process surface. Stage 1 deliberately keeps
processes out of `*workers*` — which lists async JOBS — and out of the
statusline activity indicator; a process's purpose is exposed through
`pmacs.process.list` and nowhere else, and joining the two planes is
Stage 2's work (framing §3, Q#W-4).
The refusal is correct and stays: a purpose that cannot be displayed
anywhere should still be refused, and nothing spawns either way. What
was wrong is the reason given to the user, which pointed them at two
places their process will never appear. A diagnostic that misdescribes
the system is worse than a terse one, because it sends the reader
looking in the wrong place.
The job-side twin diverges rather than converging. `_push_dispatch_name`
refuses a non-UTF-8 handler name for the same reason, and there
`*workers*` and the modeline are the RIGHT answer — the name is composed
into every job's purpose and a job renders in both. It said only "as
part of every job's purpose", which names no surface at all, so it now
names the two it reaches. The two messages must not collapse into one
sentence: whichever wording won would be wrong on the other side.
Verification. `the_two_utf8_refusals_each_name_the_surface_their_own_text_reaches`
asserts both directions, positive AND negative — the process message
contains `pmacs.process.list` and NOT `*workers*`/`modeline`, the job
message contains both of those and NOT `pmacs.process.list`. The
negative halves are the anti-collapse guard; without them a later
"unify the wording" edit reintroduces exactly one wrong sentence and
passes every other test in the file. The existing row-table assertion in
`spawning_without_a_real_purpose_is_refused_and_starts_nothing` now runs
as far as the surface name too, so the same edit breaks two tests.
Three mutation checks, each red on its own claim: restoring the old
process wording fails both content assertions; collapsing the job
message onto the process wording fails only the new test (which is the
point — the old job test asserted the prefix alone and could not see
it); restoring the job message's original vague wording fails it too.
The doc comments were fixed with the literals. `required_purpose`'s
rustdoc now states which surface its message names and why it names
neither of the other two, and the `_push_dispatch_name` comment states
the converse. A corrected string whose doc comment still argues the
other way is one refactor from reverting itself.
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
Review round 1 on worker identity Stage 1. The lane shipped `purpose` as
a required field on `ProcessSpec` but made it OPTIONAL at the
`pmacs.process.spawn` Lua surface, defaulting to `label`.
**That preserved compatibility and delivered nothing.** `COHERENCE.md`
§9's complaint about `ProcessSpec` is precisely that `label` is
"caller-supplied, unvalidated convention" — so a purpose defaulting to
the label hands every existing caller back the exact convention this lane
exists to replace. The approved framing said required; this makes it
required where callers actually are.
The two fields answer different questions and neither substitutes for the
other. `label` IDENTIFIES — `lsp:rust-analyzer`, a terminal's buffer
name — so two processes running the same binary can be told apart.
`purpose` DESCRIBES: it answers "what is happening", which is what §3's
promise of visible asynchronous work is about, and which a label chosen
for uniqueness routinely does not answer.
**The refusal covers five shapes, not one.** Absent; empty;
whitespace-only; wrong type; and metatable-provided. The middle two
matter because they satisfy the type and defeat the point exactly as
copying the label across would — R42 already rejects whitespace-only
`description`s in the config registry for the same reason, and a required
field that accepts `""` is not required in any sense a reader benefits
from. The read is RAW, matching the posture `stdin` and `group` already
document in the same function: a spec table is plain data, so `__index`
cannot smuggle a purpose in.
Every refusal also asserts **the process list is unchanged**. A
validation that rejects after spawning has already done the thing it was
rejecting.
**This is a BREAKING CHANGE to a public Lua API, taken deliberately and
now rather than later.** Weighed and reported rather than decided
silently: §10 grades extension trust "missing (one class)" and P7 package
lifecycle has not started, so the third-party population calling this
binding is ~zero and the cost of the change only rises from here. Checked
for a reason that would be wrong and found none — `pmacs.process.spawn`
has no API-reference documentation and no stability promise anywhere in
`docs/`; the guide's only mentions are an audit-rule classification and a
pointer to the bundled REPL, and its semver language governs *packages'*
own versioning, not pmacs's Lua surface. `lua_to_spec` has exactly one
caller, so the blast radius is this one binding.
Eleven executable call sites updated, each with a real description rather
than the label copied across — copying it would satisfy the type and
defeat the point as surely as the default did:
builtin/packages/repl/init.lua "interactive <interpreter> session"
builtin/runtime/compile.lua "compiling: <cmdline>"
builtin/runtime/lean.lua "checking the Lean toolchain version…"
tests/fixtures/pmacs-magit/status.lua the full argv, not just the
subcommand the label carries — "git
log" and "git log --oneline -20" are
one label and different work
tests/compile_mode_acceptance.rs (4), tests/m4_acceptance.rs (1),
tests/worker_identity_acceptance.rs (2)
`lean.lua`'s site is the clearest case for the field: its comment said
the label was where "a user wondering why their editor touched `lake`
finds an owner" — one string doing identity AND explanation, which is the
conflation being undone. The label stays a key; the purpose is now the
sentence.
Two references are deliberately NOT updated: `src/audit/mod.rs` and
`tests/m7_9_acceptance.rs` contain `pmacs.process.spawn("ls")` as **audit
fixture source text**. It is lexed by the audit engine, never executed,
and editing it would change what those rule tests scan.
`required_purpose` is extracted rather than inlined because inlining it
pushed `lua_to_spec` past the 100-line clippy bound — the validation has
its own rules and its own rationale, so it gets its own function instead
of an `#[allow]`.
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
`COHERENCE.md` §9 grades the worker model "mechanism without identity",
and §0 names step 11 (background-work ownership) as one of the two
remaining thin ends of the golden journey. The mechanism half is solid —
cancellation, supersession, streaming, frame-aware draining, `*workers*`.
The identity half was absent: `PendingJob` carried no description of what
it was doing, `pmacs.workers.dispatch` discarded the registered handler
name three layers above anything that takes one, and §9's "no progress
indicator exists anywhere" was checkable and true.
Framing: `docs/worker-identity-framing.md` (revision 4, approved).
What lands:
**A required `purpose`, on the job and on the process.** Non-optional,
with no `Default`, so the compiler — not a test — is what proves every
dispatcher supplied one. `allocate` / `allocate_with_resource` collapse
into ONE private `JobSpec`-taking funnel (Q#W-1): the two-function split
existed only because one prior lane needed one extra parameter, and a
second lane doing the same produces `allocate_with_resource_and_identity`.
`register_external` gains a `purpose` parameter rather than deriving one,
because its `JobKind` is `McpRequest`/`LspRequest` for every method — a
category, not a description.
**A dispatch-name ambient (Q#W-2), read at that same single funnel.** The
capture point is Rust, not the Lua wrapper layer, because a handler
reaching straight for `pmacs._async._dispatch_*` bypasses the wrappers
entirely — and those are precisely the callers attribution exists for.
Seven rules; the ones that decide whether it is honest:
- **Rule 1 — the extent is NON-YIELDABLE, and that is ENFORCED.** Both
supported yield APIs refuse inside it, modelled on the `commit_to`
refusal already in `async.lua`. The guards reject BEFORE parking and
reject UNCONDITIONALLY: one placed after `_is_complete` would fire only
when a yield really occurred, passing under test and failing
intermittently in production.
- **A raw `coroutine.yield` is NOT covered, and nothing here claims it
is.** R46 is a convention, and the scheduler inspects the yielded value
only after `coroutine.resume` returns — by which point the coroutine has
already suspended — so no refusal sited in a yield helper is ever
consulted. The residual is recorded in the framing §2 and in the
suite's module docs rather than papered over with a test that would
imply coverage this design lacks.
- **Rule 5 — unwind-safe.** A raising handler still pops. A version that
did not would let one failure poison every later dispatch in the session
with a stale name: the feature would stop failing loudly and start lying
silently. The bracketing also has to preserve the tail call it replaced:
`dispatch` was `return handler(args, opts)` and propagated EVERY return
value, so the pop/rethrow runs behind a varargs boundary rather than a
`local ok, result = pcall(...)` that would silently truncate a
multi-value handler. Varargs rather than `table.pack`, because that is
Lua 5.2 surface and LuaJIT is this project's default backend.
- **Rule 6 — compose, do not replace.** `"<name>: <purpose>"`, because
letting the dispatcher's purpose win loses the third party again and
letting the name win discards the only description of the actual work.
**A statusline activity indicator** — the fourth `pmacs.statusline.register`
adopter, after `mode`, `terminal` and `lsp`. A count plus the OLDEST
in-flight job's purpose ("busiest" is not a defined quantity; jobs carry
no cost estimate), and **absent entirely** when idle rather than a
zero-width segment that costs modeline width forever to say nothing is
happening. Gated by one setting, `ui.activity-indicator` (boolean, default
true, Q#W-6) — a permanently-visible modeline element is a preference
someone genuinely holds on day one. No setting for purpose capture
itself: that is substrate.
**NO WIRE CHANGE.** The indicator rides the existing `StatuslineSegments`
vector, so a fourth provider adds an element, not a variant.
`PROTOCOL_VERSION` and `ADVERTISED_PROTOCOL_VERSION` are untouched — which
is the property that lets this run beside the two lanes holding the bump
slot.
**Q#W-7 — a pre-existing defect, repaired here, and NOT one anybody has
observed.** `Handle:await()` refuses inside `pmacs.window.commit_to`
precisely so a coroutine cannot park with the frontend scope pushed
(Journey Stage 1a, Q#JR14b). But `pmacs.async.yield_to_next_tick()` also
yields, is public, and carried no such refusal — so that invariant had a
second entrance, and a coroutine could produce exactly the misrouting the
`await` guard exists to prevent. It gains both refusals here: the same
supported yield helper, the same invariant, the same edit family, so
splitting it would have preserved a known hole without reducing
integration risk.
**Reachability by a real caller is UNPROVEN.** This was found by reading
the guard family while scouting rule 1, not by reproducing a fault. No
production caller is known to yield through that door inside a commit,
and the test pins the guard rather than reproducing a user-visible bug.
Nobody should later cite this commit as evidence the bug was observed in
the wild. Its witness is a PAIR, like rule 1's: the refusal fires **and**
the commit scope is restored afterwards — a guard that raises while
leaving the scope pushed converts a silent fault into a loud one and
fixes neither.
`journey_acceptance` carries the established `commit_to` pins —
forged-destination refusal, scope-and-restore on normal return and on
raise, the await refusal, delivery to the requesting frontend. It passes
**untouched**, which is what says this closed a gap in Journey Stage 1a's
semantics rather than altering them.
What is deliberately NOT here, and why it is worth saying:
- **No `owner`, in any spelling** — not `origin`, not `subsystem` (§3).
Populated from static per-subsystem constants it would be an origin,
not an owner, and would confidently misattribute third-party work to a
builtin at exactly the point §9 wants attribution. A field that asserts
a falsehood is worse than an absent one. The slot stays empty until P3
can fill it with a real package signal.
- **No `parent`** (Q#W-5). An unpopulated field renders as `None`
everywhere and reads as "this job has no parent" rather than "this
system does not track parents". Stage 3 builds the lifetime model and
the field together.
Consequences worth recording:
- `ProcessSpec::new` takes a third argument. The 40-odd call sites are
almost all tests; the three production ones (LSP, MCP, terminal) supply
real descriptions. `pmacs.process.spawn`'s Lua surface keeps `purpose`
OPTIONAL, falling back to the label — requiring it there would break
every existing caller for no coverage the compiler is not already
providing, and a caller's own label is not a fabrication.
- `pmacs.process.list` gains a `purpose` KEY on each row and enumerates
exactly the same processes (Q#W-4). Terminal PTYs stay hidden: three
acceptance suites use `#pmacs.process.list()` as a leak baseline, and
widening the accessor would inflate all three. Stage 2's unified view
owns that decision.
- `statusline_segments_acceptance`'s builtin-provider inventory grows to
`["activity", "mode", "terminal", "lsp"]`. That assertion exists to
grow when a builtin provider is added.
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
PR #228 review found a correctness gap this lane made reachable. The
GPU dropdown derives its height, its visible window and its
selection-highlight offset from `rows.len()` — ONE logical row per
candidate — while a detail carrying a line break shapes into more
physical lines than that. One such row misaligns every row below it
and the highlight with it. The grid TUI has the same exposure from the
other side: it writes the description into a single-row suffix on the
minibuffer band.
## Why not reject CR/LF at registration
That was the obvious fix. It was implemented, measured, and abandoned
on evidence.
MCP tool registration renders a whole schema block into
`Command.description` — tool text, blank line, `Arguments:`, then one
line per argument (`tests/fixtures/pmacs-mcp-tools/init.lua:272`, a
`table.concat(lines, "\n")`, used at `:496`). And
`tests/m9_6_acceptance.rs:583-598` ASSERTS four of those lines. A
one-line guard in `CommandRegistry::define` fails 36 tests across
`m9_6` (19/25), `m9_7` (16/19) and `m9_8` (1/17), in both feature
configurations, and could only be made green by deleting a shipped
acceptance criterion.
So the one-line constraint goes where the constraint actually is: the
surfaces that have one row. `Command.description` stays free-form,
which it legitimately is.
## The change
`Command::description_first_line` clips to the first CR **or** LF — a
lone CR ends a line too, and an LF-only clip would pass a bare `\r`
straight through to the same surface. Both single-row consumers call
it: the semantic producer filling `MinibufferRow.detail`
(`src/semantic_render.rs`) and the TUI suffix (`src/editor.rs`). A
first line that is empty ships as `None` rather than `Some("")`, which
would draw trailing padding.
No ellipsis or truncation marker, matching the in-tree precedent and
the minibuffer's own width rule.
`describe-command` and `help.list-commands` are untouched and still
report every line. That is what makes this a rendering decision rather
than data loss, and it is asserted, not assumed.
## Precedent, already in this tree
The same MCP fixture clips a tool RESULT to its first line because
"a multi-line set_status would corrupt the row layout"
(`init.lua:277-285`), leaving width clipping to the frontend. Same
hazard class, same resolution.
## Verification
`src/command.rs`: a schema block registers AND clips, in all three
break forms; a single-line description is byte-identical after the
clip; an empty first line clips to empty.
`tests/discovery_stage2_acceptance.rs`: an MCP-shaped description
reaches the TUI band and the GPU row as one line, through the real
prompt path — with the full text still reachable via
`describe-command` asserted alongside, so a clip that deleted the
schema block everywhere would fail rather than pass.
`pmacs-gpu`: one physical shaped line per logical candidate row — the
geometry invariant the dropdown depends on.
Mutation-checked: neutering `first_line` to the identity fails all
four new break-handling tests
(`a_multi_line_description_registers_and_clips_to_its_first_line`,
`a_description_whose_first_line_is_empty_clips_to_empty`,
`a_multi_line_description_reaches_the_tui_band_as_one_line`,
`a_multi_line_description_reaches_the_gpu_row_as_one_physical_line`)
and leaves the two "did not tighten past purpose" tests green.
`Command.description`'s doc comment claimed "one-line", which the MCP
path openly violates. It now states the real contract and records why
a registration guard must not be re-proposed.
`m9_6`/`m9_7`/`m9_8` pass COMPLETELY UNTOUCHED, and are now named
gate suites so that stays on the record.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The lane heading said "no PR yet". It also needs to carry WHY the PR is
merge-blocked, because a reader who finds only "blocked" will treat it
as backlog hygiene and unblock it by rerunning the gate.
The problem is gate integrity. --protocol promises the CRDT workspace
sweep, that sweep has a documented precondition (handoff section 5),
and the script does not run it --- confirmed by reading the plan
emitter, not inferred from the failure. So a --protocol result can be
decided by whether the build directory happened to contain pmacs-gpu
rather than by the diff under test.
It was latent until #225 gave each worktree its own target directory. A
shared target dir usually already had pmacs-gpu built, which satisfied
the precondition by accident and hid the omission.
Unblocking needs both halves recorded: the scripts/gate repair as its
own framing and PR, and then a fresh-target rerun of this branch
protocol gate under the repaired script. A rerun alone would reproduce
the same accident.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
`Command.description` has always been required and has always been
rendered by `help.list-commands`. It was missing at the one moment it
would change a decision: the M-x row. This carries it there.
COHERENCE.md §5's clause "M-x rows are still bare names", per
docs/discovery-stage2-framing.md revision 3.
## The wire half is additive, and the old variant is FROZEN
postcard is not self-describing: enum variants encode by index and
fields by position. Widening `MinibufferPrompt.candidates` in place
would make every v12–v22 peer MIS-DECODE the bytes rather than ignore
them — and gating the widened form at `>= 23` would not rescue them
either, because with only one variant to gate they would receive no
minibuffer message at all. Compatibility requires the old shape to
still exist AND still be sent.
So `MinibufferPrompt` is retained unchanged for `12..=22`, and
`MinibufferPromptRows { prompt, input, cursor, rows, selected, total }`
is APPENDED as the final variant, carrying `MinibufferRow { label,
detail: Option<String> }`. A new row type, not `CompletionPopupRow`,
whose `kind` is an LSP `CompletionItemKind` code with no honest value
for a command (Q#D2-1).
Exactly one of the two reaches any peer, ever. The producer selects on
the session's negotiated version, so the CLOSE necessarily uses the
same family as the OPEN — a rows session closed by a legacy clear
leaves the dropdown on screen forever. The daemon's write loop gates
both directions again, with the legacy gate written as a RANGE
(`12..MINIBUFFER_ROWS_MIN_VERSION`) rather than a floor, so a v23 peer
cannot receive both and double-render.
`ADVERTISED_PROTOCOL_VERSION` stays 20, untouched.
## The TUI half involves no wire at all
`src/editor.rs` contains zero references to `MinibufferPrompt`:
`paint_minibuffer` reads `core.minibuffer` directly. So it reads
`Command.description` from the registry in-process, which is why this
half is independent of the bump.
Clipping is three ORDERED steps (§3.4), and the guarantee is "never a
PARTIAL name", not "the name always survives" — the prompt and typed
input consume the budget first, so the remainder can be too small even
for the bare name. If the whole name does not fit, the suffix is
omitted entirely; only once it fits is a description attempted; a
description that does not fit whole is dropped, leaving today's
`[name]`. No ellipsis stub, and no prefix of a name is ever emitted.
## Verification
`src/protocol.rs` gains this repo's FIRST literal postcard byte
fixtures: `minibuffer_prompt_v12_wire_bytes_are_frozen`, open and
cleared. A round-trip freezes nothing — it encodes and decodes with
the same types, so a field addition leaves it passing while every
shipped peer breaks. Bite-verified: reordering two fields of
`MinibufferPrompt` leaves `minibuffer_prompt_round_trips_through_postcard`
green and fails the fixture.
`line_wrap_facts_encoding_is_unchanged_by_the_v23_build` pins the
PREVIOUS final variant, per the handoff §4 rule that an appended
variant's own round-trip cannot detect a discriminant shift.
`tests/discovery_stage2_acceptance.rs` runs ONE daemon serving a v22
and a v23 session simultaneously, through the real M-x key path, and
asserts each receives its own variant AND ONLY its own — open and
close alike — by collecting every minibuffer message rather than
filtering for the expected one.
No cross-version cache test, deliberately (§3.2):
`SemanticRenderState::for_peer` bakes the negotiated version in at
attach and is dropped at detach, so a cache cannot span two versions.
A test for an impossible condition passes forever while teaching the
next reader that the hazard is real.
Five version assertions updated, each read before editing:
`src/protocol.rs` (the `PROTOCOL_VERSION` tripwire, renamed; and the
v6-floor ladder's accepted/rejected ranges),
`tests/statusline_segments_acceptance.rs`,
`tests/bottom_panel_stage2b_gpu_acceptance.rs`,
`tests/vterm_stage3_acceptance.rs`. No `ADVERTISED_PROTOCOL_VERSION`
assertion fired.
Gates: `scripts/gate --protocol --acceptance discovery_stage2_acceptance`
— all ten green, including the strengthened two-configuration sweep.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 3 was approved 2026-08-09 at 6a9a25d, after the three stale
internal references were cleared. The lane heading and the framing
status line both still said "in review", which is the kind of
contradiction that makes a reader trust whichever line they hit first.
The lane entry now also records WHAT the three review rounds found,
rather than only how many there were. A count says the doc was
reviewed; the list says what class of error it was reviewed for, which
is the part a later reader can act on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 3 corrected the cache model in section 3.2 and the clipping
rule in 3.4, then failed to propagate either. Internal contradictions in
a framing document are worse than the original errors: a later reader
resolves them by picking whichever statement they read first.
- Q#D2-4 still summarised the design as "per-variant cache keys",
contradicting 3.2's corrected one-per-peer model. Now names the
`peer_knows_minibuffer_rows` producer gate and the single per-peer
cache, with a parenthetical recording that the sentence was stale
rather than silently rewriting history.
- Section 6 still required the cross-version cache test that
revision 3 removed as unfalsifiable. Replaced with what IS
assertable --- a v22 and a v23 peer attached simultaneously each
receive their own variant and only their own --- and the bullet
says why the other test is absent, so it does not get "restored"
later by someone who notices the gap.
- The active-work lane still called the framing revision 2.
Swept for the same class of residue from the other two corrections
("the name must survive", "both frontends render"); the remaining hits
are the notes ABOUT those corrections, which are deliberate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three corrections, each to something revision 2 asserted without
checking the mechanism it was reasoning about. All three verified in
the tree.
A ROUND-TRIP FREEZES NOTHING. Revision 2 proposed pinning the legacy
variant with an encode/decode round-trip. That test uses the SAME types
on both sides, so adding a field to `MinibufferPrompt` leaves it
passing while every v12-v22 peer in the field breaks. The existing
`minibuffer_prompt_round_trips_through_postcard` (src/protocol.rs:2363)
is precisely that shape, and there are NO literal byte fixtures
anywhere in the protocol tests today --- checked, not assumed. Only
`assert_eq!(encoded, LEGACY_BYTES)` against bytes captured now can fail
when the encoding changes. Two fixtures, open and clear, matching the
shapes the semantic test already covers so the corpus is not a fresh
judgement call.
THE CACHE HAZARD I DESCRIBED CANNOT HAPPEN. Revision 2 argued for a
per-variant cache key on the grounds that a peer reconnecting at a
different version could have its first message suppressed as a
duplicate. `SemanticRenderState::for_peer(frontend_id,
negotiated_protocol_version)` is created PER PEER with its version
baked in on attach (src/daemon.rs:2080) and removed on detach (:1591),
so a cache never spans two versions and reconnecting creates a fresh
state. One per-peer cache stands; the selection is a producer gate,
`peer_knows_minibuffer_rows`, alongside the four such gates that
already exist (:1410-1435). The test for the impossible condition is
REMOVED rather than written --- a test that cannot fail passes forever
and teaches the next reader that the hazard is real.
The matched open/close family requirement is independent of caching and
stands unchanged.
"THE NAME MUST SURVIVE" IS NOT ACHIEVABLE. Prompt plus typed input
consume the width budget first, so the remaining suffix space can be
too small for even the bare name --- and revision 2's rule would then
have forced a partial name, which reads as a DIFFERENT command. The
rule is now ordered: if the whole name does not fit, omit the suffix
entirely; only once it fits is a description attempted; if the
description does not fit whole, drop it. The guarantee becomes "never a
partial name", which is achievable, rather than "the name always
survives", which is not. Witnessed at three widths.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
COHERENCE.md section 5 grades discoverability Partial after Stage 1 and
names "M-x rows are still bare names". The descriptions ALREADY EXIST
--- `Command.description` is required, and `help.list-commands` renders
them --- so this is substrate without surface in its purest form: the
information is present, surfaced elsewhere, and absent from the one
moment it would change a decision.
TWO REVISION-1 CLAIMS WERE WRONG, both checkable in the tree:
- "Change `candidates` in place and gate at >= 23." Postcard is NOT
self-describing: fields encode positionally, so a v22 peer decoding
`Vec<MinibufferRow>` where it expects `Vec<String>` mis-reads the
bytes rather than skipping them. And gating would not have rescued
it --- with only one variant to gate, a v12-v22 peer would have
received NO MINIBUFFER AT ALL. That variant goes to every peer
negotiated >= 12 (src/daemon.rs:1472).
Revision 2 is additive: `MinibufferPromptRows` APPENDED to the enum
(indices are positional; inserting renumbers everything),
`MinibufferPrompt` frozen for v12-v22, per-peer selection, per-
variant cache keys, and close matching the open's family --- a
mismatched close is how a popup stays on screen forever.
- "Both frontends render label + detail." The grid TUI never reads
`MinibufferPrompt`; src/editor.rs contains ZERO references to it.
It paints from `core.minibuffer` and renders the selected candidate
as `format!(" [{cand}]")` (src/editor.rs:5484). The rich wire
reaches pmacs-gpu only.
So the TUI half is a LOCAL formatting change --- it is in-process
with the core and reads `Command.description` from the registry
directly, with no wire involvement. The contract is pinned
including clipping: THE NAME SURVIVES AND THE DESCRIPTION IS
DROPPED at narrow widths, because a clipped name is strictly worse
than today's bare one. A multi-row TUI chooser is explicitly not
this lane.
This lane HOLDS THE BUMP SLOT. Git Stage 1 is no-wire and runs beside
it; git Stage 2 needs a bump and must wait.
Q#D2-5 records a trap that arrives with the feature: richer rows make
M-x LOOK like a closed set, inviting someone to make acceptance reject
unmatched input. Completion is assistance, not validation ---
`resolve_accepted_value` returns literal typed text by design --- so
that would be a behaviour change, not a rendering one, and it is out of
scope.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
`latex_within_boundary` answered a question about path COMPONENTS with
string arithmetic:
dir:sub(1, #boundary + 1) == boundary .. "/"
With a `/` boundary the needle is `"//"`, which no canonical path
begins with. Every ancestor was therefore judged out of bounds, the
marker walk never examined a single directory, and each chapter of a
thesis got its own root — two texlab processes for one document tree.
The lane's headline behaviour, silently off, with all fourteen shipped
tests still green because every one of them clamps the boundary to its
own tempdir.
Fixed by comparing segments rather than characters, so the root is a
boundary with zero segments — containing everything by construction
instead of by a special case, and tolerating a trailing separator for
free. The same root-is-special trap sat at two other points on the same
path and is closed with it:
* `latex_parent_of` returned nil for a top-level directory, making `/`
the one directory the walk could never examine — the identical bug
from the far end. It now yields `/`, matching `walk_for_marker`'s
`Path::ancestors` on the Rust side, and still terminates because `/`
has no component to strip.
* `latex_root_for` sliced `/paper.tex` to an EMPTY directory, which
canonicalizes to nothing and made the resolver DECLINE — and a
decline is the one path that falls through to `pmacs.project.detect`,
whose walk includes `.git`. A document at the filesystem root now
roots at `/`.
* `latex_marker_in`'s join is guarded for `dir == "/"`, which this
change makes reachable for the first time; the naive form produces
`//name`, the one spelling POSIX leaves implementation-defined.
Two new pins plus a strengthened one, 16 tests:
* `two_chapters_share_one_server_under_a_root_search_boundary` — the
defect end to end through ATTACH, not on the predicate, because the
symptom is two servers rather than a wrong string. Restoring the old
comparison fails exactly this test, with the two-server output.
* `latex_root_walk_stops_at_the_search_boundary` now asserts BOTH
directions. "Stops at the boundary" is also satisfied by a walk that
never runs — which is precisely what a `/` boundary produced — so the
hermeticity property (R8's shape: a stray `latexmkrc` above the
tempdir must stay invisible) is now paired with the walk still
climbing to, and examining, the boundary directory itself.
* `latex_root_for_a_document_at_the_filesystem_root_is_the_root`.
Also corrects `docs/active-work.md`: §3 no longer awaits a revision 3 —
`b5eaf27` IS revision 3 — and the lane entry now records that boundary
handling has been this resolver's interesting part twice, so a reader
weighing whether to trust it knows where to look first.
Gates: ALL GREEN via `./scripts/gate --acceptance lsp_latex_acceptance`.
`/tmp` on this machine is a near-full tmpfs and three grep tests fail
there with `QuotaExceeded`; the green run used
`TMPDIR=/home/jeans/build/pmacs-gate-tmp/lsp-latex`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The .texlabroot caveat is discharged, and discharging it falsified the
reasoning behind it.
.texlabroot is real, and texlab marker set is wider than this document
listed --- the bare texlabroot and latexmkrc spellings count too, and
the walk takes the innermost. The implementation ships texlab own set.
But the caveat framed marker 1 as conditional on texlab honouring the
FILE, which was the wrong question. Every arm of texlab ancestor walk
searches documents already loaded, and that workspace is built from the
folders the CLIENT supplies. Observed: with rootUri at chapters/, no
ancestor marker widened texlab view and its dependency graph never
reached the parent document; with rootUri at the marker directory the
parent resolved either way.
So texlab honours the root it is handed and never corrects a too-narrow
one. config.latex.root IS the project scope, which makes the resolver
the whole value of the lane for a multi-file thesis rather than a
nicety --- the opposite of how section 2 "Slice 1 is one config entry"
reads.
Second correction, and this one was a real trap. Revision 2 said .git
is deliberately excluded from the walk and stopped there. Omitting it
is not sufficient: project_root_for falls through to
pmacs.project.detect when a resolver returns nil, and that walk lists
.git among its markers at src/project.rs:184. A resolver that politely
declined on a markerless file would hand texlab the monorepo by the
back door, with the exclusion looking correct at every line you would
think to read. The resolver never declines for a file with a directory,
and the fixture asserts the shared detector really would have answered
the repo root so the pin cannot pass vacuously.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Section-local edit to the lane's own block in `docs/active-work.md`.
The heading moves from "BRANCHED, framing in review" to "IMPLEMENTED,
gates green, no PR yet", and the §3 `.texlabroot` caveat is written up
as discharged rather than merely resolved: what texlab actually does,
how it was observed, and the one place the framing now reads stale.
The substantive finding recorded here is not "the marker works". It is
that texlab's own root walk only sees markers belonging to documents
already in its workspace, and the workspace comes from the folders the
client supplies — so texlab honours the root pmacs hands it and never
corrects a too-narrow one. That makes `config.latex.root` the project
scope rather than a hint, which is worth carrying forward whether or
not anyone rereads the framing.
Also recorded: the shared-`CARGO_TARGET_DIR` trap, because a bare
`cargo test` in this worktree fails with compile errors from a sibling
lane's code and reads exactly like a broken branch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Framing: `docs/lsp-language-coverage-framing.md` (revision 2, §3 and
§6). One `pmacs.lsp.config.latex` entry — command `texlab`, args none,
a function-valued `root`, and deliberately nothing else.
STEP ZERO: the §3 caveat, discharged by observation.
Revision 2 marked marker 1 (`.texlabroot`) UNVERIFIED and blocking:
only texlab's version and CLI had been checked, and the CLI exposes
just `run` / `inverse-search`. Driving a minimal LSP client against
`texlab run` by hand, plus reading texlab's own source at the exact
installed tag, settles it — and corrects the premise underneath it.
`.texlabroot` IS a real marker. `crates/distro/src/language.rs` at
v5.25.1 maps `.texlabroot`/`texlabroot` -> Root, `Tectonic.toml` ->
Tectonic, `.latexmkrc`/`latexmkrc` -> Latexmkrc, and
`ProjectRoot::walk_and_find` (`crates/base-db/src/deps/root.rs`) walks
ancestors testing all three, innermost wins. So the shipped marker set
is texlab's own rather than a plausible-looking guess, and marker 1
stays.
But texlab CANNOT apply that walk to rescue a root pmacs gets wrong.
Each arm of `walk_and_find` searches `workspace.iter()` — documents
already loaded — and the workspace is built from the folders the CLIENT
supplies. Live sessions confirm it: with `rootUri` at a `chapters/`
subdirectory, no marker above it (`.texlabroot` included) widened
texlab's view, and its dependency graph never reached the parent
document; with `rootUri` at the marker directory the parent resolved,
marker present or not. texlab honours the root it is handed and never
corrects a too-narrow one.
That inverts the significance of the resolver rather than weakening it:
whatever `config.latex.root` returns *is* the project scope. It is the
whole value of the lane, not a nicety.
Also observed, because the entry depends on it: bare `texlab` serves
LSP over stdio — `initialize` returns `TexLab 5.25.1` with no
subcommand — so `args = {}` is right and `run` is not needed.
WHY `.git` IS EXCLUDED, AND WHY THAT IS NOT AN OMISSION.
texlab wants the document root; a thesis inside a monorepo must not get
the monorepo. The subtlety is that leaving `.git` out of the marker
list does not achieve this on its own. `project_root_for` falls through
to `pmacs.project.detect` when a resolver returns nil, and that walk
does include `.git` — so a resolver that declined on a markerless file
would hand texlab the repository root by the back door. The resolver
therefore never declines for a file that has a directory: no marker
means the file's own directory, which is also framing marker 4. The
acceptance pins this end to end through attach, not just on the
resolver's return, and asserts in the same fixture that the shared
detector really would have answered the repository root.
NO FILETYPE MAPPINGS, per revision 2 §2 — verified, not inherited.
`src/syntax.rs` already declares `name: "latex"` with `extensions:
["tex", "latex", "sty", "cls"]`, and grammar-extension detection sits
ahead of the LSP filetype map in `detect_buffer_language`
(`syntax.lua`). A `.tex` buffer already resolves to `latex`. The suite
asserts both halves — the extensions resolve, and `pmacs.lsp.filetypes`
is empty for them — so a later "helpful" addition cannot be mistaken
for the thing that made attach work.
Q#LX1: no `settings`, no `init_options`. Build-on-save and
forward-search are both opinionated and forward-search needs a
configured viewer.
Fixtures bound detection with `pmacs.project.set_search_boundary` and
assert the boundary took — R8's hazard is exactly this fixture's shape,
and one test pins the walk stopping at the boundary directly. Attach
fixtures use `pmacs_fake_lsp`, and the missing-server fixture an
asserted-absent path: texlab is installed on this machine, so relying
on either its presence or its absence would behave differently here and
in CI.
Verification: fourteen tests, one per §6 bullet plus the boundary and
decline cases. Seven mutations each fail the suite — resolver declining
on no marker (6 tests), no marker walk (4), a redundant `filetypes.tex`
(1), boundary ignored (1), `io.open` truthiness so a directory counts
as a marker (1), marker set narrowed (4), command renamed with
opinionated settings added (1).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Recorded as "implementation authorized" rather than "approved", because
that is what happened: the user authorized dispatch after a summary of
revision 2 four corrections, not after returning findings on the
document the way they did for the other four lanes.
The distinction matters for one reason. Section 3 .texlabroot caveat is
unverified and blocking --- texlab 5.25.1 is installed and its version
and CLI were checked, but the CLI exposes only run and inverse-search,
so its LSP-level behaviour was never established. A framing marked
plainly "approved" invites a reader to treat that caveat as settled
prose. It is step zero of the work.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 1 was untracked, on main, in a single checkout. By the handoff
own rule --- work is portable only after it is committed and pushed ---
it did not travel. Committing it here is the first fix.
Three factual corrections, all from checking rather than reading.
haskell-language-server IS installed on this machine, along with its
wrapper. Revision 1 said it was not, and that claim was the entire
basis of its Slice 1 / Slice 2 split. Only OCaml still lacks a server.
The argument for leaving Haskell out survives, but on use evidence ---
the .hs files are a rarely-edited Hakyll generator --- not on
dependency cost.
Slice 1 is smaller than framed. Revision 1 proposed filetype mappings
for .tex/.latex/.sty/.cls "so highlighting and LSP agree on what a
LaTeX file is". They already agree, by construction: the grammar
carries exactly those extensions at src/syntax.rs:1111,
grammar-extension detection sits AHEAD of the LSP filetype map in the
precedence chain per the merged grammar framing at :166-171, and
lsp.lua:267-270 calls the filetype map "mainly the LSP-only fallback".
The real missing piece is one config entry.
Q#LX3 deferral argument read a stale line. COHERENCE.md:124 and :867
both record multi-root LSP affinity as merged in #161; only :1669 still
says "first slice in flight", contradicting the same document twice.
The one item revision 1 said could justify deferring therefore
dissolves. The COHERENCE.md inconsistency is real and is left for
whoever next touches section 20 rather than smuggled in here.
Q#LX2, which revision 1 called the question most likely to make the
entry wrong in practice, is now answered rather than shrugged at. An
upward marker walk through config.latex.root, which already accepts a
resolver function. .git is deliberately excluded: a repository root is
the wrong answer for LaTeX, since texlab wants the document root, and
this is the one place where copying the other fourteen entries
instinct would be actively wrong.
The .texlabroot marker is marked UNVERIFIED and blocking. texlab 5.25.1
is installed and its version and CLI were checked directly, but the CLI
exposes only run and inverse-search, so its LSP-level behaviour was not
established. Confirm against a live session before implementing. Same
discipline the gate-protocol-build lane applies to its own
precondition: the thing the design rests on gets observed, not
reasoned about.
Also renumbered Q#HS1 to Q#LX4, because revision 1 Q#LX2 collided with
a live question ID in the merged grammar framing for the same language.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three corrections. The first two are the same error in two rows.
I wrote each control as if it DECIDES, when each is informative in only
one direction.
U4: extending the deadline establishes "emitted late" IF the clear
arrives. If it does not arrive, that establishes only "not observed by
the longer deadline" --- not "never emitted" --- because transport loss
produces the same absence. No deadline, however long, separates
non-emission from transport loss. That needs producer-side emission
evidence, did pmacs write the clear, cross-checked against the
collected stream. The row now states both branches and names what the
negative branch cannot conclude.
U5: one isolated run cannot decide whether the gate suite is
implicated. A matching isolated RED proves the gate suite is not
necessary for the failure. An isolated GREEN proves nothing beyond that
run, because the failure is intermittent and absence under one run is
not evidence of dependence. I had written it as though either outcome
settled the question.
This is worth naming as a class rather than two typos: a control whose
positive branch is conclusive and whose negative branch is not, written
up as though both were, is how an inconclusive result gets recorded as
an exclusion. Two rows in this file had it.
Third, minor: "three docs" was accurate at the occurrence tip and is
not now --- #229 has since added this registry file. Replaced with
"documentation" so the claim does not rot again with the next commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Four review findings, all mine.
Normalization. The byte count and the :LINE suffix are
occurrence-specific --- the count is the collected suffix length, which
varies per run, and the line moves with the file --- so neither can be
a required fragment. Both rows now carry stable fragments and an
explicit NOT-fragments field naming what must not be matched on.
The LuaJIT-pass argument was the rejected overreach again. I used a
passing sibling leg as a STRUCTURAL exclusion; a deterministic defect
can be Lua-flavour-specific, so it is corroboration only. The row now
says so in those words. The real grounds are stronger anyway and were
sitting there: the workflow never invokes scripts/gate, and
full_grid_resync_acceptance runs BEFORE the changed gate suite, which
closes even the leaked-state path.
Three contradictions inside U4, each removed.
"It never emitted the blank" asserts a mechanism the next field
simultaneously calls open. Now: no blank was OBSERVED after the mark
within the deadline.
The 25,362 bytes were not a capped window. suffix.len() is the ENTIRE
post-mark output; only the displayed head is truncated, to 400 bytes.
Verified in the test source. So my control --- capture the full stream
rather than the window --- was solving a gap that does not exist. The
gap is arrival TIME, and the control now instruments that instead.
The ~20s failure duration IS the fixed Duration::from_secs(20) timeout,
so the ratio against a fast pass is mechanically determined and is not
independent timing evidence. Also verified in the source.
U5 control relabelled. Running m5_8_acceptance alone decides whether
the gate suite is implicated --- cross-suite attribution --- and
nothing more. It cannot separate injected-before-raw-mode from
raw-mode-lost from a third cause, and another isolated pass cannot
either however often it is repeated. Mechanism discrimination needs
readiness and raw-mode state observed AT INJECTION, which is now a
second, separately labelled control.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
PR #229 first CI run went red on Test (macos-latest / lua54) with
a_pty_resize_blanks_the_host_before_repainting. The rerun turned that
selector green in 0.50s against 20.26s failing, and went red on a
DIFFERENT selector, ctrl_c_during_reconnect_sleep_yields_clean_exit.
Per this file matching rule that is a new incident, not the resize
signature occurring twice, so they are two rows.
U4 records the resize failure with its exact fragments. The diff is
excluded on two structural grounds that do not depend on a rerun: #229
touches no src/ at all and no test but gate_script_acceptance, and the
sibling luajit leg passed on the same commit. A deterministic platform
defect fails both flavours --- that is how #227 non-UTF-8 fixture
presented.
U5 records the Ctrl-C failure at deliberately WEAKER exclusion
strength, and says so in its own field. The changed gate suite ran
earlier in the same job and creates worktrees and directories. No
leaked child or persistent signal-state mutation was observed, but "the
diff touches no src/" is not the same argument here as for U4, because
cross-suite leaked state is a path reachability reasoning does not
close. Its control is to run m5_8_acceptance alone, without the gate
suite ahead of it, before attributing anything either way.
Neither row claims a mechanism. The exit status shows only that Ctrl-C
arrived as SIGINT rather than as the raw-mode key event the test
drives; whether injection preceded raw mode, raw mode was lost, or
something else happened is open, and the fragment does not separate
them.
Also flagged: worker-identity-stage1 independently defines its own U4
and U5. This lane merges first, so that branch must renumber on rebase
--- a conflict resolved textually without renumbering would leave two
different incidents sharing an id, which is the failure the matching
rule exists to prevent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 5's ledger edits were written while the witness was still the
open blocker, and landed alongside the commit that closed it --- so the
entry asserted both at once: an OPEN BLOCKER bullet saying this lane
"currently ships without the regression guard it was created to
provide", and, further down, that same gap closed at 677fd25. A
recovering machine reads the top of an entry first, so the stale half
is the half that gets acted on. Reconciled in place: the heading, the
framing bullet and the blocker bullet now say re-opened by review and
CLOSED at 677fd25, and point at the bullet that closed it.
The script header cited framing revision 4; it is revision 5.
Also recorded, from auditing whether any OTHER assertion in that suite
is detached from the thing it names: renaming every other plan step ---
fmt, clippy, lib, m4, gpu, sweep, diff-check, acceptance-<suite> ---
leaves all 20 tests green. For most that is only a log filename and a
FAILED: entry. `sweep` is not: the runner's end-of-run listing globs
*-sweep.log and *-sweep-crdt.log, so renaming that step silently
empties the "read these, do not re-run and grep" listing that is the
U2/U3 remedy, with the suite still green. Left open deliberately and
said so --- that listing exists only on the RUN path, and every test in
this file is no-gates by design, so there is no cheap witness for it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Revision 4 said it would close the rename hole for the sweep as well as
the build, and then did not: its verification bullet required only a
singular real-plan pair in the context of build-crdt. The hole is
symmetric --- renaming sweep-crdt slips through exactly the same gap
--- so section 7 now pins BOTH emitter pairs explicitly, name and exact
command, asserted from the emitter where the name still exists.
Two older bullets also still claimed named steps appear in
--print-plan. They do not; that mode prints commands only, which is the
wording that let the attribution witness drift away from the step it
names in the first place. --print-plan is now described as the command
and order witness, and nothing more.
The ledger recorded revision 4 as approved and implemented, and
presented the synthetic self-test as the attribution witness. Both were
read as done. A recovering machine or a PR preparation from that entry
would have shipped this lane without the regression guard it exists to
provide.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The lane exists to guarantee two things --- that the crdt sweep is
preceded by the build producing its binary, and that a build failure is
attributed to `build-crdt` rather than to `sweep-crdt`. It shipped with
neither guaranteed, because NEITHER WITNESS COULD SEE A NAME.
--print-plan renders `emit_plan | cut -f2-`, so the ordering test
compared commands and never saw the names beside them.
--self-test hardcodes the string `build-crdt` inside its OWN synthetic
plan, so it proves things about the runner and nothing about the real
emitter.
Review demonstrated the consequence: renaming the real build step to
`sweep-crdt` left both tests passing --- a plan that would report a
build failure under the sweep's name, sitting green, which is exactly
the misattribution the separate step exists to prevent.
--print-plan-named prints emit_plan VERBATIM: the same `name<TAB>command`
text the runner reads back from PLAN_FILE. The new assertion compares
WHOLE LINES against it, so name and command are pinned together and a
rename of either step fails. The sweep's own pair is asserted too ---
asserting only the build's name leaves the identical hole open in the
other direction.
WHY A RENDERING AND NOT A SEAM. PLAN_FILE stays uninjectable: a test
that supplied the runner's plan would turn its `eval` into a general
command executor, the same class of defect this script's own review
caught in --acceptance and fixed with a parse-time refusal. Re-deriving
the plan test-side would be a second implementation of the thing under
test, which is the failure being repaired one level up. A distinct mode
rather than a --with-names modifier leaves --print-plan's contract ---
runnable lines --- exactly as it was, and defines no flag combination
that has no meaning.
--self-test STAYS. It witnesses the runner: failure naming, the FAILED:
list, log paths, non-zero exit, and continuation past a failure via the
sentinel. That is a different thing from attributing the real step, and
what it may no longer do is stand in for it.
A second test pins that the two renderings are one plan --- the stripped
one is the named one minus its names --- so a later edit giving either
mode its own text is caught rather than leaving an assertion on a name
the runner never uses. It also pins the `name<TAB>command` shape the
runner's `IFS=<tab> read` depends on.
Both new tests stay on the no-gates paths, so the suite stays cheap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Review mutated the REAL build step name to sweep-crdt and both existing
witnesses still passed. That is the gap: --print-plan strips names
before printing, so the order assertion sees only commands, and
--self-test hardcodes build-crdt inside its own synthetic plan. Neither
witness is connected to the step it claims to describe, so this lane
shipped without the regression guard it exists to provide.
Section 7 now requires asserting the real emitter (name, command) pair
together, so a rename cannot pass. The synthetic failure and
continuation test stays --- it tests the runner, which is a different
thing --- but it can no longer stand in for attribution of the actual
step.
Also fixed the header, which read "Pre-implementation. Awaiting
approval" through three revisions while the ledger recorded this lane
as approved and implemented. That is the same contradiction class this
project keeps correcting elsewhere, left standing in the document that
keeps correcting it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The acceptance criterion is witnessed: `scripts/gate --acceptance
gate_script_acceptance --protocol` on a target root that did not exist
beforehand goes green in all eleven steps, with `09 build-crdt ok`
producing `debug/pmacs-gpu` and `gpu_invocation_acceptance` at 15
passed / 0 failed where the same suite is 3 / 12 without the build
step. No manual build anywhere, which is the thing that was false.
An EARLIER attempt at that same cold run went red, and it is recorded
rather than dropped once a later run was green. Fifty failures across
m5_5/m5_6/m5_7/m5_8 --- all real-daemon suites --- with the signature
"daemon exited with exit status: 101 before socket appeared;
socket=/tmp/.tmpXXXX/pmacs.sock" and an EMPTY daemon stderr. Not the
pmacs-gpu signature, and no row in docs/ci-red-signatures.md matches
it.
Re-running the same test binary from the same target directory gave
36/36. Per that registry's own rule a green rerun establishes
INTERMITTENCE ONLY, never environmental cause, so this is left open
rather than blamed on the load it happened under.
What DOES rule out this lane's change is a construction argument, not
the rerun: the root crate declares `default = ["luajit"]`, so
`--no-default-features --features luajit,crdt` enables exactly the same
feature set as the sweep's `--features crdt`. `build-crdt` cannot hand
the sweep a differently-featured binary, so it has no mechanism by
which to break a daemon suite.
Also records that the new assertions were mutation tested --- wrong
features, wrong position, unconditional emission, an aborting runner,
and the build folded into `sweep-crdt` each fail the suite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Found by mutation-testing the assertion rather than by reading it.
Emitting `build-crdt` AFTER `sweep-crdt` does fail the test --- so the
position criterion was never vacuous --- but it failed by panicking
inside the slice with
begin > end (427 > 282) when slicing `cargo fmt --check ...`
which names neither step and reads as a bug in the test. A gate test
whose failure has to be decoded is a gate test nobody trusts, and this
suite exists precisely to be trustworthy about the gate.
An explicit ordering assertion ahead of the slice says what is wrong:
the build must run before the sweep, because a sweep that builds its
own precondition afterwards has already failed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The durable half of this lane is a boundary question, not the missing
line. `scripts/gate`'s header names handoff section 3 as the owner of
its reasoning, and this precondition lived in section 5's hazard
register --- a coherent cause for the omission rather than mere
oversight. A requirement the script was never told to encode is one it
will keep not encoding.
So section 3 gains it NORMATIVELY: the build joins the protocol-bump
block as a third line, with its own load-bearing bullet covering the
mechanism (pmacs-gpu has no tests/ directory, so cargo never uplifts
its bin), the measurement that makes it conditional, and why it was
latent until per-worktree target directories stopped hiding it.
Section 5 keeps the INCIDENT and its signature, which is history rather
than contract, and now says so: twelve
`gpu_invocation_acceptance::crdt::*` failures on a target directory
with no `debug/pmacs-gpu`, first seen on PR #228's first gate run.
Recast so that seeing the signature again reads as "the script was
bypassed", not "the requirement moved".
The script's header keeps citing section 3 and ONLY section 3. Citing
both would split one executable contract across two homes and weaken
the script's only clean boundary at the same time as Q#GR-4 declines to
build any automated check for prose drift. A boundary that is neither
enforced nor singular is not a boundary.
The ledger records Q#GR-1's observed answer rather than the question:
both sweeps run alone from the same cold disposable target with
`debug/pmacs-gpu` asserted absent beforehand --- default exit 0 with
the binary still absent afterwards, crdt exit 101 with exactly twelve
failures --- plus the silent-skip finding, which is the part nobody was
looking for: a54 reported `ok` in that cold crdt sweep because its only
non-spawning path is its skip branch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
`scripts/gate --protocol` emitted `sweep-crdt` with no build step. The
crdt sweep spawns `pmacs-gpu` as a process, and nothing in a
`cargo test` run produces that binary --- `pmacs-gpu` has no `tests/`
directory, so cargo never uplifts its bin to `debug/pmacs-gpu`. On a
cold target directory the sweep therefore fails twelve
`gpu_invocation_acceptance::crdt::*` tests on "build pmacs-gpu before
this acceptance suite".
The hazard was never the red gate. Before per-worktree target
directories (#225) every worktree shared one, which nearly always
already held the binary, so the precondition was satisfied BY ACCIDENT
for the whole life of that arrangement --- a GREEN `--protocol` run
whose crdt sweep was decided by the state of the build directory rather
than by the diff.
Q#GR-1 SETTLED BY OBSERVATION, not by reading. On a disposable target
directory with `debug/pmacs-gpu` asserted ABSENT before each run
(recorded, not assumed), each sweep run alone from the same cold state:
default cargo test --workspace --no-fail-fast -- --skip basedpyright
exit 0, 114 test targets green, and `debug/pmacs-gpu` was
STILL ABSENT afterwards --- the default sweep never builds it
and never needs it.
crdt cargo test --workspace --features crdt --no-fail-fast
-- --skip basedpyright
exit 101, exactly twelve failures, all
`gpu_invocation_acceptance::crdt::*`, matching the signature
handoff section 5 recorded.
So the step is conditional on `--protocol`, which the framing voted for
on an inference this run confirms rather than assumes.
Also observed, and worse than the twelve: `a54_real_daemon_real_pty_and_
headless_gpu_render_one_panel_hosted_terminal` reported `ok` in that
same cold crdt sweep. Its only path that does not spawn `pmacs-gpu` is
its skip branch, so a test whose whole purpose is real wgpu rendering
passed having rendered nothing. The missing build does not only fail
twelve tests --- it silently voids coverage in tests that report green.
A NAMED STEP, NOT A FOLDED COMMAND. `cargo build ... && cargo test ...`
would report a BUILD failure under the name `sweep-crdt`, a wrong
attribution in the one place this script exists to be trustworthy
about.
`--self-test` is how that attribution is witnessed at all. The existing
suite drives only no-gates paths, so plan assertions can prove a step's
name and order and NOTHING about what the runner does when a step
fails. The mode runs a HARDCODED three-line synthetic plan through the
real runner: a passing step, a failing one named `build-crdt`, and a
passing SENTINEL after it. The sentinel is load-bearing --- with the
failure last, an aborting runner and a continuing one produce identical
output, so the witness would pass on a runner doing the opposite of the
stated policy.
The plan is a literal inside the script. Making `PLAN_FILE` injectable
would work and would turn the runner's `eval` into a general command
executor --- the same defect this script's own review caught in
`--acceptance` and fixed with a refusal at parse time.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Two findings, both about a claim that could not be falsified.
The --self-test plan put the failing step last. With the failure last,
a runner that ABORTS on failure and one that CONTINUES produce
identical output, so the witness for Q#GR-2 policy --- the suite keeps
going --- would have passed on a runner doing the exact opposite. The
plan is now three lines with a passing SENTINEL after build-crdt,
asserted to have written its own log. That is the only thing that
distinguishes the two behaviours, and it turns Q#GR-2 from a declared
policy into an observed one.
The plan test also now pins the EXACT command, not only the step name
and its position. A build-crdt running plain cargo build would leave
the gate exactly as unsound while looking repaired --- the crdt sweep
needs those specific features, which is the whole defect.
The ledger still recorded the superseded boundary decision: "section 3
gains it, section 5 keeps the incident, and the script cites both".
Revision 2 replaced that with section 3 as the sole normative home and
the script citing section 3 alone. active-work.md is the volatile
cross-machine record, so a recovering machine reading the stale entry
would have rebuilt revision 1 wrong boundary. Now updated, and it says
which decision it supersedes rather than silently replacing it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three review findings.
The normative build requirement goes entirely into handoff section 3.
Revision 1 proposed section 3 gaining it while the script header cited
both sections, which splits one executable contract across two homes
and weakens the single clean boundary the script has --- at the same
time as Q#GR-4 declines to build any automated check for prose drift. A
boundary that is neither enforced nor singular is not a boundary.
Section 5 keeps the incident and its signature, which is history rather
than contract.
Q#GR-1 observation procedure was unsafe and insufficient. "Delete
pmacs-gpu from a target directory" mutates a live worktree build
directory, and removing one binary does not establish that the other
artifacts and feature permutations are cold --- a stale dependency
graph can satisfy the run for reasons the experiment never sees. Now: a
disposable target, the binary asserted ABSENT before each run as a
recorded precondition, and the two sweeps run separately so neither can
be explained by the other having built the binary first. That last
point is the same accident that hid this defect for the whole life of
the shared target dir.
The attribution criterion had no feasible witness. gate_script_acceptance
deliberately runs no gates, so plan assertions prove name and order and
nothing about runtime behaviour. The obvious seam is a trap: making
PLAN_FILE injectable would turn the script into a general command
executor through its runner eval --- the same class of defect this
script own review already caught in --acceptance and fixed with a
parse-time refusal. Reintroducing it one lane later, in the tool whose
purpose is to be trustworthy, is not a trade worth making.
Q#GR-5 proposes --self-test over a HARDCODED two-line synthetic plan,
true and false, with the failing one named build-crdt. No injection,
no real gate, and it tests the thing actually under test: whether the
runner names the right gate when a command fails. Whether cargo build
really fails is cargo business.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Levi Neuwirth