Revision 3 corrected the cache model in section 3.2 and the clipping
rule in 3.4, then failed to propagate either. Internal contradictions in
a framing document are worse than the original errors: a later reader
resolves them by picking whichever statement they read first.
- Q#D2-4 still summarised the design as "per-variant cache keys",
contradicting 3.2's corrected one-per-peer model. Now names the
`peer_knows_minibuffer_rows` producer gate and the single per-peer
cache, with a parenthetical recording that the sentence was stale
rather than silently rewriting history.
- Section 6 still required the cross-version cache test that
revision 3 removed as unfalsifiable. Replaced with what IS
assertable --- a v22 and a v23 peer attached simultaneously each
receive their own variant and only their own --- and the bullet
says why the other test is absent, so it does not get "restored"
later by someone who notices the gap.
- The active-work lane still called the framing revision 2.
Swept for the same class of residue from the other two corrections
("the name must survive", "both frontends render"); the remaining hits
are the notes ABOUT those corrections, which are deliberate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Three corrections, each to something revision 2 asserted without
checking the mechanism it was reasoning about. All three verified in
the tree.
A ROUND-TRIP FREEZES NOTHING. Revision 2 proposed pinning the legacy
variant with an encode/decode round-trip. That test uses the SAME types
on both sides, so adding a field to `MinibufferPrompt` leaves it
passing while every v12-v22 peer in the field breaks. The existing
`minibuffer_prompt_round_trips_through_postcard` (src/protocol.rs:2363)
is precisely that shape, and there are NO literal byte fixtures
anywhere in the protocol tests today --- checked, not assumed. Only
`assert_eq!(encoded, LEGACY_BYTES)` against bytes captured now can fail
when the encoding changes. Two fixtures, open and clear, matching the
shapes the semantic test already covers so the corpus is not a fresh
judgement call.
THE CACHE HAZARD I DESCRIBED CANNOT HAPPEN. Revision 2 argued for a
per-variant cache key on the grounds that a peer reconnecting at a
different version could have its first message suppressed as a
duplicate. `SemanticRenderState::for_peer(frontend_id,
negotiated_protocol_version)` is created PER PEER with its version
baked in on attach (src/daemon.rs:2080) and removed on detach (:1591),
so a cache never spans two versions and reconnecting creates a fresh
state. One per-peer cache stands; the selection is a producer gate,
`peer_knows_minibuffer_rows`, alongside the four such gates that
already exist (:1410-1435). The test for the impossible condition is
REMOVED rather than written --- a test that cannot fail passes forever
and teaches the next reader that the hazard is real.
The matched open/close family requirement is independent of caching and
stands unchanged.
"THE NAME MUST SURVIVE" IS NOT ACHIEVABLE. Prompt plus typed input
consume the width budget first, so the remaining suffix space can be
too small for even the bare name --- and revision 2's rule would then
have forced a partial name, which reads as a DIFFERENT command. The
rule is now ordered: if the whole name does not fit, omit the suffix
entirely; only once it fits is a description attempted; if the
description does not fit whole, drop it. The guarantee becomes "never a
partial name", which is achievable, rather than "the name always
survives", which is not. Witnessed at three widths.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
COHERENCE.md section 5 grades discoverability Partial after Stage 1 and
names "M-x rows are still bare names". The descriptions ALREADY EXIST
--- `Command.description` is required, and `help.list-commands` renders
them --- so this is substrate without surface in its purest form: the
information is present, surfaced elsewhere, and absent from the one
moment it would change a decision.
TWO REVISION-1 CLAIMS WERE WRONG, both checkable in the tree:
- "Change `candidates` in place and gate at >= 23." Postcard is NOT
self-describing: fields encode positionally, so a v22 peer decoding
`Vec<MinibufferRow>` where it expects `Vec<String>` mis-reads the
bytes rather than skipping them. And gating would not have rescued
it --- with only one variant to gate, a v12-v22 peer would have
received NO MINIBUFFER AT ALL. That variant goes to every peer
negotiated >= 12 (src/daemon.rs:1472).
Revision 2 is additive: `MinibufferPromptRows` APPENDED to the enum
(indices are positional; inserting renumbers everything),
`MinibufferPrompt` frozen for v12-v22, per-peer selection, per-
variant cache keys, and close matching the open's family --- a
mismatched close is how a popup stays on screen forever.
- "Both frontends render label + detail." The grid TUI never reads
`MinibufferPrompt`; src/editor.rs contains ZERO references to it.
It paints from `core.minibuffer` and renders the selected candidate
as `format!(" [{cand}]")` (src/editor.rs:5484). The rich wire
reaches pmacs-gpu only.
So the TUI half is a LOCAL formatting change --- it is in-process
with the core and reads `Command.description` from the registry
directly, with no wire involvement. The contract is pinned
including clipping: THE NAME SURVIVES AND THE DESCRIPTION IS
DROPPED at narrow widths, because a clipped name is strictly worse
than today's bare one. A multi-row TUI chooser is explicitly not
this lane.
This lane HOLDS THE BUMP SLOT. Git Stage 1 is no-wire and runs beside
it; git Stage 2 needs a bump and must wait.
Q#D2-5 records a trap that arrives with the feature: richer rows make
M-x LOOK like a closed set, inviting someone to make acceptance reject
unmatched input. Completion is assistance, not validation ---
`resolve_accepted_value` returns literal typed text by design --- so
that would be a behaviour change, not a rendering one, and it is out of
scope.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai