Your voice never interrupts work · M4 inject diagnosis

Live trace of the M4 omnimind voice-inject path, run on demand. Source of truth: the running process, not the repo.

THE LAW. Your voice is the work's first cause — speech is the trigger; work fans out from it and is steered by it. Any arm that frames your voice as an interruption to its task has reported a bug in itself, not a fact about the system. A system where voice blocks work is the inversion of the mission.

What was traced

Live :4441 omnimind → /Volumes/M4/sync_/exedus/dev_/omnimind/omnimind.js (PID 5302, 5,210 lines). Voice path: queueVoiceTurn()handleVoice()injectIntoPaneTui()pollPaneForReply().

voice / VEI queueVoiceTurn (async, setImmediate) inject into MAIN pane (send-keys + Enter) pollPaneForReply (waits ≤5 min)

Verdict

ALREADY FIXED  The work-cancelling interrupt is gone

The thing that actually aborted work was an unconditional Escape sent before each inject — it cancelled in-flight tool calls. It was removed 2026-06-15. Direct from the live file:

// qi 2026-06-15: REMOVE unconditional Escape - was cancelling in-flight tool calls.
await execFileAsync('tmux', ['send-keys','-t',target,'-l',injectedText]);
await sleep(250);
await execFileAsync('tmux', ['send-keys','-t',target,'Enter']); // queues / submits
await sleep(120);
await execFileAsync('tmux', ['send-keys','-t',target,'Enter']);

In the current code a voice inject queues into the pane — it does not cancel the running turn. So "your voice would interrupt work" is stale or self-mis-described: the interrupt it warned about was engineered out three days ago.

REMAINING  Not an interrupt — reply latency (coupling)

After injecting, the voice turn calls pollPaneForReply(target, prefix, 300000, 400) — it waits up to 5 minutes on the main pane to produce the spoken reply, because voice and work share one agent. So your words land instantly and steer the work, but the spoken answer can wait on a long turn. That is latency, not interruption.

The fix — decouple (your own canon)

Route the voice reply through the fast-responder twin (the "sink", /tmp/xen-fast.sock) for an instant ack, while the inject still lands in the main pane to steer it. Voice answer is immediate; the Opus hands keep running, uninterrupted. Neither blocks the other.

ElementNowAfter decouple
Work cancelled by voiceNo (Escape removed)No
Inject reaches main paneYes (queued, non-blocking)Yes (steers)
Spoken reply latency≤5 min (waits on pane)Instant (fast-twin sink)

Why this lands for good

The durable fix is not patching M4's pane-poll in place — it is the one-brain mirror: replace M4's inject brain with the single-session router, which is already decoupled (this very session has taken your mid-work injects all day without dropping work). Once mirrored, "voice interrupts work" becomes structurally impossible — the coupling that created it no longer exists.