docs: decide where mavwaked and mavenclient run — not on homesrv (V-463)

They appear in no compose file and run as no host process, and the task
asked whether that is a gap to close or a decision to write down. It is a
decision.

The reason is not hardware. homesrv is a Lenovo laptop and
/proc/asound/cards lists its ACP mic array with capture devices, so
passing /dev/snd into a container would work. It would also listen to an
empty room. A wake-word daemon is worth having where he is standing, and
that is not where the server is.

mavenclient is a client by name and design, mavwaked is the gate in
front of it, and the wire already reaches off-box: ipc.Dial takes
tcp://host:port?token=... through the netaddr seam, with the token
checked before internal/ipc sees the connection. So this needs a machine
and a config line, not protocol work.

The honest consequence is worse than the task suggested, and both docs
now say it: the wake word and the VAD gate are covered by unit tests and
by nothing else. QA session 1 step 2 was reworded to claim only what it
checks, which is push-to-talk through /dash. CLAUDE.md listed all nine
binaries with no column for where they run, which is how this went
unnoticed.

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

docs/plans/17-where-the-voice-loop-runs.md

@@ -0,0 +1,60 @@
+# Plan: Where mavwaked and mavenclient run
+
+**The decision Vikunja #463 asked for. Written 04-08-2026.**
+
+**Verdict: not in compose on homesrv. They run on a client machine in the room he is in.**
+The transport for that already exists and nothing needs building to allow it. What needs
+building is a way to check the wake path at all, which is a separate task.
+
+## The state that prompted this
+
+`docker-compose.yml` runs mavend, mavsttd, mavttsd, mavweb and mavpoll. `mavwaked` and
+`mavenclient` appear in no compose file and run as no host process. Both build under
+`make build`. So the wake word and the voice-activity gate are untested by construction:
+QA session 1 step 2 covers push-to-talk from `/dash` only, and #287 (voice session
+quality) can never be more than half-answered while this holds.
+
+## The reason is not hardware
+
+homesrv has a microphone. It is a Lenovo IdeaPad 5 Pro, and `/proc/asound/cards` lists
+the ACP digital mic array with capture devices at `/dev/snd/pcmC1D0c` and
+`/dev/snd/pcmC2D0c`. Adding `/dev/snd` to compose and joining the `audio` group would
+work.
+
+It would also be pointless. A wake-word daemon is worth having in the room he is standing
+in. homesrv is a server, so its microphone hears the room the server is in, which is not
+where anybody talks to Maven. Wiring audio into a container to listen to an empty room is
+work spent on a capability nobody can use.
+
+## The reason it belongs off-box
+
+`mavenclient` is a client by name and by design: microphone, then STT, then core, then
+TTS. It is the one binary in the tree meant to run somewhere else. `mavwaked` is the gate
+in front of it, so it goes wherever the microphone goes.
+
+Maven already has components that are not containers on homesrv. `mavupdate` is a
+host-side tool. The resident model, STT and TTS prefer the workstation and fall back to
+homesrv (`docs/offload.md`). Off-box is a shape this system already has.
+
+**And the wire already supports it.** `ipc.Dial` takes a netaddr seam address:
+a bare path is the unix socket, and `tcp://host:port?token=...` reaches a core on another
+host, with the token checked in `internal/netaddr` before `internal/ipc` sees the
+connection. So a client machine reaching mavend over wg or the LAN needs no new protocol
+work. It needs mavend to listen on TCP, which `deploy/mavend.json` does not currently ask
+for.
+
+## What this means for the QA plan
+
+QA session 1 step 2 should say what it actually covers, which is push-to-talk through
+`/dash`. It should not read as though it covers the voice loop. The wake path is checked
+on the client machine or it is not checked, and today there is no client machine.
+
+That is the honest state, and it is worse than the task suggests: this is not a
+configuration gap that a compose entry closes. Until a machine with a microphone runs
+`mavwaked` and `mavenclient` against a TCP-listening mavend, `internal/wake` and
+`cmd/mavwaked`'s VAD are covered by their unit tests and by nothing else.
+
+## What was wrong in CLAUDE.md
+
+The daemon table lists all nine binaries with no column for where they run, which is how
+this went unnoticed for as long as it did. It now says which two are not on the box.