From ea6605bfae2ab64e79f5175d1b867838de5da36c Mon Sep 17 00:00:00 2001 From: Joakim Persson Date: Sun, 18 Oct 2026 17:19:26 +0200 Subject: [PATCH] release(v1.12.0): pi 1.3.0, mempalace 3.11.0, pi-atelier v0.16.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Every component at its newest upstream release; each pinned one audited against this image before tagging, none breaking. - ARG PI_VERSION 1.2.0 -> 1.3.0. No breaking-changes section. pi-agent-core, pi-tui and dist/core/extensions are byte-identical to 1.2.0. The only removed export (parseModelPattern, not index-exported) and pi-ai's dropped assistant-message-frame re-export have 0 consumers; all 54 runtime-imported names across the stack and /opt/fleet-pi resolve (negative control reported). With a copy of tor-ms22's ~/.pi/agent: pi -p exits 0 in 10 s, all extensions load, bridge 45 tools, /om:* and /studio offered, atelier paints in both renderers (-ne controls: none). - ARG MEMPALACE_VERSION 3.10.0 -> 3.11.0. init --yes still writes config.json; a 3.10.0-built palace opens, searches and serves MCP under 3.11.0, re-mines its convo file once, then skips it; stdio MCP 45 -> 47 tools, none removed. research() removal: 0 callers. synlig hub stays 3.10.0 (newer-client direction); upgrade notes in CHANGELOG. - ARG PI_ATELIER_REF/VERSION v0.15.0 -> v0.16.0 (3b42825). Additive (keyValues rows, progress bars, two roles, meter background). Protocol and pi floor unchanged; fleet:todos panel renders a real todo on both versions; the meter-background escape tells the two arms apart. - Base rebuilds anyway, so BASE_REBUILD_DATE marker refreshed (uv 0.13.1, gitea-mcp 1.9.0, Node 24.22.0 re-resolve). - CHANGELOG: Unreleased -> v1.12.0 — 2026-10-18. README pin table (and "Three" -> "Four" components), sanity-check example; DOCKER_HUB.md's stale "29 mempalace_* tools". Local gates: check-doc-drift rc 0 (check 9 names pi, mempalace, atelier, pi-extensions), lint-shell, check-workflow-shell, test-link-pi-models 13/13, test-link-pi-extensions 16/16, directive guard, skill floor. --- CHANGELOG.md | 98 ++++++++++++++++++++++++++++++++++++++++++---- DOCKER_HUB.md | 2 +- Dockerfile.base | 27 ++++++++++++- Dockerfile.variant | 45 +++++++++++++++++++-- README.md | 10 ++--- 5 files changed, 163 insertions(+), 19 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index aceec48..8aeb942 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,20 +11,49 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`). --- -## Unreleased +## v1.12.0 — 2026-10-18 -No pin changes. One floating component moves (pi-extensions, below); the rest -is docs and comments. Two of the edited files are baked into the base image -(`rootfs/usr/local/bin/studio-expose` and the `pi-devbox-environment` skill), -and `base_tag` hashes all of `rootfs/`, so **the next release rebuilds the -base** rather than reusing `base-6f3b20266de1`. +Minor release. Headlines: **pi 1.3.0**, **mempalace 3.11.0**, **pi-atelier +v0.16.0**, and **fleet pi extensions linked in at every container start** +(*Added*, below). Every component is at its newest upstream release; each +pinned one was audited for breaking changes against this image before tagging +(*Changed*, below), and none was found. Unchanged upstream, re-checked +2026-10-18: pi-observational-memory `022da5e` (= `master`), pi-studio `v0.10.1` +(`76db01f`, newest tag), pi-fork `e69725c`, pi-toolkit `3760d90`, +mempalace-toolkit `d5a03f4`. The skillset is still at `1e02b44` and its +mempalace `SKILL.md` is byte-identical to the recorded `96b840e`, so the +snapshot is not refreshed (`vendor-mempalace-skill.sh --check`: OK). The base +image is rebuilt (rootfs, `Dockerfile.base` and the mempalace pin all changed), +so the base tools pinned to `latest` re-resolve too: uv `0.13.0` → `0.13.1`, +gitea-mcp `v1.8.1` → `v1.9.0` (additive: mTLS, extra headers, +`create_organization`), Node `v24.21.0` → `v24.22.0`; nvim, fzf, gitleaks, +bat, eza, zoxide, git-lfs, gosu, tealdeer, typst, yq, agent-browser and +playwright unchanged. -### Components that move with the next build +### Components that move with this release -| Component | Baked in v1.11.2 | Next build | Why | +| Component | Baked in v1.11.2 | v1.12.0 | Why | |---|---|---|---| +| **pi** | `1.2.0` | **`1.3.0`** | audited, see *Changed* below | +| **mempalace** | `3.10.0` | **`3.11.0`** | audited, see *Changed* below | +| **pi-atelier** | `v0.15.0` (`3befe02`) | **`v0.16.0`** (`3b42825`) | audited, see *Changed* below | | pi-extensions | `750b2a8` | **`4c1d28d`** (or later: CI resolves `main` at build time) | the `confirm-destructive` gate stops prompting on harmless redirects and catches `tee`/`dd of=` (below); picks up the AWS SSO keeper's 24-hour times too (below) | +### Upgrade notes + +- **Local palaces re-mine their conversations once.** mempalace 3.11.0's + exchange chunker no longer discards text, so the first conversation mine + after upgrading re-chunks and re-embeds each conversation file it covers + (drawers of transcripts no longer on disk are kept). This only applies to a + devbox with its own palace: with `MEMPALACE_REMOTE_URL` set, the hub does the + mining, and nothing changes until the hub itself is upgraded. +- **The central palace (synlig) is still on 3.10.0.** That is the safe + direction (newer client), and the bridge's tools come from the hub, so + shared-palace devices see no change. When synlig is upgraded, its first + conversation mine re-mines every inbox transcript still on disk (upstream + estimates 40 minutes to 3 hours per million drawers): back it up first and + run it at a quiet time. + ### Added - **Fleet pi extensions are linked in at every container start** @@ -49,6 +78,59 @@ base** rather than reusing `base-6f3b20266de1`. `common/pi` from `docker-compose-repo`, and three of them are not reachable from a devbox to create a symlink by hand. +### Changed + +- **pi `1.2.0` → `1.3.0`.** Audited 2026-10-18 on tor-ms22 from an isolated npm + prefix, against the 1.2.0 tarballs unpacked side by side: + - 1.3.0 has **no** breaking-changes section. Its behaviour changes don't + reach this image: `--model` and `enabledModels` now resolve a bare model + id across providers by which one has credentials (every model here is + written `amazon-bedrock/…`, and pi-fork's profiles name a provider); + resumed sessions keep their active tools; a model switch drops the old + model's thinking; `kimi-coding` base-URL overrides need `/v1` (not used). + - pi-agent-core and pi-tui are byte-identical between 1.2.0 and 1.3.0 + (24 and 184 files, same tree hashes), and so is pi's + `dist/core/extensions`. The obsmem turn cap lives in the first and + atelier's painting in the second. + - The only export removed from any type declaration is `parseModelPattern` + (never exported from the package index); pi-ai dropped its + `assistant-message-frame` re-export. Neither has a consumer. All 54 names + that pi-toolkit, pi-extensions, pi-fork, obsmem, pi-studio, pi-atelier, + mempalace-toolkit and the fleet extensions in `/opt/fleet-pi` import at + runtime resolve in 1.3.0; an injected fake name is reported missing. + - With a copy of tor-ms22's real `~/.pi/agent`: `pi -p` exits 0 in 10 s + (1.2.0: 9 s) with nothing on stderr. The TUI loads every extension with no + extension issues; the mempalace bridge registers its 45 tools; + `/om:status`, `/om:view` and the `/studio` commands are offered; and the + atelier sidebar paints ACTIVITY/READY/TOOLS in fullscreen and regular mode + (with `-ne`: no sidebar). pi shows its 1.3.0 "What's new" once and records + `lastChangelogVersion`; nothing else in `settings.json` changes. +- **mempalace `3.10.0` → `3.11.0`.** Core requirements unchanged. Measured with + both wheels in throwaway venvs and a throwaway palace: + - `mempalace init --yes` (the entrypoint's first-run call) still writes + `config.json`, rc 0. + - A palace built by 3.10.0 opens under 3.11.0, searches, and serves MCP with + no embedder warning. Its one conversation file was re-mined once (see + *Upgrade notes*) and skipped on the next mine. + - MCP over stdio lists 47 tools instead of 45. None is removed or renamed; + `mempalace_get_drawers` and `mempalace_delete_drawers` are new, and the 14 + read-only tools now carry `readOnlyHint`. + - The removed `EntityRegistry.research()` / `confirm_research()` have no + caller in pi-devbox, mempalace-toolkit, skillset or myconfigs. +- **pi-atelier `v0.15.0` → `v0.16.0`.** Additive: a contributed sidebar panel + can send label/value rows with an optional progress bar (`keyValues`; plain + `rows` remain the fallback), two new roles (`success`, `caution`), and the + context meter no longer draws a hard-coded dark background, so it works on + light terminals. The panel protocol is unchanged (channel + `pi-atelier:sidebar-panels`, version 1, 24 rows of 160 chars), as is the pi + floor (`>=0.84.0`). On pi 1.3.0 it paints in both renderers, and the fleet's + `fleet:todos` panel (`fleet-todos-panel.ts`, plain rows) showed a todo + written in a real turn, as on v0.15.0. The v0.15.0 run still drew the old + meter background and the v0.16.0 run did not, so each ran the version it + claims. +- **DOCKER_HUB.md no longer says "29 `mempalace_*` tools".** The palace server + decides the set; it now says so, with the measured counts. + ### Fixed - **`confirm-destructive` asked for approval on nearly every `2>/dev/null`** diff --git a/DOCKER_HUB.md b/DOCKER_HUB.md index 2d78fbc..25d0644 100644 --- a/DOCKER_HUB.md +++ b/DOCKER_HUB.md @@ -61,7 +61,7 @@ The entrypoint deploys/registers all of these on first container start. Re-runni ### MemPalace (persistent agent memory) -- **MemPalace** + MCP server — semantic search over conversation history, knowledge graph, diary; queryable via 29 `mempalace_*` tools inside pi +- **MemPalace** + MCP server — semantic search over conversation history, knowledge graph, diary; queryable via `mempalace_*` tools inside pi (the palace server decides the set: the baked 3.11.0 lists 47, a 3.10.0 central server 45) - ChromaDB ONNX embedding model pre-warmed at build time (`all-MiniLM-L6-v2`) - Bind-mount your host's `~/.mempalace` and the host-pi and container-pi share one brain diff --git a/Dockerfile.base b/Dockerfile.base index 3e7ba2b..2638845 100644 --- a/Dockerfile.base +++ b/Dockerfile.base @@ -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-10-14 (v1.11.1 — rootfs skill floor to pi-extensions 750b2a8, mempalace-toolkit d5a03f4; apt and base tools re-resolve (upstream unchanged since 2026-10-12: uv 0.13.0, nvim 0.12.6, fzf 0.74.5); previous marker 2026-10-12 / v1.11.0) +# BASE_REBUILD_DATE: 2026-10-18 (v1.12.0 — mempalace 3.11.0, link-pi-extensions.sh, studio-expose and skill doc fixes; apt and base tools re-resolve (upstream on 2026-10-18: uv 0.13.1, gitea-mcp 1.9.0, Node v24.22.0; nvim 0.12.6, fzf 0.74.5 unchanged); previous marker 2026-10-14 / v1.11.1) # # ── Lineage note ───────────────────────────────────────────────────── # Adapted from opencode-devbox/Dockerfile.base (commit before v1.16.2). @@ -639,7 +639,30 @@ ARG INSTALL_MEMPALACE=true # 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 +# +# v1.12.0: 3.10.0 -> 3.11.0 (PyPI 2026-10-14). Core requirements unchanged. +# Three "Upgrade notes", checked against our callers and measured with both +# wheels in throwaway uv venvs and a throwaway palace: +# - `EntityRegistry.research()` / `confirm_research()` removed: 0 callers in +# pi-devbox, mempalace-toolkit, skillset or myconfigs. +# - The first conversation mine re-mines each covered conversation file once +# (the exchange chunker stopped discarding text). LOCAL palaces only from +# this image: in remote mode the hub does the mining. Measured: a palace +# built by 3.10.0 (84 drawers) re-mined its one convo file under 3.11.0 +# (83 -> 84 drawers, old ones replaced, 2 s); the next mine skipped it. +# - A palace refuses to open with a different embedder than the one that +# built it. The default (MiniLM) is unchanged and nothing here sets +# `embedding_model`; the 3.10.0-built palace opened, searched and served +# MCP under 3.11.0 with no warning. +# `mempalace init --yes` (entrypoint) still writes config.json, rc 0. MCP over +# stdio: 45 -> 47 tools, none removed or renamed (+delete_drawers, +# +get_drawers); 14 read-only tools now carry `readOnlyHint`. Skew: synlig's +# hub is still 3.10.0 (measured 2026-10-18), the newer-client direction, and +# the bridge's tool list comes from the hub, so nothing changes for shared- +# palace devices until synlig upgrades. When it does, ITS first convo mine +# re-mines every inbox transcript still on disk (upstream: 40 min to 3 h per +# million drawers); back it up and run it at a quiet time. +ARG MEMPALACE_VERSION=3.11.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 diff --git a/Dockerfile.variant b/Dockerfile.variant index bb08257..1a9b4b9 100644 --- a/Dockerfile.variant +++ b/Dockerfile.variant @@ -289,7 +289,35 @@ ARG USER_NAME=developer # none); a copy of tor-ms22's real ~/.pi/agent (all packages, pi-extensions # 750b2a8) starts with the same [Extensions] list as on 1.1.0 and no # [Extension issues]; `pi -p` answers PONG via ERDC in 1.0 s, Bedrock in 5.2 s. -ARG PI_VERSION=1.2.0 +# +# v1.12.0: 1.2.0 -> 1.3.0 (npm latest, 2026-10-15). MEASURED 2026-10-18 on +# tor-ms22 from an isolated npm prefix, against the 1.2.0 tarballs unpacked +# side by side: +# 1. NO `### Breaking Changes` section in 1.3.0. Behaviour changes, none of +# which reaches us: `--model`/`enabledModels` resolve a bare id across +# providers by credentials (ours are all `amazon-bedrock/...`, and +# pi-fork's effortProfiles name a provider); resumed sessions restore +# their active tools; thinking from another model is dropped on a model +# switch; `kimi-coding` base-URL overrides need `/v1` (not used). +# 2. pi-agent-core and pi-tui 1.2.0 -> 1.3.0: dist BYTE-IDENTICAL (tree +# hashes 6a2819f6 / 92eecf92, 24 / 184 files), and so is pi-coding-agent's +# dist/core/extensions. So obsmem's turn cap (agent-core) and atelier's +# painting (pi-tui) cannot have moved there; atelier's internals +# TuiMainScreen / renderLayoutFrame are in the same number of dist files. +# 3. Public API: the only removed export in any .d.ts is +# `parseModelPattern` (model-resolver, never re-exported from the package +# index), and pi-ai dropped its `assistant-message-frame` re-export. 0 +# consumers of either. All 54 runtime-imported names across pi-toolkit, +# pi-extensions, pi-fork, obsmem, pi-studio, pi-atelier, mempalace-toolkit +# and /opt/fleet-pi resolve in 1.3.0 (control: an injected fake name is +# reported missing). +# 4. engines.node is still `>=22.19.0`; internal deps are now exact pins. +# Exercised before tagging, with a copy of tor-ms22's real ~/.pi/agent: +# `pi -p` exits 0 in 10 s (1.2.0: 9 s), nothing on stderr; the TUI loads every +# extension with no [Extension issues], the bridge registers its 45 tools, +# /om:status, /om:view and the /studio commands are offered, and atelier +# paints ACTIVITY/READY/TOOLS in both renderers (controls with -ne: none). +ARG PI_VERSION=1.3.0 ARG PI_TOOLKIT_REF=main ARG PI_EXTENSIONS_REF=main # Repo URLs default to the canonical gitea origin but are overridable so a @@ -416,9 +444,20 @@ ARG PI_ATELIER_REPO=https://github.com/michaelmjhhhh/pi-atelier.git # renderers on pi 1.1.0 before tagging (see the PI_VERSION note). # v1.11.2: unchanged (still the newest tag); painted in both renderers on # pi 1.2.0 before tagging. -ARG PI_ATELIER_REF=v0.15.0 +# v1.12.0: v0.15.0 -> v0.16.0 (3b42825, 2026-10-15). Additive: contributed +# panels may send label/value rows with an optional progress bar (`keyValues`; +# plain `rows` stay the fallback) and two new roles, and the context meter +# loses its hard-coded dark background. Protocol unchanged (channel +# `pi-atelier:sidebar-panels`, version 1, 24 rows, 160 chars), peer floor +# unchanged (pi >=0.84.0), still zero runtime dependencies. On pi 1.3.0 it +# paints in both renderers, and the fleet's contributed `fleet:todos` panel +# (/opt/fleet-pi/fleet-todos-panel.ts, plain rows) shows a todo written in a +# real turn, as on v0.15.0. The v0.15.0 arm still draws the old meter +# background (48;2;48;53;56) and the v0.16.0 arm does not, so the arms ran the +# code they claim. +ARG PI_ATELIER_REF=v0.16.0 # Human-readable tag PI_ATELIER_REF was resolved from; recorded as a label. -ARG PI_ATELIER_VERSION=v0.15.0 +ARG PI_ATELIER_VERSION=v0.16.0 RUN set -e && \ # git_fetch_ref: clone-equivalent helper that accepts EITHER a branch name diff --git a/README.md b/README.md index 50a5c6e..a5121ea 100644 --- a/README.md +++ b/README.md @@ -1289,7 +1289,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 1.2.0 # assert the pi coding agent version +./scripts/recreate-sanity-check.sh --expected-version 1.3.0 # assert the pi coding agent version ``` Those are **two different versions**, and the flags are not interchangeable: @@ -1323,15 +1323,15 @@ user's pull. ### Version pins: pi, pi-atelier, mempalace -Three components are pinned to an exact version **in the repo** instead of being +Four components are pinned to an exact version **in the repo** instead of being resolved to `latest` at build time: | Component | Pin | Where | |---|---|---| -| pi | `1.2.0` | `ARG PI_VERSION` — `Dockerfile.variant` | +| pi | `1.3.0` | `ARG PI_VERSION` — `Dockerfile.variant` | | pi-obsmem | `022da5e5554d04dfdc876ed7dac4a42c6b83dfd4` | `ARG PI_OBSMEM_REF` — `Dockerfile.variant` | -| pi-atelier | `v0.15.0` | `ARG PI_ATELIER_REF` — `Dockerfile.variant` | -| mempalace | `3.10.0` | `ARG MEMPALACE_VERSION` — `Dockerfile.base` | +| pi-atelier | `v0.16.0` | `ARG PI_ATELIER_REF` — `Dockerfile.variant` | +| mempalace | `3.11.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