fix(ci): skip the BuildKit check whose warning embedded this Dockerfile in CI output

v1.10.1 (run 707) failed with ZERO failing steps: every step Success, `smoke` printing "101 passed, 0 failed", `smoke-studio` "104 passed, 0 failed", both jobs red. The clipboard fix from f3b3748 worked exactly as predicted; this is a second, independent defect that run 704 had masked. CHAIN, measured end to end rather than reasoned: `ARG BASE_IMAGE` has no default on purpose (the two-phase build always supplies it), which trips BuildKit's InvalidDefaultArgInFrom check. buildx attaches that warning's source context to the build metadata as buildx.build.warnings[].sourceInfo.data — the ENTIRE Dockerfile, base64, on ONE line. docker/build-push-action writes that metadata to $GITHUB_OUTPUT as a `name<<ghadelimiter_<uuid>` heredoc. Gitea's act_runner truncates any single line at exactly 65536 chars, so the closing delimiter was cut off: invalid format delimiter 'ghadelimiter_...' not found before end of file and the runner failed the job while attributing it to no step at all. v1.9.4 run 695 SUCCESS: longest metadata line 56355, 0 delimiter errors v1.10.0 run 704 failed : longest metadata line 65536, 1 delimiter error v1.10.1 run 707 failed : longest metadata line 65536, 1 delimiter error 65536 = 2^16: cut AT the cap, not merely long. Independent route via file size rather than log parsing: 42251 B at v1.9.4 (base64 56335, matching the log) vs 50034 B now (base64 66712, truncated). The cap corresponds to a 49152 B Dockerfile, so this cycle's comment growth crossed it by 882 B. Located by asking which top-level metadata key CONTAINS the base64, instead of assuming: it is buildx.build.warnings -> sourceInfo -> data in BOTH runs. THIS IS THE SECOND FIX FOR THIS BUG. The first, `provenance: false` on the two smoke build steps, was committed as 784fad7 and is REVERTED here: a real buildx on another host showed provenance metadata present in both modes with a longest string of 71 chars, i.e. the base64 was never in provenance. Shipping it would have left the release broken a third time while looking like a fix. Also rejected, each measured: floating action tags moving (act action-bundle hashes byte-identical between runs 695 and 707, all four) and the build-check annotation text changing (byte-identical). FIX: `# check=skip=InvalidDefaultArgInFrom` as the FIRST line of Dockerfile.variant — BuildKit parses `# check=` only before any other line, so placement is load-bearing. No honest default exists for BASE_IMAGE: `scratch` would satisfy the linter while being a lie, and would convert today's instant "invalid reference format" into a failure deep in the build. Verified against the actual edited file with `docker buildx build --check`: "Check complete, no warnings found." Zero warnings means no sourceInfo, so the longest metadata line drops 65536 -> ~1936 and the file's SIZE stops gating CI. GUARD: scripts/check-dockerfile-directives.sh, wired into BOTH lint.yml and docker-publish.yml's lint-gate, because a check that gates only `push` lets a tag regress — the adoption slip that let doc-drift land 27 h after the v1.9.3 tag. It also fails if ARG BASE_IMAGE gains a default, so the directive cannot rot into guarding a check that can no longer fire. Truth table, exit codes: present 0, removed 1, demoted to line 2 → 1, ARG defaulted 1, file missing 2 (a gate that cannot run must not pass). Release renamed v1.10.1 -> v1.10.2 with both failed tags left standing as tombstones. Docs swept again (README "since" marker, Dockerfile decision comments) because CI reads them from the TAG. Gates: doc-drift 23 OK / 0 DRIFT; base-hash, workflow-shell, skill-floor, lint-shell (17 files now), dockerfile-directives all rc=0.
fix(ci): provenance: false on the smoke builds — base64(Dockerfile) crossed 64 KiB
2026-10-02 10:58:03 +02:00 · 2026-10-02 10:50:16 +02:00 · 2026-10-02 10:36:21 +02:00 · 2026-10-02 10:27:25 +02:00 · 2026-10-02 09:00:51 +02:00 · 2026-10-02 08:20:01 +02:00
13 changed files with 1256 additions and 31 deletions
@@ -108,7 +108,14 @@ jobs:
        id: compute
        run: |
          # Hash inputs that determine the base image's contents.
-          # Order is fixed via `find -print0 | sort -z` for reproducibility.
+          # Order is fixed via `find -print0 | LC_ALL=C sort -z`. The LC_ALL=C is
+          # load-bearing: sort collates per locale, and a dictionary locale
+          # (sv_SE/en_US.UTF-8) orders rootfs differently from byte order, giving
+          # a different hash for identical content (measured 2026-09-22:
+          # base-f40c4b7b103d under C/C.UTF-8 vs base-d8df62216a81 under
+          # sv_SE.UTF-8). The runner ships LANG=C.UTF-8 today, so this pin
+          # changes nothing now; it stops the hash depending on that accident.
+          # Predicting base_tag locally MUST use the same prefix on this sort.
          # Junk filters: __pycache__/*.pyc and macOS metadata are gitignored
          # locally but still picked up by `find rootfs -type f` on a clean CI
          # checkout. Exclude them defensively.
@@ -120,7 +127,7 @@ jobs:
                ! -name '*.pyc' \
                ! -name '.DS_Store' \
                ! -name '._*' \
-                -print0 2>/dev/null | sort -z | xargs -0 cat 2>/dev/null
+                -print0 2>/dev/null | LC_ALL=C sort -z | xargs -0 cat 2>/dev/null
              cat entrypoint.sh entrypoint-user.sh
              # mempalace-toolkit is cloned in Dockerfile.base at a ref CI
              # resolves to a SHA; fold it in so base_tag changes when the
@@ -174,6 +181,29 @@ jobs:
  #
  # ~40 s, ahead of everything expensive, and it runs scripts/lint-shell.sh --
  # the same file lint.yml calls, not a second copy that drifts.
+  #
+  # scripts/check-doc-drift.sh is here for the same reason and closes the same
+  # gap -- and for it the gap is strictly worse. Shellcheck judges the TREE:
+  # green on main is still green at the tag, because the bytes did not move.
+  # Check 9 judges the tree against UPSTREAM NOW, and the floating refs it
+  # watches (PI_OBSMEM_REF=master and friends, which resolve-versions below turns
+  # into SHAs) move with no commit in this repo at all -- so a green reading on
+  # main carries no information about tag time, and that window is exactly where
+  # releases live. Worked example: pi-observational-memory moved cba0334 ->
+  # e7d77dc the day AFTER v1.9.3 was tagged. Nothing went red; it surfaced only
+  # because someone ran the gate by hand. Without this step a tag can publish a
+  # component that no CHANGELOG entry names, and the floating ref means no other
+  # file in the repo would record it either.
+  #
+  # Adds ~8 s. No token and no built image: it takes the last published vX.Y.Z
+  # from the Hub tags API, that release's baked labels from the anonymous
+  # registry API, and `git ls-remote`s each upstream -- so a plain checkout is
+  # enough, with no tags or history to fetch. Offline it SKIPs loudly and
+  # counted rather than passing, so an outage degrades it to a visible skip
+  # instead of a false green. Residual, accepted: it resolves the refs seconds
+  # before resolve-versions resolves them again, so an upstream push landing
+  # inside that window still slips through -- and check 9 on the NEXT release
+  # would then name it.
  lint-gate:
    runs-on: ubuntu-latest
    container:
@@ -189,6 +219,16 @@ jobs:
      - name: "Shellcheck + syntax-check repository scripts (severity: error)"
        run: bash scripts/lint-shell.sh

+      - name: Components the next build would bake differently are named in the CHANGELOG
+        run: bash scripts/check-doc-drift.sh
+
+      # Runs HERE as well as in lint.yml deliberately. A guard that gates only
+      # `push` lets a tag regress — the adoption slip that let doc-drift land
+      # 27 h after the v1.9.3 tag. This one protects the tag build from the
+      # zero-failing-step failure mode that killed v1.10.0 and v1.10.1.
+      - name: Dockerfile.variant still opens with its BuildKit check directive
+        run: bash scripts/check-dockerfile-directives.sh Dockerfile.variant
+
  resolve-versions:
    # Gated: a defective tree must not reach a 46-minute base build.
    needs: [lint-gate]
@@ -90,6 +90,12 @@ jobs:
        # actionlint so the more precise diagnostic surfaces first.
        run: bash scripts/check-workflow-shell.sh .gitea/workflows

+      - name: Dockerfile.variant still opens with its BuildKit check directive
+        # See scripts/check-dockerfile-directives.sh: without that first line the
+        # smoke jobs fail with `invalid format delimiter 'ghadelimiter_...'` and
+        # NO failing step. Also wired into docker-publish.yml's lint-gate.
+        run: bash scripts/check-dockerfile-directives.sh Dockerfile.variant
+
      - name: Install actionlint (pinned)
        env:
          ACTIONLINT_VERSION: 1.7.12
@@ -11,6 +11,617 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).

 ---

