[Spec 1273] Per-session submission lock: an awaited send now means submitted

[waleedkadous]

The bug

The verify-phase e2e forensics showed afx reset's /clear was never executed. It arrived as literal text welded onto the front of the re-orientation, no separator, one merged user turn:

/clear### [ARCHITECT INSTRUCTION | ... ] ###
## CONTEXT RESET — re-orientation

No slash command ran. The probe's context was fully intact — it could still recite a secret word planted before the "reset". Every layer reported success.

Refs #1273

Root cause — confirmed in source

writeMessageToSession writes the text and schedules the Enter via setTimeout (SIMPLE_ENTER_DELAY_MS = 50, PACED_ENTER_DELAY_MS = 80), then returns that offset as a number without awaiting it. /api/send responded off that.

So an awaited send resolved ~50ms before its own message was submitted. Reset awaited sendRaw('/clear'), did a fast readOutput, then wrote the re-orientation — inside the window, into the same composer, ahead of the Enter. One Enter submitted both.

The channel choice was right. The mistake was treating an awaited send as proof of submission when it only proved scheduling — the third member of a family the ledger now tracks: an operation that reports success at a point earlier than the thing it claims.

It also retro-explains phase 6's clear-confirmation finding: at the moment I sampled output, the clear hadn't even been submitted. Two bugs, one seam.

Ordering is not atomicity

SendBuffer already serializes within a flush, and #1307's per-session FIFO fixes delivery order. Neither would have prevented this — the two writes were correctly ordered and still coalesced. Being second is not the same as being separate.

The primitive

submitToSession(sessionId, write) — a promise chain per session. Each submission waits for the previous one to finish including its Enter, so concurrent sends to one terminal cannot interleave in the composer.

Architect-assigned to me; #1307 adopts it unchanged and drops their narrower versions (deliverOrBuffer's writeCompletesInMs wait, SendBuffer.busyUntil, delayed-send.ts's chain). One mechanism, two adopters.

Wired to the escape path and the immediate message path only. The buffered path is deliberately not awaited — a deferred message can sit up to 60s, and awaiting it would hang the caller instead of returning deferred: true. That constraint came from 1307 before I wired anything.

I did not touch send-buffer.ts: it's 1307's active file, and their busyUntil work should adopt this primitive rather than collide with an edit from me.

A correction to my own earlier claim

I had told both the architect and 1307 that reset's writes bump _lastInputAt and so trip their own buffering. False, verified at 1307's prompting: recordUserInput() is called only from pty-manager.ts:310,317 — the websocket handler, i.e. a human typing. Tower's own writes never touch it.

Deliberate test change

delivers message + Enter as a single atomic write asserted writeCalls.length === 1 — i.e. that the route returned before the Enter was written. That was the bug, not the contract. It now asserts the property that actually mattered (Enter is a separate write, never appended), as properties rather than an exact count since formatted messages are paced.

Testing

7 new tests, mutation-verified: removing the chaining fails the coalescing test and the ordering test, and passes the rest. The headline one models a real composer — write appends to a pending buffer, enter submits it — so it fails in exactly the way production did.

Suite 4057 → 4058, build clean.

Still open

This makes the clear submittable. The live re-run against the planted-context probe is what will confirm it actually clears, and will finally calibrate the confirmation pattern against real post-clear output.