one boot path for the workers and the API (V-639)

run() wired the daemon twice and the lists drifted: seven workers started
untracked on the unlock path, a shadowed WaitGroup hid the voice server, and
nexus and getMCPServers were never set after a passkey unlock.

newDaemonAPI and startBackground in cmd/mavend/boot.go are the one place both
paths go through now. backgroundWorkers is the pure list behind the second, so
the set is assertable without a running daemon.
This commit is contained in:
2026-08-06 23:33:26 +04:00
parent 69d0f5ee78
commit 73441bcc6c
3 changed files with 162 additions and 113 deletions
+18 -1
View File
@@ -1,9 +1,26 @@
# The two boot paths have drifted
Last verified: 06-08-2026 @ 06c1cf2
Last verified: 06-08-2026 @ 69d0f5e
V-639. Reads with `docs/operations.md`.
## What landed
`cmd/mavend/boot.go`. `newDaemonAPI(deps)` builds the CoreAPI with every field
set, and `startBackground(ctx, &wg, deps)` starts the voice server and every
worker through `goWorker`. `backgroundWorkers(deps)` is the pure list behind it,
so a test can compare the set without standing a daemon up. Both paths in
`run()` now read `coreAPI = newDaemonAPI(depsNow())` and one
`startBackground(...)`, where `depsNow` reads whatever the current path wired.
The shadowed `wg` is gone. Four tests in `cmd/mavend/boot_test.go`. Every
`daemonAPI` field is set on a fully wired deployment. The handler gets the API
it was built with. The worker set is asserted by name, at the full set and at
the floor.
Still by hand: unlock a locked box by passkey, ask something that needs Nexus,
and check `/tools` lists the MCP servers.
## What is wrong
`run()` in `cmd/mavend/main.go` brings the daemon up two ways. A box with a key in the