The managed block already tells agents to load the mempalace skill, but said
nothing about the palace being shared with other machines. Three failure modes
observed tonight while onboarding tor-ms22's feeders, all of which do damage
rather than merely confuse:
- `mempalace sync` prunes drawers whose source files look gitignored, deleted
or moved. On a central palace that describes most of the content, including
every other machine's. Compounded by RFC-001 7.2: feeders now stage inside
the palace root, so a scoped sync can delete the drawers it just filed.
- A client-side timeout is not a failure. The palace is single-writer and one
large mine blocks every client for minutes, so
`[mempalace ext] feed (tick) failed: mine timed out after 30000ms` usually
means the mine COMPLETED. Verified: drawers from a timed-out tick were
present 35 s after the client gave up. A blind retry files a duplicate.
- The `mempalace` CLI has zero references to MEMPALACE_REMOTE_URL, so it always
opens a palace on local disk and can silently disagree with the MCP tools.
Orientation depth stays in the skill; only damage-prevention belongs here,
because this file is always read and the skill's later sections often are not.
Joakim Persson
a55f6369b3