Tower/afx: one sent message re-injected into a builder prompt dozens of times (byte-identical re-delivery loop), plus same-day truncation and stuck-composer incidents

[amrmelsayed]

Owner-directed filing (2026-09-02, shannon workspace, voice lane). Three incident classes hit one architect↔builder pair in a single day; the first is the headline defect and plausibly causes the second-order symptoms.

1. Re-delivery loop (core defect)

A single wrapped afx message — sent by the architect via afx send builder-spir-4679 --file <path> '<note>' at 2026-09-02T09:45:46.866Z (the 4679 verify-evidence payload) — was surfaced into the recipient builder's prompt dozens of times, byte-identical (same timestamp, same body), as if one delivered/held message were re-injected repeatedly rather than once. It forced a response loop on the recipient; the builder recognized the duplication and held rather than re-acting. Evidence: the repeated identical 09:45:46.866Z blocks in builder-spir-4679's transcript (shannon workspace).

Possibly aggravating: during the same window the sender ran afx interrupt builder-spir-4679 twice (09:50, 09:53) on the af-mailbox watcher's advice, then an afx send --interrupt bypass (09:53) — if interrupt reprocesses the held queue without consuming, that may be the replay engine.

2. Stuck composer / held-mail wedge (same pair, same window)

af-mailbox notices at 09:48 and 09:53: messages held (reason: busy) for 3–7m because the recipient's 'composer never classifies as a ready prompt'; cron nudges did not deliver; two ESC+Enter interrupts did NOT clear it (the 09:53 watcher notice fired after both). Held ids observed: cb24419d-9bb9-4623-a560-03bfceeabc79, 8c10f62e-baf0-4069-b5c1-b0fb57c39286 (later dismissed by sender), c060d2bf-94c1-405b-a195-2a19cfc0373e. If item 1's replay loop was occupying the composer, these are downstream symptoms.

3. Mid-message truncation (same day, 3×, length-correlated)

Three architect→builder sends (different quoting styles: double-quoted, single-quoted) arrived truncated — only a tail fragment of the body surfaced in the builder prompt, with the recipient explicitly reporting 'the opening and body were lost; nothing in my inbox either' (2026-08-31T03:42Z, 03:56Z; 2026-09-02 ~09:56 near-miss re-confirmed by resend). Short messages (<~400 bytes) consistently landed intact; long bodies truncated. Workaround in use: split into <400-byte parts or use --file (which then hit defect 1).

Impact

A full day of degraded architect↔builder coordination on an active incident: repeated re-sends, forced interrupts, a builder response loop, and rulings delivered late. Workarounds (short messages, --file, --interrupt bypass) each traded one failure mode for another.

Reporter: voice architect, shannon workspace. Transcript evidence available on request; the builder transcript (builder-spir-4679) holds the replay blocks verbatim.

[amrmelsayed]

Corroborating occurrence from shannon:main, independent of the builder-spir-4679 loop: 2026-09-02T08:39:23.125Z, an architect→architect message (security→main, the '4567 fold no-objection' body) was delivered to my pane TWICE, byte-identical including the wrapper timestamp — a clean duplicate, not a resend (the sender confirmed one send). I banked it at the time as a possible regression datum from the #1573 delivery-verification change (verify-before-report could plausibly re-deliver when verification is ambiguous) and said I'd report on recurrence — this issue is the recurrence, at far worse multiplicity. Timing note: my duplicate PREDATES the 09:45 loop by ~an hour and involved no interrupt usage on either end, which weakens interrupt-as-replay-engine as the sole mechanism.

[amrmelsayed]

Triage from the tower contract seat, source-grounded against packages/codev/src/agent-farm/servers/mailbox-delivery.ts at current main.

Item 1 (re-delivery loop): mechanism identified, regression window matches 3.3.2

The #1573 fix ("verify delivery reached the terminal before reporting it delivered", 35f2e637f, shipped in 3.3.2 on 2026-09-01) added an echo-verify step AFTER the write edge. The failure path is the replay engine:

