feat(voice): stop means stop — the abort now reaches the reader and the camera

The device found three failures in one call, all of them the same shape:
"stop" was reported as done while the work carried on.

**The abort never stopped anything local.** `applyInterrupt` has always
claimed the turn's reader was torn down; nothing did it, so an aborted
task was read to its natural end and Sai reported the result of work she
had just been told to abandon. And a turn about what the user is looking
at spends most of its life on this phone waiting for the camera, so a
"wait, stop" still ended with a shutter firing and a photo arriving for a
task that no longer existed. `abort()` now stops reading, cancels the
device's own work, and only then asks the server. A generation counter
covers the gap `ensureActive` cannot see: an event already parsed and
parked on the FSM's mutex — the mutex the abort itself holds.

**There was no way to say "drop this one and carry on."** `interrupt`
took the queue with it, `cancelQueued` cannot touch a running task, and
`relayToAgent` only narrows one from the inside — so the model reached
for `resetSession`, which wipes the conversation and stops no work at
all. `interrupt` gains a scope; an absent or unknown one still means
everything, because a bare "stop" means stop.

**And `resetSession` was one mis-heard word from a wipe.** It now
confirms once. The flag is cleared by any batch that is not another
reset, because a held reset happens with nothing running, so no turn
starts to clear it and a declined "no, just drop that" left the yes
standing.

Two more from the same log. Ask-first fired after a 40s capture and
silenced a result the user was sitting there waiting for — quiet is now
measured to the moment work STARTED, keeping the first stamp after they
speak, so the camera spinning up ends their silence rather than the
forward tens of seconds later. Its nudge also says plainly that it is a
delay and not a discard, after Sai offered to retry a task whose answer
she was holding; `ActivityLog` keeps that outcome so `getSaiStatus` can
answer with it.

The camera's retries were self-inflicted: the frame counter used
`take(N).collect`, which cancels the subscription on the Nth frame, so
every `capturePhoto` was issued against a stream nobody was reading. The
collector now stays subscribed until the still is in hand.

Calls no longer mint their own session. A conversation outlives a call —
five quiet minutes, folded glasses or a misheard goodbye all end one —
and each mint added a page to the user's sidebar. What made the original
hazard unescapable was a second bug, since fixed: "start fresh" rotated
the terminal's session instead of this client's.

One review fix on top: the abort POST is best-effort in code and not only
in its comment. It threw, which returned before the turn was closed out,
leaving the FSM in `working` with its reader already gone — no event
could arrive to end it, and admission held every later task behind a turn
that could not finish.

Docs: VOICE_FSM gains the two one-shot confirmations and the
conversation-per-call trade; three stale counts corrected (63 scenarios,
fourteen effects).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: jamie-simular

docs/CONCIERGE_CLIENT_PROTOCOL.md

@@ -208,6 +208,15 @@ from; moving retires the one behind you. Two things follow, and a client owes th
   app's half, shared with the hang-up, and it exists because the FSM is rebuilt on a switch and would
   otherwise drop a queued task it had promised out loud.
 
