Files
mempalace-toolkit/docs
Joakim Persson c349d007e1 docs(§7.2): measure the shared-palace sync blast radius — it is 0 today, and the feeder is what changes that
Unscoped `mempalace_sync` dry-run against the live primary (14,829 drawers):
out_of_scope 14391, no_source 438, missing 0, kept 0. Zero drawers deletable.

The mechanism is the finding: an entirely-absent source root yields
`out_of_scope`, NOT `missing`, and only missing/gitignored drawers get removed.
So a wipe needs the root to EXIST while files under it do not -- not merely a
host that lacks the repos. §7.2's "from a laptop that lacks the repos, it is a
fleet-wide wipe" therefore overstates today's risk.

It also understates tomorrow's, which is the part worth acting on. Two guards
currently prevent the laptop scenario and neither was designed to: the CLI has
no remote support, so a client's `mempalace sync` cannot reach central at all;
and the MCP tool runs server-side on synlig, where clients' /workspace roots do
not exist. That is safety by coincidence of layout.

The feeder's remote mode dissolves it: it rsyncs staged transcripts into
per-device inboxes ON synlig, so those sources begin existing on the palace host
and become in-scope for the first time. A later stage rotation or inbox cleanup
then marks that device's conversation drawers `missing` -- prunable, and
prunable from a different device. mempalace-pi-session already documents the
single-machine form of this; a shared palace makes it cross-device.

So stage retention on synlig plus the sync guard belong to enabling the feeder
fleet-wide, not to a later cleanup pass.
2026-08-14 23:15:01 +02:00
..