3.5 KiB
Plan: Where mavwaked and mavenclient run
The decision V-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 V-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.
Correction, 2026-08-05. This plan said there was no client machine. There is: workpc, where he sits most of the day and where the microphone is. The sentence was written when the workstation was only a model host. The verdict above is unchanged, and so is everything about the seam. What changes is the size of the remaining work: deploying two daemons and asking mavend to listen on TCP, not acquiring hardware.
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.