diff --git a/CHANGELOG.md b/CHANGELOG.md
index 354d46d..efdb3a3 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -89,10 +89,15 @@ provenance), `limit`/`offset` on `kg_timeline`, `last_modified` on drawers.
 `Dockerfile.base` sequencing comment had claimed for two releases (corrected in
 this commit). Client and server are level today; this image reintroduces skew
 until synlig runs `uv tool upgrade mempalace` and restarts the unit. That is the
-step that lights up the server-side changes above. Skew-relevant meanwhile: 3.10.0
-CLI writes follow the daemon write-routing policy (`direct`/`prefer`/`require`),
-so the feeder (`mempalace-pi-session`, 3.10.0 client) against the 3.9.0 hub is
-the one path to exercise on the built image before tagging — see *Still open*.
+step that lights up the server-side changes above. The skew meanwhile is narrower
+than the release commit's message claimed: the pi extension speaks HTTP to the hub
+(no local `mempalace-mcp` is spawned), and the feeder in remote mode stages
+locally in python, rsyncs, and calls the hub's own `mempalace_mine` tool.
+Measured with a PATH shim in front of `mempalace`: a 47-session
+`mempalace-pi-session --dry-run` from this container made **zero** local CLI calls
+(the shim's positive control logged one). So 3.10.0's new CLI write-routing
+policy never runs against the hub from this image; in remote mode the client pin
+touches first-run `mempalace init` and the on-disk layout, nothing else.
 
 ### pi-atelier v0.10.1 → v0.10.3 (`734258b` → `ed3837b`)
 
@@ -134,12 +139,13 @@ a stop that #83 makes moot.
 
 ### Still open
 
-- **Feeder against the 3.9.0 hub** — run `mempalace-pi-session` from the built
-  v1.9.4 image against synlig (dry-run first) before tagging. The palace-path
-  adaptation was measured with the wheel, not the image; the recreate acceptance
-  on the first device should confirm `~/.mempalace/palace/chroma.sqlite3` still
-  passes in `recreate-sanity-check.sh` and that `~/.config/mempalace` does not
-  appear.
+- **First-boot acceptance on the built image** — the palace-path adaptation was
+  measured with the wheel, not the image. Start a throwaway container from the
+  published v1.9.4 with an *empty* `~/.mempalace` volume and confirm the
+  entrypoint's `mempalace init` lands `config.json` there, that
+  `~/.config/mempalace` does not appear, and that `MEMPALACE_CONFIG_DIR` is in
+  the container environment. On a real device the recreate checklist's
+  `recreate-sanity-check.sh` should keep passing `~/.mempalace/palace/chroma.sqlite3`.
 - **synlig upgrade to 3.10.0** after v1.9.4 is accepted on one device:
   `uv tool upgrade mempalace`, restart `mempalace-serve.service`, verify one
   search and one `event_list`.
diff --git a/Dockerfile.base b/Dockerfile.base
index bcefed0..e757bc9 100644
--- a/Dockerfile.base
+++ b/Dockerfile.base
@@ -590,10 +590,15 @@ ARG INSTALL_MEMPALACE=true
 # `get_collection()` refuses unknown collection names (library callers only).
 # MCP tool-schema review, as always: no tool removed or renamed; additive
 # fields on search results (filed_at / content_date provenance), `limit` /
-# `offset` on kg_timeline, `last_modified` on drawers. Skew-relevant while
-# synlig stays on 3.9.0: CLI writes now follow the daemon write-routing policy
-# (direct / prefer / require) — the feeder against a 3.9.0 hub is the one
-# thing to exercise before tagging.
+# `offset` on kg_timeline, `last_modified` on drawers. Skew while synlig stays
+# on 3.9.0 is narrower than it looks: the pi extension speaks HTTP to the hub
+# (no local mempalace-mcp is spawned), and the feeder in remote mode stages
+# locally in python, rsyncs, and calls the hub's own `mempalace_mine` tool.
+# Measured 2026-09-22 with a PATH shim in front of `mempalace`: a 47-session
+# `mempalace-pi-session --dry-run` made ZERO local CLI calls (the shim's
+# positive control logged one). So 3.10.0's new CLI write-routing policy never
+# runs against the hub from this image; the client pin touches first-run
+# `mempalace init` and the on-disk layout, nothing else in remote mode.
 ARG MEMPALACE_VERSION=3.10.0
 # Recorded as a label HERE, not in Dockerfile.variant, for three reasons: the
 # value lives next to the ARG that defines it (a second copy in the variant