Two holes in revision 14, both found by review of this lane's own first
commit, and both would have been discovered during implementation at
much greater cost.
Q#LL7 --- the mode never reached the GPU. Section 4 resolves
ui.line-wrap into Viewport, which reaches the GRID renderer. The GPU is
not a grid consumer: it lays out locally, ignores CellDelta,
BufferSnapshot carries only CRDT bytes, and no InstanceMessage variant
expresses a wrap mode. So truncate would have changed the TUI and left
the GPU wrapping --- the two frontends still disagreeing, which is the
one thing this lane exists to fix. Q#LL5's "character wrap in both" was
equally unreachable: setting Wrap::Glyph at startup is not honoring a
mode that can change.
Specified as an additive variant at v22, appended after the current
final variant with the advertised baseline left at 20 --- the path
FontFacts took at v17 and the panel shapes at v21, and the baseline
constant's own doc reserves moving it for changes that cannot be
expressed additively. This one can.
It carries buffer_id, and is resent on attach, on config change, AND on
buffer switch. The third trigger is the one a FontFacts-shaped design
misses: font size is global, wrap mode is per buffer, so switching from
a truncate buffer to a wrap buffer changes the effective mode with no
config event at all. A design listening only to on_change is silently
wrong and passes every single-buffer test.
Q#LL8 --- the scroll indicator falsifies the locality claim. Revision
14 asserted every vertical consumer is local. format_scroll_indicator
is not: a one-line buffer wrapping to fifty screen rows has
total_lines == 1, so the first branch returns "All" while forty-nine
rows sit below the viewport. The indicator claims the whole buffer is
visible when almost none of it is.
The claim is narrowed rather than abandoned, because the distinction
that bounds the cost survives: a TOTAL is one number, lazily computed
and cached; a PREFIX-SUM INDEX is O(N) resident storage. Stage 3 needs
the first and still does not need the second. All, Top and Bot need no
aggregate at all --- each is a local predicate falling out of the
render walk --- so only NN% pays, which matters because the M1 gate
measures open time on a 100MB file.
Also fixes a notation hazard. Section 7 said pos_to_display returns
"the visual row", which reads as redefining row --- the exact thing
5b.5 forbids, stated two sections apart. Every wrap-point example is
now the explicit triple {row, sub_row, col}. Writing them out makes the
point visible: both coordinates at a soft break share the same row,
because a wrap does not cross a source line. That is the information a
redefinition would have destroyed, and the pair notation hid it.
Status returns to not-approved. Both questions change what gets built,
not how, so implementation waits on them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
A line wider than the window cannot be read past the edge in the TUI.
The GPU is not in that state --- it already wraps --- so the
cross-frontend defect is not unreadability. It is that NEITHER behavior
was chosen: the TUI truncates because a cell walk breaks at max_cols,
the GPU wraps because cosmic-text's Wrap::WordOrGlyph default was never
overridden. Two accidents that disagree, and no way to state a
preference in either.
Eleven revisions of review, and the corrections were the substance.
Revision 1 claimed both frontends render from the same CellGrid, which
inverted the entire cost model --- pmacs-gpu ignores the grid variants
and lays out locally, and its own comment says so. Later rounds caught
an impossible round-trip invariant, a "collision" between two
coordinates that were one position, an off-grid argument against a
function that has no grid, a false binary for view_top, and a
renumbered visible-line space that does not exist. Each is recorded
with its reasoning rather than quietly fixed, because the pattern ---
an assertion that reads as precise while resting on something
unverified --- is more useful to the next reader than any single fix.
All six questions are answered and the framing is approved:
LL1 wrap + truncate, default wrap; horizontal scroll is Stage 4
LL2 buffer-local mode, resolved into Viewport like folds
LL4 do not adopt editing.fill-column; ours is ui.line-wrap
LL5 character wrap in BOTH frontends
LL6 no global map; byte-anchored view_top; additive DisplayCoord
Two of those deserve to be found later rather than discovered:
GUI users lose word wrap. Character-wrap parity is cheap, true, and
matches Emacs, whose default wrap is also a character wrap. But the GPU
has word-wrapped since it existed and nobody opted into losing it. The
alternative was a UAX #14 dependency, because a whitespace-based grid
wrap would give only APPROXIMATE parity against cosmic-text's Unicode
line breaking --- which is worse than honest divergence, since it looks
unified until it is not.
The audit strategy is asymmetric deliberately. The coordinate functions
gain a required context parameter so the compiler enumerates every call
site; DisplayCoord gains an additive sub_row so untouched consumers
stay CORRECT rather than merely findable. Compiler-enforced where
enforcement is possible, correct-by-default where it is not.
Also corrects two ledger headers that still said OPEN for PRs merged
earlier today (#218 at 09:59Z, #217's absorption; #219 at 13:41Z).
Neither lane is removed --- rule 4 removes a lane when its ARC is done,
not when a PR merges, and the QoL arc has this stage left. Read each
block before cutting it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The zoom lane recorded `1e054f7` as the authoritative tip. Committing
that line advanced the tip to b645fe7, so the claim was false before it
was pushed --- self-invalidating, not merely out of date.
The ledger already says this, twice: the docs-absorption and
signal-integrity lanes both note that any edit to their block advances
past whatever SHA it records, so the REF is the thing to trust. I wrote
a new lane without following the convention the file states about
itself.
Removes the SHA and says why, so the next lane inherits the reason
rather than the rule alone.
The base SHA stays. 218d2e7 is a merge commit that already exists and
nothing here can move it --- it is a fact about where the branch
started, not a claim about where it is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
The lane went stale across two review rounds. It said framing revision
4, 13 acceptance tests, and "the three findings review caught" --- all
true when written, none true now.
Brings it current: revision 5, the pushed tip, 15 tests, and the two
later findings. The quantization one gets a real entry rather than a
mention, because its content is a REUSABLE fact about this codebase ---
ConfigKind::Number validates finiteness and bounds and nothing else,
and on_change cannot veto --- so any future setting needing a stronger
predicate than a range meets the same wall.
Also records the verification asymmetry that mattered: the raw-step
bite fails the new witness while the pre-existing 0.37 test still
passes. That is why it had to be a separate test, and it is the kind of
detail a lane summary usually drops.
New section for pre-checkout CI reds, which #220 hit three times. The
job dies in "Set up job" before actions/checkout; grepping the full log
for checkout/cargo/test-result returns 0. No code is fetched, so the
red says nothing about the commit in either direction --- re-running it
is a first execution, not a retry-to-green.
It gets a section here and not a registry row on purpose: matching
requires an exact test selector plus fragments, and no test ran. Making
it a row would mean deforming the row shape. Whether the registry wants
a non-row section for the class is left to its owner.
Written down rather than acted on silently because the registry's
opening instruction is to read it BEFORE attributing a red run to the
environment, and that is exactly the attribution being made here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Review caught the explanation of the 0.015 round-trip break, not the
fix. Three copies of it claimed 16.015 rounds up while 16.005 rounds
down --- "opposite directions". Both round UP.
Verified rather than reasoned about: at the point the quantizer sees
them, 16.015 * 100 is exactly 1601.5 and 16.005 * 100 is exactly
1600.5. Both are exact ties, and half-up sends both away from zero.
So the mechanism is not opposed rounding, it is that half-up is not
symmetric under negation. Rounding up on the way in adds half a
centi-pixel; rounding up on the way out adds another, so the two
errors ACCUMULATE instead of cancelling, and 16.00 -> 16.02 -> 16.01
ends one centi-pixel high. "Opposite directions" would have predicted
them cancelling, which is the reverse of what happens.
Corrected in all three places that carried it: the module comment, the
test's doc comment, and framing section 3.2.
Comments only --- no behavior change, and the witness values in the
tests were already right. Zoom suite still 15/15.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
THE BOUNDS WERE NOT SUFFICIENT AND THE TEST COULD NOT SEE IT.
`ConfigKind::Number` validates finiteness and bounds and nothing else,
and `on_change` listeners are notified after a value is stored — they
cannot veto. So 0.015 is a perfectly settable step and nothing in the
registry can refuse it.
Used raw it breaks the framed guarantee, because each operation rounds
independently and 16.015 and 16.005 round in OPPOSITE directions:
step 0.015: 16.00 -> 16.02 -> 16.01 broken
step 0.37 : 16.00 -> 16.37 -> 16.00 holds
The existing round-trip test used 0.37 — centi-pixel representable — so
it passed against the defect. Bitten now: with the raw value the new
case lands on 16.01, while the 0.37 case still passes, which is exactly
why it needed to be its own witness.
QUANTIZED WHERE USED, not at `set`. Sizes live in integer hundredths
end to end and `validate_font_size` already range-checks the original
and then rounds to the nearest hundredth; rounding the step is that
same operation one level up. A step of 0.015 is not a finer step in
this domain, it is 0.02 written imprecisely.
Enforcing at set time was considered and rejected: the registry cannot
express a precision constraint, and a validating wrapper is bypassed by
a direct `pmacs.config.set` — the seam `autosave` already documents
about its own interval_ms wrapper. Quantizing at the point of use
cannot be bypassed. Both descriptions say "quantized to hundredths", so
`describe-setting` shows it.
The framing header also still said "proposed, awaiting approval" while
the lane and this PR recorded it approved and implemented. Revision 5,
with §3.2 recording the gap and why quantization rather than rejection
closes it.
Verified: fmt, clippy, diff-check, --lib 1900/0, gui_zoom 15/15.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ctrl +/- had no effect whatsoever in the GPU frontend. Stage 1 (#219)
fixed what zoom did to the TUI; this is the other half.
NO RENDERING WORK. FontMetrics::scale already derived every GUI
dimension — code size, line height, status band, divider, menu rows,
minibuffer dropdown, gutter advance — and apply_font_facts already
re-metriced all seven buffers in one transaction. This drives the
preference that existed: two settings, three commands, and a restore.
Q#Z1 = (c). Relative zoom needs an origin and the daemon is built never
to know one — font_pref.rs is explicit that it "never learns metrics,
advances, or what resolves". Hardcoding 16.0 would put a pixel constant
on the daemon side; always sending a size would destroy the `None`
state for everyone who never zooms. A configured base is the only
option where the daemon still infers nothing, and the untouched path
stays byte-identical.
THREE THINGS REVIEW CAUGHT THAT REVISION 1 HAD WRONG.
Q#Z3 was not implementable as framed. `keymap_stack::Scope` is
Buffer | Mode | Global and carries no frontend identity, so "bind on
GPU frontends only" does not exist; and FrontendEvent has no
command-invocation variant, so the GPU cannot ask for a command by name
either. A global binding would capture the chord in the TUI and take
away the terminal's own zoom — the very thing the user is pressing it
for. Commands ship; the binding waits on capability-aware keymap
resolution, which is now a named follow-on rather than something
smuggled in here.
The restore seam did not exist. Builtins and init.lua both run BEFORE
install_state_dirs, so a pmacs.state.read at module load returns
nothing, always. saveplace and recentf never meet this because both
read lazily inside functions; zoom must apply with no user action,
which makes it this project's first eager state consumer. Restore lives
at the end of install_state_dirs — by definition the moment state
becomes readable, so it cannot be ordered wrongly and a future third
startup path gets it without knowing it had to ask.
Every size write clobbered the family. set_font replaces both fields
unconditionally, so { size = n } alone silently cleared a configured
family until restart.
BITTEN, THREE WAYS. Dropping family preservation fails 3 tests.
Reverting to the framing's own first parser `^(%d+)$` fails 4 including
the seam restore — it anchors to end-of-subject and rejects the
newline-terminated file the writer emits, which is the contradiction
review caught in the framing before it reached code. Hardcoding the
16.0 origin fails the base test.
Also recorded: a loaded crdt run failed two m6_1 PTY tests with
`stty -a output was: ""`. That is R4/R6's empty-content readiness
family, and it means the readiness-helper audit's scope is wider than
three wait_for_file copies under tests/ — src/process.rs's own tests
carry the shape. Undiagnosed, load-sensitive, green isolated and on a
quiet full run; a scope note for that lane, not a registry row, since
the registry judges red CI runs and these were local.
Verified: fmt, clippy, diff-check, --lib 1900/0, crdt 2085/0,
gui_zoom 13/13, journey 47/0, m4 150/0, gpu 221/0, full_grid 1/1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two places, not one. The status line said proposed, and §3 still said
Q#FG1 "needs approval before implementation" — while the lane, the
branch, and PR #219 all record it decided as A. A framing that
survives the lane is the durable record; one that describes its own
state wrongly is worse than no record, because it reads as authoritative.
Also records what implementation corrected about the framing rather
than leaving §5.2 describing a witness that was not built: the
time-based settle it specified cannot work, since a settled pmacs
screen emits per-frame bytes forever and "output stopped growing" never
becomes true. The shipped test anchors to content instead, which
excludes startup's clears by construction rather than by timing — and
its repaint-ordering assertion has to be scoped after the new clear,
because the fixture repeats its marker and the suffix opens with the
tail of startup's own frame.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zooming a terminal with Ctrl +/- left the TUI showing the previous
frame through the new one. Q#FG1 = A, as approved.
THE RULE WAS ALREADY WRITTEN DOWN, ON A PRIVATE FIELD.
src/instance_render.rs:36 says remote frontends "must blank their local
buffer before applying the deltas" — the binding contract, in the one
place a consumer author will never look. The protocol type said only
that full_grid marks "the initial sync ... versus an incremental
frame": a label, from which no obligation follows. So FG-INV now lives
on InstanceMessage::CellDelta, where whoever writes the next frontend
reads it. A resync is a picture of the screen's INK, not of the screen.
The producer diffs against a blank grid, so a cell that should be blank
produces no span. src/frontend.rs then took `CellDelta { spans, .. }`
and discarded the flag. That was correct for exactly one frame — the
fresh-attach frame, which follows Frontend::new's Clear — and wrong for
every resize after, which follows nothing. A font-size change is the
worst case because the terminal reflows in place rather than dropping
content, so the maximum number of stale glyphs survive.
emit_cell_delta joins emit_span and emit_status_overlay as a pure
helper over a writer; apply_message routes through it. No struct
change, no generic parameter, no new pattern.
WHY SEVEN TESTS MISSED IT. Every one asserts the producer SETS the
flag; none asserted a consumer ACTS on it, and no runtime reader
existed workspace-wide. "Add a test for the flag" had already been
done and did not help. Handoff §5's enforcement-vs-documentation drift,
in a second register.
Three unit witnesses, each bitten independently. The empty-spans case
earns its own test rather than folding into the others: under the
plausible `spans.is_empty()` early return the ordering test still
PASSES and only that one fails — and an empty resync is exactly the
frame whose entire content is the blanking.
The PTY acceptance drives a real SIGWINCH, and its mark is anchored to
CONTENT rather than time. A time-based settle was written first and is
unusable: a settled pmacs screen emits per-frame bytes forever, so
"output stopped growing" never becomes true. Anchoring just past the
first painted byte excludes both startup clears by construction —
Frontend::new clears before any frame exists, and the first frame is
itself a resync whose clear precedes its own spans. Bitten against the
original defect: 34,831 bytes after the first painted frame, no CSI 2 J
anywhere in them.
What it does not prove, stated here rather than found in review: the
suites assert on raw bytes, with no screen model and no vt100/termwiz/
vte dependency. This shows pmacs emitted a blank at the right moment,
not that the screen ended correct.
Verified: fmt, clippy, diff-check, --lib 1900/0, crdt 2085/0, m4 150/0,
gpu 221/0, and the grid-driving suites — full_grid_resync 1/1, vterm
1/2/3 9+9+5, m5_5 15, m5_8 5, bottom_panel_stage1 47.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1. THE CENTRAL RULE LACKED ITS TIME QUALIFIER. It said any red matching
a retired row is a recurrence — under which this PR's own R2 finding
reopens R2. Now: a match POSTDATING the retirement challenges the
disposition; a match predating it corroborates. That is not a
technicality. An occurrence scan reaches backwards by construction, so
most matches it finds are the earlier kind, and the old wording would
reopen every retired row the first time anyone scanned.
2. R5 AND R6 SAT UNDER "RETIRED ROWS" while declaring themselves live
and undiagnosed. I inserted them before R2's heading, which put them in
the wrong section — presentation contradicting classification in a file
whose whole job is classification. Moved under Live rows.
3. RECOVERY ANCHORS STILL DECLARED 12f2970, so the check accepted a
checkout lacking #216 and #217 while the same file described both as
complete. Advanced to db1bbe9, with the ancestry verified rather than
assumed.
4. THE HANDOFF'S DURABLE TREE FACTS STILL SAID IDS ARE OPAQUE AND
COMPARED BY EQUALITY — the contract ef99b64 deliberately narrowed. A §5
lesson explaining a correction does not fix a summary that still states
the uncorrected fact; the summary is what a new agent reads first.
Corrected there and in the header, which also still called Stage 2 in
flight and anchored main at f186253.
AND ONE FINDING FROM RE-EXERCISING THE RECOVERY PATH RATHER THAN
SWAPPING ITS SHA. This file claimed `git worktree add <path>
githubsucks/<branch>` fails with "fatal: invalid reference". It does
not fail. On git 2.55.0 it SUCCEEDS and leaves a detached HEAD — no
branch, no upstream.
Still use -b, but the reason is the opposite of the one recorded: the
hazard is not an error that stops you, it is that nothing stops you.
Work committed there sits on no branch and is not pushed by a bare
`git push` — the "uncommitted work does not travel" hazard wearing the
shape of committed work. A documented error message that never appears
is worse than no documentation, because the reader waits for a signal
that is not coming.
Verified: fmt, diff-check, --lib, listview 26/26. Recovery path re-run
from an empty directory at the new base; all four steps clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The ledger requires a lane for every open PR. #171 drifted 153 commits
while invisible here and #215 had no lane until review caught it, so
the block goes in with the lane's own commits rather than after someone
asks for it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RULE 4 REMOVES A LANE AFTER MERGE, and two were overdue: the tree
primitive (#217) and macOS CI signal integrity (#215, #216).
The macOS arc could not simply be deleted. It owned R1 and R3, and a
lane removed while it still owns undone work does not close that work,
it hides it. R1 goes to a new async-runtime block; R3 goes to the
reap-ledger lane, which already parks every disposition change pending
exactly its question. Re-homing first is why this did not happen at
merge.
AN OCCURRENCE SCAN (last 25 main runs: 23 green, 2 red) found both reds
unrecorded, and I misattributed both on the first pass — by theme
rather than by required fragment, which is the exact error the registry
exists to prevent.
- Run 30710662474 is NOT R3. Same test, same EPERM, same
measured_group=unobservable(ESRCH...) — but R3 requires `leader=live`
and this reads `leader=exited(signal SIGUSR1)`, R2's exact fragment.
It is a second R2 occurrence, four days BEFORE R2's retirement, so it
corroborates the row rather than falsifying its disposition. It also
adds something: macOS luajit where R2's evidence was lua54, so the
mechanism was never flavor-specific. Filing it as R3 would have
attached a live possible product defect to an occurrence of a fixed
test race.
- Run 30555667095 is NOT R1. Different test, different module,
different assertion; they share only "supersede under a deadline on
macOS". Sharing a subject is not sharing a signature. Filed as R5,
undiagnosed.
R6 is the acc28 readiness timeout from #217's CI. Its scope is the
AUDIT, not the call site: three independently written readiness helpers
now exist and they disagree, with bottom_panel_stage1's carrying only
the zero-byte half of #216's hardening. R4's disposition predicted this
recurrence under a new selector. Patching acc28 alone repeats the
mistake this arc already made once, when the empty-file predicate was
fixed in one helper and left in its neighbour.
The registry carries a rate for the first time — a floor, not a
measurement: main only, 25 runs, readable reds only.
Four durable lessons to the handoff, two from the tree review: an
optional field the shape depends on is not optional, and a contract two
mechanisms must honour is only as strong as the weaker one.
Verified: fmt, diff-check, --lib, listview 26/26. Docs-only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The scalar contract said "identity" and enforced only "scalar", so two
ways to hold an id that is not one survived.
NaN passes `type(x) == "number"` and then errors at
`p.collapsed[row.id]` with "table index is NaN" — the one scalar Lua
accepts as a number and refuses as a key. Bitten with the check
removed, it reports exactly that, from inside listview, naming no row.
DUPLICATES do not merely collide. Every lookup here — `line_of_id`, and
toggle's scan for the row index — resolves an id to the FIRST row
bearing it, so selecting the second such row toggles the first and
re-seats the cursor onto it: a stray jump with nothing pointing at the
id. Bitten with the check removed, nothing is raised at all.
Both are enforced in `check_ids`, where rows already enter, so the
error names the offending row (and, for a duplicate, both of them)
instead of surfacing as a low-level error or a wrong jump later. The
error text says why, not just what, since the reason is not guessable
from the rule.
Verified: fmt, clippy, diff-check, --lib 1897/0, crdt 2082/0, listview
26/26, m4 150/0, gpu 221/0, bottom_panel_stage1 47/47.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TWO REVIEW FINDINGS, both real, and neither reachable from the existing
tree tests.
1. `item` WAS EFFECTIVELY REQUIRED. `render` writes `line_to_item[n] =
row.item`, so that map is SPARSE whenever a row omits the optional
`item` — and `seat_cursor` took `#` of it. A display-only tree (a
grouping node with `on_visit` unused, which the API explicitly allows)
made that length 0, so the cursor never left the header, TAB found no
row, and folding was unusable. It now counts visible rows explicitly.
The old tests could not catch this because every one of them supplies
`item`: under the reverted fix `tr_5` fails `left: 0 / right: 1` while
`tr_1` still passes.
2. THE ID CONTRACT WAS TWO CONTRACTS. The docs said "opaque, compared
by equality". Selection does compare with `==`, honouring `__eq` — but
collapse state stores ids as TABLE KEYS, and Lua indexes tables by raw
identity, consulting no metamethod. So a table id would satisfy one
half and quietly fail the other: after a refresh minted fresh id
tables, the cursor would be restored and the fold silently lost. A
divergence that shows up as a missing fold, arbitrarily later, with
nothing pointing back at the id.
Narrowed rather than generalized. Equality-aware collapse lookup is the
alternative and it is worse: `hidden_by_ancestor` runs per row, so it
turns a linear render quadratic to support a key type no consumer has
asked for. The contract is now the one both halves can honour — string
or number, compared by value — enforced by `check_ids` where rows enter
(`open` and `refresh`), so a bad id is a named error at the call site
instead of a lost fold much later. Q#TR3 in the framing records the
narrowing and why.
Verified: fmt, clippy, diff-check, --lib 1897/0, crdt 2082/0, listview
24/24, m4 150/0, gpu 221/0. Both fixes bitten independently.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It went red again in the full crdt lib run at the merged tip, this time
at 10.3% — clearing the 10% budget by 0.3 points. Ten isolated runs are
now green at -2.3% to +1.5%, and two full-suite runs at the same tips
were green too.
Still recorded as measurements rather than a cause. Two reds against
two greens in-suite is intermittence, not a mechanism, and isolated
greens reproduce nothing about a load-sensitive failure. The one thing
the second occurrence does add is that the budget is marginal rather
than comfortably clear.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#216 landed while this branch was open. Both conflicts are in the
ledger and the handoff, and both sides had independently written up the
same shared-CARGO_TARGET_DIR hazard.
THE TWO WRITE-UPS ARE NOT ABOUT THE SAME OCCURRENCE, and merging them
carelessly would have been a real error. Stage 2's is established: seven
failures against a clean baseline, failure text naming its own cause,
pgrep confirmation, and a dedicated-target-dir re-run at 41/41. This
lane's is the one whose signatures were destroyed before being read —
it has no captured text to match against Stage 2's, and it keeps two
non-causal hypotheses. A mechanism established in one occurrence is not
evidence about a different occurrence that was never characterized, so
the merged bullet says so explicitly rather than letting proximity
imply it.
The ledger records #216 merged and stops saying Stage 2 is in flight.
It does NOT retire the arc, though rule 4 now would: R1 belongs to the
async-runtime lane and R3 is an unresolved possible product defect for
the process-signal lane, and neither has a block yet. Re-homing them is
an absorption pass — not something to fold into a feature PR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It said "Unpushed while held" while githubsucks/tree-primitive-framing
sat at the same tip as HEAD. Held means no PR is open; it does not mean
the work is stranded locally, and the handoff's portability rule cares
about the latter.
The commit list also claimed to be exhaustive and then excluded the
commit that updated it — a list of that shape is wrong the moment it is
written. It is now the substantive arc, with `git log` named as the
place to get the complete one, and the remote ref rather than a pinned
SHA named as the authoritative tip: any edit to this lane advances past
whatever SHA the lane records, including this one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FOUR REVIEW FINDINGS, and the first two were right about the tests.
1. THE SELECTION ACCEPTANCE WAS VACUOUS. `tr_1` toggles the selected
root, which sits on line 1 before and after collapsing — so it passes
unchanged under the line-based re-seating that id-keyed re-seating was
built to replace. It proves collapse hides descendants; it proves
nothing about selection. `tr_4` adds the case that discriminates: an
`on_refresh` inserts a row ABOVE the selected node, so the node moves,
and the assertion is that selection follows the NODE. Bitten by
restoring `seat_cursor(p, saved)`: `tr_4` fails with left " kid2",
right "sibling", while old `tr_1` passes — which is the finding,
reproduced.
The substantive assertion is deliberately ordered first. It was second
at one point, behind the fixture check that the node moved, and a
regression then reported as "the insert must move the selected node" —
reading like a broken fixture rather than a broken re-seat.
2. FLAT PANELS WERE NOT BEHAVIOUR-IDENTICAL. `bind_local_keymap` binds
TAB on every listview, so a depthless panel that previously fell
through to the global binding — and to Q#P3's read-only intercept —
began answering "listview: no node here". `listview.toggle` now
delegates to `buffer.tab` when no row carries an id, restoring the
prior path exactly; leaf feedback is kept for panels that really are
trees. `tr_3` asserts the absence of both tree messages rather than
merely that the panel still renders.
3 and 4 are documentation. The lane now lists 38e94dc, and no longer
says the PR is held "pending review of the documentation" that the same
commit supplied — it is held pending the decision to open it. §20 said
to BUILD the tree primitive while §14 already carried ◐; it now says
what actually remains, which is adoption: dired's `i` is the next
constraint source, DAP's variables view is why this was worth building
before them.
ONE RED, CLASSIFIED RATHER THAN RERUN AWAY. The crdt lib gate failed
`composition_overhead_under_ten_percent` at 30.7%. It is an incumbent
handoff hazard, and the branch cannot reach it — the diff versus main
touches no src/, no crate, no manifest. Alone it ran 5/5 green at
-0.6% to +0.2%; the next full run was green. Recorded in the handoff as
a MEASUREMENT, not a cause: five isolated greens establish that the
ratio is nowhere near the threshold when alone, not that contention is
what pushed it over. Not a registry row either — that file judges red
CI runs, and this was local.
Verified: fmt, clippy, diff-check, --lib 1896/0, --lib --features crdt
2081/0, listview 22/22, m4 150/0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three updates, one of which was a broken cross-reference of my own
making.
THE DAEMON-LEAK ENTRY POINTED AT A LANE THAT DID NOT EXIST. It said the
unclassified failure was "recorded in the tree lane below"; this branch
had no tree lane. A pointer to nothing is worse than no pointer — it
reads as though the record exists and sends the next reader looking. The
tree lane is added, and since it now sits ABOVE that entry the direction
is corrected too, with a second pointer to the framing §6a where the
occurrence is recorded in full.
The lane carries branch, base, framing revision, every commit, the gate
table with both sweeps and their exact reconciliations, the bite
verification for both behavioural claims, the held-PR state and the
recovery command. It also names what is NOT in scope, because the four
unadopted §14 consumers and dired's `i` will otherwise read as omissions
from this stage rather than as later ones.
COHERENCE.md §14: Tree moves ✗ -> ◐, implemented with ONE consumer. Not
✓, and the row says why: the LSP outline is the only adopter, dired's
`i` remains the deferral in its §13, and the other four named consumers
have not adopted. The organising fact goes in the section rather than
only in the framing — folding is LOCAL PROJECTION STATE, NOT A REFRESH
PROTOCOL, which is why a consumer with no `on_refresh` can fold at all.
The §0 scorecard row moves with the body; a grade table disagreeing with
its own section is the defect this document keeps correcting in others.
The framing's status moves from "approved" to implemented-and-gated,
held for PR review, and four durable facts go to the handoff §1: folding
as projection state; identity being consumer-supplied and compared by
equality, with `line:col` chosen because the `::` parent chain collides
on overloads; `has_children` having to read the full row array rather
than the rendered subset, since a collapsed node's children are absent
from it by construction and the bug would look like fold working and
unfold silently not; and that a bite which passes validates the pair
rather than the test.
The daemon leak stays a separate reap-ledger candidate. It is not tree
scope, it predates this work, and folding it in would make a lane
responsible for a leak it did not cause.
Verified: fmt, diff-check, listview 21/21, --lib 1896/0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ACCEPTANCE 5, and it needed a real test rather than a weakened claim.
`listview_acceptance` says in its own header that the references panel
"needs a live LSP and is validated manually / via the m4 harness", so it
does not exercise `*references*` at all; the m4 hover test asserts
content PRESENCE, not exact output. Neither would notice a flat consumer
silently gaining an indent column — the regression a tree extension can
introduce. So the coverage is written against the real entry points
through the fake language server.
`*references*` is pinned EXACTLY: the row is the location string and
nothing else. `*lsp*` formats its own two-space indentation, so
"starts with a space" is not a violation there; what must hold is that
the primitive reproduces the consumer's text verbatim, matched as a
WHOLE LINE — a substring would still be found inside a further-indented
copy of itself. Volatile parts (pid, elapsed) are deliberately excluded,
the same normalization reasoning the CI registry uses.
THE FIRST BITE PASSED, AND THAT WAS THE FINDING. Injecting
`string.rep(" ", row.depth or 0)` did not fail the test — flat rows
carry no depth, so it added nothing. I had simulated a regression the
flat path is immune to and would have recorded the test as verified.
The regression this criterion actually guards is an UNCONDITIONAL
column, a fold gutter on every row; with that injected the test fails on
"the flat references row renders verbatim". A bite that passes validates
the pair, not the test — and injecting the wrong defect teaches nothing
while feeling like assurance.
A VERIFICATION RECORD, including one unclassified occurrence. The first
local crdt sweep of this branch reported 7 failures and its SIGNATURES
WERE DESTROYED before being read, piped through an aggregation that
emitted only totals. That is the failure the CI registry exists to
prevent, committed one lane after writing it, and it is why the cause
cannot now be established rather than merely being unknown.
It is recorded in this lane's own framing and deliberately NOT as a
registry row: that registry keys on a normalized signature, and an
occurrence with none would be granted a recognisability it cannot
support — the same reasoning that made the unevidenced incumbents audit
notes rather than rows.
Four re-runs are tabulated with what each supports. Two were not
isolated, including one where my own guard printed "aborting" and did
not abort. TWO GENUINELY ISOLATED RUNS ARE BOTH CLEAN, which supports
repeatability under isolation and establishes nothing about the cause.
Two mechanisms are recorded as NON-CAUSAL hypotheses, because both were
present and neither can now be tested: a shared CARGO_TARGET_DIR (whose
reciprocal case another lane observed independently, with `pgrep`
evidence and failing text that named its own cause), and ~40 resident
leaked daemons. Having two plausible mechanisms and no way to
discriminate IS the result; naming either would repeat the reasoning
this project has rejected — concluding something about an occurrence
from something that was not about that occurrence.
Both mechanisms are recorded as standing hazards in the handoff, and the
daemon leak gets its own candidate lane: 42 orphans, oldest four days,
reparented to systemd with deleted sockets, from
`gpu_invocation_acceptance`'s one-command tests, leaking 3-4 per sweep
as measured rather than estimated. It predates this work and belongs to
the reap-ledger family — a process outliving its supervisor with nothing
watching it — but the existing ledger arms only for `spec.group` and so
does not cover it.
Verified: fmt, diff-check, luajit sweep 3453/0 and crdt 3722/0, each
exactly +4 on its baseline.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both heads that carry code are 14/14 green — `2d9c678` (the fixes and
the framing) and `668fc72` (this block). The tip row is explicit rather
than missing: a checkpoint table can never record the head that adds
the checkpoint, and #215's lane used the same convention. The branch
tip stays authoritative over any row.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Fills in what could only be filled in after the fact: PR #216, the
opening head's CI run, and the four-way sweep table. Both branch totals
are exactly +4 on their baseline — the four witnesses, and nothing else
moved.
**A shared `CARGO_TARGET_DIR` makes a local sweep unattributable, and it
bit this lane.** The branch `crdt` sweep first reported seven failures
in three suites while the baseline `crdt` sweep was clean. All three
spawn the REAL `pmacs` binary out of the target directory, and the
failure text named its own cause — "daemon does not advertise required
capabilities … start the daemon built with the `crdt` feature". A
concurrent `cargo test --workspace` in a DIFFERENT WORKTREE, at default
(non-`crdt`) features and the same `CARGO_TARGET_DIR`, had overwritten
`target/debug/pmacs` mid-sweep. Confirmed with `pgrep` while it was
happening, and discriminated by re-running the same three suites from
the same tree with a dedicated target directory: 41/41 green, then the
whole configuration swept again there. Recorded in the handoff's
standing hazards, beside the feature-blindness rule it rhymes with: a
feature-flavored binary is a shared mutable file, not an artifact
private to your invocation.
The clean re-sweep left ONE failure, and it is recorded rather than
rerun away: `lsp_dispatch_seams_acceptance acc33_...`. It is a new
incident by the registry's rules, and it is not attributable to this
branch on a STRUCTURAL argument rather than on its green rerun — the
only Rust change lives in `#[cfg(test)] mod tests`, which compiles into
the lib test target alone, so an integration-test binary linking the
non-`cfg(test)` lib is exactly what `main` builds. CI's `Test (crdt)`
job passed at the same head and runs that suite. The 15/15 repetition
set is the weakest of the five points, not the argument. No registry
row is opened: the registry judges red CI runs and keys on linked CI
occurrences.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
COHERENCE.md §14's last missing workbench primitive. Q#TR1-TR4 decided
at review; this implements them.
EXTENDS LISTVIEW rather than adding a treeview (Q#TR1). A separate
primitive would either duplicate ~200 lines of panel discipline —
Q#GB18 handle identity, Q#GB13 `<2>` disambiguation, the read-only
intercept, `prev` capture, the quit chain, generated-buffer writes — or
require extracting them from a shipped primitive first, which is the
riskier change. Rows gain OPTIONAL `depth` and `id`; absent, they behave
exactly as before, which is what keeps the three flat consumers
untouched.
THE OBSERVATION THAT MADE THIS CHEAP: collapse only ever HIDES rows and
never changes a surviving row's depth. Combined with consumers emitting
parents before children in document order, a node's descendants are a
CONTIGUOUS RUN of following rows with greater depth. So collapse is
filtering an existing array, not re-deriving one — the primitive never
calls the consumer to re-render a fold, and pre-rendered indentation
stays correct. That is why `text` remains consumer-supplied (Q#TR4),
which also sidesteps the future conflict with dired's fixed-width
`_layout` column contract.
It is also why a panel with NO `on_refresh` can still fold. The anchor
consumer is exactly that panel: the outline has no refresh at all
(framing §1.5a), so a design requiring the consumer to re-supply rows on
every fold would not have worked for the only consumer that exists.
SELECTION IS RE-SEATED BY ID, NOT BY LINE (Q#TR3). A fold inserts or
removes rows above the cursor, so a line-keyed restore lands on an
unrelated node — the defect `listview.refresh` already had in milder
form. `id` is consumer-supplied and compared by equality; the primitive
never derives one. The outline uses `line:col`, unique per document and
stable across re-render, rather than the `::` parent chain, which
collides on overloads and same-named siblings — precisely where a stale
expansion would reattach to the wrong node.
`has_children` reads the FULL row array rather than the rendered subset.
A collapsed node's children are absent from `line_to_row` by
construction, so asking the rendered view would answer "no" for every
collapsed node and make expanding impossible.
TAB ON A LEAF REPORTS rather than silently doing nothing. The outline's
`g` is already a dead binding — bound, dispatched, no feedback — and
this primitive must not add a second one.
Tests: fold hides ALL descendants while the node and its SIBLING
survive; state and selection survive a re-render; a leaf reports; and a
depthless panel is unchanged by TAB. The fold test is bite-verified —
disabling only the ancestor filter fails it on "descendants hidden".
Verified: fmt, diff-check, clippy with and without crdt, --lib 1896, m4
149, listview 21/21, and the full serialized luajit sweep at 3453
passed / 0 failed. That count reconciles exactly: main is 3450 (Stage
3's 3449 sweep predated its capability-fallback pin) plus these three
tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"NO `g`" WAS LITERALLY FALSE, in revisions 2 and 3 both.
`bind_local_keymap` binds `g -> listview.refresh` on EVERY panel
unconditionally (listview.lua:147). What three of the four consumers
lack is an `on_refresh`; `listview.refresh` then returns immediately.
I had been collapsing three distinct facts into one word: whether `g` is
BOUND, whether refresh is ADVERTISED in the header, and whether refresh
is FUNCTIONAL. The §1.3a table now separates them, because a reader
checking "does the outline have g?" against the source would have found
the framing wrong and had no way to tell which claim was the intended
one.
The consequence is worth recording on its own: THE OUTLINE HAS A DEAD
REFRESH BINDING. `g` is bound, dispatched, and silently does nothing —
no status, no feedback. That is a small UX wart independent of anything
this framing proposes, and it is recorded rather than fixed here.
COHERENCE.md §14 IS CORRECTED IN THIS BRANCH rather than deferred to
implementation or split into its own lane. §25 is explicit that when a
PR changes an audited claim, updating the file RIDES THAT PR — #204
added `*lsp*` and did not update the "exactly three call sites"
measurement, so the correction rides the framing that found it. The
ad41cf1 audit fact is retained as history rather than overwritten, with
the current count of four and `*lsp*` named as the post-audit addition;
§25 also says symbols are authoritative and notes the line numbers have
drifted.
The §0 scorecard row carried the same "3 call sites" and moves with the
body. A grade table that disagrees with the section it summarizes is the
same defect one screen apart.
§14 also now records that `*lsp*` is the only one of the four with a
working refresh, and that the other three carry the dead binding —
which is what makes the tree framing's refresh-scoping conclusion sound
rather than lucky.
Framing only, still unapproved. COHERENCE change is a correction of an
existing audited claim, not a new grade.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Revision 4 of `docs/macos-ci-signal-integrity-framing.md` records
implementation findings, not a new design round: §4's acceptance is
unchanged and was approved at revision 3. Two of the four findings
correct this document.
- **§1.3 named the right window and the wrong assertion.**
`leader=exited(signal SIGUSR1)` is rendered only on a FAILED `kill`,
and the USR1 cannot be the call that failed — it is the call that did
the killing. The failing call is the SIGTERM that follows, so
`.expect("TERM delivers")` is what blew up, not the `Running` state
check; `ProcessState` never carries that value and nothing ticks
between the two calls. The row's fragment and mechanism were both
right. Why a group-directed TERM found no group is NOT established
here, and the fix does not depend on it.
- **§1.5 scoped the fix one function too narrowly.**
`wait_for_published_file` gates the real-TUI smoke on the identical
predicate. §1.5's note about the bottom-panel helper is about a
different file and correctly refuses creep there; it does not reach
this one.
- The fixture also had an unnamed second dependency: these signals are
group-directed, so a forked `sleep` is an untrapped group member, and
survival depended on bash and dash suppressing the fork for the last
command of a `-c` script.
- R2's witness could not reproduce the row on Linux, so it widens the
pre-trap window deliberately and proves survival by exit disposition
rather than by an absence observed within a window.
`docs/ci-red-signatures.md` gains the sentence R3 needs most: **R2's
retirement does not touch it and must not be read as touching it.** The
hardening changed a fixture and no product code; the same
group-directed `kill` runs. Because the fixture changes the shape of the
signalled group, a change in how often R3 appears would be evidence
about FREQUENCY, not about cause — and its retirement is still a
diagnosis by the process-signal / reap-ledger lanes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stage 2 of `docs/macos-ci-signal-integrity-framing.md` revision 3
(acceptance 6–9). Two test races, both the same shape: the thing waited
for was weaker than the thing asserted, so the wait could return inside
the window the assertion needs closed.
R4 — `wait_for_file` returned as soon as `fs::read` succeeded, which
succeeds on a ZERO-BYTE FILE. The probe publishes with
`open(path,'wb').write(b'1')` and `open()` creates the file before
`write()` fills it, so the helper handed `[]` to a caller asserting
`== b"1"`. It now takes the expected bytes and waits while the file
holds a STRICT PREFIX of them — the states a write in flight can be
observed in — returning anything else immediately so the caller's
`assert_eq!` stays the discriminating assertion rather than becoming a
timeout inside a helper that does not know what was expected.
All four callers pass their expectation. `wait_for_published_file`, one
function away in the same suite, gated the real-TUI smoke's
`assert_eq!(…, b"1")` on the identical predicate and is fixed with it:
leaving it would have let R4 recur under a different selector, which the
registry would then have had to judge a new incident.
R2 — the USR1 fixture waited on `ProcessEventKind::Started`, emitted at
SPAWN, not when `/bin/sh` has parsed `trap '' USR1`. SIGUSR1's default
disposition is terminate, so a signal inside that window kills the
child. The child now publishes a marker AFTER the trap and the test
waits for that marker's CONTENT (the same zero-byte trap applies to a
shell's `>` redirection). `exec` replaces the forked `sleep`, so the
group holds exactly one process and the ignored disposition survives by
POSIX rather than by the shell's fork-suppression optimization — an
unstated dependency the old fixture had, since these signals are
group-directed and a forked `sleep` is an untrapped group member.
Four witnesses, each verified by REVERTING the fix and observing the
failure rather than by reasoning about it:
- `wait_for_file_does_not_return_a_zero_byte_readiness_file` fails
`left: []`, `right: [49]` — R4's two required fragments, verbatim;
- `wait_for_file_does_not_return_a_partial_write` fails on the torn read
a length check alone would admit;
- `wait_for_file_returns_divergent_content_rather_than_timing_out` fails
against an over-strict helper that waits for an exact match;
- `usr1_readiness_waits_for_the_trap_not_for_the_spawn` fails
`left: Some("SIGUSR1")`, `right: Some("SIGTERM")` with the readiness
wait removed. Its fixture sleeps before `trap` so the pre-trap window
is deliberate rather than load-dependent, and it proves survival by
the child's EXIT DISPOSITION rather than by an absence observed within
a window.
R1 is NOT touched — referred to the async-runtime lane (Q#MCI3), because
widening its budget would make it pass and measure nothing more. R3 is
NOT touched and remains UNRESOLVED, owned by the process-signal /
reap-ledger lanes.
`docs/ci-red-signatures.md` moves R2 and R4 to a "Retired rows" section
with their dispositions and adds the rule the file needed and lacked: a
red matching a retired row is a RECURRENCE that puts the retirement in
question, never a known flake. `docs/active-work.md` carries this lane
from its first commit rather than after review asks for it.
Repetition sets, not single runs: the two `--lib` process tests 15/15,
the whole `vterm_stage2_acceptance` suite 15/15 at default parallelism.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three review findings, all verified in source before applying, plus one
found while verifying them.
`*references*` HAS NO `g` AND NO `on_refresh`. Revision 2 asserted it
twice. Its header is "RET visit n/p move q quit" and it supplies only
`on_visit` (lsp.lua:2442). The consumer with refresh is `*lsp*`
(lsp.status, lsp.lua:3004).
The error is worth naming precisely because it will recur otherwise: I
read `listview.lua`'s MODULE-DOCSTRING EXAMPLE, which illustrates the
API using `name = "*references*"` and a header containing `g refresh`,
and treated it as the real consumer. An example written to show the
shape of an API is not evidence about any caller of it. The
refresh-scoping conclusion is unaffected — it rested on the OUTLINE
lacking refresh, which holds.
THE BRANCH PLAN STILL NAMED buffer-list. Acceptance 5 had already been
corrected for exactly that error in the previous round; the same claim
survived one section further down. Fixing a mistake where it was
reported is not the same as fixing it where it occurs.
"BYTE-IDENTICALLY, PINNED BY THEIR EXISTING SUITES" WAS UNSUPPORTED.
`listview_acceptance` says in its own header that the references panel
needs a live LSP and is validated manually or via the m4 harness — it
does not exercise `*references*` at all — and the m4 hover test asserts
content PRESENCE, not byte-exact output. So the criterion claimed
coverage that does not exist. It is now posed as a decision rather than
patched: either byte-identity becomes a new test this stage writes
(needing the fake-LSP harness for references), or the claim weakens to
the substrate behaviours actually pinned. Leaning recorded toward
writing the test, because a flat consumer silently gaining an indent
column is precisely what this criterion exists to catch and
content-presence would not see it.
FOUND WHILE VERIFYING: §14's "exactly three `pmacs.listview.open` call
sites" is STALE. There are four. `*lsp*` arrived with Journey Stage 1b-2
(#204), after §14's audit at ad41cf1, and it is the ONLY listview
consumer with refresh — which is why §1.5a's conclusion holds rather
than being luck. §14's line numbers have drifted too. Recorded in a new
§1.3a so the next reader does not inherit "three".
Framing only, still unapproved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
REFRESH WAS UNSCOPED FOR THE ANCHOR CONSUMER, and this is the one that
would have wasted implementation time. Two acceptance criteria rested on
`g` refresh preserving collapse and selection. The outline's header
offers "RET visit n/p move q quit" — NO `g` — it supplies no
`on_refresh`, and `listview.refresh` opens `if not (p and p.on_refresh)
then return end`. The criteria were unreachable for the only consumer
that exists.
Refresh is now out of scope, with the question it actually raises stated
rather than hidden: an outline refresh means re-requesting
textDocument/documentSymbol, which is an async round-trip with its own
await, failure and staleness handling, and it raises who owns the result
when it arrives against a buffer the user may have edited or left. That
is LSP request-lifecycle work; bundling it here would make the tree lane
responsible for it. Acceptance is re-scoped to what the primitive
controls — collapse and selection surviving a RE-RENDER — and the
refresh follow-on is parked with its precondition.
ACCEPTANCE 1 DECIDED Q#TR4 WHILE CALLING IT OPEN. "No `string.rep`
indentation in lsp.lua" commits to primitive-owned indentation, which is
exactly the question Q#TR4 leaves unresolved. The criterion is
representation-neutral now: the outline renders its hierarchy THROUGH
the primitive rather than by pre-formatting it, and whether the
primitive emits the indentation or the consumer still supplies a string
alongside structural depth stays open.
Q#TR1 MISREAD §14, and the correction changes the tradeoff rather than
softening it. Revision 1 said a separate treeview would be "exactly the
second primitive §14 warns about". §14 EXPLICITLY LISTS A TREE in the
reusable set it wants, alongside virtual list. What it warns against is
bespoke per-consumer plumbing — each subsystem inventing its own UI
vocabulary. A treeview sharing the existing buffer/panel disciplines is
not that; a tree hand-rolled inside lsp.lua would be. The real tradeoff
is narrower and is recorded without a leaning, because the scout still
found nothing that decides it.
THE REGRESSION CRITERION NAMED THE WRONG CONSUMERS, and worse, named the
exact ones §14 exists to correct. `*buffer-list*` and project search do
NOT use listview; §14 measured three call sites, all in lsp.lua —
`*references*`, `*outline*`, `*lsp-help*` — and calls the older claim a
documentation error. Repeating it would have re-introduced a mistake
that document was written to fix. The criterion now protects the actual
siblings, and says what to do if the broader surfaces are ever in scope.
CONSUMER ACCOUNTING TIGHTENED. Five named future consumers, not six. And
the split that matters: ONE existing anchor consumer (the outline) plus
ONE future constraint source (dired's deferred `i`) — dired constrains
the design but cannot validate it, because nothing has been built
against it. Calling them "two consumers that exist" overstated the
evidence by exactly one. "Every input a tree needs" is qualified to
"every input a tree needs to RENDER", since stable node identity is
precisely what no existing field supplies.
Framing only, still unapproved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
COHERENCE.md §14 grades Tree as the last missing workbench primitive,
and §20 Priority 5 names it as what remains after the bottom panel. Its
argument is to build it once "before dired's directory view and the
workers tree harden their own conventions".
THIS FRAMING NARROWS THAT ARGUMENT DELIBERATELY. §14 lists six future
consumers, and designing a shared primitive against six hypothetical
ones is how you get a model that fits none. The scout found a better
basis: one consumer already ships a tree and fakes it, and a second is
already scoped and deliberately deferred.
THE HIERARCHY ALREADY EXISTS AND IS ALREADY DISCARDED. `Symbol::
push_hier` walks a genuine LSP DocumentSymbol tree — it recurses on
`children` — and flattens it, preserving `depth`, a `::`-joined parent
chain, and document order with parents before children. `lsp.lua` then
re-renders that depth as LEADING SPACES INSIDE THE ROW TEXT, under its
own comment "FLAT with a `depth` field --- indent, don't recurse". So
the outline has no collapse, no expand, no parent/child navigation, and
every input a tree needs is already computed. It is the anchor consumer
because it needs no new plumbing and its limitation is observable today
rather than hypothetical.
Dired is the second: it landed a flat listing for Emacs parity and
deferred `i` insert-subdirectory in its own §13 — the restraint §14
credits, and what keeps the door open.
The workers view is NOT a consumer yet: it is a Rust-generated text
buffer raw-switched into the active window, with no rows.
REFRESH RESTORES A LINE, NOT A NODE, and that is the crux rather than a
detail. `listview.refresh` saves `cursor_line()`, rebuilds rows wholesale
from a freshly produced array, and re-seats by walking `move_down`.
Today that is a mild wrong-restore. Collapse breaks it outright, because
expanding a node inserts rows ABOVE the cursor — and collapse state
itself must survive refresh, which requires recognising "the same node"
across two independently produced arrays. Neither `line_to_item` nor an
opaque `item` can do that. This is why the stable-identity question
decides whether selection and expansion survive a model update at all.
Four questions are left genuinely open: extend listview versus a
separate treeview (no leaning recorded — the scout found nothing that
decides it); who owns collapse state; what a stable node identity is;
and whether the row still carries pre-rendered text. On identity the
scout did establish constraints: listview cannot derive one because
`item` is opaque; the outline's parent chain plus name is nearly
sufficient but collides on overloads; dired's path would be genuinely
stable. So identity is almost certainly consumer-supplied, which makes
it part of the public contract rather than an internal detail.
NO INTERACTION ISLAND unless evidence forces one. Expand/collapse are
buffer-local bindings on a generated buffer, exactly as RET/n/p/g/q
already are. §6 grades islands "weak, and growing"; this must not add to
that count, and if some behaviour cannot be expressed that way it is a
finding to report rather than a licence.
§1.6 states plainly what this document is: unlike the last two lanes
there is no fallout to census and no baseline to diff, so it ARGUES a
model rather than measuring one — the shape that has historically needed
the most review rounds here.
Framing only. Acceptance is explicitly not final pending the open
questions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three corrections.
"NO OCCURRENCE WAS EVER OBSERVED" OVERSTATED WHAT THE AUDIT CAN SAY.
Someone may well have seen one of these fail and simply not recorded it;
what is established is the absence of a RECORD. The framing now says
"linked or captured" and states the distinction explicitly, because an
audit that claims to know what nobody saw is making the same kind of
unfounded assertion this lane exists to remove — one level up.
A missing closing quotation mark in acceptance 3.
THE LANE CHECKPOINTED THE REVIEWED HEAD, WHICH GOES STALE ON THE NEXT
PUSH — the exact mechanism by which #171 became invisible while it
drifted 153 commits. Recording one head is a snapshot; what a resume
ledger needs is the sequence. It is now a table of head -> CI run ->
result, newest last, with the rule stated: the branch tip is
authoritative over any row, verified by `git rev-parse`, because the
table is written by hand and the tip is not.
Verified: fmt, diff-check.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Five corrections, one blocking.
BLOCKING — the contract, not the implementation, was what needed
changing. Revision 2's acceptance 3 offered a binary: carry an incumbent
in with a signature and evidence, or remove it as never substantiated.
Stage 1 shipped a THIRD state because both incumbents are neither. The
framing is now revision 3 and names all three states, because a
governing criterion that says "two" while the branch does five is the
framing describing something that does not exist.
"MECHANISM NAMED" OVERSTATED THE EVIDENCE, and the phrase is retired.
The a33 audit proves an assertion string exists; the m6_8 audit proves a
test is timing-based. NEITHER ESTABLISHES A FAILURE MECHANISM — no
occurrence was ever observed, so nothing is known about how, or whether,
either fails. They are now AUDIT NOTES A1/A2 rather than registry rows,
with `R`-numbers reserved for signatures carrying linked evidence. The
distinction is not row-versus-weaker-row: a row says "this was seen,
here is the evidence", a note says "someone recorded a belief and no
occurrence backs it". Both remain unmatchable, so a red in either test
is a new incident.
R2's SIGNATURE WAS WEAKENED AND IS RESTORED. Splitting
`leader=exited(signal SIGUSR1)` into `leader=exited(` plus `SIGUSR1`
would match a child that exited by some OTHER disposition while SIGUSR1
appeared elsewhere in the output — precisely the name-style
over-matching this registry exists to refuse, reintroduced one level
down as fragment-style over-matching. It is one exact fragment again,
and the row says why.
THE HANDOFF STILL ISSUED LIVE IMPERATIVES. Its historical block opened
with "rerun isolated before treating a sweep failure as a regression"
and closed with "rerun the test alone before investigating", so the
supersession note I added sat between two instructions it contradicted.
Both are rewritten as record: the block now reports what that lane
OBSERVED, and the retired instruction is marked retired with its reason
— an isolated green reproduces nothing about a load-sensitive failure.
#215 HAD NO LANE, in the file that requires one for every open PR and
records why: #171 drifted 153 commits while invisible there. That is the
same defect, caught in review rather than 153 commits later. The lane
now carries branch, base, PR, reviewed head, what Stage 1 ships, the
verification, what Stage 2 owes, and the recovery worktree command. Both
snapshot headers are bumped.
Also narrowed a claim the PR body overstated: the registry is NOT
macOS-only. All four EVIDENCED rows are macOS, which is a property of
these occurrences; A1's job is `GPU Render (headless)`, which runs on
Ubuntu, and A2's job was never recorded. A future row from any job
belongs in the same table.
Verified: fmt, diff-check, clippy, --lib 1896, --lib --features crdt
2081.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stage 1 of the macOS CI signal-integrity lane. `docs/ci-red-signatures.md`
is now the single authority for judging a red CI run.
NOT NAMED "FLAKES", DELIBERATELY. One of its rows is a possible product
defect, and a filename calling it a flake would confer immunity the
evidence does not support.
A ROW MATCHES ON SIGNATURE, NEVER ON TEST NAME. All three of selector,
job/flavor and every required fragment must hold. Fragments are
normalized rather than pasted: PIDs, elapsed times and rendered
OS-error suffixes vary between runs, so a verbatim key would match
nothing, and where a fragment lists alternatives (ESRCH / "No such
process") those are one condition rendered differently by platform. A
failure in a listed test WITHOUT that row's fragments is a new incident.
The process test is why that rule exists: it produced TWO signatures
with different mechanisms and different causal status, and only one is a
test bug. Four incidents, three tests, four signatures — the registry
counts signatures.
THE RERUN RULE IS REPLACED, NOT SOFTENED. A green rerun establishes
INTERMITTENCE ONLY — never environmental cause, harmlessness, or
retirement. The same signature again is a second occurrence and stays
blocking pending investigation or a merge-base control. A different
signature is a new incident.
RETIREMENT IS CAUSAL. A test race retires by hardening that removes the
mechanism plus a discriminating witness; a measurement-design row by its
owning lane replacing or justifying the measurement; an unresolved row
by diagnosis and disposition. Main-branch greens accumulate as
occurrence evidence and retire nothing.
THE AUDIT FOUND A THIRD CATEGORY the framing's acceptance 3 did not
anticipate. It said each incumbent is either carried in with a signature
and evidence, or removed as never substantiated. Both incumbents are in
between: the tests are real and the mechanisms plausible — a33's "blue
pixels" is a genuine assertion string at pmacs-gpu/src/main.rs:17973,
and m6_8 exists and is timing-based — but NEITHER HAS A LINKED
OCCURRENCE. Deleting them would discard a real observation; carrying
them as peers of the evidenced rows would grant exactly the reputation
this lane exists to deny.
They are recorded as "mechanism named, no occurrence recorded", with it
stated that nothing there confers known-flaky status and that a red
matching one is a FIRST recorded occurrence to be investigated. R6 goes
further: with no signature ever captured it CANNOT BE MATCHED AT ALL, so
a red in that test is a new incident by default. That is the correct
outcome for an entry that never carried evidence.
LIVE POLICY IS CENTRALIZED; HISTORICAL EVIDENCE IS NOT MOVED. The
handoff's hazards rule becomes a pointer. Its landed-lesson block at
§5 keeps its own evidence and gains a note that the registry's rerun
rule supersedes "rerun isolated". active-work.md's two mentions are
verification records for the reap-ledger and bottom-panel lanes and are
left alone; only the CI-weakness block's triage half points at the
registry, because the job-cost question there is genuinely separate.
Verified: fmt, diff-check, clippy with and without crdt, --lib 1896,
--lib --features crdt 2081, pmacs-protocol 19, m4 149, required GPU 221.
All three tests the registry names pass locally on Linux, which is
consistent with every row being macOS-only and is not evidence about
any of them.
Docs only. Stage 2 (hardening) is a separate PR.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Define signatures as normalized selector/job/output matches, preserve
historical evidence while centralizing live triage policy, and replace
green-run retirement with causal disposition.
Also fix the rerun-rule contradiction and move the questions out of the
inline-math namespace.
Four red CI incidents across #213 and #214 were each judged "not caused
by this PR", and #214's case is airtight: it is docs-only and its tree is
byte-identical to a green main. THAT PROVES THE PRs DID NOT CAUSE THEM.
It does not prove they are harmless environmental noise, and three of the
four have a specific, findable mechanism. This lane separates those two
claims, which the current process conflates.
FOUR INCIDENTS, THREE TESTS, FOUR SIGNATURES. The registry counts
signatures, not test names, because the process test alone produced two
with different mechanisms and different causal status — collapsing them
under one name is how a possible product defect acquires a flake's
immunity.
1. supersede_cancels_in_flight_job_within_50ms —
"supersede did not cancel within 50ms". MEASUREMENT DESIGN. Its
premise is a 15ms sleep asserted-by-comment to mean "the worker
picked the job up"; on a loaded runner it may not have, in which
case the test measures the QUEUED path while claiming the running
one. And the 50ms clock starts before the second dispatch and is
consumed by the test's own tick+sleep pump, so the measured
interval is dominated by when THE TEST got scheduled. Widening the
number would make it pass and measure nothing more.
2. a_successful_signal_disposition — "leader=exited(signal SIGUSR1)".
TEST RACE. Readiness is ProcessEventKind::Started, emitted at
SPAWN, not when /bin/sh has installed `trap '' USR1`. USR1's
default disposition is terminate, so a signal in that window kills
the child. The fixture's own comment states the requirement it does
not enforce.
3. a_successful_signal_disposition — "EPERM,
measured_group=unobservable(ESRCH), leader=live". NOT a test race:
the group-target behaviour #176 and #200 circled and the
reap-ledger lane parked disposition changes pending. Recorded
UNRESOLVED, POSSIBLE PRODUCT DEFECT, with a diagnosis — never a
green rerun — as its retirement condition.
4. terminal_escape_gates — "left: [], right: [49]". TEST RACE.
`wait_for_file` returns as soon as `fs::read` succeeds, which
succeeds on a ZERO-BYTE file; the probe's `open()` creates the file
before `write()` fills it. The predicate is "readable", the
assertion is "contains 1" — the same shape as signature 2, fixable
at the helper so every caller inherits it.
THE EXISTING PROSE IS DUPLICATED AND KEYED BY NAME. Flake claims live in
at least six places, disagree in detail, carry no signatures or evidence
links, and the handoff's list names three tests — two of which are not
among these four incidents, while three of the four are absent from it.
A list that is both stale and incomplete is worse than none: it confers
"known flaky" on whatever happens to be named and withholds it from
everything else. Acceptance 3 therefore AUDITS the existing three: each
is carried in with a signature and evidence, or removed with a note. No
entry survives on reputation.
The rerun rule is REPLACED rather than softened: one rerun reproducing
the SAME signature is evidence of intermittence only; a DIFFERENT
signature, or the same one twice consecutively, requires investigation
or a merge-base control before the red is attributed to the environment.
Quarantine, if hardening fails, is a separate STILL-BLOCKING CI step —
never #[ignore], continue-on-error, or silent retry-to-green. A
quarantine that stops failing the build is a deletion with extra steps.
Framing only. Sequencing is registry first, hardening second, per
review.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rule 4 removes a lane when its ARC is done AND its durable facts are in
docs/agent-handoff.md. Both hold: #213 merged, and §1 carries the five
facts Stage 3 produced. The lane goes; the distribution and CI-CRDT
lanes stay, rewritten, because each keeps named follow-ons.
The canonical base and the RECOVERY FLOOR both advance to f186253. The
floor moving with the base is this file's own rule, and the reason is
worth restating: a check that accepts an older commit than the declared
base passes on a tree the rest of the file does not describe. The three
places that named cfc1710 — the base line, the prose, and the `git log`
verification step — now name f186253 together, because a floor that
advances in one place and not the others is worse than one that does not
advance at all.
TWO CI WEAKNESSES STAGE 3 EXPOSED, recorded in the crdt lane that owns
that job rather than lost with the lane being retired:
* CI does not pass --no-fail-fast, so a multi-suite break reports as a
single-suite one. #213's first crdt failure showed ONE suite where a
local --no-fail-fast sweep of the same tree showed THIRTEEN. The
Stage 3 census hit the identical trap and recorded it; CI has it
too.
* The crdt job pairs the heaviest build — lavapipe, full workspace
with crdt, the largest test count — with real-PTY smokes on
5-second deadlines. #213 saw two different such suites fail on two
runs of the same commit; one was a real regression, the other was
load. That ambiguity is the actual problem: a job where noise and
signal look alike trains people to rerun rather than read.
Neither is a defect and neither is fixed here. They are decisions about
what the crdt job should cost, and they belong to whoever picks that
lane up.
Two ops lessons move to the handoff §5, both learned the expensive way
on #213:
* A LOCAL SWEEP IS BLIND TO WHICHEVER FEATURE CONFIGURATION IT DOES
NOT BUILD. Stage 3's census and every verification sweep ran
`--features luajit` without `crdt`, so compile_mode_crdt_acceptance
reached CI broken. Sweep both configurations before calling a corpus
green.
* "MY CHANGE MADE THIS FRAGILE" IS A DIFFERENT FINDING FROM "THIS WAS
ALWAYS FLAKY", and only one of them is yours to fix. Two CI runs on
one commit failed different PTY/GPU suites — the load-sensitivity
signature, on suites the flake list already names. The tell that it
was neither: the failures kept landing on GPU TERMINAL tests, and
terminal placement was what the PR changed. Ask which tests and why
those, before reaching for a rerun.
Docs only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
P1 — compile_mode_crdt_acceptance was never revised. Its three
`compile.run` fixtures still omitted `display`, so the flip placed
output in the panel with `select = false`, the source buffer stayed
active, and `adopt_next_buffer` timed out waiting for a snapshot that
only arrives via the ACTIVE-BUFFER-FOLLOW path. Its subject is CRDT
convergence of a generated buffer, not placement, so it takes the
explicit opt-out — and the reason is recorded at `adopt_next_buffer`,
the helper that actually depends on it, rather than at each call site.
WHY MY OWN VERIFICATION MISSED IT, which matters more than the fix: the
Stage 3 census and every sweep I ran used `--features luajit` WITHOUT
`crdt`, so no crdt-gated suite was ever exercised. The census was
therefore blind to an entire configuration by construction, in exactly
the way #209 exists to prevent. The CI crdt job — added by that lane —
is what caught this, three days after it landed.
Baselined rather than assumed. A worktree at the branch base 21de0b2
sweeps 3715 passed / 0 failed under `luajit,crdt` with
PMACS_REQUIRE_GPU=1; the branch with this fix sweeps 3715 / 0. Identical.
An earlier branch sweep, taken before this fix, reported SEVENTY
failures across THIRTEEN suites. Twelve of those suites — m5_5,
gpu_invocation, gpu_initial_target, m10_11, vterm_stage3 and the rest —
are daemon, socket or GPU suites, and all of them recovered by fixing
three compile tests. The likeliest reading is that the failing
compile-crdt runs leaked daemon or PTY processes that poisoned every
subsequent socket-based suite; what is ESTABLISHED is narrower and
still useful: baseline green, branch green with the fix, and the
collateral confined to process-spawning suites. Count failures, not
causes — the same lesson this stage already learned once, at a
different layer.
Also of note: CI reported only 3 failures because `cargo test` halts
after a failing binary. The workflow does not pass `--no-fail-fast`, so
CI under-reports a multi-suite break exactly as my first census did.
P2 — builtin/runtime/compile.lua's recompile comment still said `_last`
stores only cmdline/cwd. This PR deliberately stores `display` too, so
an explicit opt-out survives replay. Corrected, with the
`display_omitted` arm's remaining purpose stated rather than implied.
P2 — the framing's §7 step 2 still called the resolver extraction
"provably behaviour-preserving", contradicting §1.6b's own record of the
intentional non-string normalization. It is DEFAULT-PRESERVING WITH ONE
INTENTIONAL NORMALIZATION, and now says so where a reader following the
branch plan will hit it.
Verified: fmt, diff-check, compile_mode_crdt 3/3, compile_mode 73/73,
and the full crdt sweep at 3715/0 against a measured baseline of 3715/0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Branch-plan step 6. The lane, the handoff, COHERENCE, and the framing all
still described Stage 3 as ahead.
COHERENCE §14's scorecard row and §20's Priority 5 both said the adopter
default flip was what remained on the panel. It is done, so the panel
half of P5 is closed and the TREE PRIMITIVE becomes the arc's successor —
§14 grades Tree ✗, and DAP's variables view is its next would-be
inventor. That sequencing is now stated where the next framing doc will
read it rather than living in a conversation.
The lane is RETAINED, not removed, because the PR has not landed; rule 4
removes it once Stage 3 merges and its facts are in the handoff. Both
conditions are half-met, and recording that honestly is cheaper than
discovering later which half.
Five durable facts move to the handoff §1, each of which cost a review
round or a defect to learn:
* A VISIT FROM A PANEL MUST NEVER USE THE RAW SWITCH.
`pmacs.window.switch_buffer` replaces the buffer in the ACTIVE
window, so from a panel it clobbers the panel itself. Q#BP11c is the
contract: after RET, `M-,` must FOCUS the still-present panel rather
than clone its buffer into the document — and an assertion on the
active buffer NAME alone cannot distinguish those two outcomes.
* AN OPT-OUT THAT DOES NOT SURVIVE REPLAY IS NOT AN OPT-OUT. Anything
that replays a stored invocation must store the escape hatch with
it, or the escape hatch is a one-shot that silently reverts.
* Compile's chords are PANEL-LOCAL, deliberately, and `M-x
compile.kill` still reaches the slot from anywhere. A global chord is
a command-surface decision framed separately.
* Two `q` mechanisms coexist by design — presentation history chains in
the side slot; `p.prev` prevents raw-switch and capability-fallback
loops. Neither supersedes the other.
* A CAPABILITY FALLBACK MUST STRIP THE QUIT ACTION TOO, not just the
side parameters. A quit action stranded on a document window makes a
later `q` try to restore a presentation that never happened.
The framing reaches revision 4 with the three defects the flip exposed
(§1.7a–c) and the census lesson (§1.6d): it counted FAILURES, not
CAUSES, and the two differed by an order of magnitude — thirteen listview
failures were one missing frame-geometry declaration. Read a census as
"how many assertions move", never "how many decisions are required".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stage 3 steps 3 and 4. Omitting `display` now resolves to the PANEL for
listview, compile and terminal; dired keeps `"current"`, passed
explicitly to the shared resolver. Per-adopter `select` per Q#BP12:
listview true, compile false (passive output must not steal document
focus), terminal true.
The census predicted 37 failures across 5 suites and the flip produced
exactly that — same suites, same per-suite counts. The measurement was a
prediction, not an estimate, which is what the inverted step order was
for. Final sweep: 3449 passed / 0 failed against a 3447 baseline, the
+2 being new pins.
THE CENSUS COUNTED FAILURES, NOT CAUSES. Thirteen listview failures had
ONE root cause: a panel is derived-hidden while frame geometry is
unknown, and listview_acceptance never declared any — it never needed to
while listview defaulted to the current window. One helper took it from
13 to 2. The same applied to m4 and vterm_stage2. Geometry is
authoritative state and a grid frontend's real frame size IS its
declaration; the panel suites have always said so.
THREE DEFECTS THE FLIP EXPOSED, each fixed rather than tested around:
1. The OUTLINE panel's `on_visit` used `pmacs.window.switch_buffer` —
the RAW switch, which replaces the buffer in the ACTIVE window. That
was harmless while the outline opened into a document window. Once
the panel became the default the active window WAS the outline panel,
so RET clobbered the panel with the source and left nothing for `M-,`
to return to. The references panel was migrated to `display_file`
when the arc landed; the outline was missed because nothing exercised
it from a panel until now. Q#BP11c names this exact corruption, and
both the outline and compile tests now assert `M-,` FOCUSES the
panel rather than cloning its buffer into the document — an
assertion the previous one could not distinguish.
2. `pmacs.compile._last` stored only `{cmdline, cwd}`, so a recompile
reached `start_run` with no `display` and took the new default. A
user who ran `compile.run{display="current"}` would be moved into a
panel the moment they pressed `g`. An opt-out that reverts on the
next recompile is not an opt-out; `display` is stored and replayed,
with nil kept as nil so an omitted value still resolves to the
default rather than freezing at the first run's resolution.
3. `opts.display` on a nil `opts` — my own regression, introduced by
fix 2 and caught by `journey_acceptance`, which is exactly what that
ratchet is for.
COMPILE'S CHORDS ARE NOW PANEL-LOCAL, and that is a contract rather than
an accidental reachability loss. Every compile chord is bound
`scope = "buffer"`, so with `select = false` none dispatch from the
document — `C-c C-k` included. `acc34` pins it, and pins that
`M-x compile.kill` still reaches the running slot from anywhere via its
`or compile_slot()` fallback. A global chord is a command-surface
decision and belongs in its own framing.
TEST CLASSIFICATION WAS PER TEST, NOT PER SUITE. Two neighbouring
compile tests land on opposite sides: acc15 (RET-visits-error,
jump-back) asserts the NEW default, while acc16 (n/p within compile
output) genuinely needs the buffer selected and says so. compile's
suite-wide helper opts out because ITS subject is compile-BUFFER
behaviour; the placement-subject tests use a second helper that takes
the default. Every opt-out states why. Nothing was mass-added to make a
suite green.
s1_12's two concerns are split as directed: it keeps its Q#GB18
name-keyed-identity bite with explicit `display = "current"`, isolating
the buffer-level `p.prev` skip rule, while a new `s3_1` pins the
side-window presentation chain — C → B → A → delete, ending at the
document with the wrapper collapsed. The mechanisms are complementary:
presentation history chains in the side slot; `p.prev` prevents
raw-switch and capability-fallback loops.
Verified: fmt, diff-check, clippy with and without crdt, --lib 1896,
--lib --features crdt 2081, pmacs-protocol 19, m4 149, required GPU 221,
and the full serialized sweep at 3449/0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review finding P1: Stage 3 was neither portable nor accurately
recoverable. `bottom-panel-stage3` had no upstream and no
`githubsucks/` ref, while docs/active-work.md still described Stage 3 as
"not started" — so a reader on another machine would have found a lane
claiming nothing existed, and no way to fetch the two commits that did.
That is precisely the failure this ledger records as its own rule:
"When a PR is opened, give it a lane", learned when #171 drifted 153
commits while invisible here. A branch without a PR is the same hazard
with less warning.
The lane now carries branch, base, the two completed steps with their
hashes, what remains, the verification at this head, and a recovery
command.
Review finding P2: the framing retained state the census superseded. It
still said "Nothing has been implemented or measured" and that the
blast-radius measurement "has not been taken", directly contradicting
§1.6b two screens below. Both bullets are rewritten to point at the
measurement rather than deny it, and the dired question is marked
DECIDED rather than left open.
Also records, in both documents, the thing step 2's original commit
message overstated: it is DEFAULT-PRESERVING WITH ONE INTENTIONAL
NORMALIZATION, not "behaviour-preserving". Every adopter kept its
default and the suite is byte-identical to baseline, but terminal's
invalid-input behaviour moved on purpose — and the sweep could not have
caught it, because every existing assertion passes an unknown STRING,
which takes the same path under both designs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stage 3 step 2 (Q#S3-1). DEFAULT-PRESERVING WITH ONE INTENTIONAL
NORMALIZATION — not "behaviour-preserving", which would be too broad a
claim. Every adopter keeps its current default, and the full serialized
suite is 3447 passed / 0 failed with ZERO suites differing from the
pre-change baseline. But invalid-input behaviour DID move, deliberately,
and that is pinned rather than asserted in prose.
Before this, FOUR adopters validated the same three-value vocabulary in
four places: Rust for the terminal, and hand-written Lua copies in
listview.lua, compile.lua and dired.lua, each carrying its own copy of
the error string. `parse_adopter_placement` read like the shared parser
its doc comment implied but had exactly one caller. Four copies of one
rule is how the next adopter gets it subtly wrong, and the next adopter
is DAP.
`resolve_adopter_display(operation, raw, default)` now owns exactly
three things: the vocabulary, the error text, and the default policy.
Reachable from Lua as the internal seam `pmacs.window._resolve_display`.
THE DEFAULT IS A PARAMETER, NOT A CONSTANT, and that is load-bearing
rather than stylistic. listview/compile/terminal will resolve omission
to the panel in step 3; DIRED MUST NOT, because
`pmacs.path.set_directory_handler` calls it with `{ dest = dest }` and
no `display` key at all — a flipped default would open `pmacs .` in a
bottom panel. Passing the default in makes dired's exemption visible at
its call site instead of hidden in a divergent copy.
TERMINAL'S `window` MUTUAL-EXCLUSION STAYS IN ITS OWN WRAPPER. Only the
terminal accepts a `window` id and only it must reject `window` combined
with `display = "panel"`. A helper pretending the four parsers were
identical would be its own defect.
THE NORMALIZATION, DECIDED AND PINNED. Terminal read
`get::<Option<String>>("display")?`, so a non-string value raised mlua's
TYPE error before reaching any custom message, while the Lua copies
stringified it into their own. Nothing pinned either behaviour — every
existing assertion passes an unknown STRING, which takes the same path
under both designs and therefore could not have caught a regression
here. The custom error wins because it names the legal vocabulary; the
value is rendered by TYPE ALONE (`unknown display (integer)`) so the
message cannot imply a string was passed.
Pinned at the terminal entry point in acc19 — the one adopter whose
behaviour changed — asserting the shared error AND that nothing is
created. The type SPELLING is deliberately not pinned: Lua 5.4 says
`integer` where LuaJIT has no integer subtype, so asserting either
literal would pass on one CI flavor and fail on the other. Verified
46/46 under both.
COMPILE NEEDED AN EXPLICIT OMISSION CAPTURE, and finding that out is
what this step is for. The resolver collapses omission into its default,
but compile's recompile gate distinguishes them: it fires on OMISSION
only, never on an explicit `display = "current"`, which is the
documented opt-out and must reach the raw switch even when the previous
run was panel-placed. Resolving first and testing `== "current"`
afterwards would have silently merged the two and broken the opt-out
with every test still green. `display_omitted` is captured before the
resolver call and the gate keys on it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Branch-plan step 1, whose whole point is that it precedes the flip. The
throwaway edit is NOT in this commit; only the measurement survives it.
A CENSUS THAT STOPS AT THE FIRST FAILING BINARY IS NOT A CENSUS. The
first sweep reported 2 failures in 1 suite and looked comfortingly
small — `cargo test` halts after a failing test binary, so everything
alphabetically past bottom_panel_stage1_acceptance never ran. With
--no-fail-fast the real figure is 37 failures across 5 suites. Any
re-measurement must pass that flag or under-report by an order of
magnitude, which is the same silent-success shape this arc keeps
finding.
M4_ACCEPTANCE WAS PREDICTED BY NOBODY — not the parent framing, not
Q#BP12's adopter table, not revision 1. Its two failures are the LSP
hover and outline panels, which are LISTVIEW CONSUMERS, so flipping
listview's default reaches the LSP suite transitively. Q#BP12's four
rows are the DIRECT population; the real one is everything built on
listview. That is the intended behaviour, but the map has to say so or
the next listview-based feature inherits a default nobody documented.
THE PROPORTIONS INVERT THE OBVIOUS READING. compile_mode has the most
failures (17) and the least placement content — process-lifecycle and
styling tests that merely use compile and now find its output
elsewhere. listview_acceptance has fewer (13) but loses THREE QUARTERS
of its suite, and its failures are placement in substance.
Classification decided per test, not per suite, because two
neighbouring compile tests land on opposite sides: acc15
(RET-visits-error, jump-back) is placement — Q#BP12 explicitly requires
panel → RET source → M-, back to the still-present panel with the
document window intact — while acc16 (n/p walk within compile output)
genuinely needs the compilation buffer selected and takes an explicit
display = "current". A sweep classifying per suite would have got both
wrong.
Both M4 failures are placement-subject: outline_panel_opens_visits_and_
restores is almost a direct realization of criterion 58 (open → visit →
jump-back → quit), and hover_doc_panel keeps the omitted default while
asserting the new placement plus its existing content and quit
guarantees. Neither takes display = "current".
Tree verified clean after revert: the three default-resolution branches
are unchanged on disk.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Arc 7's last step. Stages 1, 2A, 2B-1, 2B-2 and 2B-3 are all on main;
the panel is complete on both frontends and every mechanism this stage
needs exists. What remains is the decision the arc deferred on purpose:
omitting `display` should mean the panel, not the selected window.
Revision 2, approved with amendments. The scout found the parent
framing's plan sound and two of its details drifted.
THE FLIP IS THREE SITES IN TWO LANGUAGES, and a fourth validator that
must not move. `parse_adopter_placement` reads like the shared parser
its doc comment implies but has EXACTLY ONE CALLER, the terminal;
listview and compile each re-implement the same three-value validation
in Lua, including their own copy of the error message. Changing only
the Rust parser would leave both Lua adopters resolving omission to the
current window — a half-flip that looks done and behaves inconsistently
per adopter.
DIRED IS A FOURTH COPY OF THE VALIDATOR AND MUST KEEP `"current"`.
Review caught this; revision 1 had it as a leaning. The mechanism is
specific rather than stylistic: `pmacs.path.set_directory_handler`
passes `{ dest = dest }` with NO `display` key, so `pmacs .` resolves
by omission. Flipping dired's default would open the golden journey's
first directory listing in a bottom panel. The distinction that makes
this principled rather than an exception: listview, compile and terminal
produce output the user CONSULTS; dired produces a document the user
WORKS IN. The panel default is right for the first kind and wrong for
the second.
UNIFY NARROWLY, NOT WHOLESALE. A shared
`resolve_adopter_display(operation, raw, default)` owns the vocabulary,
the error text and the default policy, with dired passing
`default = "current"` so its exemption is a parameter rather than a
divergent copy. Terminal's `window` mutual-exclusion stays in its Rust
wrapper — the parsers are not identical and a helper pretending
otherwise would be its own defect.
One normalization is named rather than absorbed: terminal reads
`get::<Option<String>>("display")?`, so a non-string value raises mlua's
TYPE error before the custom "unknown display" message, while the Lua
callers `tostring()` it into their own. Different observable behaviour
for the same bad input; unifying the error text without deciding this
would silently change one of them.
`select` IS A CORRECTNESS REQUIREMENT, and Q#BP12's citation drifted.
`seat_cursor` is at listview.lua:130, not :64 — :64 is now a name-variant
constant. The constraint holds and is worse than "focus preference":
`seat_cursor` drives `pmacs.editor.move_down()`, which acts on the ACTIVE
window, so an unselected listview panel seats the cursor in the user's
document. That is why the table's `select` differs per adopter —
listview true, compile false, terminal true — and why a uniform value
would look right and break compile's passive output.
TESTS ARE MEASURED BEFORE THE FLIP, NOT AFTER. Two Stage 1 acceptance
tests assert the old default deliberately: acc19 (:1223) opens a
listview with no `display` specifically to seed a DOCUMENT window "so
side-affine placement cannot be vacuous" — the flip breaks its
anti-vacuity guarantee, not merely its assertion — and acc19b (:1308) is
built around a recompile reaching `start_run` with no `display`. The
sweep rule is stated: a test whose SUBJECT is placement asserts the new
default; a test whose subject is compile or terminal behaviour opts out
only when its setup genuinely requires the document window. Mass-adding
`display = "current"` to make suites green would convert a behavioural
change into an invisible one.
Acceptance gains a NEGATIVE criterion (9): omitted `display` still means
document placement for direct dired AND for `pmacs .`. That is the
criterion that catches a well-intentioned "make all four consistent"
change.
Framing only. No code, no flip, no test changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two parts, one intent: record the release, and fix the user-facing
surfaces it falsified.
ABSORPTION. v1.1.0 shipped and nothing recorded it. docs/active-work.md
had no distribution lane, the handoff anchor still named c5f7501, and
COHERENCE.md — a REQUIRED framing input — still asserted "zero release
machinery exists" and graded journey step 1 as source-build-only. Both
are now false, and a framing doc written against them would have been
written against a lie.
* §0 scorecard: step 1 Partial -> Works; §17 Missing -> Partial; the
journey row moves off "steps 1, 11 and 12 remain the thin end" to
name 11 and 12 only.
* §17 ground truth rewritten: what Stage 1 shipped, and the nine
things it explicitly did not.
* §20 Priority 8: "State: zero" -> Stage 1 shipped, with the blocker
it named ("every other priority's value is invisible until this one
exists") recorded as LIFTED. Its next increment is a DECISION about
channels/update/signing, not a queued plan — worth stating so nobody
treats Stage 2 as pre-approved.
* A distribution lane in active-work.md, rewritten-not-removed because
the arc is not done.
Five durable facts move to the handoff §1, each of which cost something
to learn:
* a release build can produce FIVE binaries and three must never ship;
layer-2 exclusion is load-bearing, demonstrated when target/release
still held all three after building only two;
* `env!("CARGO_PKG_VERSION")` expands in the crate being COMPILED, and
three correct tests could not fail while two crates shared a number;
* pin release runners, and assert the glibc floor from the binary
rather than trusting the pin;
* a tag pushed before its workflow reaches the default branch does
nothing, SILENTLY;
* verify from the downloaded artifact, with a negative control — the
1,576 `loro` strings mean nothing without the control build's zero.
STALENESS, found by reading the surfaces a new downloader hits first.
`pmacs --help` claimed the TUI was "currently the only frontend;
reserved for the M4 GUI rollout, where `pmacs` will default to the GUI".
That is not merely dated — it is false in a release that SHIPS the GPU
frontend as a second binary. Rewritten to say what -nw actually does
(name the default explicitly for scripts and wrappers), and --gpu now
states its two real preconditions: a `crdt` build, and pmacs-gpu either
beside the binary or on PATH. Both are things a downloader can get
wrong and neither was documented where they would look.
Also in main.rs: the TLS attach line said "activation in v0.2" and four
doc comments dated themselves "v0.1" or "M4+" while describing behaviour
that is still current. The behaviour claims were accurate; only the
version labels lied, so the labels are gone rather than the sentences
rewritten. One comment gained a correction it needed regardless —
FrontendChoice is IN-PROCESS dispatch and the GPU frontend is not a
value of it, which the old text implied it eventually would be.
README status block: v1.0.0 -> v1.1.0, protocol v20 -> v21, and it
pointed at docs/roadmap-2026-07.md for "current direction" — a file that
opens by calling itself a historical snapshot and redirecting to the
handoff. It now points at COHERENCE.md and the handoff, and mentions the
arcs that landed since it was last touched.
Verified: fmt, diff-check, clippy with and without crdt, --lib 1896,
--lib --features crdt 2081, pmacs-protocol 19, m4 149, required GPU 221,
and `pmacs --help` rendered and read.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operational note for §7's step 5, recorded before it can bite rather
than after.
For `on: push: tags`, GitHub resolves the workflow file AS IT EXISTS AT
THE TAGGED COMMIT, and it registers a repository's workflows from the
DEFAULT BRANCH. Verified while #211 was in review: `gh workflow list`
reports only CI, because release.yml lives on the branch and not yet on
main.
So tagging any commit that predates the merge produces no run, no error,
and no release. That failure mode is worse than a red one: a silent
no-op is indistinguishable from "the run has not started yet", which is
exactly what someone watching for an RC would assume. Cut the RC from
the merge SHA and confirm a run actually appeared before drawing any
conclusion from its absence.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
.github/workflows/ had exactly one workflow and it was test-only: no
release job, no artifact upload, no tags-to-binaries path. Installing
pmacs meant `git clone` plus knowing the feature-flag matrix.
COHERENCE.md §17 grades this "missing — zero release machinery exists";
this moves it to Partial and completes journey step 1.
Scope is one stage: binaries when a `v*` tag is pushed, attached to a
GitHub Release. Channels, rollback, update-in-place, signing, RHEL 9 and
Intel macOS are out of scope and named in the framing's §5.
WHAT SHIPS: pmacs and pmacs-gpu, both at 1.1.0, CRDT-enabled, co-located
in one archive, with SHA256SUMS. pmacs-protocol stays at 1.0.0 — it is
the wire crate and versions on its own schedule.
THE VERSION BUMP EXPOSED A REAL DEFECT, and it is the reason this PR
touches src/ at all. `InstanceIdentity::for_running_process` is defined
in pmacs-protocol and expanded `env!("CARGO_PKG_VERSION")` THERE. `env!`
expands in the crate being compiled, so the field documented as "Pmacs
version string" carried the PROTOCOL crate's version. That identity
reaches Lua as `pmacs.instance.identity()` and goes on the wire in
`Hello`, so a 1.1.0 release would have told every attached frontend it
was 1.0.0.
Nothing could have caught it earlier. Three tests assert
`id.pmacs_version == env!("CARGO_PKG_VERSION")` evaluated in the pmacs
crate — the correct assertion — but while both crates read 1.0.0 they
compared the same number reached by two different paths and COULD NOT
FAIL. Deciding to hold pmacs-protocol at 1.0.0 while moving pmacs is
what made them discriminating; all three failed on the bump. The version
is now a parameter so `env!` expands in the caller's crate. A test can
be correct and still prove nothing when the two things it compares are
equal for a reason unrelated to the code under test.
TWO LAYERS OF BINARY EXCLUSION, and layer 2 is load-bearing —
demonstrated, not argued. Cargo auto-discovers src/bin/*.rs, so a
release build can produce five binaries and three must never ship
(pmacs-audit is a contributor tool; pmacs_fake_lsp and pmacs_fake_mcp
are test fixtures). Layer 1 names explicit --bin targets. Layer 2 stages
an explicit asset list, and building this branch produced exactly the
case it guards: after building ONLY --bin pmacs and -p pmacs-gpu,
target/release still held all three forbidden binaries, left by an
earlier `cargo test --release`. Swatinem/rust-cache restores that kind
of directory in CI. An implementation trusting layer 1 and archiving the
directory would have published a fake language server in the first
release.
The three archive assertions are bite-verified: a smuggled
pmacs_fake_lsp, a missing pmacs-gpu, and a cleared executable bit are
each caught, with the honest archive passing.
THE GLIBC FLOOR IS ASSERTED, NOT TRUSTED. Pinning ubuntu-22.04 sets the
floor at 2.35 (Ubuntu 22.04, Debian 12 — NOT RHEL 9 at 2.34, which needs
a container or cross-build and is parked). But a pinned runner proves
nothing about the artifact, and the failure surfaces as a bare
`GLIBC_2.39 not found` on a user's machine with no clue which commit
caused it. The build reads versioned-symbol requirements out of the
binary and fails above the floor, so switching to ubuntu-latest fails in
CI instead of shipping. Bite-verified both directions on a glibc 2.44
host. Both runners are pinned; macos-latest would drift the minimum
supported macOS with no commit to point at.
Preflight runs before any build: the tag must match the root crate
version (stripping a prerelease suffix, so v1.1.0-rc.1 and v1.1.0 both
match 1.1.0), and the tagged commit must be an ancestor of main. Both
catch mistakes that are cheap now and expensive once a public URL
exists. The suite is not re-run — CI already tested the commit — but
nothing otherwise enforced that a tag points at a tested one.
Verified: fmt, diff-check, clippy with and without crdt, --lib 1896,
--lib --features crdt 2081, pmacs-protocol 19, m4 149, required GPU 221,
and the full serialized crdt sweep at 3,715 passed / 0 failed / 30
ignored — identical to the pre-change baseline, so the protocol
signature change broke nothing. Archive staging, contents, executable
bits and both --version outputs were exercised against a real release
build locally.
No release is cut by this PR. Per the framing's §7 the RC is tagged
after merge, from the merge SHA.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
.github/workflows/ contains exactly one workflow and it is test-only.
There is no release job, no artifact upload, no tags-to-binaries path.
Installing pmacs means `git clone` plus knowing the feature-flag matrix.
COHERENCE.md §17 grades this "missing — zero release machinery exists",
and §20 puts it at Priority 8 with the note that every other priority's
value is invisible until it exists.
Scope is deliberately ONE STAGE: binaries when a tag is pushed,
attached to a GitHub Release. Channels, rollback, update-in-place,
signing and first-launch tool detection are out of scope and named in
§5. A baseline, not the arc.
Revision 2, approved with amendments. Two of them corrected revision 1:
THE GLIBC ARITHMETIC. Revision 1 implied that moving off ubuntu-latest
buys reach "several distro generations" including RHEL 9. It does not.
RHEL 9 ships glibc 2.34, which is BELOW the 2.35 floor a pinned
ubuntu-22.04 build sets, so RHEL 9 is excluded by that choice rather
than covered by it. The floor is now stated explicitly with its table,
so a RHEL 9 user reads "not supported yet" instead of discovering a
loader error; supporting it needs a lower-glibc container or
cross-build and is parked.
WHY CO-LOCATION IS REQUIRED. Revision 1 said separating `pmacs` from
`pmacs-gpu` makes `--gpu` "silently fail". Verified against
src/main.rs:304: `gpu_binary` prefers a co-located binary when that path
is_file(), falls back to a bare-name PATH lookup, and on failure names
both — "sibling … is absent and PATH lookup for pmacs-gpu failed". So
the requirement is that a release archive be SELF-CONTAINED for a user
who unpacks it somewhere off PATH, not that failure is quiet.
The load-bearing finding: a release build can produce FIVE binaries and
three must never ship. Cargo auto-discovers src/bin/*.rs, so alongside
pmacs and pmacs-audit it also builds pmacs_fake_lsp and pmacs_fake_mcp —
test fixtures. Exclusion is therefore two-layered, because neither layer
suffices alone: explicit --bin targets so the unwanted binaries are not
produced, AND an explicit staged asset list so the archive's contents
are a decision rather than a directory's residue. Layer 1 alone still
archives whatever a cached target/release holds from an earlier step;
layer 2 alone relies on a list nobody re-checks when a new src/bin/*.rs
appears.
Two facts checked rather than assumed while framing:
`pmacs-gpu --version` already exists (pmacs-gpu/src/main.rs:667) and
prints "pmacs-gpu <ver> (protocol v21)", so asserting both binaries
report 1.1.0 is directly implementable after the bump. And `run_gpu`
refuses a non-CRDT build outright — "pmacs: --gpu requires pmacs built
with --features crdt" — which is a direct citation for shipping CRDT
rather than the inference from capability defaults revision 1 used.
Framing only. No workflow, no version bump, no release.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two jobs: absorb the CI CRDT coverage lane now that #209 has merged, and
clear documentation drift that predates it and was found while reading
in on a new machine.
ABSORPTION. docs/active-work.md's lane is REWRITTEN, not removed —
rule 4 removes a lane when its ARC is done, and three named follow-ons
remain. It shrinks from 10,441 to 3,037 characters because rule 3 puts
durable architecture in the handoff and leaves only volatile state here.
The follow-ons, each with its reason:
* the macOS crdt leg, deferred pending first-run evidence that NOW
EXISTS and is favourable — the non-crdt macOS legs pass at 3,474,
thirteen fewer than ubuntu's 3,487 purely from cfg-compilation of
the Linux-gated process tests, and no crdt-specific failure appeared
anywhere;
* the --lib --features crdt flake, which did NOT reproduce in #209's
runs — but every run was --test-threads=1 and the trigger was seen
under PARALLEL load, so that is consistent with the drain_until
hypothesis rather than evidence against it. Its own PR: a
product-defect hypothesis, where all of #209 was configuration;
* the crdt_replica serde default, a third default mechanism that
disagrees with the Default impl in non-CRDT builds, untestable
without a self-describing format this crate does not depend on.
Five durable facts move to the handoff §1, each of which contradicted
something previously recorded: gpu-render runs a DIFFERENT PACKAGE than
the suites the old fix-shape wanted moved there; PMACS_REQUIRE_GPU is
absent from two of the four GPU suites; m10_10_perf is a CI-default
tripwire rather than a bench; --keep-going is what makes a clippy run an
inventory instead of a lower bound; and a feature can matter to a crate
a per-test census scores as unaffected.
DRIFT, all of it predating this lane and all found while reading in:
* COHERENCE.md §20's Priority 1 still read "runs to step 5; thin from
step 6" and called Stage 1b-3 "in flight", while §0's scorecard said
step 10 and 1b-3 had landed. §20 is a REQUIRED FRAMING INPUT per
CLAUDE.md, so a stale priority annotation there does not just sit
wrong — it misdirects the next framing doc written against it. Its
arc-cuts list carried the same two errors.
* docs/agent-handoff.md §1 described Discovery Stage 1 and Journey
1b-3 as "IMPLEMENTED, PR open" while §1a, twenty lines above,
correctly recorded both as merged. A file that contradicts itself is
worse than one that is merely behind.
* docs/side-quest-backlog.md, compiled 2026-07-14, listed #123 as an
open PR (merged 2026-07-21), #137 as "in review" (merged), and
HTML/CSS as an unshipped grammar (#146 shipped it AND its injection
consumers). It is the cross-cutting index, so a stale entry sends
someone to build something that already exists. Its north-star
section now says plainly that every original item has shipped and
that the file no longer sets direction — COHERENCE.md §20 and the
handoff §1a do, and both postdate it.
* docs/json-yaml-framing.md's status line advertised "PR #123 open and
awaiting review" for six weeks after that PR merged. Corrected in
the status line only; the revision-4 body is the as-reviewed text
and is left unedited.
No code, no workflow, no protocol change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Acceptance 8 in its strongest form. The ledger predicted the post-round-2
job totals from the census — 3,766 for Test (crdt) and 3,487 for
Test (ubuntu/luajit) — and run 30706324644 @ 71a1ebd reported exactly
those. Predicting the count before the run and matching it says more
than reconciling one afterwards: a vacuous leg would have landed near
the non-crdt job's figure.
Also records two readings that would otherwise be misread:
The macOS legs report 3,474, thirteen fewer than ubuntu's 3,487. That is
cfg-compilation, not lost coverage — the Linux-gated process tests
(setsid, the `bash -m` job-control corroboration) are not built there
rather than skipped.
And the head_sha trap bit again. Round 1's run (30705916037 @ 6519bc3)
was CANCELLED, not green: round 2's push superseded it, which is the
concurrency group working exactly as its comment in ci.yml describes. A
`gh pr checks` summary polled around that moment reported the PREVIOUS
run's results — with entirely plausible timings — and round 1 was
briefly reported as passing on that basis. This ledger already carried
the lesson from #178 ("verified by head_sha, not by the check summary").
It recurs because the wrong answer looks exactly like the right one, so
it is now recorded against this lane too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review finding (P2), and it is this lane's own defect class one level
down. Round 1 added a `-p pmacs-protocol --features crdt` step so that
crate compiles both ways. That step EXECUTED
`InstanceCapabilities::default` in both configurations and asserted
NOTHING about it: the crate's only use of that value is a transport
round-trip, and a round-trip is invariant to the values. An all-false
default — or one whose three fields disagreed with each other — encodes,
decodes, and passes identically in both builds.
Running code is not testing it. That is the same sentence this whole
lane is about, and round 1 committed the smaller version of it while
fixing the larger one.
Three tests now pin the defaults, and the split is the point:
* under `crdt`: multi_frontend, crdt_replica and semantic_render all
default true. Advertising false on a CRDT build would strand every
frontend in single-frontend mode.
* without `crdt`: all three default false. Advertising true would be
wire-protocol false advertising — those code paths are
conditionally compiled out.
* FrontendCapabilities::default is all-false in BOTH builds, and this
test is DELIBERATELY NOT feature-gated.
That third one pins an asymmetry nothing else did.
FrontendCapabilities derives Default and is feature-INVARIANT, while
InstanceCapabilities is feature-DEPENDENT. It is load-bearing rather
than an oversight: an instance advertises what it can do, a frontend
OPTS IN through the negotiation handshake, and a v1 frontend has no
local CRDT state regardless of how the crate it links was compiled.
Making the frontend side track the feature would have frontends
claiming support they do not have. A future edit that "makes them
consistent" now fails a test that says why not to.
All three fields are asserted separately rather than by comparing whole
structs, because they track one `cfg!` and a change flipping only some
of them is exactly the regression worth catching.
Bite-verified rather than assumed: mutating `multi_frontend` to a
literal false gives `FAILED. 18 passed; 1 failed` with the expected
assertion message; restoring returns 19/19. Both configurations now
report 19 tests, up from 17, with the correct cfg-gated test running in
each.
Left untested and recorded instead: `InstanceCapabilities::crdt_replica`
carries `#[serde(default = "default_true")]`, a THIRD default mechanism
that is unconditional and therefore disagrees with the `Default` impl in
a non-CRDT build. Exercising it needs a self-describing format and this
crate's only serde dependency is postcard, which is not one. Adding
serde_json as a dev-dependency to test a divergence this lane did not
introduce is scope creep.
Also corrects a note that round 1 made stale: the ledger's "do not
subtract the two jobs' totals" figures (3,485 and 3,747) were measured
BEFORE round 1 added the protocol step, and round 2 adds two tests to
that crate. Expected totals are now 3,487 and 3,766. The root-package
census is untouched at 3,467 / 3,746 — the new tests live in a sibling
crate, which is precisely the region scripts/feature-census cannot see.
Verified: fmt, diff-check, clippy on pmacs-protocol in both feature
configurations, and workspace clippy --features crdt --keep-going.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review finding (P2): docs/active-work.md and docs/agent-handoff.md both
still said "PR not yet open". This file's own rule is that an open PR
gets a lane recording its state — "When a PR is opened, give it a lane",
written after #171 drifted 153 commits while invisible here. Both now
carry PR #209, its six commits, and the first CI run.
That run is worth recording rather than merely citing, because it
discharges the one risk the framing could not close locally. ALL 14
CHECKS GREEN, including both new jobs (Test (crdt) 12m20s, M10 Perf
Gates (crdt) 5m40s) and the macOS/luajit leg that is the documented
flake surface. This was the first time in the project's history that
any of these tests executed in CI.
ACCEPTANCE 8 HOLDS AGAINST THE REAL RUN. Test (crdt) reported 3,717
passed / 0 failed / 30 ignored: the 3,746 all-targets census (with
basedpyright NOT skipped, as it is locally) plus one doc test, less the
30 ignored. The job demonstrably compiled and ran the crdt corpus rather
than reporting green over nothing — which was the whole point of writing
that criterion while the local sweep was already green.
A trap for the next reader is recorded with it: DO NOT SUBTRACT THE TWO
JOBS' TOTALS. Test (ubuntu/luajit) reports 3,485 and Test (crdt) 3,747,
a difference of 262 rather than 279, because the jobs run different
SETS — the non-crdt job adds pmacs-protocol's 17 tests. The dark count
is the all-targets comparison, 3,746 - 3,467. The wrong number looks
entirely plausible.
Chasing that discrepancy found a real gap, and one this lane's own tool
could never have surfaced: PMACS-PROTOCOL HAS ITS OWN `crdt` FEATURE.
It gates no tests, so a per-test census reports 17 either way and scores
the crate as unaffected — but it changes `cfg!(feature = "crdt")`
EXPRESSIONS inside InstanceCapabilities::default and
FrontendCapabilities::default, so those same 17 tests exercise different
runtime values under it. CI had only ever run the non-crdt ones. Closed
with an explicit `-p pmacs-protocol --all-targets --features crdt` step,
verified 17/17.
The blind spot is structural, not an omission, so it is documented at
the tool rather than fixed in it: scripts/feature-census censuses the
workspace DEFAULT MEMBER, because that is what a bare
`cargo test --all-targets` builds. Sibling crates are invisible to it no
matter what configs are passed. The durable lesson: A FEATURE CAN MATTER
TO A CRATE A PER-TEST CENSUS SCORES AS UNAFFECTED. Check siblings by
hand.
Verified: ci.yml parses at 10 jobs, script syntax clean, fmt,
diff-check, and the new protocol step green locally.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Framing revision 3, plus the ledger and handoff updates the lane owes.
docs/active-work.md's "NEEDS A LANE" block is replaced rather than
annotated: the lane now has a branch, a framing, an implementation and
verification, so the old text's premise ("no branch, no framing yet")
was the part that needed removing. Its stale figures go with it — the
273-dark reading at 74301d1 and the seven-item clippy list, both
superseded and both explicitly labelled do-not-quote in the new block.
The corrections this lane produced, all now recorded where the next
reader will hit them:
* m10_10_perf is a CI-DEFAULT REGRESSION TRIPWIRE, not a bench. Its
bounds are deliberately generous "to catch catastrophic regressions,
not to verify a tight perf claim", so #[ignore]ing it to give it a
perf job would have reduced coverage inside a coverage lane. The
framing had this backwards through revision 1 and says so.
* gpu-render runs `cargo test -p pmacs-gpu` — a DIFFERENT PACKAGE from
the root-package GPU suites. The long-recorded fix-shape of "move
the GPU-requiring crdt suites onto gpu-render, it already has
lavapipe" does not work as written.
* PMACS_REQUIRE_GPU is not uniform: absent from
gpu_invocation_acceptance and gpu_initial_target_acceptance
entirely, so it cannot serve as blanket proof the GPU suites ran.
* The dark-test classification found THREE dispositions, not two:
benches awaiting a job, deliberately-manual operator tests, and
known-defect markers. Collapsing the second into the first gives a
CI job to tests whose #[ignore] reason says not to.
* §1.1's own target-column claim was wrong, and scripts/feature-census
caught it. Eleven targets run with zero tests under CI's flags;
eight of those gain tests under crdt and three are helper binaries
with no tests in either. The framing had merged two true statements.
Acceptance 9 is revised rather than quietly met at a lower bar. The
planned deliberately-broken-test bite is replaced by the --covers
coverage assertion plus the CI count reconciliation, and the doc states
what that trades: stronger on the claim specific to this lane (the old
job STRUCTURALLY cannot see these tests), and no longer proving that a
failing crdt test turns the job red — which is generic cargo and Actions
behavior, not anything this lane changes.
The handoff gains a census hazard beside the existing sweep note,
because every trap in it was hit while writing the script and one of
them survived two framing revisions: libtest prints `name: test` with no
space before the colon, a zero-test target prints only its Running line,
and both configurations need an --ignored pass or pre-existing ignores
get attributed to the feature.
The ledger also records what is NOT established, which is the lane's
whole remaining risk: the sweep is green SERIALIZED ON A DEVELOPER
MACHINE, and the failures this lane expects are hosted-runner timing and
concurrency. That green removes the "tests are wrong" explanation and
leaves the expected one untested. It must not be quoted as evidence the
CI leg will be green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`.github/workflows/ci.yml` never enables the `crdt` feature anywhere, so
every `#[cfg(feature = "crdt")]` test is not compiled in CI — not
skipped, not filtered, not reported. 279 tests have never executed in
CI, and 186 of them are in the library, whose `cargo test --lib
--features crdt` invocation CLAUDE.md lists as a required pre-PR gate.
CI has never once run a required gate.
Named in docs/active-work.md as "NEEDS A LANE" since it was found while
gating #166, with no branch and no owner until now.
Revision 2, approved. What the scout established beyond the ledger:
- The census moved and was re-measured at 4223dd3: 279 dark, not the
ledger's 273. Plus a fact the old census did not carry — eight test
binaries contain zero tests under CI flags, so they build, run, and
report ok with nothing in them.
- "279 dark" overstates the fix. Eleven are #[ignore]d, so a plain crdt
leg recovers 268. All 279 are now assigned a disposition: 268 by the
leg, 7 by a new m10-perf-gates job, 3 deliberately manual, 1 an
ignored known-defect marker. The lane recovers 275 of 279 and the
other four are excluded for stated reasons rather than left as
residue.
- The classification docs/active-work.md called "the lane's first task"
is finished, and it found three dispositions rather than two:
benches awaiting a job, deliberately-manual operator tests, and
known-defect markers.
- The ledger's clippy inventory was stale in both directions. It warned
its own list was "a lower bound, not an inventory" because clippy
aborts on first failure; --keep-going is what converts it. The
complete set is eight findings across four files, none behavioral.
- A hole in the proposed fix shape: the gpu-render job runs
`cargo test -p pmacs-gpu`, a different package from the four root-package
suites the fix wants to move there. And PMACS_REQUIRE_GPU is absent
from two of those four, so it cannot serve as blanket proof they ran.
- The full serialized crdt sweep is green: 3,715 passed, 0 failed, 30
ignored, reconciling exactly to the 3,746 census. That green result
shaped the acceptance criteria more than a red one would have — a
green pre-measurement is the condition under which a vacuous CI job
ships unnoticed, so the criteria gained a count reconciliation and a
deliberately-broken-test bite.
Revision 1 -> 2 also corrects revision 1's classification of
m10_10_perf, which was wrong in a way that would have made the lane
worse: the suite is a deliberate CI-default regression tripwire with
generous bounds, not a bench, so adding #[ignore] would have shipped a
coverage reduction inside a coverage lane.
Framing only. No workflow change, no source change, no branch plan
executed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nine PRs landed since the handoff's anchor (#199-#207) and it named
only four of them, so a fresh machine would not have learned that
ambient-root isolation exists, that the journey arc's 1b split
completed, or that the reap-ledger diagnostic landed. The ledger's
canonical base and recovery floor were five merges stale, and three
lanes described merged work as in flight.
Taken now because ZERO PRs are open. The ledger's own rule is never to
open a standalone refresh PR — because with several PRs open a lane
written on `main` re-conflicts at every merge — and this is the one
window where that cost is nil.
The handoff gains §1a, "Outstanding work — the whole board", which is
the point of the pass rather than a by-product: every arc against §20's
priority order with its next step, every open lane, every deferred item
attributed to the framing that parked it, and the standing hazards
someone running gates on a new machine needs — the three known flakes
by name, the basedpyright skip, the crdt sweep's build prerequisite,
and why a green a37 means nothing alone.
Two arcs completed, so per rule 4 their lanes are removed and their
facts are in the handoff: Journey Stage 1 and test ambient-root
isolation. Discovery and reap-ledger merged a stage each, so their
lanes are rewritten to the remaining plan rather than deleted — the
discovery lane now enumerates Stage 2 in dependency order and carries
the two Stage-1 facts a Stage-2 author would otherwise rediscover.
Base and floor advance together to `cfc1710`, per the file's own rule
that a floor accepting an older commit than the declared base passes on
a tree the document does not describe.
The recovery path was EXERCISED rather than asserted: from an empty
directory, clone, alias, fetch, floor check, and a lane worktree all
ran clean. The two-argument `git worktree add` still fails for a
remote-only branch, which is why every lane spells out the `-b` form.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
§7 said the classification comes first and alone, "its answer belongs in
review before any mechanical edit rides on it." The classification came
back at 342 sites across 66 of 97 files, and the whole-corpus migration
rode this PR anyway. That was a decision, not an oversight, and revision
5 records it as one so a later reader does not have to reconstruct it
from the diff.
The reasoning, in short: splitting would either leave 65 suites still
writing the developer's real data root while the seam sat unused, or ship
acceptance 12's ratchet with a ~65-file allowlist — and a ratchet
exempting most of the corpus records rather than ratchets. §7's ORDERING
is honoured (the census is the first commit); its implied SCOPING is not.
Revision 5 also records what review round 1 established about the shape
acceptance 12 needs: "a narrow, named allowlist" is not sufficient by
itself, because narrowness constrains which files are exempt and says
nothing about how far each exemption stretches. Exemptions carry counts.
`docs/active-work.md` picks up the same two facts and the PR number.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Per §25 the audited claim this stage falsifies is updated on the
landing PR. §5's scorecard row and ground truth both said the
registration metadata was best-in-class with almost no way for a user
to reach it; eleven `help.*` commands now reach it.
The row names what is still missing rather than implying the concern is
closed: packages and workers have no discovery surface, `Command` still
has no title/category/aliases/flags, M-x rows are still bare name
strings, the predicate is still never evaluated, settings value
provenance is still absent, and there is still no help prefix key. The
original audit grade is kept inline for reference.
`docs/keybindings.md` gains the family table and records that the
commands are reachable by name and bound to nothing — the help-prefix
decision belongs to a later stage, for the reason #205 recorded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
`docs/active-work.md`: the lane moves from FRAMING OPEN to
IMPLEMENTATION OPEN, with the implementation branch and worktree and a
recovery command that names them. The framing-only worktree is spent —
its doc is on `main` (#201).
`docs/agent-handoff.md` §3: a local full-suite run needs all FIVE
storage variables controlled, not four. `PMACS_STATE_HOME` outranks
`XDG_STATE_HOME`, so naming only the XDG four leaves a
higher-precedence state override live; and a run isolating only
`XDG_CONFIG_HOME` stops the `init.lua` reads while still writing through
the real data root — every local gate run in this repo before today had
that hole. `HOME` is deliberately excluded: it is the fallback the XDG
roots already cover once set, and it separately drives `~`-expansion,
which `find_file_acceptance` pins on purpose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Correct the M-x prompt census: six of the eleven canonical commands
need a second prompt, including describe-command. Make the apropos
substring negative discriminate against fuzzy matching with a concrete
non-contiguous fixture and a no-substring precondition. Update the help
index mutation to the twelfth canonical command, and carry all three
corrections into the active-work ledger.
No review findings at 1cc9d96; these are the two product choices the
framing deliberately left open.
Q#D2 resolves to `help.*` canonical with two forwarders. The family is
eleven commands under one prefix, so typing `help` at M-x surfaces all
of it — which is the discoverability win this arc exists for.
`editor.describe-command` and `editor.describe-setting` stay registered
as forwarders, so nothing in muscle memory or in
`docs/keybindings.md` breaks. Two forwarders are duplication of exactly
the kind §5 complains about; they are accepted as the bounded price of
not breaking documented names, and they carry a deprecation path. What
is not accepted is the split family revision 3 shipped.
Q#D3 resolves to substring. `fuzzy_score` is subsequence-based and
descriptions are long sentences, so a short query's letters almost
always appear in order — fuzzy would match nearly every command and
destroy the precision that makes apropos worth having. Acceptance 4 now
pins the decision rather than the intent: a subsequence that is not a
substring must find nothing.
Counts and pins follow the decision: the family is eleven throughout,
the `_show_help` counting stub expects eleven (the two renamed commands
are in it precisely because they were the pre-existing direct callers),
and the preservation pin now drives the forwarders through the real M-x
path — dropping them after the rename is the failure a user with muscle
memory would hit first.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two factual corrections, both accepted and both verified in the code.
The custom completion source does not control display order. Revision 3
justified sorting the pool by claiming `Custom` candidates appear in
return order; `recompute_candidates` hands the pool straight to
`filter_and_sort`, which ranks by fuzzy score descending and breaks
ties lexically, so the source's order never reaches the user.
The sort is kept, for a reason that is actually true: `filter_and_sort`
applies `.take(CANDIDATE_LIMIT)` to the FILTERED iterator before
sorting, so when more settings match than the limit, pool order decides
which survive truncation. Registration order would make that vary with
an unrelated config edit; sorting makes it reproducible.
Read-only would not mitigate the foreign-`*help*` collision either.
Revision 3 implied it would. A buffer the user created and named
`*help*` carries no intercept of ours, so an intercept on the buffers
we create protects nothing — the renderer still matches on the name and
clears theirs. The missing guarantee is ownership identity: a private
table of buffers this module created, so found-by-name is not adoption.
`listview` carries it as `panels` and dired as its handle table; this
mechanism carries neither. Naming the wrong missing guarantee would
send a later fix at the wrong layer, which is why the correction is
worth its own paragraph rather than a word swap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two blocking, two major. All four accepted.
The ledger lane still said revision 1 and still carried the two claims
revision 2 refuted. The cause is worth recording: revision 2's ledger
edit was an assert-then-write block whose later assertion failed, so
nothing before it was written either — while the commit message
reported the whole change as done. This is the second time in this
project that shape has silently dropped edits. The lane is rewritten
from scratch and the result verified by re-reading the file rather than
inferred from an exit code.
`names_from` does not exist. Revision 2's completion source called a
helper nobody has written, over `pmacs.config.list()`'s descriptor
tables where `CompletionSource::Custom` consumes a sequence of strings.
Opening the prompt would have raised on an undefined global. The mapper
is now specified, and sorted — `Custom` presents candidates in the
order returned, and registration order is neither stable nor useful.
`*help*` has no read-only intercept. Revision 2 claimed one while
`show_help_text` writes with plain delete/insert, and #205 had already
recorded that this mechanism has not adopted the generated-buffer write
invariant. §3.4 now names the policies that really are shared —
reuse-by-name, wholesale replacement, the `q` binding, and the
foreign-buffer hazard — and notes that the last is precisely what a
read-only intercept would have mitigated and does not.
The naming was underspecified. With no `help.describe-command` in the
table, calling the existing `editor.describe-*` commands
"aliases-by-retention" was wrong on both halves: nothing forwards to
them and there was nothing for them to alias. They are now explicit
exceptions, the resulting split surface is named as a wart, and Q#D2 is
sharpened to the two ways out — forward the two under `help.*`, or keep
the family `editor.*` throughout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two blocking, two major. All four accepted and verified in the code
before the doc changed.
Completion does not close the free-text hole, and revision 1 said it
did. `resolve_accepted_value` returns the literal typed text whenever
no candidate is selected, so a non-matching typo still reaches
`on_accept` and the existing error path; separately, a fuzzy near-miss
can silently describe a DIFFERENT setting, which is a new failure mode
revision 1 did not name. Completion is reframed as assistance, the
acceptance pins both outcomes, and closed-set acceptance semantics are
named as Rust work rather than smuggled in as a side effect of adding
a source.
`invoke_interactive` is not the M-x path — the exact error #205
corrected one PR earlier. It rotates the interactive-command boundary
and calls the body; it opens no palette. The acceptance now states the
real path once and drives it: dispatch M-x, type the name, assert the
selected candidate BEFORE RET (accept does `session.take()`), accept,
and — for the five commands that take an argument — drive the second
prompt too. A pin that stops after the first RET has tested the
palette, not the command.
The `_show_help` seam is an output sink, not a migration seam.
`src/help.rs` has semantic renderers for command/key/buffer/mode/hook/
view and none for settings, lists or apropos, and the seam takes
already-flattened text, so a later migration still has to change each
command's subject-specific logic. The claim is narrowed to what is true
— one owner for Lua `*help*` writes — and paired with a per-subject
renderer function so the future Rust work is enumerated rather than
discovered.
Ground truth corrected: the missing-command list was eight and omitted
`list-settings` while §3.1 said nine; the site count said ten where
nine additions make eleven; `pmacs.keymap.lookup` does not return
`description` (it passes `cmd = None`); and the predicate sites cited
were `MenuItem` fields, not `Command.predicate`. The predicate
conclusion survives on the correct evidence — `src/help.rs:76` and one
assertion past `#[cfg(test)]`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
`COHERENCE.md` §20 Priority 4, which §5 grades "substrate without
surface — the sharpest instance of §1.1" and calls the best
payoff-per-effort in the document. Nine describe/list commands over
introspection that already exists, picking up the family root `M-x
help` that #205 landed and documented for exactly this.
The stage adds no Rust. `pmacs.describe.*`, `pmacs.keymap.list()`,
`pmacs.command.list()` and `pmacs.config.list()` already return
everything the commands render, and `parse_completion_source` accepts a
Lua function as a `CompletionSource::Custom` — so `describe-setting`'s
free-text prompt, which today turns a typo into a status-line error
while `describe-command` has had completion all along, closes with no
new Rust either.
The consequential decision is a single rendering seam. `src/help.rs`'s
cross-referenced renderer is orphaned and the reachable Lua
`show_help_text` renders less, so nine new commands calling it directly
would turn a two-site migration into a ten-site one. Everything routes
through `pmacs.editor._show_help`, and an acceptance pin replaces that
seam with a counting stub — funnelling asserted, not merely intended.
Records that `Command.predicate` is stored and exposed but evaluated
nowhere, and deliberately does not start evaluating it: that makes
commands stop being invocable, which needs its own decision about what
"unavailable" means at each call site. A preservation pin registers a
raising predicate and asserts the command still runs, so a later stage
has to change that pin knowingly.
Adds no keybindings at all — the help-prefix question is taken once,
for the whole family, by the stage that can weigh it against the
constraint #205 recorded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Review round 2 on #205, one finding, accepted. #204 is this PR's base,
so three places still describing it as open were simply false.
- `COHERENCE.md` §2's step-6 row: "(PR open) ends the silence" ->
"(#204) ended the silence", and the "flips only on merge" clause is
replaced by the reason the row is still Partial at all — a server
that starts and then crashes is unsurfaced, which that landing did
not touch.
- `docs/agent-handoff.md`: the 1b-2 bullet says LANDED (#204), with the
same substituted reason.
- `docs/active-work.md`: 1b-2's per-stage block is removed rather than
relabelled, per rule 4 — it has merged and its durable facts are in
the handoff, which is the precondition for removal.
That last one exposed a structural problem the merge had created: 1b-2's
old lane body had come in *underneath* the unified journey header, so
the file carried two journey sections and the first one's text
described the second's predecessor. There is now one arc lane with
1b-3 nested under it as the only open stage.
Also corrects the reap-ledger lane header, which still read
"IMPLEMENTED, PR OPEN" after #202 merged. Same class of staleness,
noticed while editing the same file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Review round 1 on #205, two findings, both accepted.
The greeting was written straight into the registry without calling
`notify_buffer_edit`. The window's `TextView` had been indexed while
`*scratch*` was empty, and newlines are zero-width to a painter working
from a stale line index — so the first TUI frame collapsed the whole
three-line greeting onto row 0. Every buffer-text assertion passed
because the buffer content was correct; only the rendering was wrong.
The edit is now captured, the registry borrow released, and the core
notified.
The pin that would have caught it paints a real frame and asserts the
second line occupies its own row AND that row 0 does not contain it —
both directions, because a one-direction check passes when everything
collapses upward. Bitten by dropping the notify call: row 1 comes back
empty with row 0 holding the lot, and it is the only pin that fails.
Second: the project docs still described the arc as it was two PRs ago.
`COHERENCE.md` §20 called 1b-2 in flight and the welcome buffer
unstarted; its arc list said 1b-3 remained; and the ledger's journey
lane header still read "1b-2 PR OPEN" while the 1b-3 block carried a
mangled "Framing only; no code" line left by an earlier edit. All now
describe the PR-head state per §25.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
The journey suite conflicted additively — step 4 from this lane, step 6
from #204 — and both are kept: 44 pins now cover steps 2, 3, 4, 5, 6
and 9.
Per §25 the audited claims this stage falsifies are updated on the
landing PR rather than deferred: the scorecard's row 18 and §18's
ground truth both read "Missing" / "missing entirely", and a welcome
buffer plus a reachable cheat sheet makes both false. They move to
Partial. §2's step-4 row stays Partial, because `C-h` still deletes a
word and there is no tutorial.
§18's ground truth now records WHY `C-h` stays as it is, so the
help-prefix question reaches the discovery arc as a stated trade rather
than an oversight: non-kitty terminals cannot disambiguate
Ctrl+Backspace from Ctrl+H, so rebinding it would break Ctrl+Backspace
on every legacy terminal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two findings, both accepted.
The pinned API was crate-private while the pin was external.
`tests/journey_acceptance.rs` is a separate integration crate and
cannot call a `pub(crate)` function or match a `pub(crate)` enum, so
revision 3's acceptance 1 could not have compiled. `prepare_startup`
and `Startup` are now `pub`, which is consistent rather than expedient:
`run`, `EditorState::new`, `EditorState::open`, `install_state_dirs`
and `restore_desktop_if_armed` are already public, so the startup
sequence is public surface and this was the piece missing from it. The
alternative — keep it private and move the pin into `src/editor.rs`'s
unit tests — was rejected because §19 wants the journey row in the
journey suite.
The isolation that pin needs is now stated rather than left implicit.
`prepare_startup` deliberately calls `install_state_dirs`, which
resolves `PMACS_STATE_HOME` and XDG roots that tests cannot override
(`set_var` is unsafe and forbidden), so the pin inherits the standing
five-variable ambient-root requirement, asserts buffer content only,
and must assert that desktop restore was unarmed — a developer whose
real `init.lua` calls `desktop_mode(true)` would otherwise get a
restored scratch buffer and a silently different result.
The M-x acceptance still left its key assertion as an "or", and half of
it was impossible: `Minibuffer::accept` does `session.take()` and
resolves against the selected candidate, so after RET neither the
session nor the typed contents survive to be asserted. The framing now
specifies one observable, available before RET:
`pmacs.minibuffer.selected()` must equal exactly "help", then accept.
If the completion source selected something else the pin fails there,
naming what was actually selected, instead of passing on a help buffer
some other command produced.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two acceptance holes and one doc correction, all accepted.
The real startup wiring was still unpinned, and revision 2 knew it: it
named the gap and then accepted it as residual, which is worse than
missing it. Deleting the sole `run()` call to `finalize_local_launch`
would have left every proposed pin green while shipping no welcome —
pin 1 called the seam by hand and pin 10 only proved constructors were
blank. That is the shape of a guard with no production caller passing
every direct-call test.
The fix is extraction, not disclaimer. Everything in `run()` from
`install_panic_hook` through the end of the attach-dispatch match is
terminal-free; `Frontend::new()` is where takeover begins. That prefix
becomes `prepare_startup`, which `run()` delegates to and which the
welcome pin now drives. Deleting the finalize call inside it turns the
pin red. What stays outside a test is `Frontend::new()` and the event
loop, which is where terminal takeover genuinely lives.
Acceptance 4 was not the M-x path. `pmacs.command.invoke` is the
programmatic API; M-x is `editor.execute-command`, which opens a
minibuffer with the `commands` completion source and calls
`invoke_interactive` only on accept. The pin now dispatches the chord,
enters the name, and accepts — and names the hazard that makes that
non-trivial: a selected candidate shadows typed text, so the pin has to
assert which command ran rather than trusting that some help buffer
appeared. dired refused a completion source on its own prompt for
exactly this reason.
Also corrects the #204 references: revision 2's history said it had
landed while the framing footer and ledger still called it open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Four findings, all accepted and verified in the tree first. The three
open questions are answered and folded into the design: three lines,
name `C-c c` and `C-c t` verified from structured entries, and the
command is `help`.
The startup seam was wrong, and every acceptance criterion rested on
it. `EditorState::new()` is not the no-argument entry point:
`EditorState::open` calls it before resolving the target, the daemon
constructs one too, user config runs inside it, and desktop restore
happens much later inside `run()`'s `RunLocal` arm. Greeting from
`new()` would greet a daemon, greet before a file argument replaced the
buffer, and precede anything config or a restored session put in
`*scratch*`. The stage now adds a launch-finalization seam called right
after `restore_desktop_if_armed`, using the `had_file` signal already
threaded to that point. Its untestable part — that `run()` calls it —
is stated rather than papered over, and bracketed by pins proving the
seam works and that no constructor greets on its own.
The step-2 pin amendment is withdrawn. Revision 1 analysed a
status-line welcome and then chose `*scratch*` but kept the amendment,
which was an internal contradiction. The status stays empty so the pin
stays true, and "no error text" has no defined predicate over an
unstructured status string — replacing an exact check with a fuzzy one
would weaken the ratchet to buy nothing.
The claim that this stage carried no §25 obligation was false. The
scorecard's row 18 and §18's ground truth both read Missing, and a
landed welcome plus reachable cheat sheet falsifies both: they move to
Partial on merge while §2's step-4 row stays Partial. A stage can be
too small to flip its journey step and still falsify a "missing
entirely" grade.
Acceptance 2 could not have been implemented as written. Scraping key
sequences out of prose is ambiguous — `M-x help` mixes a chord with a
command name, and `C-c c` is two chords whose boundary the text does
not mark. One structured entry list now both renders the text and
drives the `pmacs.keymap.lookup` checks, and `M-x help` is exercised
through the real palette path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
The last of the 1b split. Journey step 4 and `COHERENCE.md` §18: a
fresh `pmacs` greets the user with an empty buffer, an empty status
line, and no indication that `M-x` exists — the sole discovery
affordance in the product is knowing to press it.
Three findings shape the design:
- The existing step-2 ratchet pin collides with any welcome. It asserts
`status.is_empty()` while its own message says "reports no error" —
the same predicate only while nothing writes a non-error status at
startup. The framing corrects the assertion to its message's claim
and names that as the one existing assertion the stage changes,
rather than burying it in a diff.
- `C-h` is not free. It is bound to word-delete because non-kitty
terminals cannot disambiguate Ctrl+Backspace from Ctrl+H — both
produce byte 0x08 — so rebinding it to a help prefix would break
Ctrl+Backspace on every legacy terminal. §2's step-4 row calls it an
oversight; it is a deliberate trade with a stated rationale. The
help-prefix decision is deferred to the discovery arc with the
constraint recorded so it is inherited rather than rediscovered.
- A `*help*` buffer mechanism already exists over `src/help.rs`, so the
welcome can point at something real. Its two gaps are recorded rather
than inherited silently: it writes with delete/insert instead of
`set_generated_contents`, and it is found by name.
The welcome deliberately does NOT use `set_generated_contents`: that
lifts read-only, discards history and marks the buffer generated, all
wrong for the buffer step 5 requires the user to type into immediately.
Step 4 stays Partial — the row names a welcome, a cheat sheet and
`C-h`, and this closes the first plus a minimal second — so this is the
first 1b stage with no landed-evidence obligation on merge.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Stage 1b-1 landed as #203, so the four places it deliberately left
saying "in flight" are flipped here rather than in a standalone docs
PR: this branch already touches all three files, and a separate PR
would re-conflict on every merge.
- `COHERENCE.md` §2's step-9 row: Partial -> **Works**.
- §2's keybinding-inversion paragraph: all three examples answered. The
quote itself is deliberately unchanged — it names a bias, and three
fixes do not retire a bias.
- §20 Priority 1 and the arc list: 1b-1 landed, 1b-2 in flight, 1b-3
remaining.
- `docs/agent-handoff.md` §1: IMPLEMENTED -> LANDED.
Conflicts were additive on both sides and are resolved keeping both:
the journey suite carries step 9 and step 6 (34 pins), and §24 keeps
both drift entries — the `ProjectKind::Cargo` naming error and §1.2's
wrong frequency note.
The two journey lanes are unified into one arc lane rather than one
being deleted. Rule 4 removes a lane when its ARC is done, and the
journey arc is not: 1b-2 is in flight and 1b-3 is unframed. Stage 1a
and 1b-1 are summarized there with their facts in the handoff, which is
rule 4's precondition satisfied rather than deferred.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Implements `docs/journey-stage1b2-lsp-guidance-framing.md` (approved at
revision 4, after three review rounds). Lua, tests and docs; no Rust
change and no protocol change.
`COHERENCE.md` §1.2's canonical silence: a preconfigured server that is
not installed failed with no status message, no record and no modeline
marker, while tree-sitter highlighting kept working and masked it. Now
the status line names the command, the language and the errno; the
modeline reads `LSP:!` instead of nothing; and `M-x lsp.status` renders
a durable `*lsp*` panel.
Half of this was already built. `status_buffer_text()` and
`last_error()` have existed since M4.8, exposed to Lua and tested, with
no production caller and no buffer to render into — several doc
comments already referred to "the `*lsp*` buffer" as though it existed.
The reporting shape was likewise already adopted twice inside
`lsp.lua`; the canonical case was silent because nobody had converted
it.
Three tables with three lifetimes, because one cannot do the job:
`reported` is never cleared and includes the command, so repointing at
another missing executable reports again; `failures` is cleared by a
successful spawn so the panel goes quiet on recovery; and a
buffer-keyed projection feeds the modeline, because that provider runs
for every window on every paint and deriving an affinity key inside it
would invoke root resolvers during painting.
The memo is on the report, not the failure: the spawn is still
attempted on every file open, so installing the binary mid-session
recovers with nothing to invalidate.
Adds `tests/lsp_spawn_guidance_acceptance.rs` (16 pins) and a step-6
row to the journey ratchet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
One blocking lifecycle gap, accepted. The registry's dispatch order was
read before specifying the fix rather than assumed.
`failed_attachments` is keyed by `tostring(buf)` and revision 3 never
said who deletes an entry, so killing a failed buffer leaked its
projection for the session — and that also made revision 3's sweep
bound ("at most the number of open buffers") false, since the table
could exceed the number of buffers that exist.
Nothing existing would have cleaned it incidentally. The LSP resource
reconciliation finds its work through `attachments_under`, which
iterates `attachments`, and a failed buffer has no attachment by
construction — that is the whole reason the projection exists. The gap
needed its own registration.
Revision 4 specifies:
- `pmacs.buffer.on_removed` registered once per projection, never per
failed attempt, since `attach_buffer` is reachable more than once for
the same buffer and per-attempt registration would stack callbacks —
the same unbounded-registrar shape with the leak moved rather than
fixed.
- The handle released on the success sweep, where the buffer is still
alive, but not from inside the removal callback: dispatch does
`callbacks.take(id)` and then iterates a local vector, so the entry is
already gone.
- Rename and delete CLEAR the projection rather than re-keying it.
The projection asserts "this buffer's server failed for affinity K",
and after a rename that is no longer known to hold — the new path may
be in a different project or none. Re-keying would assert a failure at
a location where none was observed, which is the error shape this arc
has been correcting throughout.
- The sweep bound now follows from the cleanup instead of sitting beside
it as an independent claim.
Adds acceptance 14-16 for kill, rename and delete, each asserting the
chosen behaviour rather than merely the absence of the forbidden one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two blocking, two cleanups. All four accepted, and both blockers
verified by running Lua rather than by reading it.
Recovery was inconsistent across buffers sharing an affinity. Revision
2 cleared `failures[K]` on a successful spawn but cleared only the
succeeding buffer's projection, so: buffer A fails, buffer B succeeds
for the same key, `M-x lsp.status` reports nothing wrong, and A's
modeline still reads `LSP:!`. Revision 2's claim that the two tables
are "written and cleared at the same moment" was false for exactly the
cross-buffer case, which is the normal case for a project with more
than one file. Each projection now carries its affinity key and a
success sweeps every projection holding it. The new pin asserts on A,
not B — a version checking B passes on the broken implementation.
The markerless key had no Lua representation. `key_uri` is deliberately
nil and `t[nil] = v` raises "table index is nil" — confirmed under both
LuaJIT and Lua 5.4 — so the central markerless criterion was literally
unimplementable as written, and leaving it to implementation would have
produced two ad-hoc encodings for the two tables. The framing now
prescribes one key function used by both, with a `u`/`n` discriminator
that cannot collide with any URI and a NUL separator (Lua strings are
8-bit clean, checked).
Acceptance 10 could not have observed what it claimed: making the
command resolvable changes no state by itself, since `failures` is
cleared by a successful spawn. The pin now reattaches before pressing
`g`, and says why that step is load-bearing.
Also corrects the ledger heading, which still said revision 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Review round 1 on #203, two blocking findings, both accepted.
The compile-directory assertions used the suite's lexical `canon()`,
but `pmacs.project.detect` canonicalizes before walking
(`canonicalize_or_passthrough`, `src/project.rs:509-511`), so the
compile cwd is filesystem-canonical. On macOS `/var` is a symlink to
`/private/var` and the two spellings disagree — both macOS legs failed
while Ubuntu, where `/tmp` is not a symlink, stayed green.
Fixed with a `detected_root()` expectation, and pinned by a fixture
that launches through an explicit **symlink** so lexical and canonical
paths disagree on every platform. That matters more than the fix: the
original bite ran only on Linux, where nothing could make the two
differ, so no amount of local mutation testing would have caught this.
The new pin is the only one that goes red when the lexical expectation
is restored.
Second: `COHERENCE.md` §2's step-9 row was flipped to **Works** and the
handoff said Stage 1b-1 was **LANDED**, while this PR is open. §25 is
explicit that grades change only with landed evidence, never
aspirationally. Both now describe the real state — the row stays
Partial and names #203 as the open PR that closes it, §20 and the arc
list say "in flight", and the handoff says IMPLEMENTED with the PR
number.
The flip is not dropped, it is owned: the active-work lane records the
four places to change on merge, because an unowned doc flip is exactly
how this ledger's drift starts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two blocking, three major, one minor. All six accepted and verified in
the code before the doc changed.
The affinity key was misstated. `ensure_server` sets `key_uri` only
when the root came from config or a marker walk, so a markerless file
keys on nil and loose files across unrelated directories deliberately
share one server per language. Revision 1's "(root, language)" would
have split what the runtime shares and re-reported one failure once per
directory. The memo now uses the real key and the stage changes no
reuse behaviour.
Dedupe and current-failure state were conflated into one record, and
revision 1 said nothing about recovery. One record cannot do both jobs:
keep it and `*lsp*` shows a failure the user has already fixed; clear
it and the message returns on the next file open. They are now two
records with different lifetimes, the reported identity includes the
command so repointing config at a different missing executable reports
again, and recovery is pinned in both surfaces.
The modeline provider is a pure per-buffer projection by design — it
runs for every window on every paint. Revision 1's "read the failure
table" would have made it derive an affinity key, invoking user root
resolvers and project detection inside painting. The failure is now
projected per buffer at attach time and the segment stays one map
lookup, with a preservation pin that counts resolver invocations.
"Adopt listview's idiom" is replaced by requiring `pmacs.listview.open`
and naming what it guarantees, including `on_refresh` — without which
`listview.refresh` early-returns and `g` is a bound key that silently
does nothing.
The acceptance had no journey ratchet row despite the stage making step
6 real; `tests/journey_acceptance.rs` states that steps 6-12 join as
later stages make them real, and 1b-1 added step 9 the same way. The
end-to-end row is now acceptance 1 and the M4 pins stay beneath it.
Also refreshes the ledger's canonical-base anchor and recovery floor
from `7586905` to `fbcf235`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
`COHERENCE.md` §1.2's canonical silence, and journey step 6: a
preconfigured-but-missing language server fails with no status message,
no record, and no modeline marker, while tree-sitter highlighting keeps
working and masks it.
Three findings shape the design, all verified in the tree:
- The reporting pattern is already adopted twice inside `lsp.lua`
itself — root-resolver failures and subscriber failures both report
through `pmacs.editor.set_status` with the `pmacs.error` arm riding
along. The canonical spawn failure at `:658-674` was simply never
converted, so this stage finishes an adoption rather than starting
one.
- Half the stage is already built and unwired.
`LspManager::status_buffer_text()` renders "the `*lsp*` status
buffer", `last_error(sid)` exists, and both are exposed to Lua and
tested — with no production caller, no `*lsp*` buffer and no command.
Several doc comments already refer to that buffer as though it
exists.
- COHERENCE's frequency note is wrong, and the correction decides the
hardest question. It records the failure as firing once per project
root; `LspManager::spawn` returns early *before* both
`status_tracker.ensure` and `clients.insert`, so a failed spawn
leaves no record, the affinity loop cannot see it, and the real rate
is once per file open. Hence the rule the stage adopts: memoize the
report, not the failure — the spawn is still retried, so installing
the binary mid-session recovers with nothing to invalidate.
Records one limitation rather than hiding it: `status_buffer_text`
renders from `self.clients`, which a failed spawn never enters, so the
durable surface cannot yet show the failure natively. The record stays
in Lua for this stage.
Also logs four stale `COHERENCE.md` §1.2 citations for correction when
the stage lands.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Implements `docs/journey-stage1b1-compile-defaults-framing.md`
(approved at revision 2). Lua, tests and docs; no Rust change and no
protocol change.
`C-c c` now runs `compile.run`, and the first prompt is prefilled from
the detected project kind through `pmacs.compile.defaults` — seeded
`rust = "cargo build"` and extensible from `init.lua`. `_last` still
wins, so a session that has compiled keeps its own command.
The prompt CAPTURES its directory rather than re-resolving it. Sharing
one resolver between the prompt and the run is necessary and not
sufficient: `pmacs.minibuffer.read` is asynchronous and nothing freezes
the active window while a prompt is open, so two calls to the same
resolver at two different moments are still two different answers — the
user could be offered `cargo build` for A and handed a run in B by
clicking away mid-prompt. This is Journey Stage 1a's `commit_to`
discipline on a smaller seam.
`pmacs.compile.defaults` is public and assignable, so the lookup is
guarded: a throwing `__index`, a non-string entry and a non-table
replacement all degrade to the pre-stage empty prompt and never
prevent compiling.
Only `rust` ships seeded. Rust has one answer; npm/yarn/pnpm,
make/cmake, and `go build` versus `go test` do not, and a wrong prefill
costs more than an empty one.
Adds eight step-9 rows to the journey ratchet and five module pins to
the compile suite. Corrects `COHERENCE.md`, which named a
`ProjectKind::Cargo` that does not exist — the variant is `Rust`, line
77 is its doc comment, and Lua only ever sees the tag string "rust".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Review round 1, one finding, accepted.
"A failed escalation is never retried by anything" was false.
`shutdown()`'s force-kill loop iterates the reap ledger with **no**
`!entry.killed` guard, so it does re-kill an entry the escalation arm
gave up on. The accurate claim is that no later *tick* retries it —
`tick_reap_ledger`'s escalation is guarded by `!entry.killed` and never
fires again for that group.
The overclaim collapsed two failure modes that this lane exists to keep
distinct: a failed escalation leaks the group until editor exit, where
one more attempt is made, while a failed `shutdown()` force-kill leaks
it past exit with nothing left to try. Narrowed in the framing, the
handoff, the active-work ledger and the test commentary.
The corrected claim was asserted in three documents and pinned by
nothing, so it gets a pin: a failed escalation marks the entry, the
survivor stays alive across ticks, and `shutdown()` — with no fault
planned, so its force-kill really lands — still reaps it. Bitten by
adding the missing `!entry.killed` guard to that loop: the new pin
fails and the other five stay green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Not a new design round. Every bet resolved, and one acceptance turned
out to be satisfiable vacuously.
Acceptance 2's in-drain clause said "the live descendant's named late
output absent" without saying how the descendant stays live. It does
not, by default: `poll_one` TERMs the whole group on leader exit. The
first fixture's marker was therefore absent on both paths, and the pin
would have stayed green with the collapse fixed.
Bets 1 and 2 hold — every site took a directed outcome without
restructuring, and every consequence is reachable, so the lane does not
shrink. Bet 3 resolves the shutdown coupling as real and measured. Bet
4 is falsified exactly as its own clause anticipated: `ProcessEvent` is
keyed by `ProcessId` while the ledger is keyed by pgid and is
deliberately independent of managed records, every production consumer
polls per known id, and `take_all_events` has no production consumer at
all. Q#RL3 is answered accordingly and reporting is parked as its own
lane.
Also records the four sites and the two reusable lessons in
`docs/agent-handoff.md` — that a seam for a background loop has to be
directed, and that an absence assertion is only as good as its
fixture's ability to produce the thing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Two blocking, two major. All four accepted and verified in the code
before the doc changed.
Sharing one cwd resolver between the prompt and the run does not
prevent drift. `pmacs.minibuffer.read` is asynchronous, nothing freezes
the active window while a prompt is open, and `run` re-resolved at
accept time — so the prompt could offer `cargo build` for A and execute
in B. Two calls to the same resolver at two different moments are still
two different answers. The interactive command now captures
`context()` and passes its `cwd` through to `run`. This is Journey
Stage 1a's `commit_to` discipline on a smaller seam: capture at request
time, never re-derive from whatever is ambient when the async work
lands.
No pin crossed the accept boundary. N1-N5 compared values the prompt
and the resolver had already agreed on, so a wrong directory inside
`on_accept` — exactly the defect above — passed every one of them. Two
pins now accept: N3 switches windows between prompt and RET and reads
the directory back two ways, and N4 accepts `cargo build` unedited in a
real Cargo fixture and asserts a clean exit.
N3's old falsifier was not discriminating: `project_root_of_active()`
already returns the innermost root, so re-detecting from it yields the
same kind and the pin would have stayed green. The mixed-fixture pin is
now N5 with a falsifier it actually catches, and says what it does not.
And §6.1 contradicted §3.1 — a Cargo workspace subdirectory holds no
`Cargo.toml` and correctly receives `cargo build`. The predicate is a
detected project, not a file in that one directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
`COHERENCE.md` §20 Priority 1 names Journey Stage 1b as the golden
journey's remainder and it had no branch, no framing, and no lane —
the only §20 priority with nothing in flight. This frames the first
third of it: journey step 9, build or test the project.
Scope is a global `C-c c` for `compile.run` plus a first prompt
prefilled from the detected project kind instead of empty. Lua, tests
and docs; no Rust change, no protocol change. LSP spawn guidance and
the welcome buffer are separate stages (§7).
Three ground-truth findings the framing rests on:
- `ProjectKind::Cargo` does not exist. COHERENCE names it twice; the
variant is `ProjectKind::Rust` and line 77 is its doc comment. Lua
matches the tag string `pmacs.project.detect` already returns, so
the stage needs no new Rust primitive.
- The compile cwd is resolved inside `run`, after the prompt closes,
so a suggestion built in the command's `fn` would obey a different
rule than the run. The stage extracts one resolution and has both
consume it.
- The last-resort cwd is `std::env::current_dir()` at call time, which
in tests is the pmacs repo root — itself a Cargo project. Negative
pins are built so that fallback is never reached.
Records one limitation rather than fixing it: after `pmacs <dir>` the
active buffer is dired's and pathless, so the cwd falls through to the
process cwd. That needs COHERENCE §8's execution-location model, not a
reach into dired's private handle table.
Adds the journey lane to the active-work ledger.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Refine the framing's in-drain test seam: a one-shot probe error cannot
survive the 50 ms quiescence interval, so the test-only override lasts
for one drain context and remains per-supervisor. Name the in-drain
SIGKILL as a non-observable local fact rather than adding an untestable
seam, and synchronize the revision-three ledger record.
The revision-2 commit shipped the framing alone. Its ledger edit was
generated by a script that aborted on a line-wrap mismatch before
writing, so `b881bd4` left the lane entry describing revision 1 — three
silent failures instead of four, no in-drain twin, no site-directed
seam, and the withdrawn "Bet 1 ships alone" staging.
Synchronized now: four sites including `final_drain_runtime` and its
distinct reader-cancellation consequence; journey step 9 rather than 8;
the `any_running()` precondition on the shutdown coupling; and the
first PR scoped as seam plus tests.
The failure mode is worth naming, because a partial write is exactly the
shape that leaves a document confidently wrong: the commit succeeded and
reported one file changed, which is easy to read as success when two
were intended.
Three blocking and two major findings, all accepted, all verified in the
code first.
- **§0 named the wrong journey step**, and contradicted Q#RL5 in the same
document. The ledger arms only for `spec.group`, which spawn rejects
for PTY mode, so no terminal reaches it. The only production
`group = true` caller is compile mode, making this journey step 9
(build/test) plus general pipe-process cleanup.
- **A fourth site was missed.** `final_drain_runtime` collapses every
probe errno to "dead" while no tick runs, discards its SIGKILL result,
and sets its own flag. It is not identical to the persistent ledger —
a later tick can retry that, this decision is terminal for the drain —
and its consequence differs: a false "dead" cancels the readers, so
the failure mode is truncated output rather than a leaked process. It
also constrains the seam, being a free function with no `&mut self`.
- **The staging contradicted itself**: "Bet 1 ships alone" against an
acceptance requiring failure-path tests, under one-branch/one-PR. It
was also wrong on its own terms — a seam with no tests does not show
it reaches the intended production calls. The first PR is now seam
plus behaviour-preserving tests, still diagnosis-only.
- **A generic seam is the wrong shape.** `shutdown()` calls
`self.signal(*id, SIGKILL)` before its ledger force-kill, so one
shared "next kill errno" would be consumed by the wrong call and the
test would pass while proving nothing. The seam is now site-directed
with four independently addressable outcomes, expressing more than one
pending result because the coupling test needs two at once, and with
fixture cleanup stated rather than assumed.
- **§1.3 overstated the loop coupling.** Early exit needs the ledger
empty AND `any_running()` already false. The precondition is now in
the ground truth and in Bet 3's fixture requirement.
Framing only. No code.
Unparked from PR #200's §5, which retired the premise justifying the
ledger's leniency and deliberately changed no disposition.
Scouting found three silent failures where #200 named two. A probe error
of any errno drops the entry and cancels escalation; a failed escalating
SIGKILL is recorded as a success and never retried; and `shutdown()`
discards its own force-kill result identically — on the path written
specifically to stop a leak at editor exit.
Two facts shape the lane. `shutdown()`'s final loop terminates when the
ledger empties, which happens through the same silent drop, so the probe
error that hides a leak can also end the cleanup loop early — the probe
cannot be made strict in isolation. And all three paths are untestable
today: `tick_reap_ledger` and `shutdown()` call nix directly and consult
no injection seam, unlike `signal()`'s `forced_kill_errno`, so every one
of the five existing ledger tests exercises only the success path.
Diagnosis first; no disposition change is proposed. Stage A of the signal
lane had three tolerance rules rejected across three revisions, each for
concluding something about one entity from something about another, on
this same data structure.
The framing states plainly that none of the three has been observed:
#200 saw an explicit SIGTERM fail in `signal()`, not a ledger call.
Framing only. No code.
`docs/active-work.md` auto-merged without conflict — this branch's lane
entry sits above the folding lane, clear of the six blocks #199 removed.
Verified rather than assumed: all lane headers checked afterwards.
The merge surfaced a stale statement on `main`. The process-signal lane
still read "PR #200 open, four review rounds closed, held for review",
which stopped being true when #200 merged as `a2a92bb`. Its arc is
complete — Stage A #176 and Stage B #200 both landed, and the items its
§5 parked become their own lanes — so under the rule #199 established
(a lane retires when its ARC is done, not when a PR merges) it is
removed and recorded under "Closed since the last snapshot".
Doing that here rather than deferring it: this PR already edits the
file, and leaving a known-false statement on `main` to keep a PR
single-purpose is the wrong trade. The alternative was letting it stand
until the reap-ledger lane, which is scoped next and inherits from the
very §5 list being retired.
Review round 5: one blocking, one major. Both documentation-only; the
runtime fixes from round 4 are unchanged.
**The pre-kill sample was overclaimed.** Acceptance 4 said the measured
group "describes the target that was attempted". It does not. `getpgid`
and `kill` remain separated by the same read-then-act window §1.5 is
built on, so the sample can be stale by the time the signal is
delivered. Moving it earlier removes a POST-HOC reading; it does not
make the reading contemporaneous. The criterion now says it records
pre-kill evidence about the attempted target, and adds an explicit
sentence forbidding any acceptance from claiming otherwise.
This is worth naming rather than quietly editing: the framing's whole
spine is that this telemetry establishes less than it appears to, and
round 4 fixed a real ordering defect and then inflated the fix's meaning
inside the document that governs it.
**`95897f7`'s commit message carries the same overclaim.** It is not
amended — force-pushing a branch under review to rewrite history would
hide the error rather than correct it. This message is the correction,
and the two read in sequence.
**A dead doc comment was documenting a constant.** The original
pre-Stage-B acceptance-1 block survived the rewrite and came to rest
above `const BASH`, so the file explained a string constant with the
sentence this entire lane exists to remove — "here they are asserted to
agree only because nothing has moved the terminal", describing a test
that no longer exists. Removed; only the BASH explanation remains.
Verified the overclaim is gone from the whole tree, not only the cited
line: no hits in `docs/` or `src/`.
Gates: 11 gates, 4,471 tests, zero failures.
Review round 4: three blocking, one major. All accepted.
**`measured_group` was sampled after the failure.** It ran inside
`signal_failure_report`, after the `kill` and after `observe_leader`,
while the framing and the function's own doc both said before. A
concurrent group change would have made the diagnostic report
post-failure state as evidence about the attempted target. It is now
sampled in `signal` before the kill and passed into the report, so the
field describes the target that was attempted rather than the state the
failure left behind.
**The Linux corroboration did not exercise the production lookup.** Its
helper read `portable_pty::process_group_leader` — the accessor this
lane stopped using on the signal path — so `pty_foreground_group` could
have fallen back on every call with every test still green. Forcing it
to always fall back demonstrates the hole exactly: the corroboration
fails, and the injected pin PASSES, because the injected tests supply
the group themselves and structurally cannot detect a broken lookup.
The helper now calls the production lookup, and the corroboration forces
only the kill so the report is built from a real terminal read. The
residual limitation is recorded rather than left to the green: on macOS
`pty_foreground_group` has no end-to-end coverage, because the platform
cannot produce the precondition.
**The framing did not update its own acceptance contract.** Revision 5
recorded Bet 1's falsification in the revision history and in the bet,
and left the normative criterion demanding the real-shell rewrite — the
"implementation quietly diverges from the contract" shape this project
already recorded as a lesson on #191/#188. Acceptance 1 now describes
the injected pin, 1a adds the corroboration and its macOS limitation,
and 4 states the sampling order. The ledger is synchronized: revision 6,
four commits, 4,471 tests, bash armed on Linux only.
**`TargetSource`'s doc had the wrong classification.** Two of the four
variants target the leader pid, not one, and the pid-versus-group split
does not line up with PTY-versus-pipe — which is why the fallback needed
its own variant rather than reusing `LeaderPid`.
Gates: 11 gates, 4,471 tests, zero failures.
CI falsified framing Bet 1. Both macOS legs reported
job control never moved the terminal off the leader
(leader=8542, foreground groups observed: [8542])
with the terminal staying on the leader for the entire 10s bounded wait.
Linux diverges reliably — 20/20 locally and green on both ubuntu legs —
so this is a platform difference rather than a flake, and rerunning past
it would have been wrong.
The framing named this outcome and prescribed the response, so that is
what ships rather than an improvised fix:
- The divergent case is pinned by INJECTING the foreground group at the
`signal_target` seam. Deterministic, runs on every platform. The
injection seam widens from failure-only to either outcome; the branch,
target choice, leader observation against the real child, and report
construction all remain production code.
- Verified still discriminating: the `leader_pid`-substitution mutation
fails it, `target=-1707909` against an expected `-1707910`. That was
the whole point of the original rewrite and it survives the fallback.
- The real shell is retained as corroboration in
`job_control_really_diverges_the_foreground_group`, Linux-only. It
skips on macOS by PLATFORM CHECK rather than by arming: the
precondition genuinely does not hold there, so running it would assert
a false claim about macOS instead of finding a bug.
- Framing revision 5 records the falsification and states exactly how
the injected pin is weaker — it proves the target is read from the
lookup rather than substituted from the leader; it does not by itself
prove any real shell produces that divergence.
`PMACS_REQUIRE_BASH` moves to Linux-only. The earlier reasoning for
arming both platforms — macOS is where the failures happen, so Linux-only
leaves it dark where it matters — was right about the diagnostic and
wrong about this test, which cannot produce its precondition on macOS at
all. Arming it there made a missing binary fatal for a test that can
never run. The measurement is recorded in ci.yml and the README so it is
not re-derived.
Gates on this tree: 11 gates, 4471 tests, zero failures.
One blocking and two major findings, all accepted.
- The isolated gate still inherited `PMACS_STATE_HOME`, which wins over
`XDG_STATE_HOME` in `user_state_dir` (`src/state.rs:47-68`), so
controlling the four XDG storage variables did not isolate state on a
machine that exports it. The contract now names the exact five
variables rather than counting roots.
- Q#TI5 still called self-spawn the durable regression guard after
revision 3 had accepted that it proves behaviour, not continued
adoption. It now names both guards and their different jobs: self-spawn
is the behavioural proof, the checked source inventory is the adoption
proof.
- The active-work lane still said revision 2 and still prescribed an
isolated `XDG_CONFIG_HOME` alone; both are synchronized, and the stale
config-only gating note elsewhere in the ledger is corrected to say it
isolates the observed symptom rather than the gate.
Framing only. No code.
`docs/active-work.md`'s snapshot header was the only conflict; main's
absorption version supersedes this branch's. `docs/agent-handoff.md`
auto-merged, and both sides were verified present afterwards rather than
assumed: the absorption's `4cd4a7b` anchor and its new landed-lane
entries, and this branch's macOS occurrence with its run link.
This lane's ledger entry is updated from "revision 4 awaiting review" to
its actual state — implemented, gated, PR open — since the framing was
approved and both implementation commits have landed on the branch.
The full gate suite is re-run on the merged tree rather than inherited
from the pre-merge head. The absorption is docs-only, so a clean merge
is very likely correct — which is exactly when inheriting a green would
be most tempting and least justified.
Three blocking and two major findings, all accepted. Two were verified
by running the thing rather than reading it.
- **Journey isolation had no executable mechanism.** Cargo launches each
integration-test binary with the caller's environment, and a binary
cannot re-point its own roots before its tests run — the `set_var`
prohibition applies to itself. Revision 2's "isolated by its launched
environment" therefore assumed the external wrapper this lane exists
to delete. Now named and pinned: each journey test re-execs
`current_exe()` with `--exact`, a marker, and controlled roots; the
child runs the real body against the ambient `EditorState::open`, so
the production-entry-point ratchet is untouched while the roots are
contained. The same helper serves the hostile-environment check.
- **One self-spawning test is not a ratchet.** It proves the seam works
and cannot notice a raw `EditorState::new()` added to another binary
later. A checked source inventory, falsifiable by adding an ambient
constructor, is now acceptance 12.
- **The root list and the gates disagreed with the audit.** The scope is
now explicit — bootstrap STORAGE roots only (config, data, state,
cache). `HOME`'s non-storage semantics are excluded by decision, not
omission: `expand_tilde` resolves user-entered `~` and
`find_file_acceptance` pins it deliberately, so redirecting `HOME`
would retarget a user-facing feature. `XDG_RUNTIME_DIR` addresses
sockets, not stored data.
- **The gate instruction itself was insufficient**, and this is the
finding with immediate consequences: isolating only `XDG_CONFIG_HOME`
stops the reads and leaves the write path open. Every local gate run
in this repository today had that hole.
- **The count was one high and the ledger overstated it further.** 65
files call the constructor; 66 mention it. The 66th, `m5_6_acceptance`,
mentions it only to say it deliberately does not use it — making it
the third place in the suite documenting the `cfg(test)` gap. The
ledger's "all 96 test files load the real config" was false.
- **The recovery command did not work**, verified by running it:
`git worktree add <path> <remote-only-branch>` fails with `fatal:
invalid reference` after a bare fetch. Replaced with the explicit
tracking-branch form.
Framing only. No code.
Levi Neuwirth