tower: mailbox delivery race eats leading bytes when the write lands mid-composer-settle

[amrmelsayed]

Problem

Mailbox delivery (Spec 1313) can intermittently lose the leading bytes of a delivered message when the write lands while the receiving terminal's composer is still settling after a turn. The render-gate classifies the prompt as clean, then writes — but if the classification races the composer's settling window, the terminal eats the front of the burst.

Observed (2026-08-18, two independent sightings)

• The owner's dev-approval relay for pir-1494 arrived in the vscode architect's channel with its header truncated: ER via VS Code | 2026-08-18T10:52:43.461Z instead of [USER via VS Code] | …. Witnessed first-hand by the receiving architect.
• The pir-1494 builder saw the same corruption intermittently while testing the gate-relay message and diagnosed it: not the message formatter (the string is correct at the source and test-pinned), not the vscode: approval gates should relay through the spawning architect instead of invoking porch approve directly #1494 change (it does not touch the write path). The loss happens at delivery.

Why it matters more now

Truncation severity depends on what the leading bytes carry. Until now they were mostly prose. Under the gate-approval relay shipped by #1494, the leading bytes are the [USER via VS Code] header — the marker that tells the receiving agent a human's decision is being relayed. Losing exactly that prefix downgrades an authorization-bearing message into what reads like ordinary agent traffic. The relay path also fires on-demand (button click), which appears to hit the settling window more often than queued sends.

Suspected mechanism

Race between the render-gate's clean-prompt classification and the composer finishing its previous turn: classify-then-write is not atomic, so a write that lands mid-settle loses its head. Intermittent; timing-dependent.

Fix directions (for whoever takes it)

• Settle-before-write: require the prompt to be stable for a short interval after classification before the burst is written, or re-verify cleanliness immediately before the write.
• Sacrificial leading byte(s): prefix the burst with expendable bytes (e.g. a newline) so any swallowed head costs nothing meaningful.
• Either must preserve the mailbox-first contract: persist first, deliver only onto a verified-empty prompt, respond delivered | held.

Out of scope

• Any change to vscode: approval gates should relay through the spawning architect instead of invoking porch approve directly #1494's relay content or routing — the message is correct at source; this is a delivery-layer defect.

[amrmelsayed]

Two additions from the surface owner, one reassuring and one that raises the stakes.

The downgrade direction is fail-safe under the provenance discipline we already run. Losing the [USER via VS Code] prefix makes an authorization-bearing message look like ordinary agent traffic — and our standing bars then treat it as exactly that: a relayed word without a human marker does not clear a gate or an admin bypass; the executor asks again. Cost is friction and a re-ask, not a wrong action. The system errs cold, which is the right direction to err.

The elevation direction is the one to design against: truncation can promote a quoted header to apparent-first position. Forwarding with quoted content is standard practice here — misrouted builder reports get forwarded between architects daily, and those forwards embed the original message's header verbatim in the body. If the delivery race eats the leading bytes of such a forward, the receiver's first intact line can be the quoted header — an agent-authored message now opening with what reads as a first-class [USER via VS Code] or [BUILDER … MESSAGE] marker it never earned. Unlike the downgrade, this direction manufactures provenance rather than shedding it, and this week's incidents (#1457, the #1429 circular-corroboration argument) show exactly how much weight those markers carry.

Consequence for the two fix directions recorded above: they are not equivalent. Settle-before-write shrinks the race window but leaves any residual truncation silent — and a rarer silent corruption is harder to catch, not easier. Sacrificial leading bytes can be made verifiable: make the sacrificial prefix a fixed sentinel the receiver (or the harness) can check arrived intact, and truncation converts from silent corruption into a detectable, discardable delivery error — re-deliver from the mailbox, which already persists the message (that is the mailbox-first contract paying for itself). That is the instrument principle applied to the transport: a delivery that can lose bytes must say so in its output, not hope the reader notices a malformed header.

Recommendation: do both (settle to make it rare, sentinel to make the remainder detectable), but if only one ships, ship the detectable one.

[amrmelsayed]