+**Do not rotate on your own initiative.** `POST /new-session` is the user's command, not the client's
+housekeeping: a send already resolves the channel's current session, so there is nothing a client has
+to do to stay in one conversation. sai-fi used to mint a session per call and the rotation was
+visible — every call added a page to the user's sidebar in the desktop app. The unit matters more than
+it sounds. A *call* ends on five minutes of quiet, on the wearer folding the glasses, or on the model
+mishearing a goodbye, so a client that rotates per call rotates several times inside one thing the
+user would call a conversation. Rotate when asked, and leave it alone otherwise. (Session growth is
+the real cost of not rotating; if it needs bounding, bound it on the session's age, not on a call.)
+
 ## 8. Keeping a port honest
 
 If you implement this in another language, mirror the guards that already exist rather than inventing

docs/ON_DEVICE_CHECK.md

@@ -301,9 +301,14 @@ The other half of the queue: check 6 is about work that waits, this is about wor
 - **Expect:** it stops, Sai says so plainly, and — the part that matters — it does **not** describe the
   stopped task as finished. "That's done" about work that was killed is the failure.
 - **Exercises:** `interrupt` → `applyInterrupt` → `POST abort`. Watch for `→ effect: interrupt` and then
-  `→ POST abort` in logcat. The abort produces **no agent event by design** (the stream reader is torn
-  down), so the handler has to close the turn out itself. If it doesn't, everything you ask afterwards
-  queues behind a turn that will never end — so follow up with a fresh, quick task and check it runs.
+  `[voice] stopped following the turn — it was aborted`. No agent event follows, *because* of that line:
+  the abort stops this device reading the turn, so the handler has to close the turn out itself. If it
+  doesn't, everything you ask afterwards queues behind a turn that will never end — so follow up with a
+  fresh, quick task and check it runs.
+- **Also watch for what must NOT appear:** any `•` progress line, a `✓ done:`, or a `→ nudge: complete`
+  after the stop. On 2026-08-20 all three did — nothing tore the reader down, the cancelled task was
+  read to its natural end, and Sai reported its result to a user who had just stopped it. If you see
+  `[voice] dropped … from an abandoned turn` instead, that is the guard working.
 
 **9b — stop everything, from two.** Start a long task, queue a second behind it (check 6a), then:
 
@@ -326,6 +331,16 @@ The other half of the queue: check 6 is about work that waits, this is about wor
   orphans it. This path is worth the attention: its last bug rotated the *terminal's* conversation
   instead of this one, which no off-device test could see.
 
+**9d — two calls, one page.** With the desktop app's sidebar visible: make a call, ask for anything
+that reaches the agent, hang up. Start a second call and ask for something else.
+
+- **Expect:** **one** conversation page total, with both calls' work in it — not a new page per call.
+  Then say "start fresh" and expect a second page to appear, since that one is asked for.
+- **Exercises:** the absence of a per-call mint (`VOICE_FSM.md` §7b). Nothing off-device can see this
+  — `VoiceSession` has no unit test and the harness fakes reimplement the transport — and the symptom
+  is only visible in the sidebar, which is why it went unnoticed. Note that a **machine switch** still
+  starts a new page and that is expected: `machineId` is in the server's session key.
+
 ### 10. endCall
 
 **10a — with work still outstanding.** Do this one *before* letting the queue drain — if check 6's tasks

docs/SAI_GLASSES_APP.md

@@ -103,7 +103,7 @@ while nothing is running, for instance.
 | `ActivityLog` / `ConciergeProtocol`  | The canonical nudge and activity-log wording (`describeAgentEvent` with prompt-injection fencing). Originally ported verbatim from the server's `core/activity-log.ts` / `core/nudges.ts`; those are gone and these are the only copy, pinned by the string goldens (§8.1). Feed `getSaiStatus` + the UI activity view.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | `GlassesGestureSession`              | DAT `DeviceSession` (no display/camera capability) reacting to the only temple gestures DAT surfaces: tap = mute/unmute Sai, tap-and-hold/doff/fold = end (all just `DeviceSessionState`; no gesture is remappable — see §6 "Glasses gestures").                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | `SaiFiApp` / `MainActivity`     | App init (`Wearables.initialize` once); `MainActivity` is now just the DAT-registration deep-link callback host (`saiwearables`) — the CameraAccess sample UI was pruned in productization.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| `fsm/` (13 files)                    | **The conversation state machine**, ported from the server: modes and transitions, the bounded effect grammar and its parse boundary, the admission rule that holds a mid-turn task instead of folding it in, the local held-task queue, the cost guard, and every line the FSM speaks. Everything but `Concierge.kt` is pure, which is what makes the 59-scenario golden catalog runnable as JVM tests; `Concierge.kt` serialises all four input kinds through one `Mutex`, because two forwards interleaving at a suspension point books the restaurant twice. Design: [`VOICE_FSM.md`](VOICE_FSM.md). **This drives every call** — `CallService.buildConcierge` builds one `VoiceSession` per call and feeds the model's tool calls straight into it.                        |
+| `fsm/` (13 files)                    | **The conversation state machine**, ported from the server: modes and transitions, the bounded effect grammar and its parse boundary, the admission rule that holds a mid-turn task instead of folding it in, the local held-task queue, the cost guard, and every line the FSM speaks. Everything but `Concierge.kt` is pure, which is what makes the 63-scenario golden catalog runnable as JVM tests; `Concierge.kt` serialises all four input kinds through one `Mutex`, because two forwards interleaving at a suspension point books the restaurant twice. Design: [`VOICE_FSM.md`](VOICE_FSM.md). **This drives every call** — `CallService.buildConcierge` builds one `VoiceSession` per call and feeds the model's tool calls straight into it.                        |
 
 ## 3. The client contract (frozen; the Kotlin app ports the browser reference client)
 
@@ -176,6 +176,11 @@ programmatic channel, as with a rebound Telegram link), so coming back to a mach
 `recallHistory` will not reach what you did there before. Within a call that costs nothing: the Live
 model holds the whole call in its own context.
 