1. The gated write completes: every byte of the message, Enter included, is accepted by the recipient's PTY. The recipient sees the message. (mailbox-delivery.ts ~line 684.)
2. Echo-verify then samples the screen for the message header. If it cannot find it (screen scrolled, recipient's agent already repainting/responding, or the item-2 classifier condition), the row returns hold('busy') (~line 694) even though delivery physically happened.
3. The redelivery machinery re-runs the row on the next clean gate pass, which performs a full re-WRITE before verifying again. Same outcome, same hold. There is no cap on write attempts per row anywhere in the module.
4. The recordStreak escalation deliberately excludes busy holds from liveness telemetry ("a human legitimately at the line - must not false-alarm", ~line 1038), so the loop is also silent to the owner.

The design comment at the verify site says the intended worst case is "a duplicate delivery the agent can see, instead of a silent loss". With a systematically failing verify, the actual worst case is an unbounded stream of byte-identical injections, and it is self-sustaining: the recipient responding to each injected copy keeps the screen busy and scrolling, which keeps the verify failing. The reported afx interrupt attempts likely made it worse, not better: each interrupt produces a fresh clean prompt, which is precisely the trigger for another redelivery pass.

Item 2 (stuck composer): consistent as the verify-failure condition

"Composer never classifies as a ready prompt" is the same render-gate classification family the streak telemetry calls classifier-stuck, but surfaced here under reasons (busy) that are intentionally unescalated. If the composer misclassification caused echo-verify to fail while writes succeeded, items 1 and 2 are one defect observed from two sides.

Item 3 (length-correlated truncation): known open class

This is #1567 (delivery-side silent truncation of long bodies), filed 2026-08-31 from the same workspace's first report and still open. Cross-linking rather than duplicating; the two 08-31 instances here predate 3.3.2, so item 3 is not part of the #1573 regression.

Fix directions (for whoever takes this)

• A row whose write COMPLETED but whose verify failed is in an at-least-once-delivered state. It must not be blindly re-held as if never written: either cap re-write attempts per row (2-3), then escalate to the owner as unverified-but-probably-delivered, or track a per-row write-completed count and switch to verify-only (no re-write) passes after the first completion.
• Echo-verify needs to tolerate a recipient that starts responding immediately (header scrolled out of the sampled region is not non-delivery).
• Reconsider busy-hold exclusion from escalation for rows with at least one completed write: that specific combination is never "a human at the line".

Related lineage: Spec 1313 (mailbox-first), #1365 (write-edge lock), #1521/#1564 (residuals #1573 targeted), #1567 (item 3), #1573 (the regression window).

[waleedkadous]

Confirmed as a 3.3.2 regression from #1573 (PR #1577), and the triage above is accurate against current main: a completed write whose echo-verification fails is re-held (mailbox-delivery.ts:694), the next clean-prompt pass performs a full re-WRITE, there is no per-row attempt cap, and busy holds are excluded from escalation — so the loop is unbounded and silent. This was recorded as residual #1578 at merge time with the trigger judged rare (agy alternate-screen); the field trigger is far more common than that — any recipient that starts responding before verification samples scrolls the header out of the checked region. The 08:39 architect→architect duplicate is the same mechanism at multiplicity 1. Hotfix lane opening now, targeted at a 3.3.3 hotfix release today. Item 3 is the pre-existing #1567/#1564 truncation class (settle-before-write + size cap in 3.3.2 target it; not part of this regression). Interim mitigation for affected workspaces until 3.3.3: avoid --file/long bodies to busy builders, and do not use afx interrupt to clear a held row — each interrupt triggers another redelivery pass.

[waleedkadous]

Hotfix lane: #1584 (BUGFIX, builder spawned). Design: zero re-writes after a completed write — verification failure marks the row delivered with verified:false surfaced to the sender + WARN + escalated flag; never held, never re-injected. Targeting 3.3.3 to @latest on merge.

[amrmelsayed]

Item 2 is now split out as #1590 (investigation-first, area/tower). Item 1 was fixed by #1584 / PR #1585. Item 3 is dispositioned on #1567 as plausibly-resolved-in-3.3.2, verify-before-close. This issue stays open as the parent report until #1590 and the #1567 verification window resolve.

[amrmelsayed]

Recurrence data (shannon workspace): the head-truncation class hit twice in two days on architect→builder sends. (1) 2026-09-03 ~03:13Z → builder-pir-4755: a ~990-byte send arrived as only its tail fragment ("n or jest is fine given the stub is typed-only."); nothing recoverable in afx inbox. (2) 2026-09-04 ~05:48Z → builder-spir-4775: a ~1065-byte send arrived as an empty "###" fragment plus a second message with only the tail visible — the head cut mid-instruction. Both sends were flagged "(unverified — header not seen on the terminal)" at send time, which appears to be a reliable leading indicator of this class. Workaround holding: short body + --file attachment with an absolute on-disk fallback path resends intact. Both receiving builders correctly refused to act on fragments.

[amrmelsayed]

Third occurrence (2026-09-05, shannon): architect→builder-pir-4755, ~1088-byte send, flagged "(unverified — header not seen on the terminal)" at send time, arrived tail-only. The mitigation protocol (immediate --file resend with an absolute on-disk fallback path, triggered by the unverified flag WITHOUT waiting for a fragment report) worked — zero round-trip lost. The unverified-flag→truncation correlation is now 3/3.

[amrmelsayed]

Fourth occurrence (2026-09-05, shannon): architect→builder-bugfix-4796, ~939 bytes, unverified-flagged at send, arrived as a fragment ending mid-word. Correlation now 4/4. The proactive file-resend mitigation was already in flight when the builder reported it.

[waleedkadous]

Closing the tracking issue: the re-injection loop was fixed by #1584/PR #1585 (never re-write a completed delivery), the truncation half by #1567/PR #1644 (bracketed-paste write), and the stuck-composer half by #1482/PR #1604 (held-verdict details). All three are on main and installed here; the long-send path was field-verified 2026-09-08. Adopters on 3.3.3 still carry the truncation until the next release.