docs: record the primary's real lineage — EMB-X1JY06WJ -> EMB-7KJ4VR4G -> synlig

Three docs said the primary was "seeded from EMB-7KJ4VR4G's palace", which is
true but stops one hop short. That palace was itself carried over from
EMB-X1JY06WJ, the previous work computer, when it was replaced around
2026-07-06.

Evidence, read read-only out of the frozen archive on EMB-7KJ4VR4G: 76 drawers
carry `source_machine=EMB-X1JY06WJ` and they are the oldest in the store --
earliest filed_at 2026-05-04, two months before that machine's stack existed --
with no other source_machine value present. The remaining ~16k were filed
locally afterwards (15,189 in July, 1,073 in August). Last write is
2026-08-14T15:07:06, the seed instant.

Two consequences, recorded in rfc-001 S4.4:

- It was the *second* whole-palace file copy, not the first, and both were
  single-source clones. So the method has two successes behind it and still
  zero exercises of merge semantics -- S7.6 is *less* tested than "we've done
  this twice" would suggest, not more.
- The primary now holds records from a machine that no longer exists, and
  `source_machine` is the only thing marking them. Not noise; don't prune it.

Also corrects a94eb7f, which inferred the archive's origin from the
`.devbox-owner` marker. That marker only records that the devbox adopted the
directory and says nothing about provenance -- the archive predates the stack.
And native pi on EMB-7KJ4VR4G is "not installed *yet*", a deferred hazard rather
than a closed one: a native install there would resolve its palace to
~/.mempalace, i.e. the frozen archive, and split that machine's memory from
central silently. Flip at install time.

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).

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 |
 | --- | --- | --- |

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.
 >