+That retirement is the server's, and the client no longer adds a rotation of its own on top of it.
+Ending a call and starting another stays in one conversation — one page in the desktop sidebar — and
+the only thing that rotates the session is the user saying "start fresh". See
+[`VOICE_FSM.md`](VOICE_FSM.md) §7b for what that trades away.
+
 **Client-local voice tools** (declared server-side, handled on-device): `getSaiStatus` (status
 pull), `recallHistory` (recent machine history via `GET /v1/agents/context` — recall questions
 answered without waking the agent), `switchMachine` (rebuilds the concierge against another owned VM; the Live audio session keeps

docs/VOICE_FSM.md

@@ -64,7 +64,7 @@ Everything in `State.kt`, `Effects.kt`, `Speech.kt` and `AgentIngest.kt` is pure
 input go in, a new state comes out. No coroutines, no clock, no I/O. `Concierge.kt` is the only part
 that suspends, and the ports (`AgentBridge`, `VoiceChannel`) are the only way it reaches the world.
 
-That split is what makes 59 golden scenarios runnable as plain JVM tests. It is the same shape
+That split is what makes 63 golden scenarios runnable as plain JVM tests. It is the same shape
 `GlassesLink` uses, for the same reason.
 
 **Do not make the pure parts call the clock or the network.** The moment they do, the catalog stops
@@ -104,7 +104,7 @@ to different questions.
 
 ## 4. Effects: the conversation is open, the capabilities are not
 
-The model can say anything. It can *do* only the fifteen things in `Effects.kt`. `parseEffect` is the
+The model can say anything. It can *do* only the fourteen things in `Effects.kt`. `parseEffect` is the
 boundary, and an effect it does not recognise — or whose payload is the wrong shape — is **dropped**,
 not guessed at. A newer model inventing a capability does not get to exercise it.
 
@@ -115,6 +115,9 @@ The parse rules are deliberately asymmetric, and the asymmetry is the contract:
 - `askAndWait` and `setState` **reject outright** on a bad enum — an invented mode must never become
   a state.
 - An unrecognised `urgency` **degrades to normal** rather than dropping the task.
+- An unrecognised `interrupt` **`scope` widens to `everything`**, for the same reason pointed the
+  other way: a bare "stop" means stop, and a scope a build does not know must never quietly
+  narrow a cancellation into leaving work running the user believes they stopped.
 
 `askAndWait` does **not** speak. It is a pure state signal: the Live model has already voiced the
 question, and speaking it again doubles it up and interrupts the model mid-sentence.
@@ -152,6 +155,33 @@ hears "on it" waits for a result nothing is producing. So the spoken line names
 
 > "Got it — I'll start that as soon as I'm done with: …"
 
+## 6b. Two questions the FSM asks before it acts, each exactly once
+
+`interrupt` and `resetSession` both guard themselves with a one-shot flag, and both flags are cleared
+by `startTurn` — new work is a new context, and a stale yes is a yes to something else.
+
+**The interrupt's scope question** fires when more than one thing is outstanding, counting running
+PLUS queued: since admission holds a second request rather than folding it in, "one running, one
+queued" is the same question with the same stakes. A second `interrupt` while the flag is set reads as
+"all of it" and goes straight through. A scoped `running` interrupt skips the question entirely,
+because the user has already answered it — the waiting list is explicitly being kept.
+
+**The reset confirmation** exists because a rotation cannot be undone, and because "forget it", "never
+mind" and "drop that" are almost always about the last thing said while sharing their vocabulary with
+"forget everything we talked about". On a device call a bare "forget it" — about a question Sai had
+just asked — arrived as `resetSession` and cleared the conversation. The prompt says not to do that;
+the prompt is not a guarantee, and there is nothing behind it. So the first call asks and the second
+rotates.
+
+That flag needs one thing `startTurn` cannot give it: a held reset happens with **nothing running**,
+so no turn starts to clear it. A user who answers "no, just drop that" would leave the yes standing
+for the next stray "forget it", minutes and subjects later. So `applyEffects` also clears it after any
+batch that is not another `resetSession` — the user having moved on. Asking again is the safe
+direction; the failure being avoided is a wipe nobody asked for.
+
+Neither question is a `say`. Both are `instruct`, so the model asks in its own words and nothing is
+voiced that describes an action as already taken — see §5.
+
 ## 7. The queue is local, and that is a trade
 
 Held tasks live in this FSM and **nowhere else**. Nothing is written server-side when a task is
@@ -170,6 +200,39 @@ the world that starts a held task.** So every path that can leave `mode` at `IDL
 It runs after each agent event, which covers every way a turn ends today; miss one and a task the
 user was told was coming simply never runs.
 
+## 7b. The conversation outlives the call, and that is a trade
+
+The client does **not** rotate the agent session on its own initiative. A send resolves the server's
+`{uid}_{machineId}_{channel}` pointer to whatever session is already current, and the only thing that
+moves that pointer is the user asking — `resetSession`, on "start fresh". Two consecutive calls are
+one conversation, and one page.
+
+**Why it used to rotate per call.** `VoiceSession` minted a fresh `api` session on its first forward,
+and the hazard it was guarding is real: everything in that transcript is read back as the agent's own
+prior turns on every later call, so one bad turn is not a bad turn — it is a permanent change of
+behaviour. That is not hypothetical. A stubbed reply written during local testing was still being
+imitated by the real agent days later, on a machine doing real work, and fixing the code that wrote
+it did not help, because a code fix does not reach the data.
+
+**Why that no longer justifies it.** What made that episode unescapable was a *second* bug: the one
+command for getting out — "start fresh" — was rotating the terminal's `cli` session instead of this
+client's `api` one, so the user could not rotate away from the poisoned transcript even by asking.
+That is fixed and pinned by a test. Meanwhile the cost of auto-rotation was being paid constantly,
+because **a call ends far more easily than a conversation does**: five quiet minutes trips the idle
+guard, folding or removing the glasses ends it, and the model can decide it heard a goodbye. A chat,
+glasses off for a minute, two more questions, then a machine switch produced four pages in the user's
+sidebar for what they experienced as one conversation.
+
+**What this costs, plainly.** The `api` transcript now grows without bound, and a bad turn persists
+across calls until the user says "start fresh". That is a step backwards on blast radius, accepted
+knowingly. If a long-lived session turns out to degrade the agent measurably, the next move is
+**age-bounded rotation** — not a return to per-call, which trades a rare problem for a constant one.
+
+One part of this is not reachable from here: a **machine switch** still starts a new page, because
+`machineId` is part of the server's session key. That needs a cloud-api change — dropping `machineId`
+from the `api` channel's key, or a `sessionId` parameter on `POST /message` so a client could pin the
+session the `data-session` frame already names.
+
 ## 8. The races that used to be here
 
 `Races.kt` is gone. It guarded three cases that arose because held work lived in two uncoordinated
@@ -241,7 +304,7 @@ changed. Concretely: two forwards both observe an empty `inFlight` before either
 take the immediate path, and the user's restaurant is booked twice.
 
 **Testability.** `Dispatchers.Main` has no implementation in a plain JUnit run, and nothing in this
-suite installs one. An FSM that named it could not be unit-tested at all — and the 59 golden
+suite installs one. An FSM that named it could not be unit-tested at all — and the 63 golden
 scenarios are the only thing that proves this port matches the server's behaviour.
 
 The server does the same job with a promise-tail chain. One `Mutex` is the same guarantee.