First boot of the 2026-08-15 image on EMB-7KJ4VR4G shipped 7 transcripts to the
palace host and filed none. Two causes, neither visible in the log:
- MEMPALACE_PI_REMOTE_PATH was unset, so the feeder used its /data/feed default,
which assumes a CONTAINERIZED palace server. That fleet's primary runs
natively (systemd user unit + uv tool), so it only sees host paths and the
mine died with "source directory not found". rsync had already succeeded.
- The feeder decided success with `'"error"' in body`, but MCP escapes the
tool's JSON inside result.content[].text, so the check was blind and the
catch-up log said "Done. Wing updated." Fixed in mempalace-toolkit 6e1f4f3,
which ships `--self-test` with fixtures pinning that exact response body.
- smoke-test.sh: run `mempalace-pi-session --self-test` against the BAKED
toolkit, so a stale or reverted MEMPALACE_TOOLKIT_REF cannot reintroduce a
feeder that mines nothing while reporting success.
- .env.example: spell out that MEMPALACE_PI_REMOTE_PATH is the path the SERVER
PROCESS can open — container path for a dockerized server, and identical to
the ssh-target path for a native one — and that a mismatch fails quietly.
Joakim Persson
d8b745c164