--- name: dispatch-midflight-messages-unreliable description: "⭐⭐ PLATFORM LIMIT, OBSERVED 2026-07-21: send_message to an ALREADY-RUNNING code session is UNRELIABLE — of two sends, one was NEVER received at all and one arrived only after a long delay. 'Message delivered' means queued, not read. ⇒ A BRIEF MUST BE COMPLETE AT LAUNCH; if you must send mid-flight, DEMAND EXPLICIT CONFIRMATION." metadata: node_type: feedback type: feedback originSessionId: 1060dea9-0dc3-42b4-958d-2a6f7a6c0c58 modified: 2026-07-21T04:59:03.530Z --- **Owner, 2026-07-21:** *"I don't think you actually sent the update to the session"* → *"yeah I don't think that msg went through either"* → *"well make sure you remember that now that you know."* ## THE OBSERVED FACT On 2026-07-21, session `local_ef47bcf6` (skill guard / drift gap / museum-for-AI) was running. Dispatch sent it two `send_message` follow-ups mid-flight: 1. A tightening constraint (a guard must earn its existence; "no change" is a valid conclusion; the skill must not become a fourth source of truth). 2. An explicit "CONFIRM RECEIPT — answer yes or no" challenge about Suite 243. Both returned `Message sent to "..."`. **The session's own confirmation, once it finally answered: message 1 was NEVER RECEIVED ("Q1 — did I receive the earlier tightening message? No"). Message 2 DID arrive, but only after a long delay** — long enough that it built and shipped an entire commit (`5d57fff`) under the original looser brief first. ⇒ **The behaviour is UNRELIABLE, not uniformly broken.** One lost outright, one delayed. From the outside both look identical to being ignored — which is why Dispatch and the owner both initially concluded "nothing lands," and why Dispatch then over-corrected to "they land, just slowly." **Neither reading was right.** Both were confident conclusions drawn from a few minutes of non-reaction. ### ⚠ THE SECOND-ORDER LESSON — the one that generalises Dispatch stated a platform limitation as fact, told the owner, and wrote it into memory as a rule, on ~3 minutes of evidence. Then reversed it on equally thin evidence. **The correct move both times was to say "unverified" and wait for the session's own answer** — which is exactly what finally settled it. When the only witness to a session's behaviour is Dispatch, Dispatch's confidence IS the failure surface (see the "where can Dispatch bury dissent" problem in the workflow review). ## ⚠ THE MISTAKE THIS CORRECTS Dispatch treated **"Message delivered" as "the session read it."** That is an unverified assumption about a mechanism the platform does not guarantee — **the same class of error as the polling failure** ([[session-reporting-standard]]): trusting a mechanism that does not exist, then being surprised by the consequence. Dispatch also *told the owner* the message had been sent, which made Dispatch's report wrong, not just its expectation. ## ⇒ THE RULE **A BRIEF MUST BE COMPLETE AT LAUNCH.** Once a code session is running, assume it cannot be steered. - Front-load everything: constraints, the bar for adding mechanisms, what "done" means, what counts as a valid *negative* conclusion, and permission boundaries. - If new information arrives mid-flight, **do not assume a `send_message` fixes it.** Either let the session finish and correct afterwards, or stop it and relaunch with a complete brief. - If you DO send mid-flight, **make the message demand explicit confirmation of receipt** ("answer yes or no plainly"). That is what finally produced ground truth here, and it costs one line. - **Correcting after idle is cheap and reliable** — a guard is removable, a commit is revertable. Losing a whole session's work to a relaunch is usually the more expensive option. Default to: let it finish, then apply the bar to what it actually produced. - `send_message` after a session goes **idle** DOES work (proven — that is how `local_68504e25` was resumed after the usage limit). The failure is specific to messaging a session **mid-turn**. - **Never report a mid-flight send to the owner as though it landed.** Say it was sent and that delivery is unverified. ## WHY IT MATTERS BEYOND THIS INCIDENT This is a genuine constraint on the whole workflow and it belongs in the Dispatch self-audit section of `planning/_standing/WORKFLOW_REVIEW_PROMPT.md` as an OBSERVED limitation with evidence — alongside the no-completion-event finding. It shapes everything: it is a large part of why briefs to sessions must be long and complete, and why "the orchestrator's design proposals are hypotheses, not specs" has to be stated *up front* rather than added when a session starts down the wrong path. Related: [[session-reporting-standard]], [[dispatch-session-launch-discipline]], [[always-acknowledge-actions]].