From a94eb7fdd0bc167e30c843e095b7b8e88c7243ba Mon Sep 17 00:00:00 2001 From: Joakim Persson Date: Fri, 14 Aug 2026 23:00:46 +0200 Subject: [PATCH] docs: native pi has no .env to flip, and EMB-7KJ4VR4G has no native pi Follow-up to ec436ed, closing the one item that commit left as "unverified". Verified on the EMB-7KJ4VR4G host: native pi is not installed at all -- no `pi` or `mempalace` on PATH, no ~/.config/pi/, no ~/.pi/agent/extensions/. That host's ~/.mempalace exists solely to back the devbox container through the bind mount (.devbox-owner holds 1000:1000). So the 2026-08-14 flip covers every pi on that machine and there is no split-brain to fix. The general hazard stays documented, because it is a per-machine question. Also documents how a native install *would* be flipped, since the obvious guess is wrong: pi loads no dotenv file and has no `env` block in settings.json, and the extension reads process.env only. The launching shell is the sole hook, so the vars must be exported from a shell rc (a GUI-launched pi may not read one), and ~/.config/pi/.env is not sourced by anything automatically. --- docs/phase-1-exposure-runbook.md | 12 +++++++++--- extensions/pi/README.md | 24 ++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/docs/phase-1-exposure-runbook.md b/docs/phase-1-exposure-runbook.md index 118695f..c1833bb 100644 --- a/docs/phase-1-exposure-runbook.md +++ b/docs/phase-1-exposure-runbook.md @@ -442,9 +442,15 @@ moment of the flip, so anything the agent filed into central since then will not publishes only on `v*` tags and the latest tag *is* the currently deployed image — built on 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 nobody has - checked. If the container is flipped and native pi is not, that machine writes into two different - palaces and its memory silently splits in two. Verify per machine with the §3.8(c) path check. +- **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. + 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. - **§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/extensions/pi/README.md b/extensions/pi/README.md index e62f2f4..e1d6ff9 100644 --- a/extensions/pi/README.md +++ b/extensions/pi/README.md @@ -162,6 +162,30 @@ chosen at load time: dead archive, not in the shared palace. Use the agent's own palace tools (which go over HTTP), and mine backfills **on the palace host**. + **Setting these for a *native* pi install — there is no `.env` to edit.** + Worth stating plainly, because the obvious guess is wrong: **pi loads no + dotenv file and has no `env` block in `settings.json`**, and this extension + reads `process.env` and nothing else (`createClient()` → + `process.env.MEMPALACE_REMOTE_URL`). A native install therefore inherits + whatever **the shell that launches `pi`** exports — that is the only hook. + So export them from your shell rc, or from a file it explicitly sources: + + ```sh + # ~/.zshrc (or ~/.bashrc) — if you keep secrets in ~/.config/pi/.env, + # nothing sources it for you; do it yourself: + set -a; [ -f ~/.config/pi/.env ] && . ~/.config/pi/.env; set +a + ``` + + Two traps. A pi launched from a **GUI** (Spotlight, dock, an editor's + terminal that spawns a non-login shell) does not necessarily read that rc, so + it can silently stay on the local palace. And exporting the variable in the + shell where you *edited* the rc does not affect an already-running pi — the + transport is chosen once at extension load. Confirm the result the same way + as a container flip: ask the agent for `mempalace_status` and check the + reported palace path is the **remote** host's, not your own + `$HOME/.mempalace/palace` — see + [`docs/phase-1-exposure-runbook.md`](../../docs/phase-1-exposure-runbook.md) §3.8. + Serve such an endpoint with `mempalace serve --host 172.17.0.1 --port 8765` (the `pi-devbox` / `opencode-devbox` repos ship a `docker-compose.mempalace.yml` for exactly this).