claude
86dcd99de2
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>
3.1 KiB
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.