Filer follow-up: adopting the surface owner's reframing, and one adjacent instance

The analysis above changes which fix should win, and I am updating the issue's framing as filer rather than leaving the correction buried in a comment thread.

1. My original "downgrade" framing described the fail-safe direction, not the dangerous one. A relay that loses its [USER via VS Code] marker reads as ordinary agent traffic and gets refused and re-asked under the standing provenance bars — the cost is friction. The direction to design against is elevation: forwards with embedded headers are daily traffic between architects, so a truncation that eats the real prefix can leave an agent-authored message opening with a quoted [USER via VS Code] header it never earned. That manufactures provenance rather than shedding it, and the receiving agent has no way to know.

2. Consequently the two recorded fix directions are not equal.

• Settle-before-write makes the race rarer but leaves the residue silent — a truncation that still slips through is indistinguishable from a well-formed message.
• Sacrificial leading bytes can be made verifiable: a fixed sentinel the receiver checks for. Sentinel intact → delivery clean. Sentinel damaged or absent → detectable delivery error, and the mailbox re-delivers from its persisted copy (which mailbox-first already guarantees exists).

Both together is best. If only one ships, ship the detectable one — a rare-but-silent failure in a provenance channel is worse than a common-but-detected one.

3. Adjacent instance of the same family, from the misroute that briefly delayed this comment. Inter-architect messages render with the header BUILDER architect MESSAGE without naming which architect sent them. Sender identity is therefore inference from context and priors, not evidence — and today an architect misattributed a message's sender for an hour on exactly that basis. Same family as the truncation problem: transport metadata carrying less information than the weight agents put on it. A sender name in the delivered header would close it; worth considering in the same delivery-layer pass, since both fixes touch the same surface.

[waleedkadous]

Root cause confirmed at the code level (2026-08-30 investigation): the render gate's 'clean prompt' has no stability requirement — a screen that repainted 1ms ago passes identically to one idle for a minute, and session.lastDataAt is never consulted before the write. The quiescence drain trigger has an accidental 500ms settle window, but the on-demand send path (handleSend delivers immediately at request time) and the 'submit' fast trigger have none — matching the observation that on-demand relays hit this more. This is the same defect as #1564 at a different offset (disruption at write start eats the head; mid-window eats everything before it). Fix prescribed in #1573: settle-before-write (~250ms of output silence required, using existing lastDataAt) plus echo-verification before markDelivered, with this issue's sacrificial-leading-bytes suggestion included as an optional hardening. Note PR #1492 explicitly does NOT cover this case (single-writer race, documented in its boundary comment).

[waleedkadous]

Fix merged in #1577 — staying open for field verification

#1573 shipped settle-before-write, aimed directly at this report's mechanism.

The gap was that the render gate proved a composer was empty but never that it had finished being painted — session.lastDataAt was never consulted, so a screen that repainted 1 ms ago passed identically to one idle a minute. That is the window where [USER via VS Code] arrived as ER via VS Code. Your observation that on-demand relays hit it more was the tell, and it held up in the code: the quiescence drain trigger had an accidental 500 ms settle window, while the request path (handleSend's immediate delivery attempt) and the submit fast trigger had none. All three now share a 250 ms floor, checked before the per-terminal lock and again inside it, and written so an unknown screen age holds rather than writes blind.

Two things also landed that cover the residual: a write that goes out anyway is no longer reported as delivered unless the message's header actually appears on the terminal, and any head-eating that does occur therefore surfaces as a held row and a redelivery instead of a silent success.

Why this stays open: verified by regression tests (a write attempted inside the settle window is held; at the boundary it proceeds), not by reproducing the original race. It ships in the next release. Please close it after a relay landing on a just-settled composer has been seen to arrive intact.

[waleedkadous]

Closing: the leading-bytes loss has the same mechanism as #1567 (kernel PTY split of a >1022-byte write + paste-heuristic discard of the first chunk), fixed by PR #1644 and field-verified 2026-09-08. If a head-loss recurs on a body under 256 bytes, or without the paste placard in the recipient's PTY log, reopen with the byte log — that would be a different bug.