diff --git a/docs/phase-1-exposure-runbook.md b/docs/phase-1-exposure-runbook.md index c1833bb..cf9aff8 100644 --- a/docs/phase-1-exposure-runbook.md +++ b/docs/phase-1-exposure-runbook.md @@ -7,8 +7,10 @@ items 2 and 5. > **Status 2026-08-14 — DONE. Exposed, seeded, and one client flipped.** > `https://mempalace.jordbo.se/mcp` has been serving since 2026-08-12 (§3.3–§3.6 are all ✅ below). -> The palace was seeded 2026-08-14 15:07 from EMB-7KJ4VR4G (14,777 → 14,803 drawers), and that -> machine's pi-devbox container is flipped and **verified end-to-end — see §3.8**, which is the +> The palace was seeded 2026-08-14 15:07 from EMB-7KJ4VR4G (14,777 → 14,803 drawers) — whose palace was +> itself carried over from the previous work computer **EMB-X1JY06WJ** around 2026-07-06, so the +> primary's lineage is EMB-X1JY06WJ → EMB-7KJ4VR4G → synlig by two file-level copies (rfc-001 §4.4 +> Deviation) — and that machine's pi-devbox container is flipped and **verified end-to-end — see §3.8**, which is the > verification procedure that did not exist when the first flip was performed. > Still outstanding: the transcript feeder is **inert on every deployed image** (§3.7), and §7.6 is > still a hard blocker for the *second* machine to join (§4). @@ -443,14 +445,19 @@ moment of the flip, so anything the agent filed into central since then will not pi-devbox ≥ `7c00dd6` **and** mempalace-toolkit ≥ `29e660e`. Both are required: the first restores the container-start catch-up, the second is where extension-side feeding was implemented at all. - **Whether *native* pi on a flipped machine was also flipped** is a per-machine question. Answered for - **EMB-7KJ4VR4G (2026-08-14): native pi is not installed there at all** — no `pi`/`mempalace` on the - host PATH, no `~/.config/pi/`, no `~/.pi/agent/extensions/`; that host's `~/.mempalace` exists only to - back the devbox container through a bind mount. So that machine needs nothing further. **Still open - for every other host**: a machine running native pi beside a flipped container writes into two - different palaces and splits its memory silently. Verify with the §3.8(c) path check, per machine. + **EMB-7KJ4VR4G (2026-08-14): native pi is not installed there *yet*** — no `pi`/`mempalace` on the host + PATH, no `~/.config/pi/`, no `~/.pi/agent/extensions/`; it is a replacement machine that has not had + native pi set up. So nothing further needs flipping there **today** — but this is a deferred hazard, + not a closed one: a native install resolves its palace to `~/.mempalace`, which on that host is the + bind-mounted **frozen archive**, so it would start writing there and split the machine's memory from + central silently. **Flip native pi at install time, not after.** **Still open for every other host** + running native pi beside a flipped container. Verify with the §3.8(c) path check, per machine. Note native pi has **no `.env` to edit** — pi loads no dotenv file and has no `env` block in `settings.json`, so the variables must come from the shell that launches it; recipe in - [`extensions/pi/README.md`](../extensions/pi/README.md#transport-local-vs-external) § Transport. + [`extensions/pi/README.md`](../extensions/pi/README.md#transport-local-vs-external) § Transport. On + EMB-7KJ4VR4G specifically, that tree's `config.json` also points at + `palace_path=/home/developer/.mempalace/palace` — a *container* path that does not exist on macOS — so + a native install must not inherit it unexamined. - **§7.2**: never run `mempalace sync` against the shared palace. Doubly true now that the pi/opencode feeders stage *inside* the palace root, which puts staged sources in scope for a sync of the palace dir. - **nyvaken's public FQDN and the web hotel's CNAME rules** — unverified (§3.4). diff --git a/docs/rfc-001-global-palace.md b/docs/rfc-001-global-palace.md index 52e5441..494ade2 100644 --- a/docs/rfc-001-global-palace.md +++ b/docs/rfc-001-global-palace.md @@ -7,7 +7,9 @@ | **Applies to** | mempalace 3.6.0, mempalace-toolkit @ `96699f2`, pi-devbox ≥ v1.3.0 | | **Decision** | Phases 0–2 + 4 in scope. **Phase 3 (full pull replication) explicitly deferred** — "a laptop that can reach its own stuff plus whatever it can reach" is good enough. **Centralization is strictly opt-in — solitary devbox operation remains the default and must not change (§1.1).** | | **Recon update** | **2026-08-09 — §9 Q1 and Q6 are RESOLVED, both in the permissive direction** (opencode supports remote MCP; opencode-devbox already templates the mempalace entry). Neither is a blocker. See those entries for evidence; §2, §4.1 and R5 were corrected accordingly. | -| **Rollout update** | **2026-08-14 — Phase 1 is live.** Primary serving at `https://mempalace.jordbo.se/mcp` since 2026-08-12 (synlig, `mempalace-serve.service` under `systemctl --user`, palace `/home/ecsjper/.mempalace/palace`); **seeded 2026-08-14 15:07** from EMB-7KJ4VR4G's palace — 14,777 drawers / 9 wings / 16,337 embeddings / KG 46 entities, 34 triples (14,803 drawers by 17:00); **first client flipped and verified end-to-end** the same afternoon. ⚠️ Two things not to misread: the seed was a **file-level copy of one palace**, *not* the §4.4 MCP replay (see the Deviation note in §4.4), and it therefore **sidestepped §7.6 rather than resolving it — §7.6 remains a hard blocker for the *second* joiner (§8 Phase 0).** §2's and §4.1's predictions about the pi client were confirmed in production; §4.4's count-based verification advice was **wrong** and has been corrected. | +| **Rollout update** | **2026-08-14 — Phase 1 is live.** Primary serving at `https://mempalace.jordbo.se/mcp` since 2026-08-12 (synlig, `mempalace-serve.service` under `systemctl --user`, palace `/home/ecsjper/.mempalace/palace`); **seeded 2026-08-14 15:07** from EMB-7KJ4VR4G's palace — which is itself a carry-over copy from the +operator's previous work computer **EMB-X1JY06WJ** (lineage and evidence in the §4.4 Deviation note) — +14,777 drawers / 9 wings / 16,337 embeddings / KG 46 entities, 34 triples (14,803 drawers by 17:00); **first client flipped and verified end-to-end** the same afternoon. ⚠️ Two things not to misread: the seed was a **file-level copy of one palace**, *not* the §4.4 MCP replay (see the Deviation note in §4.4), and it therefore **sidestepped §7.6 rather than resolving it — §7.6 remains a hard blocker for the *second* joiner (§8 Phase 0).** §2's and §4.1's predictions about the pi client were confirmed in production; §4.4's count-based verification advice was **wrong** and has been corrected. | **Read this first if you are asked to "centralize MemPalace" / "sync palaces between machines".** Most of the hard-won facts below are non-obvious and two of them are actively destructive if you guess wrong @@ -353,6 +355,22 @@ history**, and the only real question per record type is *what dedupes it*. > **`stat -c%s`, not `du`** (APFS and ext4 disagree on block accounting, so `du` shows a spurious delta). > Quiesce the writer first — the source palace's own MCP server was live throughout, which is how a write > landed on the far side of the snapshot boundary and produced the false alarm described below. +> +> **Lineage — this was the *second* file-level copy, not the first (established 2026-08-15).** The +> "chosen palace" on EMB-7KJ4VR4G was itself carried over from **EMB-X1JY06WJ**, the operator's previous +> work computer, around 2026-07-06 when that machine was replaced. Evidence in the archive: **76 drawers +> tagged `source_machine=EMB-X1JY06WJ`**, and they are the oldest in it — earliest `filed_at` +> 2026-05-04, two months before the EMB-7KJ4VR4G stack existed — with no other `source_machine` value +> present; the remaining ~16k were filed locally afterwards (15,189 in July, 1,073 in August). So the +> primary's full provenance is **EMB-X1JY06WJ → EMB-7KJ4VR4G → synlig, by two successive whole-palace +> file copies and zero merges.** +> +> Two consequences worth stating, because this is easy to read as reassuring. First, it **strengthens** +> condition 3 rather than weakening it: the method now has two successes behind it, both of them +> single-source clones, and still not one exercise of merge semantics — so §7.6 is *less* tested than a +> "we've done this twice" reading would suggest. Second, the primary's history contains records from a +> machine that no longer exists, so `source_machine` is the only thing distinguishing them; do not treat +> it as noise when pruning or re-mining. | Record type | Dedupe on replay | Client work needed | | --- | --- | --- | diff --git a/docs/synlig-primary-runbook.md b/docs/synlig-primary-runbook.md index 5a00bba..4a77c7e 100644 --- a/docs/synlig-primary-runbook.md +++ b/docs/synlig-primary-runbook.md @@ -5,7 +5,8 @@ on the primary, with verified evidence, so the next session (or the next machine > **Status 2026-08-14 17:00 — SUPERSEDED IN PART. The primary is live, exposed, and seeded.** > Serving since 2026-08-12 at `https://mempalace.jordbo.se/mcp`. Seeded 2026-08-14 15:07 from -> EMB-7KJ4VR4G's palace — 14,777 drawers / 9 wings / 16,337 embeddings / KG 46 entities, 34 triples, +> EMB-7KJ4VR4G's palace (itself a carry-over from the previous work computer EMB-X1JY06WJ — rfc-001 §4.4) +> — 14,777 drawers / 9 wings / 16,337 embeddings / KG 46 entities, 34 triples, > now 14,803 drawers. One client (EMB-7KJ4VR4G's pi-devbox container) is flipped and verified > end-to-end. Both Phase 0 blockers below are cleared. >