+## v1.10.2 — 2026-10-02
+
+**v1.10.0 and v1.10.1 were both tagged and never published.** Neither failure
+was in the image — both were in the test and CI harness, and each hid the other:
+
+| tag | run | symptom | cause |
+|---|---|---|---|
+| v1.10.0 | 704 | `smoke` 100 passed / **1 failed**; `smoke-studio` 103 / **1** | a smoke assertion required a pi dependency upstream had deleted |
+| v1.10.1 | 707 | `smoke` **101 passed / 0 failed**, `smoke-studio` **104 / 0**, and both jobs red anyway with **no failing step** | base64(`Dockerfile.variant`) in buildx's warning metadata crossed act_runner's 64 KiB line cap |
+
+In both runs every publish job skipped, so no image, no `latest`, and no Hub
+description was ever written — the gates did their job twice. **Everything
+described under v1.10.0 below ships here**; that section remains the content
+record and nothing in it changed.
+
+The tag number moves each time rather than being re-pointed, because CI had
+already consumed the previous one. A version that failed its build should stay
+failed and readable, not be quietly overwritten with different bytes.
+
+### Fixed
+
+- **A job can fail with every step green, a smoke suite reporting `0 failed`,
+  and no failing step anywhere — and it cost two tags** — `Dockerfile.variant`
+  now opens with `# check=skip=InvalidDefaultArgInFrom`, and
+  `scripts/check-dockerfile-directives.sh` keeps it there.
+
+  The chain, measured rather than reasoned: `ARG BASE_IMAGE` deliberately has no
+  default (the two-phase build always supplies it), which trips BuildKit's
+  `InvalidDefaultArgInFrom` check. buildx attaches that warning's source context
+  to the build metadata as `buildx.build.warnings[].sourceInfo.data` — **the
+  entire Dockerfile, base64, on one line**. `docker/build-push-action` writes
+  that metadata to `$GITHUB_OUTPUT` as a `name<<ghadelimiter_<uuid>` heredoc,
+  and Gitea's act_runner truncates any single line at exactly 65536 chars. Once
+  base64 of the file passed 64 KiB the closing delimiter was cut off and the
+  runner reported `invalid format delimiter 'ghadelimiter_...' not found before
+  end of file`, then failed the job while attributing it to nothing.
+
+  Numbers: the file was 42251 B at v1.9.4 → base64 56355 chars, fine; it is
+  50034 B now → base64 66712, truncated to exactly 65536 (2^16, i.e. cut *at*
+  the cap, not merely long). The cap corresponds to a 49152 B Dockerfile, so
+  this release's comment growth — much of it comments added while documenting
+  the v1.10.0 round — crossed it by **882 bytes**. Confirmed two ways: by
+  parsing the metadata out of both job logs, and independently by arithmetic on
+  the file size at each tag. Verified fixed by running `docker buildx build
+  --check` against the actual edited file: *"Check complete, no warnings
+  found."* With zero warnings there is no `sourceInfo`, so the longest metadata
+  line drops from 65536 to ~1936 chars and the Dockerfile's **size stops being
+  coupled to whether CI passes**.
+
+  Hypotheses measured and rejected on the way, each of which would have produced
+  a wrong fix: floating action tags moving (the act action-bundle hashes are
+  byte-identical between the green v1.9.4 run and the red one — all four); the
+  build-check annotation text changing (byte-identical); and `provenance: false`,
+  which was written, tested against a real buildx, and **reverted** when the
+  metadata turned out to carry the base64 under `buildx.build.warnings`, not
+  under provenance. The published images are unaffected either way: they are
+  built by raw `docker buildx build --push`, which never writes
+  `$GITHUB_OUTPUT` metadata.
+
+  The new guard runs in **both** `lint.yml` and the publish workflow's
+  `lint-gate`, because a check that gates only `push` lets a tag regress — the
+  same adoption slip that let doc-drift land 27 h after the v1.9.3 tag. It
+  also fails if `ARG BASE_IMAGE` ever gains a default, so the skip directive
+  cannot rot into pointing at a check that can no longer fire. Truth table:
+  directive present → rc=0; removed → rc=1; demoted to line 2 → rc=1; ARG given
+  a default → rc=1; file missing → rc=2 (cannot-run must not pass).
+
+- **The smoke suite asserted a pi dependency that upstream deleted, and it cost
+  this release its first tag build** — `scripts/smoke-test.sh` required
+  `@mariozechner/clipboard` to be installed and `require()`-able at every install
+  site. pi **0.86.0** (`#9163`) *"Replaced the external native clipboard
+  dependency with bundled asynchronous macOS, Windows, and X11 helpers while
+  preserving platform command and OSC 52 fallbacks"*. Measured in the published
+  tarballs: pi `0.85.1` declares `@mariozechner/clipboard@0.3.9`; `0.87.1` and
+  `1.0.0` declare no `@mariozechner/*` at all. So on a correct v1.10.0 image the
+  package is legitimately absent, the assertion's `if [ -z "$sites" ]; then exit
+  1` fired, and run 704 ended **100 passed / 1 failed** on `smoke` and **103
+  passed / 1 failed** on `smoke-studio` — same single assertion, every
+  studio-specific check green. `build-variant`, `build-variant-studio`,
+  `promote-base-latest` and `update-description` were all skipped, so **nothing
+  was published**: the gate behaved exactly as designed, against a stale
+  expectation rather than a real defect.
+
+  The fix does not delete the guard, because the guard was right: "fail when the
+  family is absent" is what stops `prune_foreign_natives()` from silently
+  deleting the binding instead of the surplus platform copies. It now **derives
+  its expectation from what the image's pi actually declares** — if pi declares
+  the dependency an install must exist and load; if pi does not, no install may
+  linger. That re-arms by itself should a future pi re-add it, and it still
+  catches an orphaned install. Verified as a four-quadrant truth table with the
+  command string extracted verbatim from the file and run through `sh -c` the way
+  `run()` invokes it: declared+present → rc=0, declared+absent → rc=1,
+  undeclared+absent → rc=0, undeclared+present → rc=1.
+
+  Worth stating plainly, since it is the whole value of the round: pi 1.0.0,
+  pi-atelier v0.13.0 and pi-studio v0.9.61 passed **103 of 104** assertions on a
+  pi MAJOR bump. The one red was the suite describing pi 0.85.1's dependency
+  graph, not the image.
+
+---
+
+## v1.10.0 — 2026-10-02 (tagged, never published — content shipped as v1.10.2)
+
+> Tagged 2026-10-02 at commit `12f99c4`. Its build (run 704) went red on the
+> stale clipboard assertion described under v1.10.1, so `build-variant`,
+> `build-variant-studio`, `promote-base-latest` and `update-description` all
+> skipped and nothing reached the Hub. No image carries this tag. The content
+> below is accurate and shipped as **v1.10.2**. v1.10.1 (commit `c2c42c3`,
+> run 707) was the first attempt at republishing it and died on the separate
+> act_runner line-cap bug described under v1.10.2.
+
+Three small fixes found by the v1.9.4 first-boot acceptance and the CI base
+hash prediction, plus one boot-time wiring fix that stops a recurring `git push`
+failure inside the container, four small base packages, **pi 1.0.0**, and
+**pi-atelier v0.13.0**. `entrypoint-user.sh` and `Dockerfile.base` are both in
+the base hash, so this tag rebuilds the base (~64 min) regardless of what else
+it carries.
+
+A **minor**, not a patch: this was prepared as `v1.9.5` under the "patch — pi
+version bumps" rule, but it now carries a pi MAJOR, a three-minor pi-atelier
+jump, four new base packages and a new mailbox feature. The release carrying a
+1.0.0 should not be the one numbered as a patch.
+
+### Components that move with the next build
+
+| Component | Baked in v1.9.4 | This release | Why |
+|---|---|---|---|
+| pi | `0.85.1` | **`1.0.0`** | the hold is over: obsmem's `finishTurn` migration shipped, and 1.0.0 ships no breaking change that reaches us (below) |
+| pi-obsmem | `e7d77dc` (`master`) | **`731c3d4`** (pinned SHA) | PR #83 is merged but unreleased; pinned so a rebuild is reproducible (below) |
+| pi-atelier | `v0.10.3` (`ed3837b`) | **`v0.13.0`** (`34d26f1`) | closes the gap v1.9.5 flagged as the pi bump's residual risk; its own breaking change reaches nothing of ours (below) |
+| pi-extensions | `25c1265` | **`143a214`** | `install.sh`: skip hook activation on a clone this user cannot configure (below) |
+| mempalace-toolkit | `2167a1b` | **`975ab92`** | mailbox: an ask can declare `dormant_unless`, so deliberately-waiting work stops being announced (below) |
+| pi-studio | `v0.9.60` (`e04fc7a`) | **`v0.9.61`** (`641aa32`) | upstream release, adopted as-is; `-studio` variant only |
+
+### Changed
+
+- **pi `0.85.1` → `1.0.0`, and pi-obsmem off `master` onto the pinned SHA
+  `731c3d4` — in one commit, because neither is safe alone.** v1.9.4 held pi at
+  0.85.1 because 0.87.0 *removed* `shouldStopAfterTurn`, which
+  pi-observational-memory 3.1.4 still used; its `peerDependencies` are `*`, so
+  nothing would refuse at install time and the breakage would be silent at
+  runtime (turn caps ignored, workers losing their specialised prompts). PR #83
+  merged 2026-09-23 and fixes exactly that. Re-measured 2026-10-01 across
+  `src/agents/{observer,reflector,dropper}/agent.ts`, using the same counting
+  method as the v1.9.4 audit so the two are comparable:
+
+  | ref | `shouldStopAfterTurn` | `finishTurn` | `systemPrompt` |
+  |---|---|---|---|
+  | `e7d77dc` (3.1.4, baked in v1.9.4) | 3 | 0 | 3 |
+  | `731c3d4` (pinned here) | 0 | 3 | 0 |
+
+  All three workers migrated, and the 0.86.0 `AgentContext.systemPrompt` reads
+  are gone too. The direction of the coupling is worth stating because it is not
+  symmetric: 3.1.4 + 0.87.1 ignores turn caps, and `731c3d4` + 0.85.1 breaks the
+  workers outright, since `finishTurn` does not exist before 0.87.0. They move
+  together or not at all.
+
+  **Pinned to a SHA rather than waiting for a tag**, departing from the v1.9.4
+  instruction to bump "once #83 has shipped in a release". The newest obsmem tag
+  is still 3.1.4, cut 2026-09-20 — *before* the merge — and upstream tags slowly
+  while moving `master` often: `e7d77dc` → `1529e14` → `731c3d4` in the nine days
+  to 2026-10-01. Waiting for a tag means holding pi indefinitely. The full
+  40-char form is deliberate: `check-doc-drift.sh` recognises a literal SHA only
+  via a 40-char match, so a short pin would fall through to its branch-or-tag
+  lookup and quietly downgrade that component's drift check to a SKIP.
+
+  **0.99.x was skipped and 1.0.0 was ADOPTED, because the evidence arrived.**
+  v1.9.5 was prepared holding at 0.87.1 on the grounds that obsmem's only
+  compatibility work names Pi 0.87 (`2b1dc1c`) and a repo-wide issue/PR search
+  for `0.99` or `1.0` returns zero matches. That reasoning had a hole worth
+  naming: *no issue mentions 1.0* is an absence of a statement, not a
+  measurement. So 1.0.0 was measured directly, against the published npm
+  tarballs for 0.87.1 and 1.0.0 unpacked side by side (2026-10-02):
+
+  - **1.0.0 has no `### Breaking Changes` section at all.** The changelog's
+    breaking sections belong to 0.87.0, 0.86.0, 0.84.3, 0.84.0, 0.83.0, 0.80.8,
+    0.80.7 and 0.75.0 — none to anything between 0.88 and 1.0.0. The major is a
+    milestone (fullscreen default, leaner codemode), not an API break. The last
+    break that touched us was 0.87.0's `shouldStopAfterTurn` removal, absorbed
+    above.
+  - **`finishTurn` is still in 1.0.0's dist**, so the pinned obsmem SHA keeps
+    the API it migrated to.
+  - **All 8 `pi.*` APIs our extensions call exist in 1.0.0's dist** —
+    `registerTool`, `registerCommand`, `registerFlag`, `getFlag`, `on`, `exec`,
+    `sendMessage`, `sendUserMessage`, extracted from `mempalace.ts`, the
+    pi-extensions tree and obsmem's `src/`.
+  - `engines.node` is `>=22.19.0` on both; the image ships 24.x.
+
+  **The 0.99.2 change that looked fatal and is not.** From 0.99.2 the default
+  MCP `exposure` is `codemode`, meaning such tools are "neither declared to the
+  model nor listed in the codemode description" and must be found with
+  `searchTools()`. That would gut the MemPalace protocol — every skill says to
+  call `mempalace_search` — if MemPalace were a builtin-MCP server. It is not:
+  `mempalace.ts` and `mcp-loader.ts` each run their own MCP client and surface
+  tools through `pi.registerTool()`, which is why they are named
+  `mempalace_search` rather than `mcp__mempalace__search`. Confirmed on a second
+  route: `settings.json` has neither an `mcpServers` block (builtin,
+  exposure-governed) nor an `mcp` block. Extension-registered tools are declared
+  like built-ins, so `exposure` cannot reach them. Noted here because the change
+  is filed under "Changed", not "Breaking", and would be easy to meet the hard
+  way.
+
+  **What is NOT proven.** Grepping dist shows the symbols survive, not that
+  their signatures are unchanged — necessary, not sufficient. 1.0.0 is four days
+  old (published 2026-10-01T19:15Z) and neither obsmem nor atelier has a commit
+  naming it. Acceptance must prove the obsmem workers **cap turns** (peerDeps
+  are `*`, so a mismatch is silent at runtime) and that the atelier sidebar
+  **paints**.
+
+  **User-visible behaviour change: the TUI is now fullscreen.** 1.0.0 changed the
+  default `tuiMode` to `"fullscreen"`, which draws into the terminal's alternate
+  screen — so the transcript no longer accumulates in the terminal's (or tmux's)
+  native scrollback. **Upstream's default is adopted deliberately**, not
+  inherited by omission: no `tuiMode` is baked, so the image follows pi rather
+  than pinning the fleet to either mode. The way back is documented in README
+  → *Terminal UI mode*: `"tuiMode": "regular"` in `~/.pi/agent/settings.json`
+  for every session, `pi --tui-mode regular` for one, or the same key in a
+  project's `.pi/settings.json` for one project. That section also covers the
+  four related `fullscreen*` settings — including `fullscreenWheelScrollLines`,
+  whose `"auto"` behaviour differs over SSH, which is how this container is
+  normally driven — and records that pi-atelier's sidebar works in both modes,
+  so reverting costs nothing.
+
+- **pi-atelier `v0.10.3` (`ed3837b`) → `v0.13.0` (`34d26f1`)** — closes the
+  two-minor gap v1.9.5 named as the pi bump's residual risk. `peerDependencies`
+  are unchanged at pi `>=0.84.0` across v0.10.3, v0.12.1 and v0.13.0 — still a
+  floor, so still not evidence of anything; 1.0.0 satisfies it either way. What
+  was actually checked:
+
+  - **v0.13.0 carries its own breaking change, unrelated to pi:** "the package
+    entry point now exports only the sidebar contribution protocol
+    (`registerSidebarPanel`, the ID and request guards, size limits, event
+    types). The internal registry and layout helpers are no longer exported."
+    That reaches nothing of ours — grepping `pi-atelier` and
+    `registerSidebarPanel` across mempalace-toolkit, pi-devbox, pi-extensions,
+    pi-fork, pi-observational-memory and pi-studio returns **zero matches in all
+    six**. atelier is a leaf here: it registers its own sidebar, and nothing
+    consumes its API.
+  - **Settings churn in the gap, checked against our own tree:** v0.12.0 removed
+    the `showSessionActions` setting (zero references here) and migrated the
+    Control Center shortcut Alt+A → F6 (zero references here, so no doc goes
+    stale). `showSidebarAgent` / `showSidebarTodos`, the only atelier keys README
+    names, are both still documented in v0.13.0's README.
+  - The TUI internals atelier patches (`TuiMainScreen`, `renderLayoutFrame`) are
+    both still present in pi 1.0.0's dist, and atelier's changelog shows it has
+    handled fullscreen vs regular renderers explicitly since 0.84 — so
+    fullscreen-by-default is terrain it already covers.
+  - **Residual:** v0.13.0 is a same-day upstream release (2026-10-02).
+    Acceptance proves the sidebar **paints** with the two-sided check from
+    0.84.4/0.85.1 that can tell "loaded" from "silently absent" — "no crash" is
+    not the test.
+  - **Note for future bumps:** `v0.13.0` is an *annotated* tag, so
+    `git ls-remote --tags` reports the tag OBJECT (`dd06971`), not the commit.
+    The commit is `34d26f1`, via `ls-remote 'refs/tags/v0.13.0^{}'` — which is
+    what `check-doc-drift.sh` resolves and therefore what must be named here.
+    The gate caught the wrong SHA on the first attempt.
+
+- **`check-doc-drift.sh` now checks the pi-obsmem pin** against README's
+  version-pin table, the same way it already checks pi, pi-atelier and
+  mempalace. The ref-move check also covers pi-obsmem, but for a pinned SHA it
+  can only ever answer "upstream did not move" — never "the table still says what
+  we bake", which is the claim a reader of the table actually relies on.
+
+### Added
+
+- **Mailbox: an ask can declare its own dormancy (`mempalace-toolkit` `975ab92`)**
+  — a first-boot acceptance ask is planted deliberately unanswerable, describing
+  work that becomes possible only when the device is next recreated, and it must
+  stay owed until then because closing it early to tidy the mailbox is how that
+  work gets lost. `deriveOwed` could not tell that apart from neglected work, so
+  such an ask was announced at every session start and every poll for as long as
+  it was correctly waiting — three days running on `emb-7kj4vr4g`
+  (2026-09-28 → 2026-10-01) and across three consecutive releases before that.
+  An ask may now carry a `dormant_unless` predicate (`file_mtime` / `json_field`
+  against local paths) and is withheld from the *announced* owed-set while every
+  condition still matches its baseline, returning the moment any differs.
+  Withheld from the announcement, never from the mailbox: the wake-up injection
+  still lists dormant asks once per session. Unevaluable predicates announce the
+  ask — dormancy is proven, never assumed — and an ask without the key behaves
+  exactly as before. Nothing in the image changes except the bridge the
+  `MEMPALACE_TOOLKIT_REF=main` clone already tracks.
+
+- **Four base packages: `sqlite3`, `bc`, `dc`, `bsdextrautils`** — requested
+  2026-09-28 after a session had to reach for `bc` and found it absent. 1311 KB
+  total, and ZERO transitive packages: `libsqlite3-0`, `libreadline8t64`,
+  `zlib1g`, `libsmartcols1` and `libtinfo6` are each already in the image
+  (verified with `dpkg-query`, all five `install ok installed`), so nothing new
+  is pulled under `--no-install-recommends`. Package names were verified with
+  `apt-cache` and `dpkg -S` on a real trixie host rather than assumed, which
+  caught two traps: `dc` is a SEPARATE binary package from `bc` on Debian, and
+  `column` ships in `bsdextrautils`, not in the pre-bullseye `bsdmainutils`.
+  `sqlite3` is the one that was genuinely missing rather than merely absent —
+  MemPalace stores both the palace and the logstream as SQLite files
+  (`palace/chroma.sqlite3`, `logstream.sqlite3`) and `mempalace_status` reports a
+  `sqlite_integrity` block, so every integrity check on this fleet had been done
+  through a `python3 -c` one-liner. `bc`/`dc` are frankly low value on their own
+  (`awk`, `python3` and `perl` are all already baked and each is strictly more
+  capable) and are here only because copy-pasted shell snippets assume `bc`
+  exists; the incident that prompted the request was NOT `bc` being absent but
+  `printf '%6.2f'` rendering the missing tool's empty output as a confident
+  `0.00 days` for a figure that was really 4.81 days. Declined at the same time:
+  `datamash` and `xsv`/`csvkit`, because Python's stdlib `csv` module correctly
+  handled a real 7-file Excel-export concatenation (BOM, CRLF, embedded newlines
+  inside quoted fields) without them.
+
+### Fixed
+
+- **`git push` from inside the container dies on a read-only ControlPath, and no
+  amount of documentation was fixing it** — `entrypoint-user.sh` now sets
+  `core.sshCommand` to `ssh -F $HOME/.ssh-local/config` when that sidecar exists.
+  `~/.ssh` is commonly bind-mounted **read-only** from the host, so a per-host
+  `ControlPath ~/.ssh/cm/%r@%h:%p` — the standard CGNAT multiplexing recipe, and
+  correct *on the host* — resolves inside an unwritable directory here. Every
+  push then dies `unix_listener: cannot bind to path ~/.ssh/cm/...: Read-only
+  file system`, hidden behind git's misleading `Please make sure you have the
+  correct access rights`, which sends the reader hunting for a key problem that
+  does not exist. `setup-lan-access.sh` already wrote the writable sidecar, whose
+  leading `Host *` block overrides `ControlPath` into `~/.ssh-local/cm` and only
+  *then* `Include`s the user's own config, so `-F` repairs the socket path while
+  keeping every per-host `User`/`Port`/`IdentityFile`. Measured on tor-ms22
+  (2026-09-22): `ssh -G -F` yields `user gitea`, `port 22`, `egl_ed25519`
+  inherited from the host's own block, with a writable ControlPath; a master
+  socket is created and multiplexing is preserved, which is the whole point of
+  the host's setting.
+
+  The reason this is code and not a doc line: the remedy was already in the
+  global `AGENTS.md`, in `pi-devbox-environment` SKILL.md §3, in 24 MemPalace
+  drawers from three devices, **and printed verbatim by
+  `recreate-sanity-check.sh`** — and an agent that had run that script two hours
+  earlier still hit the failure and reinvented a `/tmp/sshcm` workaround. A fifth
+  copy of the text was not the missing piece; removing the need to know was.
+  The `[ -r ]` guard is load-bearing: `setup-lan-access.sh` writes no sidecar on
+  native Linux Docker, and `-F` at a missing file would break *every*
+  git-over-ssh call instead of fixing one. An existing `core.sshCommand` is left
+  alone, matching the first-wins convention of the three git settings above it.
+  Host configs need no change — the same line that is right on the host is simply
+  unusable through a read-only mount, so the fix belongs in the container layer.
+
+- **Boot log: `WARN: pi-extensions install.sh failed (continuing)` on every start
+  of every device** — pi-extensions `143a214`. `/opt/pi-extensions` is root-owned
+  and `install.sh` runs as `developer`; git refuses the repo ("dubious
+  ownership"), `git config --local` fails silently, and the unguarded
+  `git config core.hooksPath hooks` exited 128 under `set -e`, aborting the
+  installer one line before `Done`. Damage was nil (all nine extension symlinks
+  were already created) but the WARN fired on v1.9.3 and v1.9.4 alike and would
+  have masked a real installer failure. `activate_hooks` now resolves the git dir
+  and requires a writable `.git/config`, else prints one note and returns 0 —
+  hooks are for clones you commit from. Measured with the function extracted and
+  run under `set -euo pipefail`: old function rc=128 on `/opt/pi-extensions` and
+  on a root-owned throwaway; new function rc=0 on those two, on a dir without
+  `.git`, and on a clone with `.git/config` mode 444; still activates on a
+  writable unset clone (config reads back `hooks`) and reports already-active on
+  a preset one; no root-owned config was touched.
+- **`Initializing MemPalace for workspace` re-fired on every boot of a container
+  that had never mined locally** — `entrypoint-user.sh`. The first-run test
+  checked `$PALACE_DIR/palace`, but `mempalace init` writes `config.json` and
+  never creates `palace/` (mining does). v1.9.4 acceptance measured 1
+  "Initializing" line after one boot and 2 after a restart. Idempotent, so
+  harmless, but the comment claimed it skipped. Sentinel is now `config.json`
+  (what init writes; also a 3.10.0 legacy-layout marker). Populated volumes skip
+  either way.
+- **`developer` can now run git in the root-owned `/opt` clones** —
+  `Dockerfile.variant` adds `git config --system --add safe.directory` for
+  `/opt/{pi-toolkit,pi-extensions,pi-fork,pi-observational-memory,pi-atelier,mempalace-toolkit,pi-studio}`
+  (paths listed, not `*`, so the ownership check still protects `/workspace`;
+  the pi-studio entry is inert in the plain variant). Before: `git -C
+  /opt/pi-atelier rev-parse --short HEAD` as `developer` printed nothing, which
+  produced one false FAIL in the v1.9.4 acceptance and an earlier
+  "dubious ownership" wall on `/opt/mempalace-toolkit`. Mechanism verified live
+  in a v1.9.3 container (add → `25c1265`, unset → fatal again).
+
+### CI
+
+- **`base-decide` pins the collation of the hash input order:
+  `find -print0 | LC_ALL=C sort -z`** — `docker-publish.yml`. `sort` collates per
+  locale, and the order of `rootfs` files under a dictionary locale differs from
+  byte order, so identical content hashed differently: measured
+  `base-f40c4b7b103d` under `C` and `C.UTF-8` (== CI run 695) versus
+  `base-d8df62216a81` under `sv_SE.UTF-8` and `en_US.UTF-8`. The runner image
+  happens to export `LANG=C.UTF-8`, so the hash was stable by accident and the
+  comment "order is fixed via `sort -z`" was not true as written. The pin is
+  hash-neutral today (no spurious base rebuild from this commit; the workflow
+  file is not a hash input) and removes the dependency on the runner's locale.
+  Predicting `base_tag` locally must use the same per-command prefix — it is
+  scoped to that one `sort`, not to the shell, so it leaves `sv_SE.UTF-8`
+  everywhere else alone.
+
+- **`smoke-test.sh` + `recreate-sanity-check.sh` assert the sidecar wiring, and
+  the permanent ControlPath warning now says whether it matters** — three
+  assertions, each placed where it can actually pass. `smoke-test.sh` gets two
+  **static** greps against the image's `entrypoint-user.sh` (the wiring line, and
+  the `[ -r ]` guard around it), because `run` executes
+  `docker run --entrypoint=""`, so the entrypoint never runs there and asserting
+  the runtime *value* would repeat the v1.8.0 mistake of an assertion that cannot
+  pass, unvalidated until the next tag. Its runtime-deployment phase gets a
+  **biconditional**: sidecar present ⇒ `core.sshCommand` must route through it;
+  sidecar absent ⇒ it must be unset. Both arms are real, and the absent arm is
+  the one CI exercises, since a Gitea runner is native Linux Docker where
+  `setup-lan-access.sh` writes no sidecar — so "is set" would have failed CI for a
+  correct image.
+
+  `recreate-sanity-check.sh` gets the runtime assertion proper, with an explicit
+  `fail` for the inverted state (`core.sshCommand` set while the sidecar is
+  missing — which breaks every git-over-ssh call). The existing
+  "default ssh precedence" warning is unchanged in severity but now states its own
+  scope: it is **structural and can never reach zero** while a bind-mounted
+  config pins `ControlPath` inside the read-only `~/.ssh`, and it reports whether
+  git is wired, not wired, or has no sidecar to point at. That matters because the
+  script's own comment already warned that "a check that fires benignly every time
+  is one you learn to ignore" — and on 2026-09-22 that is exactly what happened,
+  with the remedy sitting inside the dismissed line. All five arms were exercised
+  against the real script before commit; doing so caught a defect in the first
+  draft, which reported "git IS wired … unaffected" about a state where the
+  sidecar was gone and every git-over-ssh call failed.
+
+### Still open
+
+- **pi 1.0.0 + pi-observational-memory, now adopted but not yet witnessed** —
+  the v1.9.4/v1.9.5 blocker (upstream
+  [PR #83](https://github.com/elpapi42/pi-observational-memory/pull/83),
+  `shouldStopAfterTurn` → `finishTurn`) is merged and pinned, and 1.0.0 measures
+  clean against every API we use. What remains is runtime proof, and it cannot
+  be had before the build: obsmem's `peerDependencies` are `*`, so an
+  incompatibility is silent — the workers simply stop capping turns. The newest
+  obsmem *tag* is still 3.1.4 (2026-09-20, before the merge), so this ships on a
+  pinned master commit; a 3.1.5 that tags the fix would let the pin become a
+  version again.
+- **pi-atelier v0.13.0 and pi 1.0.0 are both days old** — adopted on measured
+  evidence (no breaking section, symbols present, no importers of the removed
+  exports), not on anyone's report of running them together. The three
+  first-boot acceptance asks carry both checks: workers **cap turns**, sidebar
+  **paints**.
+- **synlig hub** — upgraded to mempalace 3.10.0 on 2026-09-22T14:42:53Z (uv
+  tool, hot backup first, 3 s downtime, 40996 embedding rows before == after).
+  Client-visible: `event_list` without a cursor now returns newest first;
+  search results carry `filed_at` / `authored_at_source` / `content_date`.
+  Recorded here because v1.9.4's "still open" listed it.
+
+---
+
+## v1.9.4 — 2026-09-22
+
+### Dependency audit (2026-09-22)
+
+Every component checked against upstream by direct command, not assumed. "Baked"
+is v1.9.3's published labels or, for the floating `*_VERSION=latest` tools, the
+binaries in a running v1.9.3 container. The 13 GitHub-`latest` tools were
+resolved through the same `/releases/latest` redirect the Dockerfile follows.
+
+| Component | Baked in v1.9.3 | Upstream now | Action |
+|---|---|---|---|
+| **pi** | `0.85.1` (pinned) | **`0.87.0`** (0.86.0, 0.86.1, 0.87.0 since) | **held — blocked by pi-observational-memory, see below** |
+| **pi-atelier** | `v0.10.1` (`734258b`) | **`v0.10.3`** (`ed3837b`, released 2026-09-22) | **bumped** |
+| **mempalace** | `3.9.0` (pinned) | **`3.10.0`** (changelog dated 2026-09-15) | **bumped, with one adaptation** |
+| **mempalace-toolkit** | `817b3a8` | **`2167a1b`** | floating `main`; the commit is this release's own (below) |
+| **pi-observational-memory** | `cba0334` (3.1.3) | **`e7d77dc`** (3.1.4) | adopted implicitly via `master` (below) |
+| pi-toolkit | `9c87ee8` | `9c87ee8` | none |
+| pi-extensions | `25c1265` | `25c1265` | none |
+| pi-fork | `e69725c` | `e69725c` | none |
+| pi-studio (studio variant) | `e04fc7a` | `e04fc7a` highest semver tag | none |
+| skillset (mempalace fallback snapshot) | `e9e45f7` | skillset at `1c5f960`; `check-doc-drift.sh` rc=0 (snapshot still byte-identical) | none |
+| gitea-mcp, agent-browser, node | `1.7.0`, `0.38.1`, `v24.21.0` | identical | none |
+| 13 floating `*_VERSION=latest` tools | — | all 13 identical to the running v1.9.3 binaries | none |
+
+### mempalace 3.9.0 → 3.10.0, and why one `ENV` line comes with it
+
+v1.9.3 deferred 3.10.0 for two "Upgrade notes" items. Both were re-measured
+against the 3.10.0 wheel rather than the changelog; one needed an adaptation, the
+other turned out to be the other side's problem.
+
+**"New installs keep config and palace under `~/.config/mempalace`."** The
+resolution order (`config.py`, `_default_config_dir`) is `$MEMPALACE_CONFIG_DIR`,
+then `~/.mempalace` *if* it holds `config.json`, `people_map.json` or
+`palace/chroma.sqlite3`, then XDG. An **empty** `~/.mempalace` fails that test —
+and an empty `~/.mempalace` is exactly what a freshly mounted `devbox-palace`
+volume looks like at first boot (and what `entrypoint.sh`'s `mkdir` leaves on a
+volume-less container). Measured with a fresh `$HOME` and `uvx mempalace==3.10.0`:
+`mempalace init` wrote `config.json` to `~/.config/mempalace`, `~/.mempalace`
+stayed empty, and `entrypoint-user.sh`'s first-run test `[ ! -d ~/.mempalace/palace ]`
+would have stayed true on every start. Same run with `MEMPALACE_CONFIG_DIR` set:
+everything landed in `~/.mempalace`.
+
+So `Dockerfile.base` now sets `ENV MEMPALACE_CONFIG_DIR=/home/${USER_NAME}/.mempalace`
+(in the non-root-user section, where `USER_NAME` is in scope), and
+`entrypoint-user.sh` reads `PALACE_DIR` from the same variable with the old path
+as fallback — the first-run test and mempalace's own resolution can no longer
+disagree. Existing volumes were safe either way (`config.json` is a legacy
+marker; this container's volume holds one); the `ENV` is for first boots.
+`palace_path` still defaults to `<config_dir>/palace` and `MEMPALACE_PALACE_PATH`
+is still honoured (`config.py:927`), so `smoke-test.sh`'s stage-path test keeps
+its meaning, and `recreate-sanity-check.sh`'s hard-coded `~/.mempalace/palace/chroma.sqlite3`
+stays correct.
+
+**"MCP event listing returns the newest events first when no cursor is given."**
+This is **server-side**. The pi extension talks to the fleet hub over
+`MEMPALACE_REMOTE_URL`, so `mempalace_event_list`'s default flips when *synlig*
+upgrades, not when this image does. `mempalace-toolkit` `2167a1b` (this release)
+makes every cursor-less `event_list` call in the extension say `order: "desc"`
+explicitly — three of five did not — so the mailbox's `deriveOwed` and
+`deriveClosed` read the same newest-N window against either server version. Its
+selection was already order-independent (`isStrictlyAfter`); what the fix changes
+is *which* events are in the window: on a 3.9.0 hub the cursor-less calls were
+returning the **oldest** N, the latent truncation `deriveOwed` had already fixed
+for two of its calls in toolkit `e2b060a` (2026-09-09).
+
+Also in the upgrade notes, neither reaching this image: `mempalace rules` dropped
+`--agent` (zero callers in pi-devbox, mempalace-toolkit, skillset, myconfigs);
+`get_collection()` refuses unknown collection names (library callers only). MCP
+tool-schema review — the regression class this pin exists for: no tool removed or
+renamed; additive fields on search results (`filed_at` / `content_date`
+provenance), `limit`/`offset` on `kg_timeline`, `last_modified` on drawers.
+
+**Server state, measured over ssh on 2026-09-22:** synlig serves mempalace
+**3.9.0** as a `uv tool` under `systemd` (`mempalace-serve.service`, python
+3.12.13, chromadb 1.5.9) — *not* via `docker-compose.mempalace.yml`, which the
+`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. 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`)
+
+Fixes only per the release notes for v0.10.2 and v0.10.3 (both 2026-09-22):
+sidebar text/borders preserved beside inline images (#53), transcript images
+hidden while capturing overlays are open, Workspace Pulse skips redundant
+HEAD/diff when nothing tracked changed (#61), sidebar height from row counts
+(#59), git/usage scans suspended while disabled, Display Revert + Undo ordering.
+Checked before bumping: `package.json` at v0.10.3 still declares zero runtime
+dependencies and no build script (the no-`npm install` reasoning in
+`Dockerfile.variant` holds), `peerDependencies` still `>=0.84.0` (spans the
+pinned pi 0.85.1), 13 commits all under `src/ tests/ docs/ scripts/` plus
+metadata, no entry-point move. Both tags are annotated: the SHA above is the
+peeled commit, which is what `resolve-versions` bakes and what check 9 compares.
+
+### pi held at 0.85.1 (0.86.1 and 0.87.0 exist)
+
+Not an oversight. pi 0.87.0 *"Removed the inherited `shouldStopAfterTurn` agent
+option. Use `finishTurn` and return `{ action: "end" }` instead"*, and 0.86.0
+moved provider stream inputs to `TranscriptContext` with the system prompt read
+from `context.messages`. pi-observational-memory 3.1.4 still uses both the
+removed option and `AgentContext.systemPrompt` in its observer, reflector and
+dropper workers — measured in `src/agents/*/agent.ts` on both the baked 3.1.3
+tree and upstream `master`: `shouldStopAfterTurn` once per worker, `finishTurn`
+zero. Its `peerDependencies` are `*`, so nothing at install time would refuse;
+under 0.87 the workers would lose their turn caps and their specialised prompts
+at runtime. Upstream tracks it as pi-observational-memory
+[#82](https://github.com/elpapi42/pi-observational-memory/issues/82) with fix PR
+[#83](https://github.com/elpapi42/pi-observational-memory/pull/83) — opened
+2026-09-21, mergeable, **not merged** at this writing. Bump pi and pi-obsmem
+together once #83 ships in a release.
+
+The other extensions were checked against the 0.86.0 and 0.87.0 breaking lists
+and are clean: `ssh-controlmaster`'s `user_bash` handler already returns
+`undefined | { operations }` (0.86.0's fail-closed contract), and its four
+`registerTool` calls spread the built-in tools so they carry parameter schemas
+(#9300). 0.86.1 as an intermediate was not tested — not worth the pty matrix for
+a stop that #83 makes moot.
+
+### Still open
+
+- **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`.
+- **pi 0.87.x + pi-observational-memory ≥ 3.1.5** together, when #83 has shipped.
+
+### pi-observational-memory 3.1.3 → 3.1.4 (`cba0334` → `e7d77dc`)
+
+No change in this repo. `PI_OBSMEM_REF` defaults to `master`
+(`Dockerfile.variant`) and CI resolves it to a SHA at build time
+(`docker-publish.yml`, `resolve-versions`), so the next rebuild bakes this
+whether or not anyone acts — which is exactly why it is written down here. The
+floating ref means this CHANGELOG is the only place a reader of the next tag can
+learn that the component moved.
+
+v1.9.3 shipped `cba0334` (3.1.3) and was internally consistent: its manifest,
+its image labels and the baked `/opt/pi-observational-memory` clone all agree on
+that SHA. Upstream `master` then moved to `e7d77dc` (3.1.4) on **2026-09-20**,
+the day *after* the v1.9.3 tag — so the drift is real but v1.9.3 has no defect,
+and a green `check-doc-drift.sh` reading taken before that date was correct when
+it was taken.
+
+| | |
+|---|---|
+| Upstream range | [`cba0334...e7d77dc`](https://github.com/elpapi42/pi-observational-memory/compare/cba03347a60af8b8afbb35677ade4d6bb05d4c5a...e7d77dc9a8305acb8054124e47662b3c766c2321) — 4 commits |
+| Substance | one line in `src/agents/worker-stream.ts` — *preserve registry receiver when resolving stream* (PR #78, upstream issue #77) — plus a 19-line regression test |
+| Remainder | `chore(release): prepare 3.1.4` (version bump) and the release merge (PR #79) |
+| `peerDependencies` | unchanged — all four `@earendil-works/*` peers still `*`, so no pi floor to clear |
+| `engines` | absent in both — no node floor |
+
+Because the ref floats, the SHA this repo actually bakes is whatever `master`
+resolves to **at build time**. If upstream moves again before the next tag, the
+value above is stale and `check-doc-drift.sh` will say so; re-run it immediately
+before tagging rather than trusting this row.
+
+---
+
 ## v1.9.3 — 2026-09-19

 ### Dependency audit (2026-09-19)
@@ -56,6 +56,8 @@ Full setup guide — authentication for each provider (Anthropic, OpenAI, Gemini

 The entrypoint deploys/registers all of these on first container start. Re-running is idempotent and preserves user edits.

+**Terminal UI mode — fullscreen by default.** pi 1.0.0 made the TUI fullscreen, and this image adopts upstream's default. Fullscreen uses the terminal's alternate screen, so the transcript no longer lands in your terminal's (or tmux's) native scrollback. To get the previous behaviour back, set `"tuiMode": "regular"` in `~/.pi/agent/settings.json`, or pass `pi --tui-mode regular` for a single session. The bundled pi-atelier sidebar works in both modes. See the README for the related `fullscreenExitOutput` / `fullscreenScrollbar` / `fullscreenCopyOnSelect` / `fullscreenWheelScrollLines` settings — the last one behaves differently over SSH, which is how this container is usually driven.
+
 ### MemPalace (persistent agent memory)

 - **MemPalace** + MCP server — semantic search over conversation history, knowledge graph, diary; queryable via 29 `mempalace_*` tools inside pi
@@ -80,7 +82,7 @@ The entrypoint deploys/registers all of these on first container start. Re-runni
 - **Editor**: neovim (system-wide `termguicolors` default; bring your own config/plugins), tmux (configured for 0-indexed sessions)
 - **Search/nav**: ripgrep, fd, fzf, zoxide
 - **Display**: bat, eza, htop, tree
- **Data**: jq, yq
+- **Data**: jq, yq, sqlite3, bc/dc, column
 - **Help**: tldr (tealdeer — Rust port; run `tldr --update` once to populate cache)
 - **Git**: git-lfs, git-crypt, gitleaks (for pre-commit secret scanning)
 - **Build**: gcc, g++, make, patch
@@ -14,7 +14,7 @@
 # content-addressed over this file, so any byte change invalidates the
 # cache. Recommended cadence: once per release for security updates.
 #
-# BASE_REBUILD_DATE: 2026-09-19 (v1.9.3 — mempalace-version label, mempalace-toolkit 817b3a8 mine deadline, pi-extensions skill floor 25c1265; the marker had been stale since 2026-07-13 through the v1.9.0 Node 24 and v1.9.2 npm-residue rebuilds, updated now because the base is rebuilding anyway)
+# BASE_REBUILD_DATE: 2026-09-22 (v1.9.4 — mempalace 3.9.0 -> 3.10.0 with ENV MEMPALACE_CONFIG_DIR pinning the layout, mempalace-toolkit 2167a1b explicit event_list order; previous marker 2026-09-19 / v1.9.3)
 #
 # ── Lineage note ─────────────────────────────────────────────────────
 # Adapted from opencode-devbox/Dockerfile.base (commit before v1.16.2).
@@ -162,6 +162,42 @@ ENV DEBIAN_FRONTEND=noninteractive
 #                  /dev/tcp does reachability checks with zero packages
 #                  (verified against gitea.egl.lan:3000). Recorded here so the
 #                  omission reads as a decision rather than an oversight.
+#   sqlite3      — the `sqlite3` CLI. Added 2026-09-28 at ALC's request. 587 KB.
+#                  This is the one that was genuinely missing rather than merely
+#                  absent: MemPalace keeps BOTH the palace and the logstream as
+#                  SQLite files (palace/chroma.sqlite3, logstream.sqlite3),
+#                  mempalace_status reports a sqlite_integrity block, and every
+#                  integrity or forensics check on this fleet has so far been
+#                  done through a python3 -c one-liner because the CLI did not
+#                  exist in the image.
+#   bc, dc       — arbitrary-precision calculators. 236 KB + 149 KB. SEPARATE
+#                  binary packages on Debian (dc split out of bc before
+#                  bookworm), so both must be named — verified with apt-cache on
+#                  a trixie host, not assumed. Added 2026-09-28. HONEST
+#                  RATIONALE: low value on their own, because awk, python3 and
+#                  perl are all already baked and each is strictly more capable.
+#                  They are here because copy-pasted shell snippets assume bc
+#                  exists. Note what actually went wrong on 2026-09-28, since it
+#                  was NOT bc's absence: `printf '%6.2f'` was handed the empty
+#                  output of the missing bc and rendered it as a confident
+#                  "0.00 days" for a figure that was really 4.81 days. A missing
+#                  tool that formats as a plausible number is worse than one
+#                  that fails loudly, and no package fixes that — only not
+#                  taking a formatted value on trust does.
+#   bsdextrautils— ships /usr/bin/column. 339 KB. Added 2026-09-28. Confirmed
+#                  with `dpkg -S /usr/bin/column` on trixie rather than inferred
+#                  from the pre-bullseye bsdmainutils name, which is where column
+#                  used to live and is the obvious way to get this wrong.
+#                  MEASURED COST OF ALL FOUR: 1311 KB total and ZERO transitive
+#                  packages — libsqlite3-0, libreadline8t64, zlib1g,
+#                  libsmartcols1 and libtinfo6 are each already present in the
+#                  image (checked with dpkg-query, all five report
+#                  "install ok installed"), so under --no-install-recommends
+#                  nothing new is pulled.
+#                  NOT added — datamash, xsv/csvkit: considered 2026-09-28 and
+#                  declined. Python's stdlib csv module handled a real 7-file
+#                  Excel-export concatenation that day (BOM, CRLF, embedded
+#                  newlines inside quoted fields) correctly and without them.
 #   python3-yaml — PyYAML. Added 2026-09-10 for precisely the same reason as
 #                  shellcheck above: a gate this repo ALREADY OWNS could not be
 #                  run locally by anyone. scripts/check-workflow-shell.sh — the
@@ -220,6 +256,10 @@ RUN apt-get update && \
    ldap-utils \
    xxd \
    python3-yaml \
+    sqlite3 \
+    bc \
+    dc \
+    bsdextrautils \
    && ln -s /usr/bin/fdfind /usr/local/bin/fd \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*
@@ -532,14 +572,22 @@ ARG INSTALL_MEMPALACE=true
 # the part that should stay manual.
 #
 # Deployment sequencing note for whoever ships this bump: synlig (the shared
-# central palace host) serves mempalace 3.8.0 SERVER-SIDE via
-# docker-compose.mempalace.yml, which reuses this same devbox image. (Measured
-# 2026-09-06 over ssh: synlig's UV_TOOL_DIR mempalace entry last changed
-# 2026-08-25 15:33 — this comment previously said 3.7.1, which was stale.)
-# Bumping this ARG changes only the CLIENT version baked into pi-devbox
-# images: it introduces client/server skew until synlig's compose stack is
-# separately rebuilt/redeployed with the new pin. Not something to code around
-# here — just sequence the redeploy.
+# central palace host) serves mempalace SERVER-SIDE as a `uv tool` install run
+# by the systemd unit `mempalace-serve.service` (`python -m mempalace.mcp_server
+# --transport http`), NOT via docker-compose.mempalace.yml — that compose file
+# exists in this repo but is not what runs there. (Measured 2026-09-22 over
+# ssh: `uv tool list` -> mempalace v3.9.0, python 3.12.13, chromadb 1.5.9;
+# `docker ps` matched no palace container. This comment previously said the
+# compose stack served 3.8.0, which was stale on both counts.) Bumping this ARG
+# changes only the CLIENT version baked into pi-devbox images: it introduces
+# client/server skew until synlig's tool is upgraded (`uv tool upgrade
+# mempalace` + restart the unit). Not something to code around here — just
+# sequence the upgrade. And note which side OWNS what: MCP tool semantics
+# (event_list ordering, kg_timeline pagination, search result fields) come
+# from the SERVER the extension talks to over MEMPALACE_REMOTE_URL, so they
+# change when synlig upgrades; only the local CLI (`mempalace init` at first
+# run, the mempalace-pi-session feeder) and the on-disk layout under
+# ~/.mempalace change when THIS pin does.
 #
 # v1.8.13: 3.8.0 -> 3.9.0. Audited: no Breaking/Removed changelog headings.
 # Adopted mainly for #2281 (`mempalace_mine` accepts a single conversation
@@ -551,7 +599,47 @@ ARG INSTALL_MEMPALACE=true
 # (release awareness, `task create`/`task launch` MCP tools) are SERVER-side,
 # so they stay dark until synlig is redeployed — a client bump alone cannot
 # light them up.
-ARG MEMPALACE_VERSION=3.9.0
+#
+# v1.9.4: 3.9.0 -> 3.10.0 (PyPI 2026-09-15). Deferred at v1.9.3 for two
+# "Upgrade notes" items; both re-measured against the 3.10.0 wheel, one needed
+# an adaptation:
+#   - "New installs keep config and palace under ~/.config/mempalace". The
+#     resolution order is $MEMPALACE_CONFIG_DIR, then ~/.mempalace IF it holds
+#     config.json / people_map.json / palace/chroma.sqlite3, then XDG. An
+#     EMPTY ~/.mempalace does not count — and an empty ~/.mempalace is exactly
+#     what a freshly mounted devbox-palace volume (or entrypoint.sh's mkdir on
+#     a volume-less container) looks like at first boot. Measured with a fresh
+#     $HOME: `mempalace init` wrote to ~/.config/mempalace, outside the
+#     persisted path, and entrypoint-user.sh's first-run test
+#     `[ ! -d ~/.mempalace/palace ]` would stay true on every start. With
+#     MEMPALACE_CONFIG_DIR set, everything landed in ~/.mempalace. Hence the
+#     ENV MEMPALACE_CONFIG_DIR below (in the non-root-user section, where
+#     ${USER_NAME} is in scope): first in the resolution order, so the
+#     heuristic never runs and the image's layout contract no longer depends
+#     on it. Existing volumes were safe either way (config.json is a legacy
+#     marker); the ENV is for first boots. palace_path still defaults to
+#     <config_dir>/palace and MEMPALACE_PALACE_PATH is still honoured (config.py
+#     :927), so scripts/smoke-test.sh's stage-path test keeps its meaning.
+#   - "MCP event listing returns the newest events first when no cursor is
+#     given". SERVER-side (see above), so it lands when synlig upgrades, not
+#     here. mempalace-toolkit 2167a1b made every cursor-less event_list call
+#     in the pi extension say `order: "desc"` explicitly, so the mailbox reads
+#     the same window against either server version.
+# Also in the notes, neither reaching this image: `mempalace rules` dropped
+# `--agent` (no caller in pi-devbox, mempalace-toolkit, skillset or myconfigs);
+# `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 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
 # would be one more pin able to drift, which is the class check-doc-drift.sh
@@ -832,6 +920,18 @@ print('chromadb embedding model warmed: all-MiniLM-L6-v2')" && \
 ENV NPM_CONFIG_PREFIX=/home/${USER_NAME}/.pi/npm-global
 ENV PATH="/home/${USER_NAME}/.pi/npm-global/bin:${PATH}"

+# ── MemPalace config/palace root: pin it, do not let a heuristic pick it ──
+# mempalace >= 3.10.0 resolves its config dir as $MEMPALACE_CONFIG_DIR, then
+# ~/.mempalace ONLY if it already holds a config/palace, else ~/.config/mempalace
+# (XDG). An empty ~/.mempalace — a fresh devbox-palace volume, or entrypoint.sh's
+# mkdir on a volume-less container — fails that test, so a first boot would put
+# the palace outside the persisted path and re-run first-run init forever. This
+# ENV is first in the order, so the layout is what entrypoint.sh (mkdir),
+# entrypoint-user.sh (first-run test), the feeder's <palace-root>/pi-stage and
+# scripts/recreate-sanity-check.sh all already assume. Rationale and the
+# measurement live with ARG MEMPALACE_VERSION above; keep the two in step.
+ENV MEMPALACE_CONFIG_DIR=/home/${USER_NAME}/.mempalace
+
 # ── Shell defaults (bash history, aliases, readline) ─────────────────
 RUN mkdir -p /etc/skel-devbox
 COPY rootfs/home/developer/.bash_aliases     /etc/skel-devbox/.bash_aliases
@@ -1,3 +1,37 @@
+# check=skip=InvalidDefaultArgInFrom
+#
+# ^ MUST stay the FIRST line of this file, and it is load-bearing for CI, not
+# style. BuildKit parses `# check=` only before any other line, so moving it
+# below the title comment silently disables it.
+#
+# Why it exists: `ARG BASE_IMAGE` (below) deliberately has NO default — this
+# file is only ever built by the two-phase CI with --build-arg BASE_IMAGE=
+# <image>:base-<hash>. BuildKit's InvalidDefaultArgInFrom check flags that as
+# "default value for global ARG results in an empty or invalid base image
+# name". There is no honest default to give it: `scratch` would satisfy the
+# linter while being a lie (nothing here can build FROM scratch), and it would
+# convert today's instant "invalid reference format" into a failure deep in the
+# build. So the check is skipped by name, with the reason written down.
+#
+# What the warning actually COST, which is why this is not cosmetic: buildx
+# attaches the warning's source context to the build metadata as
+# buildx.build.warnings[].sourceInfo.data — the ENTIRE Dockerfile, base64, on
+# ONE line. docker/build-push-action writes that metadata to $GITHUB_OUTPUT as
+# a `name<<ghadelimiter_<uuid>` heredoc, and Gitea's act_runner truncates any
+# single line at exactly 65536 chars. Once base64(this file) crossed 64 KiB the
+# closing delimiter was cut off, and the runner failed the job with
+#   invalid format delimiter 'ghadelimiter_...' not found before end of file
+# and NO failing step: every step green, smoke suite "0 failed", job red.
+# Measured: 42251 B at v1.9.4 -> base64 56355 (fine); 50034 B at v1.10.1 ->
+# base64 66712, truncated to exactly 65536. The cap corresponds to a 49152 B
+# Dockerfile, so this release's comment growth crossed it by 882 B. It killed
+# v1.10.0 (run 704, where a stale clipboard assertion hid it) and v1.10.1
+# (run 707). With zero warnings there is no sourceInfo, so the longest metadata
+# line drops from 65536 to ~1936 chars and the Dockerfile's SIZE stops being
+# coupled to CI passing at all.
+#
+# If this ever recurs — job red, zero failing steps, suite reporting 0 failed —
+# grep the job log for `ghadelimiter` first.
 # pi-devbox — variant image
 #
 # FROMs a base-<hash> image produced by Dockerfile.base and adds only
@@ -113,7 +147,91 @@ ARG USER_NAME=developer
 # signature is ~5s of sustained CPU. Two-sided check: the atelier sidebar
 # painted ACTIVITY+WORKSPACE identically to the 0.84.4 control, so the test
 # could distinguish "loaded" from "silently absent".
-ARG PI_VERSION=0.85.1
+#
+# v1.9.4: HELD at 0.85.1 while 0.86.1 and 0.87.0 exist upstream. 0.87.0's
+# changelog: "Removed the inherited `shouldStopAfterTurn` agent option. Use
+# `finishTurn` and return `{ action: "end" }` instead" (no issue number on
+# that line); 0.86.0 moved provider stream inputs to `TranscriptContext`, with
+# system prompts read from `context.messages`. pi-observational-memory 3.1.4
+# (the `master` ref baked below) still uses both the old option and
+# `AgentContext.systemPrompt` in its observer, reflector and dropper workers —
+# measured 2026-09-22 in src/agents/*/agent.ts, both the baked 3.1.3 tree and
+# upstream master 3.1.4: `shouldStopAfterTurn` 1 per worker (3), `finishTurn`
+# 0, `systemPrompt` 1 per worker. Its peerDependencies are `*`,
+# so nothing at install time would refuse; it would break at runtime (turn
+# caps ignored, workers losing their specialised prompts). Upstream tracks it
+# as pi-observational-memory #82 with fix PR #83 (opened 2026-09-21, mergeable,
+# not merged at this writing). Bump pi and pi-obsmem TOGETHER once #83 has
+# shipped in a release. The other extensions were checked against the 0.86.0
+# and 0.87.0 breaking lists and are clean: ssh-controlmaster's `user_bash`
+# handler already returns `undefined | { operations }` (0.86.0 fail-closed
+# contract) and its registerTool calls spread the built-in tools so they
+# carry parameter schemas (#9300). 0.86.1 as an intermediate is untested and
+# not worth the pty matrix for a stop that #83 will make moot.
+#
+# v1.9.5: 0.85.1 -> 0.87.1, and pi-obsmem moves off `master` to a pinned SHA in
+# the SAME commit, because neither is safe alone. 0.87.0 REMOVED
+# `shouldStopAfterTurn`, which 3.1.4 still used; the pinned tip uses
+# `finishTurn`, which does not exist before 0.87.0. So 3.1.4 + 0.87.1 silently
+# ignores turn caps, and the new tip + 0.85.1 breaks the workers outright — the
+# pair only works together, exactly as the v1.9.4 note predicted.
+# MEASURED 2026-10-01 across src/agents/{observer,reflector,dropper}/agent.ts,
+# deliberately the same counting method as the v1.9.4 audit above so the two
+# numbers are comparable:
+#   3.1.4   (e7d77dc): shouldStopAfterTurn 3, finishTurn 0, systemPrompt 3
+#   731c3d4 (pinned) : shouldStopAfterTurn 0, finishTurn 3, systemPrompt 0
+# i.e. all three workers migrated, and the 0.86.0 `AgentContext.systemPrompt`
+# reads are gone too. #82/#83 merged 2026-09-23.
+# WHY A SHA AND NOT A TAG, departing from the v1.9.4 instruction to wait for a
+# release: #83 is merged, but the newest obsmem tag is STILL 3.1.4, cut
+# 2026-09-20 — before the merge. Upstream tags slowly while moving master often
+# (e7d77dc -> 1529e14 -> 731c3d4 in the nine days to 2026-10-01), so waiting for
+# a tag means holding pi indefinitely. A full SHA keeps the one property
+# `master` does not have: rebuilding this tag later produces the SAME image.
+# v1.9.5 SKIPPED 0.99.x and 1.0.0 for lack of evidence. v1.10.2 went and got the
+# evidence instead of waiting for obsmem to mention a version, because "no issue
+# names 1.0" is an absence of a statement, not a measurement.
+#
+# v1.10.2: 0.87.1 -> 1.0.0. MEASURED 2026-10-02 against the published npm
+# tarballs for 0.87.1 and 1.0.0, unpacked side by side:
+#   1. NO `### Breaking Changes` SECTION IN 1.0.0 AT ALL. The changelog's
+#      breaking sections belong to 0.87.0, 0.86.0, 0.84.3, 0.84.0, 0.83.0,
+#      0.80.8, 0.80.7 and 0.75.0 — none to 0.88+..1.0.0. The major is a
+#      milestone (fullscreen default, leaner codemode), not an API break. The
+#      last break that touched us was 0.87.0's `shouldStopAfterTurn` removal,
+#      which v1.9.5 already absorbed.
+#   2. `finishTurn` IS STILL IN 1.0.0's dist, so the obsmem SHA pinned below
+#      keeps the API it migrated to. (`shouldStopAfterTurn`: absent from both
+#      0.87.1 and 1.0.0, as expected after its 0.87.0 removal.)
+#   3. EVERY pi.* API our extensions call exists in 1.0.0's dist — all 8 of
+#      registerTool, registerCommand, registerFlag, getFlag, on, exec,
+#      sendMessage, sendUserMessage, extracted from mempalace.ts, the
+#      pi-extensions tree and obsmem's src/.
+#   4. engines.node is `>=22.19.0` on both; the image ships 24.x.
+# THE 0.99.2 CHANGE THAT LOOKED FATAL AND IS NOT: from 0.99.2 the DEFAULT MCP
+# `exposure` is `codemode`, i.e. such tools are "neither declared to the model
+# nor listed" and must be found with `searchTools()`. That would gut the
+# MemPalace protocol if MemPalace were a builtin-MCP server. It is not: both
+# mempalace.ts and mcp-loader.ts run their OWN MCP client and surface tools via
+# `pi.registerTool()`, which is why they are named `mempalace_search` and not
+# `mcp__mempalace__search`. Confirmed on a second route — settings.json has
+# neither an `mcpServers` block (builtin, exposure-governed) nor an `mcp` block.
+# Extension-registered tools are declared like built-ins, so `exposure` cannot
+# reach them.
+# WHAT IS NOT PROVEN, stated so acceptance does not mistake this for cleared:
+# grepping dist shows the SYMBOLS survive, not that their SIGNATURES are
+# unchanged — necessary, not sufficient. 1.0.0 is also four days of upstream old
+# (published 2026-10-01T19:15Z) and neither obsmem nor atelier has a commit
+# naming it. Acceptance must prove the obsmem workers CAP TURNS (peerDeps are
+# `*`, so a mismatch is silent) and that the atelier sidebar PAINTS.
+# USER-VISIBLE BEHAVIOUR CHANGE, decided rather than inherited: 1.0.0 makes the
+# TUI fullscreen by default, which replaces the terminal's normal scrollback.
+# Upstream's default is ADOPTED on purpose and no `tuiMode` is baked here, so
+# the image follows pi instead of pinning the fleet to either mode. The revert
+# is documented (README -> "Terminal UI mode"): `"tuiMode": "regular"` in
+# ~/.pi/agent/settings.json, `pi --tui-mode regular` for one session, or the
+# same key in a project's .pi/settings.json.
+ARG PI_VERSION=1.0.0
 ARG PI_TOOLKIT_REF=main
 ARG PI_EXTENSIONS_REF=main
 # Repo URLs default to the canonical gitea origin but are overridable so a
