feat(voice): audible recipient ack on inbound /handoff in #general#1332
Merged
Conversation
…ask-1777140469973)
When a real `/handoff to=<name>` lands in #general and the named agent
is on this host, that agent speaks a 1-4 word audible acknowledgment in
its own voice — same /canvas/speak path voice-on-chat already uses, so
the existing voice_output SSE → activeSpeaker rail drives it. No chat
duplication, no extra canvas UI.
Locked behavior:
- real `/handoff to=<name>` only — strict prefix, cloud SDK typo set
('/handof', '/andoff', '/andof') is intentionally NOT honored on this
audible path; embedded mentions and follow-up text are ignored.
- voiceCapable recipient only (agent_config.settings.voice non-empty)
- ≥1 human present in room
- recipient not already mid-TTS (gate on activeSpeaker)
- 1-4 word recipient-authored line via Anthropic claude-haiku-4-5
- silence on any gate-fail or LLM failure — no canned chrome in prod;
a tiny dev-only fallback pool fires only when ANTHROPIC_API_KEY is
unset, so dev environments aren't mute.
- turn-local dedup: ack IS the vocal artifact for this turn; the
existing voice-on-chat content-cache prevents the /handoff line
itself from also speaking.
Wires into chatManager.sendMessage right after triggerVoiceOnChat.
Adds active-speakers store mirrored from setActiveSpeaker /
setActiveSpeakerAudio in server.ts and from /canvas/speak queue/clear
in canvas-interactive.ts so the gate has truth without depending on
canvasStateMap closure.
Tests: 24 unit tests covering parse, decide-gate ordering, ack
clamping, and trigger wiring (including silent-on-gate-fail and
silent-on-empty-ackLine paths).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
itskai-dev
force-pushed
the
claude/voice-ack-on-handoff
branch
from
May 4, 2026 19:34
fcb5790 to
67c4fb5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When an agent posts
/handoff to=<name>in #general, the namedrecipient emits a recipient-authored 1–4 word audible acknowledgment
through the existing
/canvas/speakpath (Kokoro/ElevenLabs →voice_outputSSE → activeSpeaker rail). Closes the joyless seam whereinbound handoffs were silent on canvas.
Locked behavior (per kai msg-1777921934933):
Files
Proof bar (canonical staging)
After merge + image roll on `rn-34faba44-wlgkeq`:
Test plan