When the orchestrator is allowed to interrupt me

Question

What earns an unprompted spoken interruption, who notices the event, and what happens when nobody is listening?

Decide:

The event set that justifies speaking: a decision gate created, a worker escalation, a dispatch failing, a long task finishing, or nothing at all.
Who watches for them: the brain polling orchestration check / inbox / gate-list, a scheduled Orca automation, or a push from Orca into the daemon.
Behaviour with the toggle off: stay silent and queue, speak anyway, or degrade to a notification that is not speech.
Behaviour mid-sentence: queue behind the user, or interrupt them.
Whether an interruption expects an answer, and so becomes a gate resolution, or is strictly one-way.

Ground every part in what the out-of-band speech research found is actually possible today.

Constraints established by Out-of-band speech — this ticket should decide against these, not rediscover them.

The brain has no record of what it says unprompted. An injected utterance never reaches the Claude Code subprocess's history. The human will reply to something the agent does not know it uttered. That gap, not the frame plumbing, is the substantive decision here.
Writing to history races the live turn. ClaudeSDKClient.receive_messages iterates one shared receive stream with no lock and no fan-out, so a query issued from an HTTP handler while a voice turn is in flight splits the stream and breaks both. Any design that records the utterance has to serialise.
Mid-sentence behaviour is already fixed by the code. Injected frames are dropped at user turn start, and talk over the user after it. Making unprompted speech win requires the UninterruptibleFrame mixin, which inverts barge-in for that frame. That is a product call, not a technical one.
Toggle-off behaviour now waits on the recording indicator task, because the speak-only path is only honest if the indicator stays dark.