@@ -128,7 +246,14 @@ ARG PI_EXTENSIONS_REPO=https://gitea.jordbo.se/joakimp/pi-extensions.git
 ARG PI_FORK_REPO=https://github.com/elpapi42/pi-fork.git
 ARG PI_FORK_REF=master
 ARG PI_OBSMEM_REPO=https://github.com/elpapi42/pi-observational-memory.git
-ARG PI_OBSMEM_REF=master
+# PINNED to a full 40-char SHA as of v1.9.5, not `master` — see the PI_VERSION
+# note above for the measurement and the reasoning. Moves together with
+# PI_VERSION by necessity, not by convention. The width matters: 731c3d4 is the
+# same commit, but check-doc-drift.sh recognises a literal SHA only via a
+# 40-char match (SHA40), so a short pin would fall through to its
+# branch-or-tag lookup, fail, and downgrade that component's drift check to a
+# silent SKIP — a pin that reads fine and is no longer verified.
+ARG PI_OBSMEM_REF=731c3d49288580f4d79cabdbfbc0d16b34db0f41
 # pi-atelier (TUI sidebar: ordered panels, split-pane, themes) is PINNED TO A
 # TAG, which CI resolves to that tag's commit SHA — same treatment as
 # pi-studio, for reproducibility plus cache-busting.
