afx send: delivery-side silent truncation of long bodies (head-loss can invert meaning) — needs integrity check before Enter

[amrmelsayed]

Reported by the shannon workspace's main architect (Amr-directed forward, 2026-08-31, three-part relay received complete); reviewed and filed by codev:main.

Defect

afx send can silently truncate long message bodies at delivery (the mailbox row stores the full body; what lands on the recipient's prompt is incomplete). The sender receives delivered with no error; the recipient has no marker that anything is missing. Both variants observed:

• Head-truncation: only the tail arrives; the recipient loses all framing. Worst confirmed case: a ruling arrived INVERTED in meaning (the part that negated the instruction was in the lost head), caught only because the sender re-read their own sent text.
• Probable tail-clip: body ends early.

Occurrence ledger (shannon workspace, six confirmed, three senders)

• ~2026-08-26T22:24Z, shapps architect → builder-pir-4596: two consecutive long rulings head-truncated.
• 2026-08-27 ~09:08Z, main architect → builder-air-3816: a 5-part instruction arrived as "item 5 + a fragment"; the builder's hold-and-ask discipline caught it.
• 2026-08-27, brand architect: three occurrences (receipts at shannon codev/state/.brand.bak.md lines 240/244/246): two clipped relays to builder-pir-4623 plus the inverted ruling to builder-pir-4625.

Every catch was behavioral (hold-and-ask, sender re-read). No mechanical detection exists. Raw receipts available from shannon:main on request.

Relation to known defects (same channel, distinct integrity failures)

• Mailbox: delivered-message wrappers carry no recipient field — deliveries are not self-attesting (rescoped from refuted misrouting report) #1543 tracks sender/recipient labeling in the wrapper (now 8+ occurrences per shannon, including two architect-to-architect label misroutes on 08-30). That defect corrupts attribution; this one corrupts CONTENT. Together they mean neither who-said-it nor what-was-said is currently trustworthy for long inter-agent messages.
• Sender-side clipping via shell substitution (inline backticks) is a separate, known operator-error class with the --file discipline as its mitigation; the ledger cases above are delivery-side (mailbox row complete, delivered text incomplete), which --file does not protect against.

Investigation leads (from a source skim, not conclusions)

• The delivery path has a documented race window after the render-gate sample: mailbox-delivery.ts:392 ("if the screen advanced since we sampled tokenBefore, a draft may have started"). Longer bodies take longer to write, widening any post-verification race — consistent with the length correlation.
• Head-loss specifically suggests early-written bytes being consumed by a recipient TUI state that had not settled, or input-buffer overflow dropping early chunks under a large single write. The write path (Spec 1365 routed the mailbox write edge through submitToSession) should be audited for chunking/backpressure behavior on large bodies.

Ask

1. Root-cause the delivery-side loss (write path chunking/backpressure + the post-gate race) rather than capping message size as a workaround.
2. Mechanical integrity check regardless of root cause: after writing the body and BEFORE pressing Enter, verify the composed prompt content (length or hash) matches the intended body; on mismatch, do not submit — clear, re-hold the row with a reason, and return held+integrity to the sender instead of delivered. This converts silent corruption into a visible hold, which is the mailbox-first contract's spirit.
3. If any legitimate hard limit exists (PTY, harness input), enforce it at SEND time with an explicit error/held reason, never by silent clipping — plus an explicit truncation marker in any degraded delivery mode that must exist.
4. Consider surfacing delivered-vs-stored length in the mailbox row (delivered_bytes) for post-hoc auditability.

Interim practice (circulating in shannon, endorsed until fixed)

Short bodies; numbered multi-part sends; playback confirmation on load-bearing rulings. Codev-side senders should prefer --file for composition (existing discipline) plus part-numbering for anything long.

[amrmelsayed]

Overlap note: open community PR #1492 (fixes #1365, serializer convergence at the terminal write edge) targets what is likely the primary mechanism behind this issue. Its documented failure mode is an interrupt/escape interleaving inside the delivery text-to-Enter window producing a FALSE delivered for text the agent never saw; a partial clear in the same window is exactly the head-truncation variant in the ledger above, and longer bodies widen the window (the observed length correlation). It also ships a degraded flag on the send response + sender-side warning, part of this issue's visibility ask. Residue this issue retains even if #1492 merges: the verify-composed-text-before-Enter integrity check (belt against ANY residual loss cause, not just interleaving) and delivered-vs-stored byte auditability. Any lane picking this up should start from #1492's plan Part 1 evaluation rather than re-deriving the write-edge model.