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>
docs/active-work.md says the dark-test figure "moves with every merge
and must be re-measured, not quoted." That instruction has never had a
tool, so every re-measurement was a hand-rolled `--list` pipeline
written from scratch.
Hand-rolling it is not safe. Writing this lane's census by hand, the
first attempt filtered libtest's list with `/ : test$/` — but the output
is `name: test` with NO space before the colon, so it matched nothing,
reported zero targets, and looked like a clean run. A census that
silently reports nothing is the same failure class as the dark tests
themselves: no signal, presented as a result.
scripts/feature-census diffs `cargo test --list` between two feature
configurations and reports what the second has that the first cannot
see. Its header records each parsing trap, because every one of them was
hit while writing it:
* `name: test` has no space before the colon.
* `--list` also emits `: benchmark` lines.
* cargo's `Running` lines have two shapes — `unittests src/lib.rs` and
`tests/foo.rs` — so a fixed field index handles one and mangles the
other.
* a target with zero tests prints its `Running` line and nothing else,
so counting only test lines DROPS it from the diff — losing exactly
the finding worth surfacing.
* `--list` includes #[ignore]d tests, which are dark in the same sense
but are NOT recovered by adding a feature to an ordinary test job.
That last one needed a second correction after the script was running.
Counting only B's ignored set attributed pre-existing ignores to the
feature: `rope::tests::perf_smoke_*` are ignored under both configs and
are not "dark and ignored." Both sides now get an ignored pass and the
figure is the difference, which is what turns a flat "279 dark" into
"268 recovered by a plain leg, 11 needing --ignored."
The script also corrected a claim in this lane's own framing doc. The
framing said eight test binaries contain zero tests under CI's flags,
derived from a target-count difference (93 vs 101). The truth is that
ELEVEN targets run with zero tests under those flags; eight of them gain
tests under crdt and three are helper binaries with no tests in either
configuration. Two different true statements, and the framing had
merged them.
Fail-closed on a build failure (exit 3) rather than reporting a census.
A configuration that does not compile yields no test list, which is
indistinguishable by counting from "this configuration has no tests" and
would render as a spectacular and entirely false "every test is dark."
That is not a small error; it is a number that would get quoted.
All five documented exit codes are exercised rather than asserted: 0 on
a clean census and a holding --covers claim, 1 when the claim fails
(both for a test present under both configs and for a misspelled name),
2 on usage, 3 on a configuration that fails to build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nothing in this workflow ever enabled the `crdt` feature, so every
`#[cfg(feature = "crdt")]` test was NOT COMPILED — not skipped, not
filtered, not reported. Measured at 4223dd3: 3,467 tests under the
`test` job's flags versus 3,746 with `crdt`. 279 tests had 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 had never run a required gate.
Eight test binaries also contained zero tests under the old flags. They
built, ran, and reported `ok` with nothing in them.
This job recovers 275 of the 279. The other four are excluded on
purpose, each for a stated reason rather than left as residue: three are
m10_11_acceptance's PTY-doubled tests, marked "operator-invoked before
tagging, not CI-default", and one is the #157 CRDT undo repro, an
#[ignore]d marker for a known open defect whose arming belongs to that
defect's lane. Seven of the 275 arrive via m10-perf-gates in the
previous commit; this job carries the remaining 268.
ONE JOB, NOT TWO. The shape recorded in docs/active-work.md put the
GPU-requiring suites onto `gpu-render` "which already has lavapipe and
PMACS_REQUIRE_GPU". That job runs `cargo test -p pmacs-gpu` — a
DIFFERENT PACKAGE from the four root-package suites that would move
there, so co-locating them would mean adding a whole new invocation
rather than extending an existing one. Splitting also requires
enumerating which suites are GPU-requiring, and a suite added later
would silently land in the job that needs no GPU and skip there forever.
Running the whole corpus in one place with a working adapter cannot
develop that hole.
PMACS_REQUIRE_GPU is set because these suites do not fail without an
adapter — a37 and its siblings eprintln a skip and return `ok`, measured
at 9/9 in 0.17s versus ~4s for a real run. The build is --workspace
rather than root-only because those suites locate the `pmacs-gpu` binary
beside `pmacs`, and its absence is the documented cause of twelve
gpu_invocation_acceptance failures on a crdt sweep.
The external-tool install block from the `test` job is deliberately not
duplicated. It gates m4_acceptance, m6_5_repl_acceptance and
m6_8_multi_repl_acceptance, and none of those has a single dark test —
measured, not assumed. Installing clangd/zsh/fish/lua/rust-analyzer/
gopls/npm servers again would cost minutes to change nothing. The only
tool-gated code in the dark set is src/process.rs, whose two variables
need no install and are set.
Clippy for the crdt targets runs HERE rather than in the `clippy` job.
Clearing those lints once is not enough: the `clippy` job matrixes over
Lua flavor and never enables `crdt`, so without this step the targets
drift straight back out of compliance and the next job to compile them
is red on arrival — the exact state this lane found. One job now owns
"crdt compiles, lints, and passes."
Verified locally at the exact commands this job runs: clippy green,
doc tests green, and the full serialized sweep with PMACS_REQUIRE_GPU=1
at 3,715 passed / 0 failed / 30 ignored in 366s — identical to the
pre-change sweep, so the lint commit changed no behavior. The 35-minute
ceiling is justified in the job comment against that measurement plus
lavapipe and cold-cache headroom.
This job has NOT yet been proven non-vacuous. That is the next commit:
break a crdt-gated test, confirm this job goes red, revert. A leg added
to a corpus that is already green locally cannot otherwise be
distinguished from a leg that compiles nothing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`m10_2_perf` and `m10_11_perf` were dark for TWO independent reasons,
and only one of them is this lane's headline subject:
1. They are `crdt`-gated, and nothing in the workflow enabled the
feature, so they were never compiled.
2. Even setting `crdt` aside, no job named them. Grepping ci.yml for
`--test` yielded exactly four suites: acceptance, m4_acceptance,
m5_perf_acceptance, m6_perf_acceptance. Their `#[ignore]` is
deliberate; their absence from every workflow was not.
Fixing both here is a deliberate scope call, taken with the second cause
named rather than absorbed: leaving it would ship a lane headlined "the
dark tests now run" with 7 still dark, and the remedy is one job block,
not a second investigation.
The two suites are NOT the same kind of thing, and the job says so
because a future reader will otherwise assume "perf gates" means
"budgets":
* m10_11_perf asserts one budget — cross-frontend propagation p99
under 50ms. Measured 1.47ms locally, a ~34x margin, so a red here
is a regression rather than runner noise.
* m10_2_perf asserts NOTHING. Six benches that print throughput
numbers, the baselines M10.2's 391x unicode finding and v0.2+
optimization work compare against.
Including a suite that cannot fail a budget needs its own
justification, so the workflow states it: `run_workload` drives 30
seconds of randomized mixed edits against both the v0.1 and CRDT buffer
paths, and nothing else in the corpus exercises a sustained randomized
CRDT workload. Its value here is soak and panic detection, not gating.
The comment explicitly warns against "fixing" it later by adding
throughput assertions, which is how perf jobs become flaky on shared
runners.
Per framing Q#CC3 and §1.3a, `tests/m10_10_perf.rs` is deliberately NOT
touched: it is a CI-default regression tripwire with generous bounds,
not a bench, and adding `#[ignore]` to give it a job would have shipped
a coverage reduction inside a coverage lane. It is recovered by the
plain crdt leg in the next commit instead.
Observed execution, local release build 2026-08-01: m10_2_perf 79s
(6 passed), m10_11_perf 5s (1 passed). The 25-minute ceiling matches
m5-perf-gates and is set by the cold-cache release build, not the ~85s
of tests — the reasoning the file already applies to its other perf
jobs.
Verified: ci.yml parses, 9 jobs, every one carrying timeout-minutes.
Both suites pass locally under the exact commands the job runs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`cargo clippy --workspace --all-targets --features crdt -- -D warnings`
has never passed on main. The standing gate list runs clippy without
`crdt`, so these lints have never been enforced, and any CI job that
compiles the crdt targets would be red on arrival. This is framing §7
step 1: nothing else in the lane is testable until it lands.
Eight findings across four files, none behavioral:
src/daemon.rs useless_conversion (u64)
src/daemon.rs missing doc backticks
src/daemon.rs too_many_lines (112/100)
tests/auto_indent_crdt_acceptance.rs missing doc backticks
tests/bottom_panel_stage2b_gpu_acceptance too_many_lines (104/100)
tests/vterm_stage3_acceptance.rs too_many_lines (122/100)
tests/vterm_stage3_acceptance.rs too_many_lines (132/100)
tests/vterm_stage3_acceptance.rs redundant `continue`
--keep-going is what made this an inventory rather than a lower bound.
docs/active-work.md recorded seven findings at 74301d1 and correctly
warned they were "a lower bound, not an inventory" because clippy
abandons remaining targets once one fails. With --keep-going the set is
complete, and it differs from the ledger's in both directions: the
`unneeded mut` at src/daemon.rs:4965 is gone (fixed incidentally by
later work), a finding in bottom_panel_stage2b_gpu_acceptance.rs is new,
and every src/daemon.rs line number had moved. A stale lint inventory is
worse than none — it invites fixing lines that no longer exist.
The four too_many_lines findings are silenced with a reason rather than
refactored. Refactoring a test body to satisfy a lint that has never run
would be a behavioral change riding a CI-configuration lane, and the
codebase already has ~20 `#[allow(clippy::too_many_lines)]` sites, the
best of them carrying `reason =`. Each reason states why the scenario is
one test: the GPU acceptances exist specifically to prove a real
daemon, a real PTY and real wgpu fit together, which splitting would
hide.
The redundant `continue` needed care. Replacing it with `Err(_) => {}`
traded the lint for `single_match` — the match then destructured one
pattern. Rewritten as an edition-2024 let-chain, which drops both
without changing semantics: an unreadable message still falls through
to the next loop iteration.
Verified: clippy green with and without `crdt` (the second confirming
no regression to the enforced gate), fmt, diff-check, --lib --features
crdt 2081 passed, and the three touched suites green — vterm_stage3 at
9/9 in 4.34s rather than 0.17s, so a37 really ran rather than reporting
ok on a missing binary.
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
CI caught this on all four test legs. The forwarder body called
`pmacs.command.invoke_interactive`, which raises when the alias is
reached through `pmacs.command.invoke` — and
`tests/config_registry_acceptance.rs` does exactly that, three times.
The acceptance pin passed throughout because it drives the M-x path,
which is the path the framing spent three review rounds getting right.
Being right about one entry point is not the same as covering the
command, and a rename touches every caller of the old name regardless
of how it is reached.
Plain `invoke` is also the correct semantics rather than merely the
working one: the interactive-command boundary is rotated once, by
whatever entry point the user actually used, for the name they actually
typed. Rotating again on the inner call would record a second boundary
for a command the user never invoked.
Adds `d8c`, which invokes both forwarders programmatically. Bitten by
restoring `invoke_interactive`: the new pin fails alongside the three
config-registry tests that found it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
The isolation lane (#206) landed with an adoption ratchet, and it
caught this branch's brand-new suite on the first run after the merge:
these suites construct an editor through the ambient entry points,
so they read the developer's real init.lua and write into their real
data root: ["discovery_acceptance.rs (1 site(s))"]
That is the ratchet working as designed against code written by someone
who was not looking at the isolation lane while writing it — which is
the case it exists for.
`discovery_acceptance` is therefore MIGRATED, not allowlisted: it
includes `common/iso.rs` and constructs through
`EditorState::new_with_roots(&iso::roots())`. Allowlisting would have
put a fresh ambient site into the census the same day the census was
built.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Review round 2 on #207, two findings, both accepted.
Three places said workers have no discovery surface. They do:
`editor.list-workers` opens `*workers*` via M-x, which §2's own step-11
row has recorded all along — so the document contradicted itself. Two
of the three were mine, including the bullet I wrote last round while
correcting a different stale claim in the same section; grepping for
the phrase found only the two pre-existing sites because my own copy
was split across a line break.
Corrected to say what is actually missing, which is not the same thing
for the two subjects: PACKAGES have no comparable surface at all, while
workers have one and lack §9's ownership model and activity indicator.
Collapsing those into "no discovery surface" would send a reader at the
wrong work.
Separately, §4's extension-surface list called completion/minibuffer
sources "a fixed Rust vocabulary". `parse_completion_source` accepts a
Lua function as `CompletionSource::Custom` — the mechanism this very PR
uses to give `help.describe-setting` completion with no Rust. The claim
now names it, since a reader who believed the old text would conclude a
custom source needs binding work it does not.
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
Review round 1: `isolated_construction_is_init_complete` asserted its
paired half — that the *ambient* constructor is unchanged — with an
ambient `EditorState::new()` in an ordinary parent test. That reads the
developer's real `init.lua` and materializes packages into their real
data root: the exposure this suite exists to remove, committed by the
suite itself.
The claim is worth keeping, so it moves rather than dies. It now lives in
the re-exec'd positive control, which runs only as a child under a
hostile-by-construction environment. That is the one place an ambient
constructor is safe, and so it is where every ambient claim this suite
makes belongs.
**The ratchet did not catch this, and that is the more important half.**
`ambient_isolation_acceptance.rs` was on the allowlist for its positive
control, and a bare file-level exemption licenses the named file to grow
new ambient sites forever — which is exactly what happened. So every
exemption now carries its **exact permitted site count**, and a file with
more sites than it was reviewed with fails even while allowlisted. A
count that drops fails too, so the allowlist stays a census rather than
drifting into a ceiling nobody rechecks.
The count immediately earned itself: it rejected the number written from
memory for `journey_acceptance` (47) and reported the real one (26 — 19
`new()` + 7 `open(`, after the scanner drops two assertion-message
mentions and the assembled `concat!` needle).
Verified in both directions: restoring the removed ambient site fails the
ratchet with `2 site(s), allowlist says 1`; and with the ambient half
gone, both init-complete pins still fail under the `if roots.is_ambient()`
mutation, so neither has become a test that passes for the wrong reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Review round 1 on #207, one finding, accepted. I moved §5's scorecard
row and ground-truth grade but left the itemized "what is missing" list
below them describing the pre-stage world, so the section contradicted
itself.
Two claims were false at this PR's head:
- §4's disclosure table said keybinding search was absent ("no
list-keybindings/where-is commands"). It now reads ✓ with the three
commands named, and keeps the real remaining gap: no key reaches
them.
- §5's "missing as commands entirely" bullet listed all nine new
commands and recorded `describe-setting` as free-text with no
completion source. Both shipped. The bullet now states what exists,
and names what genuinely remains: no discovery surface for packages
or workers, no key on any of it, and completion that assists rather
than validates.
The superseded text is pruned rather than kept as a provenance note,
per §25 — "prune superseded facts rather than appending; this is a
briefing, not a log."
While in the section I also corrected the `C-h` bullet, whose citation
I was touching anyway. It reported the keymap's own "the key was free"
comment without the reason that comment omits: non-kitty terminals
cannot disambiguate Ctrl+Backspace from Ctrl+H, so rebinding breaks
Ctrl+Backspace everywhere legacy. Reading it as an oversight is what
would send someone at the wrong fix, and it is precisely why Stage 1
shipped the family unbound.
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
Implements `docs/discovery-stage1-command-family-framing.md` (approved
at revision 6). `COHERENCE.md` §5 graded discoverability "substrate
without surface": the registries already carried descriptions, source
locations and reverse key lookup, and almost none of it was reachable.
Eleven commands under one `help.*` prefix, so typing `help` at M-x
surfaces the whole family. Nine are new; `editor.describe-command` and
`editor.describe-setting` are renamed in, with the old names retained
as forwarders so nothing documented breaks.
No Rust. Every command renders data `pmacs.describe.*`,
`pmacs.keymap.list()`, `pmacs.command.list()` and `pmacs.config.list()`
already return, and `describe-setting`'s completion source is a Lua
function via `CompletionSource::Custom`, which needed no binding work
either — correcting a comment in `default.lua` that claimed `source`
was a fixed Rust-side vocabulary.
`apropos` matches by substring, not fuzzy: `fuzzy_score` is
subsequence-based and descriptions are long sentences, so fuzzy would
match nearly every command.
Two disciplines the file keeps. Every command renders through the
public `pmacs.editor._show_help`, which buys one owner for the shared
`*help*` policy — reuse-by-name, wholesale replacement, `q`, and the
foreign-buffer hazard. It does NOT buy a one-site migration to
`src/help.rs`, which has no renderer for settings, lists or apropos; so
rendering is a named per-subject function, and the future Rust work is
enumerated per subject rather than discovered per call site.
The seam-counting pin earned its place immediately: the two renamed
commands were still calling the file-local `show_help_text`, so the
funnel was fiction for exactly the two commands that predate it. They
now call the public seam, with a comment saying why the local is not
used from the same file.
Moves `help` out of `welcome.lua` into the new `runtime/help.lua`,
which owns the family and loads after it so the index can read
`pmacs.welcome.entries`.
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
The mechanical half, riding on the census in the previous commit.
* 342 in-process construction sites in 65 files now take
`new_with_roots` / `open_with_roots` with `iso::roots()`. The isolated
base is a pure function of `CARGO_TARGET_TMPDIR` — no counter, no
`OnceLock` — so two copies of the module in one binary agree instead of
racing, and the tree lives somewhere `cargo clean` owns rather than
leaking into `/tmp` once per run. It is shared deliberately:
materialization is content-gated and idempotent, so a per-test
directory would repeat it ~330 times per run for a byte-identical
result.
* `journey_acceptance` keeps the ambient `EditorState::open`, because
proving the production entry point has a caller is the whole of what
that ratchet is for. Rev 2's "isolated by the environment its binary is
launched with" was not a mechanism — cargo launches each test binary
with the caller's environment, and a binary cannot re-point its own
roots before its tests run. Each test is now a thin parent that
re-execs this binary for its own name with controlled roots, and the
child runs the body against production's call. Two pins guard it: the
child asserts all four roots resolve inside the controlled base, and
the suite asserts against its own source that it has not quietly taken
the seam. The parent also asserts the child ran `1 passed` — a stale
`--exact` filter would otherwise hollow the whole thing out silently.
* The shared spawners take all five storage variables.
`spawn_daemon_process_with_env` set `HOME` and `XDG_CONFIG_HOME` only;
`HOME` is a FALLBACK, so it isolates a root only while the matching
`XDG_*` is unset — the harness's apparent adequacy was a property of
one developer's environment. The PTY spawner backfills whichever of the
five its caller did not pin. The 10 direct `Command::new` daemon and
attach spawns get the same treatment.
Three suites had `mod common;` behind `#[cfg(feature = "crdt")]`;
`common::iso` is needed in every build, so those are ungated. Files that
already pull in `common` reach `iso` through a `use` rather than a second
`#[path]` declaration — loading one file as two modules is
`clippy::duplicate_mod`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
The census first, because it decides how large the mechanical edit is
(framing §7). Every occurrence was listed with its enclosing context and
read; a grep for the bare name over-counts, which is how revision 1
reported 18 by grepping `Editor::new` — a pattern that does not match the
real constructor.
in-process 342 calls in 66 of 97 files
(330 of 334 `EditorState::new()` occurrences; 4 are prose)
(12 of 14 `EditorState::open(` occurrences; 2 are strings)
spawned 14 real `pmacs` spawns in 8 files
(of 36 `CARGO_BIN_EXE_pmacs` hits, 18 are the fake-LSP and
fake-MCP siblings and 4 are path derivations for
`pmacs-gpu`, not spawns)
mixed 5 files are both, so sites — not files — are the unit
The full census, with per-site attribution, is the module doc of
`tests/ambient_isolation_acceptance.rs`.
Four things it pins:
* Isolated construction still finishes initialization, asserted twice —
the flag, and the behaviour it gates (`pmacs.attach` must refuse).
Falsified by wrapping the config block in `if roots.is_ambient()`;
`m8_2_acceptance` does NOT catch that, because reopening an already-open
init phase is a no-op.
* The writes land in the redirected data root — content produced, not an
invariant preserved. A "the real root did not change" check would pass
vacuously wherever it already holds identical bytes, since
`write_if_changed` is content-gated.
* Bet 3, in two children with opposite jobs. The positive control proves
the hostile environment IS hostile (an ambient editor loads its
`init.lua` and writes its data root); without it the isolation half
asserts nothing. The isolated child then stays green under the same
environment and leaves its hostile root byte-identical.
* A durable adoption ratchet, not a one-time census: a source scan that
fails when a new ambient constructor appears outside a named allowlist,
plus a check that no allowlist entry has gone dead. Its scanner strips
comments, strings and raw strings, and that stripping has its own pin —
the corpus contains all three shapes, and a grep-shaped answer already
cost this lane a review round.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
`EditorState::new` resolves two storage roots from the process
environment before it returns: the data root, which the bundled-package
materialization then WRITES into unconditionally (outside every `cfg`
guard), and the config root, from which `init.lua` is read.
The `#[cfg(not(test))]` guard on the second was written to stop the
crate's own unit tests picking up a developer's real `init.lua`. It does
exactly that and nothing more: `cfg(test)` is set only while compiling
the lib's own tests, so an integration test in `tests/` — compiled
without it — reads the real config and writes the real data root. On a
machine with a real `~/.config/pmacs/init.lua`, that is 11 deterministic
failures in `compile_mode_acceptance`, attributed to whatever branch is
checked out.
Tests cannot fix that themselves: `std::env::set_var` is `unsafe` and
this crate is `#![forbid(unsafe_code)]` — the same constraint that
produced `Installer::with_install_root_override`. So isolation arrives as
a parameter.
`BootstrapRoots` names the four storage roots (config, data, state,
cache). `ambient()` leaves every one `None` and every resolution goes to
the environment exactly as today, so production is unchanged.
`new_with_roots` and `open_with_roots` take it — both, because `open`
calls `Self::new()` internally and a constructor-only parameter would
leave every open-path test ambient. `install_state_dirs` consults it
too: it runs after construction, so resolving from the environment there
would reopen the hole the constructor closed.
The redirected branch changes WHICH directory is read, never WHETHER the
block runs. Config loading shares one conditional with
`set_init_complete()`, and `tests/m8_2_acceptance.rs:75` documents its
dependence on integration-test construction finishing init-complete.
`child_env()` translates the same value into the environment a spawned
`pmacs` needs. Five variables, not four: `PMACS_STATE_HOME` outranks
`XDG_STATE_HOME`, so a child given only the XDG four still resolves an
inherited state override — invisible on a machine that exports none.
The `src/editor.rs` comment claimed a protection it does not provide and
said nothing about the write above it; both are corrected in place. The
guard is deliberately NOT widened to cover integration tests.
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
Two audited rows were false at this PR's head and one of them is this
PR's own doing, so per §25 the correction rides the landing PR rather
than a follow-up.
Row 19 said the journey suite covers "steps 2, 3, 5". This PR adds step
4; #203 and #204 added 9 and 6 before it. It now carries 45 pins over
six steps, and the row names the five §19 scenarios that genuinely
remain unwritten instead of an out-of-date count.
Row 2 said the journey "runs to step 5 ... thin from step 6 on". That
was already stale when #203 and #204 landed and should have ridden
them. With 1b complete the journey runs to step 10, and the thin end is
now steps 1, 11 and 12 — install, background-work visibility, and
session restore.
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
Implements `docs/journey-stage1b3-welcome-framing.md` (approved at
revision 4, after three review rounds). The last of the 1b split.
`COHERENCE.md` §18 graded onboarding "missing entirely": no welcome, no
cheat sheet reachable from inside the editor, and `M-x` — the only door
in — discoverable only by already knowing about it. A fresh `pmacs` now
greets an untouched `*scratch*` with three lines naming `M-x` and four
real bindings, and `M-x help` renders a cheat sheet.
The startup seam is the substance. No constructor is the right hook:
`EditorState::open` calls `new` before resolving its target, the daemon
constructs one too, `init.lua` runs inside `new`, and desktop restore
happens later still. So `run()`'s terminal-free prefix is extracted into
`prepare_startup`, which `run` delegates to, and the greeting happens
there — after config, after attach dispatch resolves to local, and
after desktop restore. Extracting it is also what makes the wiring
testable: with the greeting called by hand from tests instead, deleting
the production call would leave every assertion green while shipping no
welcome.
Lua owns what is said, Rust owns when and where. `pmacs.welcome.entries`
is a structured list that both renders the text and drives the binding
checks — scraping the rendered prose would be ambiguous, since `C-c c`
is two chords and nothing in the text marks the boundary.
The greeting is deliberately NOT written through
`set_generated_contents`: that would lift read-only, discard history and
mark the buffer generated, all wrong for the buffer journey step 5
requires the user to type into immediately. It is left unmodified so it
does not look like unsaved work.
`M-x help` renders through `editor.describe-command`'s existing `*help*`
mechanism via a new `pmacs.editor._show_help` seam, rather than growing
a second help surface.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lv428Fth9LRtffwJSsqH7T
Levi Neuwirth