@@ -170,9 +295,46 @@ ARG PI_ATELIER_REPO=https://github.com/michaelmjhhhh/pi-atelier.git
 # old and new pin. Included because it was already exercised: the pty matrix
 # for PI_VERSION above ran atelier v0.10.1 against pi 0.85.1 and painted the
 # sidebar identically to v0.10.0.
-ARG PI_ATELIER_REF=v0.10.1
+#
+# v1.9.4: v0.10.1 -> v0.10.3 (both v0.10.2 and v0.10.3 released 2026-09-22).
+# Fixes only per the release notes: sidebar text/borders preserved beside
+# inline images (#53), transcript images hidden while capturing overlays are
+# open, Workspace Pulse skips redundant HEAD/diff when nothing tracked changed
+# (#61), sidebar height from row counts (#59), git/usage scans suspended while
+# disabled, Display Revert + Undo ordering. Checked before bumping: package.json
+# at v0.10.3 still declares zero runtime dependencies and no build script (so
+# the no-`npm install` reasoning above holds) and peerDependencies are still
+# pi >=0.84.0, so it still spans the pinned 0.85.1. 13 commits v0.10.1..v0.10.3,
+# all under src/ tests/ docs/ scripts/ plus metadata; no entry-point move.
+#
+# v1.10.2: v0.10.3 -> v0.13.0, closing the two-minor gap v1.9.5 flagged as the
+# residual risk of the pi bump. peerDependencies are UNCHANGED at pi >=0.84.0
+# across v0.10.3, v0.12.1 and v0.13.0 — still a FLOOR, so still not evidence of
+# anything; the floor is satisfied by 1.0.0 either way. What was actually
+# checked, 2026-10-02:
+#   - v0.13.0 CARRIES ITS OWN BREAKING CHANGE, unrelated to pi: "The package
+#     entry point now exports only the sidebar contribution protocol
+#     (`registerSidebarPanel`, guards, size limits, event types). The internal
+#     registry and layout helpers are no longer exported." Harmless HERE only
+#     because nothing of ours imports them: a grep for `pi-atelier` and
+#     `registerSidebarPanel` across mempalace-toolkit, pi-devbox,
+#     pi-extensions, pi-fork, pi-observational-memory and pi-studio returns
+#     ZERO matches in all six. atelier is a leaf here — it registers its own
+#     sidebar and no one consumes its API.
+#   - Settings churn in the gap, checked against our own tree: v0.12.0 REMOVED
+#     the `showSessionActions` setting (0 references here) and migrated the
+#     Control Center shortcut Alt+A -> F6 (0 references here, so no doc goes
+#     stale). `showSidebarAgent` / `showSidebarTodos`, the only atelier keys
+#     README names, are both still documented in v0.13.0's README.
+#   - The TUI internals atelier patches (`TuiMainScreen`, `renderLayoutFrame`)
+#     are both still present in pi 1.0.0's dist, and atelier's changelog shows
+#     it has handled fullscreen vs regular renderers explicitly since 0.84.
+#   - Residual: v0.13.0 is SAME-DAY upstream (2026-10-02). Acceptance proves
+#     the sidebar PAINTS with the two-sided check from 0.84.4/0.85.1 that can
+#     tell "loaded" from "silently absent" — "no crash" is not the test.
+ARG PI_ATELIER_REF=v0.13.0
 # Human-readable tag PI_ATELIER_REF was resolved from; recorded as a label.
-ARG PI_ATELIER_VERSION=v0.10.1
+ARG PI_ATELIER_VERSION=v0.13.0

 RUN set -e && \
    # git_fetch_ref: clone-equivalent helper that accepts EITHER a branch name
@@ -282,6 +444,22 @@ RUN set -e && \
    echo "pi-observational-memory at $(cd /opt/pi-observational-memory && git rev-parse --short HEAD)" && \
    echo "pi-atelier at $(cd /opt/pi-atelier && git rev-parse --short HEAD) (${PI_ATELIER_VERSION})"

+# ── git: let the unprivileged user read the root-owned /opt clones ──────────
+# The clones above (and /opt/mempalace-toolkit from the base, /opt/pi-studio in
+# the studio variant) are root-owned; the container runs as `developer`. Since
+# git 2.35.2 (CVE-2022-24765) any git command in a repo owned by another user
+# fails with "dubious ownership" — so `git -C /opt/pi-extensions rev-parse`
+# returns nothing, `install.sh` used to abort on it, and acceptance checks that
+# read a baked ref via git silently measured "" (v1.9.4 first-boot run: one
+# false FAIL from exactly this). Listing the paths (not `*`) keeps the check
+# meaningful for everything else, e.g. the virtiofs-mounted /workspace.
+# Entries for paths absent in a variant (pi-studio) are inert.
+RUN for d in pi-toolkit pi-extensions pi-fork pi-observational-memory pi-atelier \
+             mempalace-toolkit pi-studio; do \
+      git config --system --add safe.directory "/opt/${d}"; \
+    done && \
+    git config --system --get-all safe.directory
+
 # ── Image-baked skill refresh: pi-extensions (Option 1 over Option 2) ──
 # rootfs ships a VENDORED snapshot of the pi-extensions skill at
 # /usr/local/share/pi-devbox/skills/pi-extensions/ (the "floor" — guarantees the
@@ -358,6 +358,61 @@ DOT syntax errors instead of crashing. Then in Studio: open the PNG (or a
 `.md` that embeds it) and hit **refresh-from-disk** after each edit.
 Note: SVG is **not** in Studio's local-image-link allowlist — use PNG.

+## Terminal UI mode: fullscreen is the default (since v1.10.2)
+
+pi **1.0.0** changed the default terminal UI mode to **fullscreen**, and this
+image adopts upstream's default rather than overriding it. Fullscreen draws into
+the terminal's alternate screen, so pi's transcript no longer accumulates in your
+terminal's native scrollback — you scroll inside pi instead, and on exit pi
+prints the transcript (`fullscreenExitOutput`).
+
+That is a real behaviour change if you were used to the old mode, so here is the
+way back. Nothing in the image is pinned, so all three routes below work:
+
+| Scope | How |
+|---|---|
+| **Permanently, for every session** | add `"tuiMode": "regular"` to `~/.pi/agent/settings.json` |
+| **One session** | `pi --tui-mode regular` |
+| **One project only** | add `"tuiMode": "regular"` to that project's `.pi/settings.json` — project settings override the agent directory |
+
+The settings file is plain JSON and `tuiMode` is top-level, so the minimal
+permanent change is:
+
+```bash
+# merge the key without disturbing the rest of the file (python3 is always present)
+python3 - <<'PY'
+import json, pathlib
+p = pathlib.Path.home() / ".pi/agent/settings.json"
+d = json.loads(p.read_text()) if p.exists() else {}
+d["tuiMode"] = "regular"        # "fullscreen" is pi's default
+p.write_text(json.dumps(d, indent=2) + "\n")
+PY
+```
+
+If you stay on fullscreen, four related settings are worth knowing — all
+documented in pi's own `docs/settings.md` under *Terminal and display*:
+
+- `fullscreenExitOutput` — `"transcript"` (default) or `"resume-hint"`: what pi
+  leaves behind in the terminal when fullscreen exits.
+- `fullscreenScrollbar` — `"auto"` (default), `"always"`, `"hidden"`.
+- `fullscreenCopyOnSelect` — `true` by default; selecting text copies it.
+- `fullscreenWheelScrollLines` — `"auto"` by default. Relevant **here** in
+  particular: this container is normally driven over SSH, and over SSH `"auto"`
+  accelerates fast wheel spins to at most 6 lines per event (local macOS
+  terminals accelerate on their own, so there it moves one line). `Alt`+wheel
+  moves five times as far.
+
+Two notes specific to this image:
+
+- **tmux.** Fullscreen uses the alternate screen, so `tmux` copy-mode scrollback
+  shows the pane's history *around* pi, not pi's transcript. Scroll within pi,
+  or use `"tuiMode": "regular"` if you rely on tmux copy-mode to search the
+  conversation.
+- **pi-atelier.** The bundled sidebar works in both modes — upstream has handled
+  regular and fullscreen renderers separately since pi 0.84, including
+  fullscreen divider dragging and keeping sidebar text out of fullscreen
+  selection — so switching back to `regular` does not cost you the sidebar.
+
 ## Using pi-atelier (TUI sidebar)

 `pi-atelier` is bundled in **both** variants (vendored at `/opt/pi-atelier`,
@@ -572,7 +627,13 @@ ChromaDB ONNX embedding model so first-time semantic search is
 instant.

 The palace data lives at `~/.mempalace/palace` on the host
-(bind-mounted into the container). This means:
+(bind-mounted into the container). The image pins that layout with
+`ENV MEMPALACE_CONFIG_DIR=/home/developer/.mempalace` (`Dockerfile.base`):
+mempalace ≥ 3.10.0 would otherwise treat an *empty* `~/.mempalace` — a freshly
+mounted volume at first boot — as "no install here" and put a new palace under
+`~/.config/mempalace`, outside anything the compose files persist. With the
+variable set, first in mempalace's resolution order, the location is a contract
+rather than a heuristic. This means:

 - A pi running on the host and a pi running inside this container see
  the same palace.
@@ -1100,7 +1161,7 @@ persisted volumes survived, and pi runtime wiring is intact:
 ```bash
 ./scripts/recreate-sanity-check.sh                              # auto-detects variant
 ./scripts/recreate-sanity-check.sh --expected-image-version 1.8.9  # assert the pi-devbox release tag
-./scripts/recreate-sanity-check.sh --expected-version 0.85.1        # assert the pi coding agent version
+./scripts/recreate-sanity-check.sh --expected-version 1.0.0          # assert the pi coding agent version
 ```

 Those are **two different versions**, and the flags are not interchangeable:
@@ -1139,9 +1200,10 @@ resolved to `latest` at build time:

 | Component | Pin | Where |
 |---|---|---|
-| pi | `0.85.1` | `ARG PI_VERSION` — `Dockerfile.variant` |
-| pi-atelier | `v0.10.1` | `ARG PI_ATELIER_REF` — `Dockerfile.variant` |
-| mempalace | `3.9.0` | `ARG MEMPALACE_VERSION` — `Dockerfile.base` |
+| pi | `1.0.0` | `ARG PI_VERSION` — `Dockerfile.variant` |
+| pi-obsmem | `731c3d49288580f4d79cabdbfbc0d16b34db0f41` | `ARG PI_OBSMEM_REF` — `Dockerfile.variant` |
+| pi-atelier | `v0.13.0` | `ARG PI_ATELIER_REF` — `Dockerfile.variant` |
+| mempalace | `3.10.0` | `ARG MEMPALACE_VERSION` — `Dockerfile.base` |

 The objective is **not** to freeze versions. Bumping is routine — usually one
 line plus a changelog note. The objective is that adopting a new upstream
@@ -100,8 +100,21 @@ fi
 # existing data. `--yes` auto-accepts detected entities so the init is
 # non-interactive.
 if command -v mempalace &>/dev/null && [ -d /workspace ]; then
-  PALACE_DIR="${HOME}/.mempalace"
-  if [ ! -d "$PALACE_DIR/palace" ]; then
+  # Read the root from the same variable mempalace itself reads (set as an
+  # image ENV in Dockerfile.base since mempalace 3.10.0 started resolving
+  # ~/.config/mempalace for an EMPTY ~/.mempalace). The fallback keeps the
+  # historical location for anyone running this script with the ENV unset;
+  # the point of naming the variable here is that this test and mempalace's
+  # own resolution can no longer disagree about where the palace lives — a
+  # disagreement that would make this branch fire on every start.
+  PALACE_DIR="${MEMPALACE_CONFIG_DIR:-${HOME}/.mempalace}"
+  # Sentinel = config.json, because that is what `mempalace init` writes.
+  # It does NOT create palace/ — mining does — so the earlier test on palace/
+  # re-fired on every start of a container that had never mined locally
+  # (v1.9.4 acceptance: 1 "Initializing" line after one boot, 2 after a
+  # restart). Harmless (init is idempotent) but the log lied. Populated
+  # volumes (config.json present) skip either way.
+  if [ ! -f "$PALACE_DIR/config.json" ]; then
    echo "Initializing MemPalace for workspace (non-interactive)..."
    # </dev/null: mempalace init has an interactive "Mine this directory
    # now? [Y/n]" prompt that --yes does not auto-answer in all paths.
@@ -306,6 +319,35 @@ fi
 if [ -f "$HOME/.gitignore_global" ] && ! git config --global core.excludesFile &>/dev/null; then
  git config --global core.excludesFile "$HOME/.gitignore_global"
 fi
+# Route git-over-ssh through the WRITABLE ssh sidecar. ~/.ssh is commonly
+# bind-mounted read-only from the host, and a per-host
+#   ControlPath ~/.ssh/cm/%r@%h:%p
+# inherited from that config (the standard CGNAT multiplexing recipe) kills every
+# push with
+#   unix_listener: cannot bind to path ~/.ssh/cm/...: Read-only file system
+# hidden behind git's misleading "Please make sure you have the correct access
+# rights", which sends the reader hunting for a key problem that does not exist.
+# setup-lan-access.sh (run near the top of this script) already wrote
+# ~/.ssh-local/config, whose leading `Host *` block overrides ControlPath into
+# the writable ~/.ssh-local/cm and only THEN `Include`s the user's own config —
+# so -F repairs the socket path while keeping every per-host User/Port/
+# IdentityFile. Wiring it here means no caller has to know any of that.
+#
+# WHY THIS IS NOT LEFT TO DOCUMENTATION: measured 2026-09-22 on tor-ms22, an
+# agent with the remedy in its system prompt, in a loaded skill, in 24 palace
+# drawers, AND printed verbatim by recreate-sanity-check.sh two hours earlier
+# still hit this and reinvented a /tmp/sshcm workaround. The knowledge was
+# available four times over, so a fifth copy is not the fix — removing the need
+# to know is.
+#
+# The [ -r ] guard is load-bearing, not decoration: setup-lan-access.sh only
+# writes the sidecar on VM-backed hosts (OrbStack / Docker Desktop). On native
+# Linux Docker there is none, and pointing -F at a missing file would break EVERY
+# git-over-ssh operation instead of fixing one. Respect a value the user already
+# set — same first-wins convention as the three settings above.
+if [ -r "$HOME/.ssh-local/config" ] && ! git config --global core.sshCommand &>/dev/null; then
+  git config --global core.sshCommand "ssh -F $HOME/.ssh-local/config"
+fi

 # ── pi: deploy toolkit + extensions + mempalace bridge ─────────────
 # pi is always installed in pi-devbox; no INSTALL_PI guard needed.
@@ -181,8 +181,14 @@ check_pin() {
 PI_ACTUAL="$(read_arg "$DF_VARIANT" PI_VERSION)"
 ATELIER_ACTUAL="$(read_arg "$DF_VARIANT" PI_ATELIER_REF)"
 MEMPALACE_ACTUAL="$(read_arg "$DF_BASE" MEMPALACE_VERSION)"
+# pi-obsmem became a PIN in v1.9.5 (was the floating `master`), so it joins the
+# reviewable table. It is also covered by the ref-move check below, but that one
+# can only ever report "unchanged" for a pinned SHA -- it answers "did upstream
+# move?", never "does the table still say what we bake?", which is this check.
+OBSMEM_PIN_ACTUAL="$(read_arg "$DF_VARIANT" PI_OBSMEM_REF)"

 check_pin pi              "$(read_pin_row pi)"          "$PI_ACTUAL"        "ARG PI_VERSION in $DF_VARIANT"
+check_pin pi-obsmem       "$(read_pin_row pi-obsmem)"   "$OBSMEM_PIN_ACTUAL" "ARG PI_OBSMEM_REF in $DF_VARIANT"
 check_pin pi-atelier      "$(read_pin_row pi-atelier)"  "$ATELIER_ACTUAL"   "ARG PI_ATELIER_REF in $DF_VARIANT"
 check_pin mempalace       "$(read_pin_row mempalace)"   "$MEMPALACE_ACTUAL" "ARG MEMPALACE_VERSION in $DF_BASE"

@@ -0,0 +1,69 @@
+#!/usr/bin/env bash
+# Guard: Dockerfile.variant must OPEN with its BuildKit `# check=` directive.
+#
+# Why this is a gate and not a comment. BuildKit parses `# check=` ONLY before
+# any other line in the file, so moving it below the title comment — or dropping
+# it during an unrelated header edit — silently re-enables the
+# InvalidDefaultArgInFrom warning on `ARG BASE_IMAGE` / `FROM ${BASE_IMAGE}`.
+#
+# A re-enabled warning is not cosmetic. buildx attaches the warning's source
+# context to the build metadata as buildx.build.warnings[].sourceInfo.data: the
+# entire Dockerfile, base64, on ONE line. docker/build-push-action writes that
+# metadata to $GITHUB_OUTPUT as a `name<<ghadelimiter_<uuid>` heredoc, and
+# Gitea's act_runner truncates any single line at exactly 65536 chars. Since
+# base64(Dockerfile.variant) passed 64 KiB (50034 B source -> 66712 chars, cut
+# to 65536), the closing delimiter is lost and act_runner fails the job with
+#   invalid format delimiter 'ghadelimiter_...' not found before end of file
+# while attributing it to NO step: every step reports Success, the smoke suite
+# prints "0 failed", and the job is red regardless. That cost two tags —
+# v1.10.0 (run 704, where a stale clipboard assertion masked it) and v1.10.1
+# (run 707) — and most of a session to localise.
+#
+# So: one deterministic grep, run both on push AND in the publish workflow's
+# lint-gate. A check that gates only `push` lets a tag regress — the same
+# adoption slip that let doc-drift land 27 h after the v1.9.3 tag.
+#
+# Exit codes: 0 OK, 1 violation, 2 cannot-run (missing file) — matching
+# lint-shell.sh / check-skill-floor.sh / check-doc-drift.sh, because a gate that
+# cannot run must not pass.
+set -euo pipefail
+
+DF="${1:-Dockerfile.variant}"
+EXPECTED='# check=skip=InvalidDefaultArgInFrom'
+
+if [ ! -f "$DF" ]; then
+  echo "::error::check-dockerfile-directives: '$DF' not found (cannot-run)" >&2
+  exit 2
+fi
+
+first="$(head -n 1 "$DF")"
+if [ "$first" != "$EXPECTED" ]; then
+  {
+    echo "::error::$DF line 1 must be exactly: $EXPECTED"
+    echo "::error::found instead: ${first:-<empty>}"
+    echo "::error::"
+    echo "::error::BuildKit only honours '# check=' before any other line. Without it the"
+    echo "::error::InvalidDefaultArgInFrom warning returns, buildx embeds this whole file as"
+    echo "::error::base64 in buildx.build.warnings[].sourceInfo.data, that single line exceeds"
+    echo "::error::act_runner's 65536-char cap, and the smoke jobs fail with"
+    echo "::error::  invalid format delimiter 'ghadelimiter_...' not found before end of file"
+    echo "::error::and NO failing step. See the header of $DF for the full measurement."
+  } >&2
+  exit 1
+fi
+
+# Second, independent assertion: the condition the directive exists FOR. If a
+# later edit gives ARG BASE_IMAGE a default, the directive becomes dead weight
+# and should be removed deliberately rather than left to rot — and if the ARG is
+# renamed, this guard would otherwise keep passing while guarding nothing.
+if ! grep -qE '^ARG BASE_IMAGE$' "$DF"; then
+  {
+    echo "::error::$DF no longer contains a bare 'ARG BASE_IMAGE' (no default)."
+    echo "::error::That is the only thing '$EXPECTED' suppresses. Either restore the bare ARG"
+    echo "::error::or drop the directive and this guard together — do not leave a skip"
+    echo "::error::directive pointing at a check that can no longer fire."
+  } >&2
+  exit 1
+fi
+
+echo "Dockerfile directive guard OK — $DF opens with the check-skip directive and still declares a bare ARG BASE_IMAGE."
@@ -502,13 +502,33 @@ _ssh_cm_probe() {
  elif [ "${#bad[@]}" -eq 0 ]; then
    pass "$label: $n ControlMaster host(s), every ControlPath dir exists and is writable"
  elif [ "$sev" = "warn" ]; then
-    warn "$label: ${#bad[@]}/$n host(s) resolve ControlPath to a missing or unwritable dir [$shown] — expected when ~/.ssh/config pins ControlPath inside the read-only ~/.ssh; use 'ssh -F ~/.ssh-local/config' (see Dockerfile.base CAVEAT)"
+    warn "$label: ${#bad[@]}/$n host(s) resolve ControlPath to a missing or unwritable dir [$shown] — STRUCTURAL and permanent while ~/.ssh/config pins ControlPath inside the read-only ~/.ssh, so this line can never reach zero and is not a to-do; $_git_ssh_note (see Dockerfile.base CAVEAT)"
  else
    fail "$label: ${#bad[@]}/$n host(s) resolve ControlPath to a missing or unwritable dir [$shown] — ssh dies rc=255 'unix_listener: cannot bind to path' and the remote command never runs"
  fi
 }

 if command -v ssh >/dev/null 2>&1; then
+  # Whether git-over-ssh already routes through the sidecar decides how much the
+  # permanent default-route warning below actually matters, so state it IN that
+  # message rather than leaving each reader to work it out. Asserted properly as
+  # its own pass/fail in the next section.
+  #
+  # THREE states, not two, and the [ -r ] test is why: core.sshCommand NAMING the
+  # sidecar does not mean the sidecar EXISTS. Without that test, the arm where the
+  # path is wired but the file is gone printed "git IS wired ... unaffected" about
+  # a state in which every single git-over-ssh call fails. Found by exercising all
+  # five arms of this check rather than only the healthy one.
+  if [ ! -r "$HOME/.ssh-local/config" ]; then
+    _git_ssh_note="there is no ssh sidecar on this host, so nothing for -F to point at and these hosts cannot multiplex at all — see the git-over-ssh check below"
+  elif command -v git >/dev/null 2>&1 &&
+       git config --global --get core.sshCommand 2>/dev/null |
+         grep -qF -- "-F $HOME/.ssh-local/config"; then
+    _git_ssh_note="git IS wired to the sidecar (core.sshCommand), so git push/fetch is unaffected; bare 'ssh' to these hosts still needs 'ssh -F ~/.ssh-local/config'"
+  else
+    _git_ssh_note="git is NOT wired to the sidecar (see the git-over-ssh check below), so both git and bare 'ssh' need 'ssh -F ~/.ssh-local/config'"
+  fi
+
  # Concrete Host aliases only: patterns (*, ?) and negations (!) are not
  # connectable targets, so `ssh -G` on them proves nothing.
  _cm_cfgs=()
@@ -535,6 +555,46 @@ else
  warn "ssh not on PATH — effective ControlPath not verified"
 fi

+echo
+echo "-- git-over-ssh routed through the writable ssh sidecar --"
+# The one question in this area that is BINARY, FIXABLE, and therefore worth a
+# check that can reach zero and stay there.
+#
+# The ControlPath warning above cannot: while a bind-mounted ~/.ssh/config pins
+# ControlPath inside the read-only ~/.ssh, the default route will ALWAYS resolve
+# to an unwritable dir, so that line fires benignly on every run of every device
+# forever — and the script's own comment above says why that is dangerous: it is
+# a warning you learn to skip. MEASURED 2026-09-22, exactly that: an agent ran
+# this script, recorded "two by-design warnings", then two hours later hit
+# `unix_listener: cannot bind ... Read-only file system` on `git push`, failed to
+# connect it to the warning it had already read, and reinvented a /tmp/sshcm
+# workaround — while the remedy string sat inside the dismissed warning.
+# entrypoint-user.sh now wires core.sshCommand to the sidecar so nobody has to
+# know; this section asserts the wiring actually happened, which is the part a
+# reader can act on.
+if ! command -v git >/dev/null 2>&1; then
+  warn "git not on PATH — sidecar wiring not verified"
+elif [ ! -r "$HOME/.ssh-local/config" ]; then
+  # No sidecar (native Linux Docker, where setup-lan-access.sh writes none). The
+  # correct state is UNSET: -F pointing at a missing file breaks every
+  # git-over-ssh call, which is worse than the problem being solved.
+  if [ -z "$(git config --global --get core.sshCommand 2>/dev/null || true)" ]; then
+    pass "no ssh sidecar on this host and core.sshCommand correctly unset (guard holds)"
+  else
+    fail "core.sshCommand is set but ~/.ssh-local/config does not exist — every git-over-ssh call dies on a missing -F file; entrypoint-user.sh's [ -r ] guard did not hold"
+  fi
+else
+  _git_ssh_cmd=$(git config --global --get core.sshCommand 2>/dev/null || true)
+  case "$_git_ssh_cmd" in
+    *"-F $HOME/.ssh-local/config"*)
+      pass "git core.sshCommand routes through the sidecar ($_git_ssh_cmd)" ;;
+    '')
+      fail "a sidecar exists but git core.sshCommand is unset — 'git push' to any host whose config pins ControlPath inside the read-only ~/.ssh dies rc=255 behind git's misleading 'correct access rights'. entrypoint-user.sh should set it; expected on images built before that wiring landed, where the fix is: git config --global core.sshCommand \"ssh -F \$HOME/.ssh-local/config\"" ;;
+    *)
+      warn "git core.sshCommand set to something else and left alone (first-wins, deliberate): $_git_ssh_cmd" ;;
+  esac
+fi
+
 echo
 echo "-- Shell defaults re-seeded from /etc/skel-devbox --"
 if [ -f "$HOME/.bash_aliases" ]; then
@@ -30,7 +30,7 @@
 #     client bundle present + registered via `pi install`
 #   - no foreign npm-11 platform packages (@esbuild, clipboard) beyond the host
 #   - no build-time npm cache (/root/.npm) shipped in the image
-#   - esbuild compiles + clipboard native loads at every install site
+#   - esbuild compiles everywhere; clipboard present iff pi declares it
 #   - image size within threshold

 set -euo pipefail
@@ -250,6 +250,22 @@ run_expect "remote-palace-without-inbox skip is announced, not silent" \
    "MemPalace catch-up skipped"
 run "...and the skip notice names the variable that fixes it" \
    "grep -A6 'MemPalace catch-up skipped' /usr/local/bin/entrypoint-user.sh | grep -q 'MEMPALACE_PI_SSH_TARGET'"
+# git-over-ssh must be wired to the writable ssh sidecar, because ~/.ssh is
+# commonly bind-mounted READ-ONLY and a per-host `ControlPath ~/.ssh/cm/...`
+# inherited from it kills every push with `unix_listener: cannot bind ...:
+# Read-only file system` behind git's misleading "correct access rights".
+#
+# STATIC assertion, deliberately. `run` executes `docker run --entrypoint=""`, so
+# entrypoint-user.sh never runs here and `git config --global core.sshCommand` is
+# necessarily unset — asserting the VALUE in this harness would repeat the v1.8.0
+# mistake (an assertion that cannot pass, unvalidated until the next tag). What
+# IS checkable at build time is that the wiring code shipped in the image. The
+# runtime value is asserted below in the Runtime deployment section, where the
+# real entrypoint chain has run.
+run "entrypoint wires git core.sshCommand to the ssh sidecar" \
+    "grep -q 'core.sshCommand \"ssh -F' /usr/local/bin/entrypoint-user.sh"
+run "...and guards it on the sidecar existing (native Linux has none)" \
+    "grep -B2 'core.sshCommand \"ssh -F' /usr/local/bin/entrypoint-user.sh | grep -q '\\[ -r \"\$HOME/.ssh-local/config\" \\]'"
 # A remote mine that FAILS must not report success. MCP answers a hard tool
 # failure with HTTP 200 and the tool's own JSON escaped inside
 # result.content[].text, so the feeder's old `'\"error\"' in body` check could
@@ -659,6 +675,23 @@ exec_test "settings.json bootstrapped"             'test -f $HOME/.pi/agent/sett
 exec_test "pi-devbox-environment skill linked"     'test -L $HOME/.agents/skills/pi-devbox-environment && test -f $HOME/.agents/skills/pi-devbox-environment/SKILL.md && echo ok'
 exec_test "pi-extensions skill linked (fallback)"  'test -L $HOME/.agents/skills/pi-extensions && test -f $HOME/.agents/skills/pi-extensions/SKILL.md && echo ok'
 exec_test "mempalace skill linked (fallback)"      'test -L $HOME/.agents/skills/mempalace && test -f $HOME/.agents/skills/mempalace/SKILL.md && echo ok'
+# git-over-ssh sidecar wiring, asserted as a BICONDITIONAL rather than "is set".
+# setup-lan-access.sh writes ~/.ssh-local/config only on VM-backed hosts, and a
+# CI runner is native Linux Docker — so "core.sshCommand is set" would fail here
+# for a correct image, which is precisely the v1.8.0 trap (an assertion whose
+# environment was never checked, unvalidated until the next tag). Both arms are
+# real: sidecar present => must route through it; sidecar absent => must be UNSET,
+# because -F pointing at a missing file breaks every git-over-ssh call and is
+# worse than the problem being fixed. This arm is the one CI actually exercises,
+# so CI validates the guard; the other is covered by the static greps above and
+# by scripts/recreate-sanity-check.sh on a real device.
+exec_test "git core.sshCommand matches sidecar presence" '
+  cmd=$(git config --global --get core.sshCommand 2>/dev/null || true)
+  if [ -r "$HOME/.ssh-local/config" ]; then
+    case "$cmd" in *"-F $HOME/.ssh-local/config"*) echo "wired: $cmd" ;; *) exit 1 ;; esac
+  else
+    [ -z "$cmd" ] || exit 1; echo "no sidecar, correctly unset"
+  fi'
 # The vendored mempalace snapshot is refreshed MANUALLY per release (see
 # rootfs/usr/local/share/pi-devbox/skills/VENDORED.md). Through v1.8.4 it also
 # silently SHADOWED the live skillset copy, so staleness was invisible — and the
@@ -953,11 +986,27 @@ run "no build-time npm cache shipped (/root/.npm)" \
 run "esbuild works at every install site (prune removed weight, not function)" \
  'sites=$(find /usr/lib/node_modules /opt -type d -path "*/node_modules/esbuild" -prune 2>/dev/null); if [ -z "$sites" ]; then echo "no esbuild install found at all" >&2; exit 1; fi; for d in $sites; do node -e "require(\"$d\").transformSync(\"const x:number=1\",{loader:\"ts\"})" || { echo "esbuild broken at $d" >&2; exit 1; }; done; echo ok'

-# Clipboard is the family pruned second, and its napi-rs loader picks its native
-# binding at require() time — so a successful load IS the proof that the kept
-# platform package is the one this image needs.
-run "clipboard native loads at every install site" \
-  'sites=$(find /usr/lib/node_modules /opt -type d -path "*/node_modules/@mariozechner/clipboard" -prune 2>/dev/null); if [ -z "$sites" ]; then echo "no @mariozechner/clipboard install found at all" >&2; exit 1; fi; for d in $sites; do node -e "var c=require(\"$d\"); if (typeof c.setText !== \"function\") { throw new Error(\"native binding missing\"); }" || { echo "clipboard native broken at $d" >&2; exit 1; }; done; echo ok'
+# Clipboard is the family pruned second. Upstream pi 0.86.0 (#9163) REPLACED the
+# external `@mariozechner/clipboard` dependency with bundled macOS/Windows/X11
+# helpers plus the OSC 52 fallback, so from 0.86.0 on there is nothing external to
+# prune and nothing to require(). pi 0.85.1 declared it; 0.87.1 and 1.0.0 do not.
+# This assertion therefore derives its expectation from what the image's pi
+# actually DECLARES rather than hardcoding either state: it re-arms by itself if a
+# future pi re-adds the dependency, and it still fails if an install lingers that
+# nothing depends on. Hardcoding "must exist" is what failed the v1.10.0 tag build
+# (100 passed, 1 failed, nothing published) against a perfectly correct image.
+run "clipboard native: present iff pi declares it (prune removed weight, not function)" \
+  'PKG=/usr/lib/node_modules/@earendil-works/pi-coding-agent/package.json;
+   if grep -q "\"@mariozechner/clipboard\"" "$PKG" 2>/dev/null; then declared=yes; else declared=no; fi;
+   sites=$(find /usr/lib/node_modules /opt -type d -path "*/node_modules/@mariozechner/clipboard" -prune 2>/dev/null);
+   if [ "$declared" = yes ]; then
+     [ -n "$sites" ] || { echo "pi declares @mariozechner/clipboard but NO install found - prune removed function" >&2; exit 1; };
+     for d in $sites; do node -e "var c=require(\"$d\"); if (typeof c.setText !== \"function\") { throw new Error(\"native binding missing\"); }" || { echo "clipboard native broken at $d" >&2; exit 1; }; done;
+     echo "ok: pi declares it and the native binding loads at every site";
+   else
+     [ -z "$sites" ] || { echo "pi no longer declares @mariozechner/clipboard yet installs remain: $sites" >&2; exit 1; };
+     echo "ok: pi bundles clipboard since upstream 0.86.0 (#9163); no external install expected";
+   fi'

 # ── Image size ────────────────────────────────────────────────────────
 echo ""