Runbook gaps found while fixing the 2026-08-15 feed failure:
- §2.5 still titled "written but not installed" and still asserting "Not
installed, not enabled" — false since 2026-08-12. A reader landing there got
a flat contradiction of §4 item 3. Retitled, with the verified-2026-08-16
process line, and it now states the fact §2.6 depends on: the server is a
NATIVE process (no mempalace container on synlig), so it sees host paths.
- New §2.6 documents ~/mempalace-feed/<device>/: why transcripts cannot travel
over the HTTPS leg at all, the three client variables, and why
MEMPALACE_PI_REMOTE_PATH is the trap (its /data/feed default assumes a
containerized server; here it must equal the ssh-target path, and a mismatch
fails with rsync succeeding and only the mine failing). Plus the operational
notes that cost time: dedup keys on the absolute path so the inbox path is
load-bearing, grown sessions are purged+refiled by mtime, and a client-side
MCP timeout is NOT a failed mine.
- Header status: counts refreshed with an explicit "treat counts as timestamps".
Also, bin/mempalace-pi-session: default HOME from the passwd database when it is
unset. `docker run --entrypoint="" <image>` inherits no HOME when the image
config declares none, and every default is HOME-anchored under `set -u`, so the
script — including the palace-free --self-test — died with "HOME: unbound
variable" in exactly the environment pi-devbox's smoke suite uses. pi-devbox
v1.8.0 lost a release to the same assumption from the other side.
Joakim Persson
b609cf5a69