joakimp/mempalace-toolkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: the silent-skip fix is base-image-gated, so today's fleet still skips silently

Browse Source 
pi-devbox cbd7cf5 makes the remote-palace-without-inbox skip announce itself, but
entrypoint-user.sh is COPY'd in Dockerfile.base, so the fix only reaches a
container after a base rebuild. Every image running today still skips silently --
recording both behaviours with the cut-off, so the table stays true for whichever
image a container is actually on, rather than describing a fix that has not
shipped yet.
This commit is contained in:
Joakim Persson
2026-08-13 16:31:18 +02:00
parent 2e73a9eae8
commit 2293f1c89b
1 changed files with 12 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/phase-1-exposure-runbook.md
+12 -5
View File
@@ -304,12 +304,19 @@ the code 2026-08-12, and the quieter one is the trap:
| Caller | Behaviour with `REMOTE_URL` set and `SSH_TARGET` unset |
| --- | --- |
| direct run, session-end hook, cron | `exit 1` with `error: MEMPALACE_PI_SSH_TARGET unset` (`:298-300`) |
| **pi-devbox container start** | **silently skips — no error, no log file** (`entrypoint-user.sh:134`: `: # remote palace but no inbox configured — nothing we can ship to; skip quietly`) |
| **pi-devbox container start, images ≤ v1.7.0** | **silently skips — no error, no log file** (`entrypoint-user.sh:134`: `: # remote palace but no inbox configured — nothing we can ship to; skip quietly`) |
| pi-devbox container start, images after `cbd7cf5` | prints `MemPalace catch-up skipped: remote palace with no transcript inbox` to the start output *and* to `mempalace-catchup.log`, naming both variables |
The entrypoint's skip happens *before* the subshell that writes
`~/.pi/agent/mempalace-catchup.log`, so there is not even an empty log to notice. Someone asking "why is
nothing from this container in the palace?" finds no artifact at all. The skip is deliberate — there is
genuinely nothing to ship to — but it is indistinguishable from a healthy run that had nothing to do.
The silent skip is fixed in pi-devbox (`cbd7cf5`), but the fix is in
`entrypoint-user.sh`, which is `COPY`d in `Dockerfile.base` — so **every container running an image built
before that base rebuild still skips silently.** That is the whole fleet today. Until the rebuild lands,
assume silence and check by hand.
The old skip happened *before* the subshell that writes `~/.pi/agent/mempalace-catchup.log`, so there was
not even an empty log to notice. Someone asking "why is nothing from this container in the palace?" found
no artifact at all. The skip itself is correct — there is genuinely nothing to ship to — but it was
indistinguishable from a healthy run that had nothing to do, which is the worst property a memory system
can have: **the failure looks exactly like success.**
→ On a pi-devbox container, confirm the feeder is actually alive after a flip rather than assuming: