Second planning round. Three findings from verification, and the
decisions that were blocking phasing.
Verified in mempalace 3.6.0 and written up:
- NEW §7.6 — diary_write has no idempotency guard at all. The id embeds
datetime.now() at microsecond resolution and the write is a bare
col.add (mcp_server.py:3546) with no col.get probe, in direct contrast
to add_drawer's probe 900 lines earlier (:2593-2600). So §3's "log the
intent, replay the intent" is false for diaries — replay duplicates.
This lands on the critical path because diaries are `replicated` and
are exactly what a join replays.
- NEW §4.4 — join/bootstrap protocol, which the RFC simply lacked. Not
"seed the primary from one palace": every container joins the same way,
repeatedly, so a join is idempotent replay and the only question per
record type is what dedupes it. Drawers and open KG facts need zero
client bookkeeping; closed KG facts and diaries need client-side keys.
Join state belongs in the palace dir, not the container (~/.mempalace
is not preserved by default), which also makes two containers sharing
one host's palace the easy case rather than a double-upload hazard.
- §3.2 — the add_triple guard is scoped to `valid_to IS NULL`, so closed
historical facts are unguarded. §3 read as unconditionally idempotent.
- §7.3 — drawer/diary metadata is exhaustive: no session, PID or
conversation field. Two concurrent pi sessions are indistinguishable,
and pi-vs-opencode is only accidentally distinguishable because the pi
extension never sets added_by (it sets identity for diaries only,
mempalace.ts:758). Corrects the §7.3.3 bullet that claimed
multi-harness attribution was already solved — the field is the right
home, but nothing populates it. Design rule stated: device + agent,
never session; provenance granularity equals token granularity.
- §6.2 — Host-pinning is coupled to the bind address
(enforce_host_pin = _http_is_loopback(host), :5367). The trap is the
RFC's own "bind loopback" reflex: behind a proxy that forwards a public
Host, a loopback bind 403s, while a non-loopback bind deliberately
relaxes the pin. The Origin check is never relaxed. This replaces the
warning I first wrote, which had it backwards.
- §9.3 — largely resolved: the last-chunk-only probe is deliberate
(batched upsert is all-or-nothing, :2586-2592). Only a crash mid-upsert
remains untested.
- §4.1 — fix shape for opencode's stale-config asymmetry: make the
mcp.mempalace subtree env-authoritative, with a fingerprint so
hand-edits still win. pi-devbox/entrypoint-user.sh:131-162 already has
the jq deep-merge pattern to port; no OPENCODE_CONFIG* layer exists
upstream, so the real file must be written. Now Phase 1.5.
Decisions (new §8.1): primary = synlig; TLS at Pangolin; single shared
token for now (so origin_device stays advisory); diaries replicated.
Work/personal is per-wing, not per-device — two primaries split along
machine lines is rejected, because pi-devbox/opencode-devbox are
simultaneously work and home projects and the device where work happened
cannot classify the project. MEMPALACE_REMOTE_URL stays scalar so
multi-store remains additive later (new §9.7 keeps the placement
question open).
Joakim Persson
7e51055c96