31 Commits

Author	SHA1	Message	Date
Joakim Persson	c2c42c34a2	docs(v1.10.1): cut v1.10.1; v1.10.0 stays tagged-but-never-published ... v1.10.0's build failed one assertion of 104 and published nothing. Rather than re-point a tag CI had already consumed, the number moves: a version that failed its build should stay failed and readable, not be quietly overwritten with different bytes. CHANGELOG gains a v1.10.1 section carrying the smoke fix (moved out of v1.10.0's Fixed list), and states plainly that everything under v1.10.0 ships here so the big section stays the content record. v1.10.0's heading is marked "tagged, never published — superseded by v1.10.1" with a blockquote naming the commit (12f99c4), the run (704), the four jobs that skipped, and the fact that no image carries the tag. Pre-tag doc sweep, because CI reads docs from the TAG and POSTs DOCKER_HUB.md to the Hub as full_description: - README "Terminal UI mode: fullscreen is the default (since v1.10.0)" -> v1.10.1. A "since" marker pointing at an image nobody can pull is a worse lie than no marker. - Dockerfile.variant decision comments for the pi and pi-atelier bumps -> v1.10.1 (these describe which release carries the change). - scripts/smoke-test.sh deliberately KEEPS "the v1.10.0 tag build" — that one is a historical event and v1.10.0 is its correct name. - DOCKER_HUB.md needed no change: its fullscreen note is version-free. No code changes. RELEASE_TAG is derived from github.ref_name, so nothing in the build hardcodes the version. Base layer does NOT rebuild: no base input (Dockerfile.base, rootfs/**, entrypoint.sh, entrypoint-user.sh) has changed since 12f99c4, so base-decide will cache-hit base-dad0f365ff24, which run 704's build-base already pushed at 07:52:38Z. This retry skips the expensive half. Gates: doc-drift 23 OK / 0 DRIFT / 0 SKIP; base-hash, workflow-shell, skill-floor, lint-shell all rc=0.	2026-10-02 10:36:21 +02:00
Joakim Persson	12f99c49e3	docs(v1.10.0): adopt pi's fullscreen default and document the way back ... Decision: keep pi 1.0.0's default (tuiMode "fullscreen"). No tuiMode is baked, so the image follows upstream rather than pinning the fleet to either mode - but "we inherited a changed default" is only acceptable if the revert is written down, so it now is. README gains a "Terminal UI mode" section ahead of the pi-atelier section, because the two interact. It gives all three scopes, taken from pi 1.0.0's own docs/settings.md and docs/cli.md rather than from the changelog prose: - permanent: "tuiMode": "regular" in ~/.pi/agent/settings.json - one session: pi --tui-mode regular (the flag is real: cli.md:221) - one project: the same key in .pi/settings.json, which overrides the agent directory It also documents the four related settings (fullscreenExitOutput, fullscreenScrollbar, fullscreenCopyOnSelect, fullscreenWheelScrollLines) and two things specific to this image: - tmux: fullscreen uses the alternate screen, so tmux copy-mode shows the pane history AROUND pi, not pi's transcript. That is the concrete reason someone here would want "regular" back. - fullscreenWheelScrollLines "auto" behaves differently over SSH (caps fast wheel spins at 6 lines/event) than in a local macOS terminal (1 line) - worth naming because this container is normally driven over SSH. - pi-atelier works in BOTH modes (upstream has handled regular vs fullscreen renderers separately since pi 0.84), so reverting costs nothing. Stated so nobody assumes the sidebar is the price of the old scrollback. The python3 merge snippet in that section was RUN before being documented: against a realistic settings.json under an overridden HOME, twice, confirming it is idempotent and preserves sibling keys including nested objects and the _comment fields the seeded file uses. Documented code that has never been executed is a guess. DOCKER_HUB.md gets a short version of the same note, because CI reads it from the TAG and POSTs it to Docker Hub as full_description - a behaviour change this visible should not require reading the repo to undo. Gates: doc-drift 23 OK / 0 DRIFT / 0 SKIP / 0 FAIL; base-hash, workflow-shell, skill-floor, lint-shell all rc=0.	2026-10-02 09:00:51 +02:00
Joakim Persson	e026f6f65e	release(v1.10.0): pi 1.0.0 and pi-atelier v0.13.0, on measured evidence ... Renames the unpublished v1.9.5 section to v1.10.0 and adopts the two bumps that section had deliberately deferred. v1.9.5 was never tagged or published, so nothing shipped under that name. A minor, not a patch. v1.9.5 was numbered under the "patch - pi version bumps" rule, but this release 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. pi 0.85.1 -> 1.0.0. v1.9.5 held at 0.87.1 because obsmem's only compatibility work names Pi 0.87 and no upstream issue mentions 0.99 or 1.0. 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, against the published npm tarballs for 0.87.1 and 1.0.0 unpacked side by side: - 1.0.0 has NO "### Breaking Changes" section at all. Those belong to 0.87.0, 0.86.0, 0.84.3, 0.84.0, 0.83.0, 0.80.8, 0.80.7, 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. - 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. - engines.node >=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`, so 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 - mempalace.ts and mcp-loader.ts each run their own MCP client and register tools via pi.registerTool(), which is why they are named mempalace_search and not mcp__mempalace__search. Second route: settings.json has neither an mcpServers block nor an mcp block. Filed upstream under "Changed", not "Breaking", so it would have been easy to meet the hard way. pi-atelier v0.10.3 (ed3837b) -> v0.13.0 (34d26f1), closing the gap v1.9.5 flagged as the pi bump's residual risk. peerDependencies are unchanged at pi >=0.84.0 across v0.10.3/v0.12.1/v0.13.0 - a FLOOR, so not evidence of anything. What was checked instead: v0.13.0 carries its OWN breaking change (the entry point no longer exports the internal registry and layout helpers), which 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. v0.12.0 removed the showSessionActions setting (0 references here) and moved 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 in v0.13.0's README. TuiMainScreen and renderLayoutFrame both still exist in pi 1.0.0's dist. PI_ATELIER_VERSION is bumped with PI_ATELIER_REF; it is a separate ARG and the image label would otherwise have lied. v0.13.0 is an ANNOTATED tag: `ls-remote --tags` reports the tag object (dd06971), not the commit (34d26f1). check-doc-drift.sh resolves the commit, so that is what the CHANGELOG names. The gate caught the wrong SHA on the first attempt - noted in the CHANGELOG for future bumps. NOT PROVEN, and stated so acceptance does not mistake it for cleared: grepping dist shows the SYMBOLS survive, not that their SIGNATURES are unchanged - necessary, not sufficient. 1.0.0 is four days old 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, deliberately NOT overridden: 1.0.0 makes the TUI fullscreen by default, replacing the terminal's normal scrollback. tuiMode: "regular" restores the old behaviour. No baked default is set, so the image inherits upstream's choice rather than silently pinning the fleet. Gates: check-doc-drift 23 OK / 0 DRIFT / 0 SKIP / 0 FAIL; base-hash, workflow-shell, skill-floor, lint-shell all rc=0.	2026-10-02 08:16:37 +02:00
Joakim Persson	9d0b3dec0b	release(v1.9.5): pi 0.87.1 with pi-obsmem pinned to the merged finishTurn fix ... v1.9.4 held pi at 0.85.1 because 0.87.0 REMOVED `shouldStopAfterTurn`, which pi-observational-memory 3.1.4 still used in all three workers. Its peerDeps are `*`, so nothing refuses at install time and the breakage is silent at runtime -- turn caps ignored, workers losing their specialised prompts. PR #83 fixes that and merged 2026-09-23. Re-measured 2026-10-01 across src/agents/{observer,reflector,dropper}/agent.ts, deliberately reusing the v1.9.4 audit's counting method so the numbers compare: e7d77dc (3.1.4, baked in v1.9.4): shouldStopAfterTurn 3, finishTurn 0, systemPrompt 3 731c3d4 (pinned here) : shouldStopAfterTurn 0, finishTurn 3, systemPrompt 0 All three workers migrated, and the 0.86.0 AgentContext.systemPrompt reads are gone too. The coupling is asymmetric and that is why these move in ONE commit: 3.1.4 + 0.87.1 silently ignores turn caps, and 731c3d4 + 0.85.1 breaks the workers outright, because finishTurn does not exist before 0.87.0. Pinned to a SHA rather than waiting for 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 and moves master often (e7d77dc -> 1529e14 -> 731c3d4 in nine days), so waiting means holding pi indefinitely. A pinned SHA keeps the property `master` lacks: rebuilding this tag later produces the same image. The 40-char form is load-bearing, not pedantry. check-doc-drift.sh recognises a literal SHA only through a 40-char match, so a 7-char pin would fall through to its branch-or-tag lookup, fail to resolve, and downgrade pi-obsmem's drift check to a silent SKIP -- a pin that reads correctly and is no longer verified. Full gate run after this change: 23 OK, 0 DRIFT, 0 SKIP, 0 FAIL. 0.99.0/0.99.1/0.99.2 and 1.0.0 all exist upstream and are deliberately skipped: 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. 1.0.0 is its own round. pi-atelier stays at v0.10.3 and is the residual risk. Its peerDeps declare pi >=0.84.0 -- a floor, satisfied -- on both v0.10.3 and the current v0.12.1, so it spans this bump. But atelier hooks pi TUI internals that a declared floor does not protect, and an under-declared floor is exactly what failed to warn anyone at pi 0.84. Acceptance must confirm the sidebar PAINTS, using the two-sided check from 0.84.4/0.85.1 that distinguishes "loaded" from "silently absent". Also here: - check-doc-drift.sh gains a pi-obsmem pin check. The ref-move check covers the same component, but for a pinned SHA it can only answer "upstream did not move", never "the table still says what we bake". - scripts/lint-shell.sh mode 100644 -> 100755. Pre-existing since f25efa0 and the only non-executable script in scripts/; it was latent because both CI steps call it as `bash scripts/lint-shell.sh`, but it failed rc=126 "bad interpreter" when invoked directly. Same dropped-exec-bit signature recorded on 2026-09-22, found the same way: by RUNNING it, not by reading a diff. - Unreleased section renamed to `## v1.9.5 — 2026-10-02`, satisfying the release-gate rule that a tag's CHANGELOG must name its own version.	2026-10-02 00:23:28 +02:00
joakimp	37fcbfcf04	fix: three v1.9.4-acceptance findings (installer WARN, init sentinel, hash collation) ... Unreleased; no pin moves except pi-extensions master 25c1265 -> 143a214. 1. entrypoint-user.sh: first-run sentinel is now config.json, which is what `mempalace init` writes. The old test on palace/ (created by mining, not init) re-fired "Initializing MemPalace" on every boot of a container that never mined locally: v1.9.4 acceptance measured 1 line after one boot, 2 after a restart. Idempotent, so harmless; the comment lied. This file is a base-hash input, so the next tag rebuilds the base (326fb7c03949 predicted with the pinned sort below; f40c4b7b103d before). 2. Dockerfile.variant: `git config --system --add safe.directory` for the seven root-owned /opt clones (listed, not `*`). Since git 2.35.2 any git command in a repo owned by another user fails "dubious ownership"; as `developer` that made `git -C /opt/pi-atelier rev-parse` print nothing (one false FAIL in the v1.9.4 acceptance) and is the root cause of the per-boot "WARN: pi-extensions install.sh failed" (fixed at the source in pi-extensions 143a214; this is the belt to that suspender). Verified live in a v1.9.3 container: add -> rev-parse prints 25c1265, unset -> fatal again; /etc/gitconfig restored to its 5 lines afterwards. 3. docker-publish.yml: `find -print0 | LC_ALL=C sort -z` in base-decide. sort collates per locale; identical rootfs hashed to base-f40c4b7b103d under C/C.UTF-8 (== run 695) and base-d8df62216a81 under sv_SE/en_US.UTF-8. The runner exports LANG=C.UTF-8, so the hash was stable by accident. Pin is hash-neutral: pinned sort + HEAD inputs reproduces f40c4b7b103d exactly. Per-command prefix only; nobody's locale changes. CHANGELOG: new `## Unreleased` above v1.9.4 naming pi-extensions 143a214 (check 9 rc=0), the three fixes, and the synlig 3.10.0 hub upgrade that v1.9.4 listed as still open. One invented URL org (gwpl) caught before commit; upstream is elpapi42, as Dockerfile.variant:151 says. Gates: check-doc-drift rc=0, check-base-hash rc=0, lint-shell rc=0 (16 files), hadolint 2.15.1 rc=0, YAML parses (10 jobs), bash -n rc=0.	2026-09-22 17:20:10 +02:00
joakimp	e3b38cdb0b	release(v1.9.4): mempalace 3.10.0 with a pinned palace root, pi-atelier v0.10.3, pi held at 0.85.1 ... Three pins move or are deliberately held; the CHANGELOG's Unreleased section becomes the v1.9.4 entry in this same commit, because since ee6cb9e the tag build runs check-doc-drift.sh check 9 and every would-bake value must be named above the last published heading. mempalace 3.9.0 -> 3.10.0 (Dockerfile.base). Deferred at v1.9.3 for two "Upgrade notes" items; both re-measured against the 3.10.0 wheel: - New installs resolve ~/.config/mempalace. The order is $MEMPALACE_CONFIG_DIR, then ~/.mempalace IF it holds config.json / people_map.json / palace/chroma.sqlite3, then XDG. An EMPTY ~/.mempalace fails that test, and an empty ~/.mempalace is 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 and `uvx mempalace==3.10.0 init`: config.json landed in ~/.config/mempalace, ~/.mempalace stayed empty, and entrypoint-user.sh's `[ ! -d ~/.mempalace/palace ]` would fire every start. Same run with MEMPALACE_CONFIG_DIR set: everything in ~/.mempalace. => ENV MEMPALACE_CONFIG_DIR=/home/${USER_NAME}/.mempalace, placed in the non-root-user section where USER_NAME is in scope, and entrypoint-user.sh reads PALACE_DIR from the same variable (old path as fallback). Existing volumes were safe either way; this is for first boots. MEMPALACE_PALACE_PATH is still honoured (config.py:927), so smoke-test.sh's stage test holds. - event_list defaults newest-first without a cursor. Server-side: the extension talks to synlig over MEMPALACE_REMOTE_URL, so it lands when the hub upgrades. mempalace-toolkit 2167a1b (floating main) makes every cursor-less call say order:"desc" so the mailbox reads the same window on either server version. Corrected a stale sequencing comment while there: synlig serves the palace as a `uv tool` under systemd (mempalace-serve.service; measured 2026-09-22: mempalace 3.9.0, python 3.12.13, chromadb 1.5.9, no palace container), not via docker-compose.mempalace.yml as the comment had said for two releases. pi-atelier v0.10.1 -> v0.10.3 (Dockerfile.variant). Fixes only (both tags released 2026-09-22); package.json at v0.10.3 still has zero runtime deps and no build script, peerDeps still >=0.84.0. Annotated tags: the CHANGELOG names the peeled SHA ed3837b, which is what resolve-versions bakes and check 9 compares. pi HELD at 0.85.1 while 0.86.1 / 0.87.0 exist. 0.87.0 removed the shouldStopAfterTurn agent option; pi-observational-memory 3.1.4 still uses it and AgentContext.systemPrompt in observer/reflector/dropper (measured: 1 hit per worker in src/agents on both the baked 3.1.3 tree and upstream master; finishTurn 0). peerDeps are `*`, so it would break at runtime, not install. Upstream #82, fix PR #83 open and unmerged. Bump pi and pi-obsmem together once #83 ships. The other extensions are clean against the 0.86/0.87 lists. Verified locally the way CI does: check-doc-drift.sh rc=0 with check 9 reporting all four moved components as named above the v1.9.3 heading; lint-shell.sh rc=0; hadolint 2.15.1 (CI's pin, with .hadolint.yaml) rc=0 on both Dockerfiles; PyPI 3.10.0 present, not yanked. Two claims caught by re-measurement before commit and corrected in the text: a pi issue number that does not exist on the 0.87.0 changelog line, and "8 shouldStopAfterTurn hits" that was 3 (one per worker) in src/. Still open before the tag: run the feeder from the built image against the 3.9.0 hub (dry-run first); recreate acceptance must show ~/.mempalace/palace still passing and no ~/.config/mempalace appearing. After acceptance: upgrade synlig's tool to 3.10.0.	2026-09-22 14:26:10 +02:00
joakimp	9aaff26e3a	docs: the withdrawal fix shipped in v1.9.1 unnamed — say so, and re-pin the canary ... v1.9.1 bakes mempalace-toolkit e68ee20, which contains e2b060a. Requester-side ask withdrawal has therefore been LIVE on every v1.9.1 device since 2026-09-10, while the v1.9.0 section of CHANGELOG.md still read "not yet pinned ... this image still pins e45f6b4", and the mempalace skill still told every agent at session start that a withdrawal is impossible. Measured, two independent routes, expectation recorded before looking: - published image label, :v1.9.1-studio and :latest-studio (same digest): se.jordbo.pi-devbox.mempalace-toolkit-ref = e68ee2071ca3ad39... - ancestry: e2b060a is an ancestor of e68ee20 - baked mempalace.ts sha 7c16fe14 != v1.8.14's dfca71e9 (different bytes) - grep -c isWithdrawn on this container's baked copy = 0 (v1.8.14, so tor-ms22 cannot exercise the behaviour it is documenting) The first label read came back EMPTY, and that empty was a claim about the request rather than the image: Hub redirects blob fetches to a CDN and curl without -L returns 0 bytes at exit 0. Recorded in the notes, because a registry audit reporting "no labels" is missing -L until proven otherwise. Changes: - CHANGELOG Unreleased: the floating-ref mechanism, which is the reusable part. ARG MEMPALACE_TOOLKIT_REF=main + CI resolving it to a SHA at build time means a release absorbs whatever toolkit main holds, and "what behaviour did this image gain" is a question nobody is forced to answer. The fleet rule (name the pickup before tagging) was honoured for the feed-tick commits v1.9.1 names, and missed for one in the same range. - CHANGELOG v1.9.0: the stale caveat is ANNOTATED, not rewritten. The sentence is the evidence for how the drift happened; deleting it would destroy the only trace. Same discipline as fleet-ops d42412c. - CHANGELOG Unreleased: corrected the size entry's "needs no base rebuild" claim. True of that entry alone, false of the release now that the vendored skill snapshot -- a base_tag input -- moves with it (~67 min). - rootfs mempalace skill snapshot 44472 -> 46045 B, refreshed via scripts/vendor-mempalace-skill.sh so the bytes and SKILLSET_SNAPSHOT_REF (4d7c0ea -> e9e45f7) move together; --check confirms exact match. - scripts/smoke-test.sh canary RE-PINNED. The retired pair was still green against the new snapshot, i.e. blind to this refresh for the same reason the pre-v1.8.13 pair was blind to that one. The replacement is stronger than any predecessor here because BOTH witnesses come from the same upstream commit: e9e45f7 added "Withdrawing an ask you sent" and deleted "nothing anyone can do about it from the other end", the sentence the new bullet contradicts. Directions measured against both files, then the canary body EXECUTED against each: new -> rc=0 "ok", old -> rc=1 empty. A canary whose negative witness was removed by the commit it pins fails loudly on stale bytes instead of merely failing to notice them. Gates: check-doc-drift OK, check-skill-floor OK, vendor --check OK, hooks/pre-push OK (16 shell files clean at severity error). Not fixable here: isWithdrawn is deployed and UNPROVEN. 17 assertions and 4 mutation kills, never once exercised on a released image against the live logstream. Ask routed to a v1.9.1 device.	2026-09-14 15:07:26 +02:00
Joakim Persson	1baba79c96	fix(size): the v1.9.1 residual was npm's own cache, not the platform binaries ... v1.9.1's @esbuild prune fixed the 431 MB size-gate failure but still shipped +131 MB compressed over v1.8.14, nearly all of it in the pi/extensions install layer (87 -> 206 MB). That leftover was filed as an open item with an explicit hypothesis — the @mariozechner/clipboard-* family, same npm 11 behaviour, a different package — and an explicit warning that the hypothesis was not a measured cause. Measured now, after recreating onto v1.9.1, and the hypothesis accounted for one sixth of it: +110 MB /root/.npm/_cacache (35.2 -> 145.3 MB) the build's npm cache + 21 MB clipboard foreign platform packages, both install sites = 131 MB i.e. the whole delta, no unexplained remainder Method, since there is no docker CLI inside the container: pulled both variant layer blobs straight from the registry with a token + manifest + blob fetch and listed the tarballs (29 789 vs 29 889 entries, 270.8 vs 401.9 MB uncompressed), then aggregated per package. The file COUNT barely moved, which is what said "few large files", not "npm installed more packages". - purge_build_caches: npm cache clean --force + rm -rf /root/.npm, in the SAME layer as the installs, in both the main RUN and the studio RUN. npm 11 caches every platform tarball it downloads, including the ones the prune then deletes, so the cache grew faster than the tree. Nothing at runtime reads it: build is root, container is developer with its own cache in $HOME. - prune_foreign_esbuild -> prune_foreign_natives: now covers both MEASURED families. Clipboard keeps linux-$arch-gnu AND -musl because its napi-rs loader picks between them at runtime via its own isMusl() probe; the musl package is a 420-byte stub. The bare @mariozechner/clipboard wrapper has no hyphen suffix and cannot match the pattern. Verified on arm64 before writing the glob — a widened rm -rf against a tree you cannot inspect is the one change shape not to write blind, which is why the order was update-then-patch. Exercised against a copy of the real trees with foreign dirs fabricated back in (aix-ppc64, android-arm64, darwin-arm64, win32-x64, linux-x64): all removed, host linux-arm64 kept at both sites, 21 MB freed, require('@mariozechner/clipboard') still loads and exports all 18 functions, esbuild.transformSync still compiles TS at both sites. v1.9.1's own arm64 validation also passed here; CI could only smoke amd64. Two sentinel assertions, because the size gate did not catch this: it has ~225 MB of margin, so 131 MB of residue stayed green. Both were verified RED against the running v1.9.1 image and GREEN against a pruned tree. The cache one refuses to run as non-root: test ! -d /root/.npm on mode-700 /root would otherwise pass for the wrong reason. Size-failure diagnostics now list cache paths too — they previously enumerated only node_modules and /opt, where these bytes were not. Also fixed: -printf '%f\\n' reaches the shell with both backslashes (confirmed from the published image's recorded created_by), so v1.9.1's progress line printed a mangled "li ux-arm64" — find emitted a literal backslash and tr ate the n out of the name. Single backslash now. Deliberately not purged: /tmp/node-compile-cache (1.3 MB). The manifest RUN calls pi --version again, so deleting it earlier only relocates those bytes into that layer — today's manifest layer is 128 kB precisely because it finds the cache warm. Dockerfile.base untouched, so no base rebuild: this rides the next release.	2026-09-11 09:39:54 +02:00
Joakim Persson	42bd29d654	fix(ci): unblock the release — npm 11 esbuild bloat + two self-inflicted assertions ... v1.9.0 was tagged but never published: smoke failed 90-passed/3-failed and build-variant needs smoke, so nothing reached the registry. All three are fixed. 1. Size, 431 MB over threshold. Node 24 brings npm 11, which installs EVERY @esbuild/<platform> optional binary instead of the matching one: 26 dirs, 284 MB per pi-coding-agent copy. Measured on pi-fork: npm 10.9.8 -> 165 MB (exactly what v1.8.14 shipped), npm 11.19.0 -> 449 MB. npm 11 ignores the os/cpu constraints AND --os/--cpu AND an npmrc carrying them, all measured, so Dockerfile.variant prunes explicitly, keeping linux-$(node -p process.arch) so one line is right on both arches. Pruned in the SAME layer as each install, or the bytes survive in the earlier layer. Three sites: global pi, pi-fork, pi-studio. Verified esbuild still transforms TS after. 2. om's node_modules assertion tested an npm artefact. om has zero runtime deps; its node_modules held ONE file (.package-lock.json) and 20 empty scope dirs. npm 11 stopped creating it. Now asserts the entry point pi actually loads, read from package.json -> pi.extensions. 3. The skill-source annotation added in v1.9.0 ("baked (package copy)") broke the assertion matching "baked$". Pattern now allows an optional suffix; which copy shipped stays authoritatively asserted against the manifest + tree hash. Also: a failed size check now prints the largest layers, largest directories and an @esbuild sentinel, so this class attributes itself next time instead of costing a CI dig plus a local npm bisect. Threshold stays 3800 MB: it caught a real regression and raising it would have thrown the signal away. No Dockerfile.base/rootfs change, so base-0fb1256c7f99 is reused and build-base is skipped.	2026-09-10 23:39:40 +02:00
Joakim Persson	ff6fd1492a	feat(manifest): record WHICH pi-extensions skill copy shipped ... Closes the half deliberately left open by cac5e00's skill-floor gate, and the more important half: "the floor is currently fresh" is a fact with a shelf life, whereas "the image says which copy it got" keeps working. The refresh in Dockerfile.variant is guarded by `[ -f /opt/pi-extensions/skill/SKILL.md ]`, so a build whose clone predates the co-located skill keeps the vendored floor and still succeeds GREEN, with nothing in the manifest, labels or logs separating that from a normal build. Afterwards the two are indistinguishable by inspection -- same path, same filenames, same permissions -- which is exactly how the floor went unnoticed from 2026-07-30 to 2026-09-10. build-manifest.json gains pi_extensions_skill_source and pi_extensions_skill_tree_sha256, MEASURED rather than passed as build-args, per the ground-truth rule the surrounding block already follows -- and necessarily so, since the outcome depends on the clone's contents and no ARG could express it. Three values, because two would force a lie: package (served bytes equal the clone's skill/), vendored-floor (clone had no skill/ at this ref), and divergent (both exist but differ -- e.g. the clone ships SKILL.md but not evaluate-extension-usage.py, so the served directory is a genuine MIX). No OCI label mirrors these deliberately: LABEL cannot take a RUN-computed value, and a label fed from an ARG would be the claim-not-measurement being removed here. Two smoke assertions make the record a gate: the source must be named and be `package` -- vendored-floor FAILS rather than warns, since these images track main where the package has shipped skill/ since fa04d20, so a fallback means the clone did not resolve as intended -- and the tree hash is recomputed over the served directory, because a recorded hash never recompared is a claim. pi-devbox-version annotates the line too: "baked (package copy)" normally, or a yellow "(FALLBACK: vendored floor)". Its existing section reports which copy is READ at runtime; this is the one fact decided at BUILD time and unrecoverable later. Old images degrade cleanly -- field absent, jq // empty yields nothing, line prints plain "baked" as before (verified against this v1.8.14 manifest). Tested by running the exact logic against this container's real layout, with the expected value written down before each: package (served == clone), vendored-floor (clone path absent), divergent (clone lacking the .py while the served dir has it), and null (empty served dir) -- all four as predicted. The five pi-devbox-version render branches likewise, including the absent-field case. Emitted JSON validated with jq for both the populated and null forms. Gates green: lint-shell.sh (15 files), hadolint 2.15.1, actionlint 1.7.12, check-base-hash.sh, check-skill-floor.sh, vendor-mempalace-skill.sh --check.	2026-09-10 20:30:16 +02:00
Joakim Persson	edc7659add	chore(deps): node 22->24, actionlint 1.7.12, hadolint 2.15.1, skillset ref ... Audited every component the image obtains OUTSIDE debian/apt. Of ~23, the 19 that resolve `latest` at build time were already current or refresh themselves on the next rebuild, and the hard pins for pi (0.85.1), mempalace (3.9.0) and pi-atelier (v0.10.1) were already newest. Four needed a human. NODE_VERSION 22 -> 24 (LTS "Krypton"). This was a latent defect rather than housekeeping: agent-browser publishes engines.node ">=24.0.0", so the image sat BELOW a declared requirement -- v1.8.14 shipped node 22.23.2 with agent-browser 0.37.1, so every build installed it with an npm EBADENGINE warning and ran the baked browser automation outside its supported range. pi (">=22.19.0") and playwright (">=20") are satisfied either way. Verified before bumping, since a missing NodeSource suite breaks every arch at once: setup_24.x returns HTTP 200 and node_24.x advertises `Architectures: amd64 arm64 armhf x86_64`, covering the arm64 fleet and the amd64 CI runners. Nothing else pinned the node major. actionlint 1.7.7 -> 1.7.12 and hadolint 2.14.0 -> 2.15.1, each RUN AGAINST THIS TREE at the new version before being pinned -- both clean, no new findings. A linter bump is the one dependency update that can turn CI red on unchanged code, so it is verified locally rather than discovered on a round trip. SKILLSET_SNAPSHOT_REF e9e09d9 -> 4d7c0ea via scripts/vendor-mempalace-skill.sh, never by hand: that script is the only thing permitted to write the ARG, because a cp without a matching bump yields a manifest that confidently lies. This proved PROVENANCE-ONLY -- the ref was 6 commits behind, but skills/mempalace/SKILL.md is byte-identical at both (3675bfab), so the snapshot was already correct and only its recorded origin was stale. No rootfs/ bytes changed, the smoke-test phrase canary stays valid, and this ARG alone would not force a base rebuild (the node bump does). Two measurement traps worth recording, since both would have produced a wrong answer: GitHub's releases/latest reports pi-atelier v0.10.0 as newest because v0.10.1 is a TAG WITH NO RELEASE OBJECT -- the pin was already current, and `git ls-remote --tags` is the instrument that shows it. And gitea-mcp is hosted on gitea.com, not GitHub, so querying api.github.com returned nothing at all rather than an error. Verified with every gate this repo owns, all green, using the NEW linter pins: lint-shell.sh (15 files), check-workflow-shell.sh, check-base-hash.sh, actionlint 1.7.12, hadolint 2.15.1, check-skill-floor.sh, and vendor-mempalace-skill.sh --check.	2026-09-10 20:17:32 +02:00
joakimp	aa0fbc5ec0	fix: correct the pi-studio claim — CI publishes v0.9.59, not the v0.9.60-rc.0 label ... Measured at the wrong layer during the v1.8.13 audit. I read `ARG PI_STUDIO_REF=main` in Dockerfile.variant, concluded the release would adopt main (= v0.9.60-rc.0), set PI_STUDIO_VERSION to that, and wrote a comment plus a CHANGELOG entry describing deliberate RC adoption. A Dockerfile default cannot answer "what will CI publish?" when CI overrides it, and it does: build-variant passes PI_STUDIO_REF=studio_ref and PI_STUDIO_VERSION=studio_tag (lines 598-599 and 787-788), and resolve-versions picks the newest STABLE semver tag via `^v?[0-9]+\.[0-9]+\.[0-9]+$`, which excludes pre-releases. Caught by reading run 639's own resolve-versions output rather than the Dockerfile: studio_tag=v0.9.59, studio_ref=9eed84f = refs/tags/v0.9.59^{}, while main/v0.9.60-rc.0 is 658536f and never gets built. So published v1.8.13 studio images carry pi-studio v0.9.59. ARG restored to `none` rather than pinned to v0.9.59: the local-build default should not hardcode a tag that goes stale as soon as main moves, which is how the previous value came to lie. The comment now leads with the override so the next reader starts at the layer that decides. Upstream's tag-over-main policy is deliberate (Releases stopped at v0.5.55, main receives half-finished commits), so adopting an RC from CI would mean changing that filter, not this ARG. Consequence kept on purpose: the RC's opt-in Studio network binding is in NO published v1.8.13 image, so it needs no audit this release. Doc/label-only: base_tag hashes Dockerfile.base + rootfs/** + both entrypoints + mempalace_toolkit_ref, none of which this touches, so the in-flight base build (base-ad9faf00f2b2) stays valid and the tag run will reuse it. Verified with CI's pinned linters: hadolint 2.14.0 exit 0 on both Dockerfiles, actionlint 1.7.7 exit 0, shellcheck 0.10.0 -S error exit 0.	2026-09-06 23:51:00 +02:00
joakimp	f561acc89a	skills: refresh vendored mempalace snapshot a12fe5e -> e9e09d9, re-pin the canary ... Folded into v1.8.13 at zero marginal cost: the snapshot is hashed into base_tag, but Dockerfile.base already changed this release, so the ~67 min base rebuild was already being paid. vendor-mempalace-skill.sh --check reported exit 0 (stale-but-truthful) beforehand, so skipping was sanctioned -- this is the deliberate call the release checklist asks for. Upstream content: the bare project-name wing convention and the <harness>@<device> added_by rule, both downstream of the attribution defect measured on this device 2026-09-06. The canary re-pin matters more than the refresh. Its old pair ("Provenance is stamped for you" present / "Attribute what you file yourself" absent) still PASSED against the new snapshot, so leaving it would have yielded a canary green on both old and new bytes -- blind to exactly the refresh it exists to witness, the same false-green family as the pre-v1.8.5 canary. New pair chosen by measuring direction against both files rather than reading the diff ("Diaries self-heal; plain drawers do not" new=1/old=0; "Agent diaries live in" new=0/old=1), then tested two-sided: PASS on refreshed bytes, FAIL on the old bytes recovered from git. Gates after the change: smoke-test.sh parses, vendor --check exit 0, check-base-hash exit 0.	2026-09-06 22:31:47 +02:00
joakimp	adcf56f829	release: audited bumps (pi 0.85.1, mempalace 3.9.0, atelier v0.10.1) + two guards ... Version audit for the next release. pi 0.84.4 -> 0.85.1, deliberately skipping 0.85.0 (it published internal experimental code and broke SDK imports, upstream #9132). mempalace 3.8.0 -> 3.9.0. pi-atelier v0.10.0 -> v0.10.1. PI_STUDIO_VERSION relabelled none -> v0.9.60-rc.0 so the floating main ref's RC status is visible at docker-inspect time instead of discovered later. PI_FORK_REF stays floating and adopts e69725c. The pi bump was verified by running it under a pty in five combinations rather than by reading the changelog, because this repo has already shipped a version pair no changelog flagged (atelier < 0.7.1 hangs pi >= 0.84). CPU delta 0.00-0.01s over 5s against a ~5s sustained-CPU hang signature, two-sided via the atelier sidebar painting identically to the 0.84.4 control. NODE_VERSION stays 22 on purpose: node 24 is technically safe (pi's five prebuilt addons are all NAPI, nothing declares a ceiling, agent-browser's engines.node >=24 is vestigial for the shipped aarch64 ELF), but this release already moves two minors and bakes an RC, and a node major would leave four suspects if the image misbehaves. Own release, smoke suite as the gate. Also corrects a stale claim at the mempalace ARG: synlig serves 3.8.0 server-side, not 3.7.1 (measured over ssh 2026-09-06). agent-browser volume shadowing: the image has shipped 0.35.2, but every session on mbp-m1-2020 ran 0.27.0 from a 2026-07-17 hand-install in ~/.pi/npm-global (a VOLUME, at PATH position 2 vs /usr/bin at 8). Third package hit by this hazard after pi and pi-atelier, so the guard is now generalised: entrypoint-user.sh retires the copy by moving it aside (reversible, only when the image ships its own), recreate-sanity-check.sh asserts resolution under /usr where the volume is real, smoke-test.sh carries the build-time half and says in the source why it is weak. The real damage was the stale BUNDLED SKILL (3 skillsets/17.6 KB vs 8/31.5 KB, ten subcommands undocumented to the agent) - a stale tool errors, a stale skill quietly teaches wrong commands. pi-fork capability floor (extensions: []): forks were measured across four dispatches ignoring their brief, answering in the user's voice, fabricating self-referential measurements, and once filing a diary entry as agent_name=pi. Cause is upstream by design - the child gets getHeader()+getBranch(), the whole active session branch, with the brief as the final user message. Not a model-capability problem: the same model as the fast profile obeyed the identical brief perfectly with a fresh session and no inherited context. extensions: [] runs children with --no-extensions, so the mempalace bridge is absent and palace writes are impossible by construction (verified by asking a child to enumerate its tools: read, bash, edit, write). Removes palace writes, not filesystem writes.	2026-09-06 20:40:02 +02:00
joakimp	a2846a5f7e	release: adopt pi 0.84.4 + pi-atelier v0.10.0, and fix the doc claim the pi bump invalidates ... pi 0.84.3 -> 0.84.4 (no Breaking Changes / Removed heading in that section, grepped). Adopted for three fixes that land on machinery this fleet runs: #6879 (large tool results crossing the auto-compaction threshold were sent to the provider before compacting), #8345 (a resumed session corrupted its next appended entry when the JSONL lacked a trailing newline -- that file is the memory feeder's input; measured 49/49 clean here beforehand), and #8537 (triggerTurn:false messages sent mid-run were inserted between a tool call and its result). The mempalace mailbox is outside #8537's precondition: it delivers at agent_settled with deliverAs:"steer" and no triggerTurn, and 0.84.4 leaves the documented steer semantics unchanged. pi-atelier v0.8.2 -> v0.10.0: two minor releases, both UI-only, no BREAKING notice. v0.9.0 raises its minimum pi to 0.84.0 and, unlike the 0.7.1-under-pi-0.84 startup-hang precedent, encodes it in peerDependencies (>=0.84.0). Satisfied by PI_VERSION=0.84.4. Both executable floors compare with sort -V, so 0.10.0 >= 0.7.1 evaluates correctly. docs/observational-memory.md: pi's own compaction.md gained one paragraph in 0.84.4 -- autoCompact is now also checked mid-run, after a tool batch's results are appended. Our text said compaction is checked only when pi goes idle and so "never interrupts a turn"; that was only ever true of the OM trigger. The section now states both entry points into session_before_compact and the diagram carries the second edge (mermaid checker re-run: 6 blocks, 44 labels, 0 soft-wrapped, no cut glyphs at 1280px and 800px). README: the version-pin table had been wrong since v1.8.6 -- 93f986e moved ARG PI_VERSION to 0.84.3 and MEMPALACE_VERSION to 3.8.0 and neither table row, so it advertised pi 0.84.2 / mempalace 3.7.1. Corrected, plus the --expected-version example that would now fail against a 0.84.4 image. CHANGELOG: Unreleased retitled v1.8.12 (2026-08-31) with the audits above and a dependency-audit table -- every other component measured SAME (skillset snapshot --check OK at a12fe5e, 0 commits since baked).	2026-08-31 07:08:41 +02:00
joakimp	495b7e3859	vendor: resync mempalace skill snapshot to skillset a12fe5e ... scripts/vendor-mempalace-skill.sh, real refresh not --check: skillset moved 6eb20af -> a12fe5e (mermaid-diagrams cutU normalisation, and the from_agent identity rule this same release ships in RFC 003). --check reported stale-but-truthful (exit 0, the sanctioned skip) but this release's point is getting today's fixes live fleet-wide, and the base rebuild is already forced by the entrypoint change and the floating mempalace-toolkit ref moving -- so the incremental cost of also bumping this pin is zero. Phrase canary in scripts/smoke-test.sh unaffected: neither pinned phrase ('Provenance is stamped for you' present, 'Attribute what you file yourself' absent) is in the section that changed; both verified still correct in the new snapshot.	2026-08-27 23:36:03 +02:00
joakimp	34cf1e3810	release: v1.8.8, and a notice that named the wrong remedy ... Freezes the v1.8.8 section and clears the two non-code checklist items pi@emb-7kj4vr4g handed over (evt_20260826T134919_a614ecfc2d4f), plus the two carried nits from its round-2 verification (evt_20260826T133356_d56792791a49). Every claim below was re-measured here rather than taken from the handoff. THE STALENESS NOTICE ASSERTED A DIRECTION IT NEVER TESTED — Blocker 1's shape, one layer down, in the message I added to replace the message that named the wrong cause. The notice fired on "recorded != HEAD" and then announced HEAD as the newer side without testing ancestry, so a clone that was merely BEHIND got "has moved to 82a8d3c; the snapshot describes the older 5fd0d5c" when 82a8d3c is 5fd0d5c's ANCESTOR. Found by EMB against the real state of its own host, not a fabrication. The verdict was never wrong (rc 0, nothing mis-verified) but the remedy it implies is a ~67-minute base rebuild when the actual fix is `git pull` — the only one of the two carried nits with a price tag, which is why it went first. Now tests ancestry with the merge-base --is-ancestor primitive the refresh path 60 lines below already used, and reports three verdicts: stale (refresh), clone behind (pull, do NOT refresh), diverged (reconcile). All three verified by execution; only the first was correct before. --help no longer errors on the one script whose argument order was itself a landmine. The `-s "$VENDORED"` guard is now commented as load-bearing: it makes the empty-stdin collision unreachable by construction, which also means no test below exercises it any more, so deleting it as "redundant with the probes" would silently restore the false OK. CHANGELOG: retitled, and three stale spots fixed in what becomes the permanent record. It cited the skill at 82a8d3c (twice superseded); it RE-ASSERTED the retracted mailbox measurement as live evidence 200 lines after withdrawing it, which is the exact non-contradiction failure this release exists to fix; and its warning block still described the pre-e8ddeaf world ("still records c04cd15", "now exits 1") while quoting as exemplary the very notice whose direction was unverified. Per EMB's steer the conclusion was kept and only the evidence replaced: the status filter does drop broadcast noise, it just never computed owed-ness. Honest replacement, measured on both machines: raw filter returns 2 here and 1 there, EVERY ONE already answered, derivation returns 0 for both. SNAPSHOT RESYNCED AGAIN, 5fd0d5c -> 6eb20af, because skillset 6eb20af adds the limit of my own seq ordering test: seq is REPLICA-LOCAL, equal to origin_seq only because one replica authors for all four machines, so use hlc once mesh_peers reports a peer. Recorded as reasoning not measurement — a second replica cannot be stood up here. The durable half is the asymmetry: seq skew makes an ANSWERED item resurface (noise, visible, self-correcting) while created_at SUPPRESSES AN UNANSWERED ask forever (silent, permanent), so the skill now says outright that "fixing" a resurfacing item with a timestamp trades the safe failure for the dangerous one. The resync was free: rootfs/ was already changing, so the base rebuild was forced regardless — the ordering warning about accidental staleness does not apply to a deliberate refresh before the tag. --check is a clean OK at 6eb20af with no notice, canary re-verified bidirectionally (present 3, withdrawn 0), baked snapshot 0644, tree hash recomputed at build time and re-verified in-container. bash -n clean; shellcheck/hadolint/actionlint remain absent locally, so CI is still the only evidence for those.	2026-08-26 15:56:03 +02:00
joakimp	e8ddeaf89f	skills: a gate that could pass without checking, and a mailbox that never empties ... Fixes the three blockers and seven should-fixes from pi@emb-7kj4vr4g's review (logstream correlation skills-provenance-review, full text in drawer_pi-devbox_reviews_e43e766641c9ec85217bc6ce). Every finding was reproduced by execution here before being fixed; two were refined by that reproduction rather than taken as given. BLOCKER 1 — the provenance gate could print OK and exit 0 without verifying. `git show <ref>:<path> | sha256sum` hashes EMPTY STDIN when the ref does not resolve, so at_ref was never empty and the UNKNOWN branch was dead code. Measured: a bogus ref reported MISMATCH — accusing the snapshot of lying when the real cause was an incomplete clone, and the operator's natural remedy for MISMATCH is to re-run the refresh, which rewrites provenance to silence the complaint; and with a 0-byte snapshot against a 0-byte upstream file it printed "OK: exactly skillset@aaaaaaa" with exit 0 for a ref that does not exist. The script already had the sha_empty idiom and had applied it to blob_sha but not to at_ref. Existence is now PROVEN with git cat-file -e before anything is hashed, at two levels (ref resolves / path exists at it) because those deserve different messages. Same defect class as the canary it replaces: a check that can succeed without checking. A second, unflagged instance of the same pipeline shape in blob_sha was found and fixed too. Exit codes split, because the old contract failed the sanctioned case: 0 truthful (including stale, with a NOTICE), 1 a lying record only, 2 cannot determine. AGENTS.md step 2 promised "the message distinguishes the two" and was the thing this branch was breaking; rewritten to state all three. BLOCKER 3 — VENDORED.md contradicted itself in the release whose stated invariant is non-contradiction: its hand-maintained provenance line named skillset 670f7f1, seven commits behind the ARG and itself the commit that told agents to hand-stamp added_by — the withdrawn instruction this work exists to stop shipping — while its cp recipe contradicted the "not cp" rule 20 lines above. Line removed (nothing forced it to move when the ARGs did); 670f7f1 kept only as a labelled cautionary example. The pi-extensions half was verified redundant (CI require_sha resolves PI_EXTENSIONS_REF) before removal. SHOULD-FIXES: `<root> --check`, the spelling VENDORED.md documented, silently ran a REFRESH because only $1 was parsed (both tools now parse all args and reject unknown ones); refresh at a detached/older HEAD silently rewound ref and bytes (now refused unless the recorded ref is an ancestor, --force to override); upstream_dirty was computed and never used in check mode; --no-skills --json printed human text and broke jq; --help was a hardcoded sed range this branch had already made stale; the fingerprint hashed SKILL.md alone so a live skill differing only in a sibling file reported "identical", and pi-extensions already ships two files, so it is now a per-skill TREE hash with the manifest field renamed skillset_snapshot_tree_sha256; the --no-skills smoke assertion was negative-only and passed on a crashed binary. mktemp+mv left files 0600 — CI was unaffected since the index records 100644, so the blast radius was local builds only, narrower than the review inferred. Snapshot resynced c04cd15 -> 5fd0d5c so the no-clone fallback carries the CORRECTED coordination protocol rather than the withdrawn one; --check is now OK with no staleness notice, and the bidirectional canary re-verified against the new bytes. Local validation is bash -n only (shellcheck, hadolint and actionlint are all absent in this container) — CI remains the shellcheck gate.	2026-08-26 14:38:07 +02:00
joakimp	e070e0bcbf	skills: record the vendored snapshot's provenance, and report which copy wins ... Found while verifying v1.8.7 from inside a fresh container: the baked mempalace snapshot is read by no host on this fleet. devbox-skill-reconcile repoints ~/.agents/skills/mempalace at the mounted live clone (the v1.8.5 fix working as designed), and all four compose stacks mount a workspace containing the skillset. So the phrase canary that blocked v1.8.7's first tag polices a file nobody opens, while the drift that could actually mislead an agent — a git pull nobody ran in /workspace/skillset — was invisible from inside the container and is invisible to CI by construction. Record provenance instead of policing it, and move the check to where the skillset actually is: - Dockerfile.variant: ARG SKILLSET_SNAPSHOT_REF (the claim) + a sha256 of the shipped bytes measured in the manifest layer (the fact), as manifest siblings rather than components{} members, plus an OCI label. An ARG default, not a CI-resolved output: no credential for the private skillset, no change at any of the four variant build call sites, and a local docker build records what CI does. Variant-only, so no base rebuild — check-base-hash.sh scans Dockerfile.base alone, verified by running it. - pi-devbox-version: a skills: section naming baked vs live <repo> @ <sha> per vendored skill, and for mempalace whether the live copy is identical to the baked fingerprint, at the same commit with uncommitted edits, or divergent. entrypoint-user.sh passes the new --no-skills, because the banner prints before the links exist and long before the reconcile runs. - scripts/vendor-mempalace-skill.sh: refresh the file and rewrite the ref together (a cp without an ARG bump makes the manifest lie, which is worse than anonymity); --check verifies the claim against a real clone. - 5 new smoke assertions (78 -> 83), mutation-tested through the real sh -c path: 6 fabricated manifests, where a well-formed hash of the wrong file proves the two manifest assertions are not redundant; the all-baked reporting test verified to FAIL against a live-skillset environment. Reviewed mid-flight by pi@emb-7kj4vr4g over the logstream (correlation skillset-vendor-drift), which retracted its own earlier recommendation of a build-time byte-compare against skillset HEAD and supplied the better framing: the invariant is NON-CONTRADICTION, not currency. Byte parity on a fallback would have cost a resync commit plus a ~67-min base rebuild for each of the four skillset commits pushed in one evening. Its warning also found a real bug here: the script now CONSTRUCTS the snapshot from `git show HEAD:<path>` instead of copying the working tree, because a clean `git diff` says nothing about an untracked file — the one input the first draft would have recorded a false ref for. Tested: untracked, unstaged and staged-but-uncommitted all refuse, atomically. Also fixes three stale in-repo markers of the same class the canary belongs to (true when written, silently false at release): two dangling "Unreleased" pointers and a typst line still marked Unreleased five releases after v1.4.0.	2026-08-26 10:30:27 +02:00
joakimp	93f986e90e	v1.8.6: adopt pi 0.84.3 + mempalace 3.8.0, close the v1.8.5 doc/observability gaps ... Three coupled pieces of work, all of which ride on the base rebuild that the mempalace bump forces anyway. DRIFT ADOPTED - pi 0.84.2 -> 0.84.3. Its release notes carry a "Breaking Changes" line (GoogleThinkingLevel -> GoogleApiThinkingLevel). Audited before adopting: zero references across all four vendored companions (pi-fork, pi-observational-memory, pi-atelier, pi-studio), so it is inert for us. The reason to adopt is two skill-discovery fixes that land directly on v1.8.5's vendored-skill work: nested Markdown skills inside grouping directories were not discovered, and root README.md/AGENTS.md in skill dirs were reported as broken skills. - mempalace core 3.7.1 -> 3.8.0. Additive/reliability only. Its sync fix (#2320/#2322) stops sync --apply deleting drawers whose source_file was unreachable *at that moment* -- which does NOT relax the standing landmine against sync on the shared palace, because that landmine is about paths permanently absent from whichever host runs the sync. Different failure shape; the caution stands. DOCS -- three defects, one of them public - DOCKER_HUB.md advertised "neovim (LazyVim defaults)". Nothing in the image installs LazyVim; the only nvim config is a 19-line sysinit.vim. CI PATCHes this file into the Docker Hub description on every release, so this was a false claim published to the world. Removed. - agent-browser + Playwright + Chromium is the single largest addition in the image (~625 MB) and had zero mentions in README, DOCKER_HUB or THIRD_PARTY -- it was documented only to agents, in the AGENTS.md managed block. Now documented to humans, including the Chromium licence dimension. - typst and socat appeared in README prose but not in the "What's inside" inventory. Added. OBSERVABILITY -- the three gaps v1.8.5 listed as still open - build-manifest.json now records mempalace core, read from the live binary (ground truth, not the build ARG). Placed as a sibling of pi_version rather than inside components{}, because pi-devbox-version renders that map through [0:12] and would truncate a version string. - smoke asserts the pi-observational-memory clone actually CONTAINS the ce9fc98 auth fix, pinned to src/runtime.ts. Deliberately not a repo-wide grep: two of the three markers also live under tests/, so the repo-wide form stays green with the fix site reverted. That is the third false-green of this exact family in this repo (canary phrase in both snapshots; reconciler fixture using a non-owned name; now this) -- pin containment checks to the fix site. - smoke asserts the feeder's pi@<device> agent default behaviourally. The earlier audit concluded this needed a --print-config added upstream; it does not. AGENT is assigned before arg parsing, so `bash -x mempalace-pi-session --help` observes the real resolution with no toolkit change. Two-sided: device set => pi@<device>, unset => must not be pi@*. - pi-devbox-version now prints a palace: line with the same live-vs-baked drift detection pi already had. This matters more than it looks: mempalace is the one component that is both client (here) and server (synlig), so skew between them is a real failure mode. Degrades quietly on pre-v1.8.6 images. Deferred deliberately: a native arm64 act_runner on tor-ms22 (the current runner is on synlig, x86_64, so every arm64 layer ships QEMU-emulated). Analysis and caveats filed to the palace rather than actioned here.	2026-08-25 15:29:22 +02:00
Joakim Persson	2ebf00d6d4	v1.8.4: the om fix lands upstream, pi-atelier v0.8.2, todo edit ... Headline: pi-observational-memory 37986b6 -> ce9fc98. The ambient-credential gate fix (6f694e6 + 699ccc7) was merged upstream as PR #52 on 2026-08-22, closing issue #51, so this release picks it up through the ordinary PI_OBSMEM_REF=master path with nothing carried locally. Every image up to and including v1.8.3 silently recorded zero observations on a Bedrock host using ambient AWS credentials; from this one on, /opt is the fix and the settings.json packages[] workaround should be deleted (verify against /etc/pi-devbox/build-manifest.json first). npm still ships the broken 3.0.4, which does not matter here because the image clones the ref instead. Pin bump: PI_ATELIER_REF / PI_ATELIER_VERSION v0.8.1 -> v0.8.2, audited per the floor note above the ARG. The only version in between is 0.8.2 itself and both its entries are Workspace-Pulse-internal (inspection coalescing and serialization; fresh inspection guaranteed at Turn end, retired sessions can no longer publish stale results). Nothing touches pi's private TUI renderer, which is the coupling behind the 0.6.0/0.7.0-under-pi-0.84 startup hang, and pi is unchanged at 0.84.2 - so the bump stays outside that risk class. Also baked by this build, no pin needed: pi-extensions 98eb07b -> 2022887 (the todo edit action), pi-fork 4a09af4 -> f1ff808, pi-studio 0.9.44 -> v0.9.48, mempalace-toolkit b609cf5 -> fd8b15f (docs only - the pi-session false-success guard was already baked in v1.8.3, confirmed by ancestry), aws-cli 2.36.24 -> 2.36.29 and the other *_VERSION=latest tools. README: the pin table also said mempalace 3.6.0, stale since v1.8.3 bumped it to 3.7.1. Fixed in passing. Unchanged and verified current: pi 0.84.2 (npm latest, published 2026-08-14), MEMPALACE_VERSION 3.7.1 (PyPI latest), pi-toolkit 0e1369e.	2026-08-22 21:19:48 +02:00
Joakim Persson	29b62093f0	v1.8.0: bump pi 0.84.1 → 0.84.2 and pi-atelier v0.8.0 → v0.8.1, audited ... pi 0.84.2 closes the Amazon Bedrock tool-argument poison pill that v1.6.4 recorded as "Not fixed upstream". pi-ai 0.84.2 adds a recursive sanitizeBedrockDocument() and applies it at exactly the site that entry named (dist/api/bedrock-converse-stream.js, line 692 -> 704; upstream PR #7882): - toolUse: { ..., input: c.arguments }, + toolUse: { ..., input: sanitizeBedrockDocument(c.arguments) }, It strips object members whose key is the empty string, recursing through arrays and nested objects. It runs at request-build time, so it covers the live turn and a resume alike: a session already bricked by an empty-key tool argument now replays instead of dying on a Bedrock ValidationException. pi-session-repair is therefore no longer the recovery path on this image -- it stays useful for older images and for inspection, since the fix sanitises what is sent, not what was recorded. Bumping PI_VERSION is the ONLY way to get that fix: pi publishes an npm-shrinkwrap.json, so pi 0.84.1 pins pi-ai to exactly 0.84.1 even though its package.json range (^0.84.1) would admit 0.84.2. Transitive upstream fixes never leak into this image. pi-atelier v0.8.1 is the matching companion -- both sides changed fullscreen input handling within three days. Its only code change (src/split-pane.ts) stops atelier writing its own 1002h/1006h pair around a sidebar resize under pi's fullscreen renderer, which had been tearing down the mouse reporting pi itself enabled and leaving the wheel dead. Audited against the surfaces the pin policies name: - session .jsonl: identical migrateV1ToV2/migrateV2ToV3 ladder - node engine floor: unchanged >=22.19.0 (image ships 22.23.2) - atelier's three private couplings all intact in pi-tui 0.84.2 -- class TuiAltScreen extends TuiBase (detected by constructor NAME, so a rename would fail silently), inputListeners still `new Set()` at the same line 103, own render(width) descriptor still present - pi's mouse sequences byte-identical between 0.84.1 and 0.84.2 - atelier metadata unchanged: engines >=22.19.0, peerDeps >=0.80.7, zero runtime deps, so the "no npm install step" note holds Not proven by execution: CI smoke does not drive the TUI, and 0.84.2 adds a focused fullscreen search overlay that also participates in input handling. The pairing is reasoned from the diffs. Worth an alt+a plus a sidebar resize and wheel scroll in fullscreen on first use.	2026-08-15 00:22:08 +02:00
joakimp	43cd6e22f2	v1.7.0: bundle pi-atelier at a pinned tag; pin pi to an audited 0.84.1 ... Two changes that belong together, because the first is what makes the second dangerous to get wrong. pi-atelier (TUI sidebar + status rail) is now vendored to /opt/pi-atelier at PI_ATELIER_REF=v0.8.0 and registered by entrypoint-user.sh — the pi-fork / pi-observational-memory / pi-studio pattern, deliberately NOT `pi install npm:pi-atelier`, which writes into ~/.pi/npm-global on the config volume where it shadows the image and pins nothing. Unlike its siblings it gets no `npm install`: atelier declares zero runtime deps (peerDeps only, satisfied by the baked pi) and has no build step, so pi loads its TypeScript straight from the checkout via package.json `pi.extensions`. pi is no longer resolved to npm `latest` at build time. The pin lives in Dockerfile.variant and CI reads it from there, so a local `docker build` and a CI release ship the same versions by construction. The pin is a CHECKPOINT, NOT A FREEZE: bumping stays a one-line change; what stops is *unreviewed* adoption of whatever shipped that morning, in the same build that then gets tagged and published. CI fails when a pin is not concrete or not actually published on npm, and warns — never adopts — when npm latest moves ahead, naming what to re-check. Why this pairing needed care: pi-atelier 0.6.0/0.7.0 wrap pi's PRIVATE TUI renderer, and under pi 0.84 that wrapper recurses — pi hangs at startup burning CPU with no error. Upstream fixed the recursion in 0.7.1 and restored the non-overlapping split in 0.7.2; 0.8.0 is additive on top. atelier's own peerDependencies still say >=0.80.7, which does not express that floor, so nothing in npm metadata could have warned us. The floor is therefore encoded as an executable rule — pi >= 0.84 => pi-atelier >= 0.7.1 — asserted in both smoke-test.sh (build time) and recreate-sanity-check.sh (after a real recreate), verified against a 4x4 version matrix. Existing volumes needed migration, not just vendoring: a hand-installed `npm:pi-atelier` entry is counted as already-registered by the entrypoint guard, so every existing volume would have kept its unpinned npm copy — and a 0.6.x copy next to pi 0.84 is exactly the startup hang. The entrypoint now drops that one exact string (settings.json.bak.atelier.<ts> backup, distinct prefix so it cannot clobber the template merge's backup in the same second) and lets the pinned /opt copy register. Tested against a real settings.json: only that entry removed, other packages and all keys intact, idempotent, and unparseable JSON leaves the file untouched. DEVBOX_ATELIER=0 opts out entirely — in the entrypoint rather than via `pi uninstall`, because this component's failure mode is "pi will not start", which cannot be repaired from inside pi. 0.84.1 was audited for this release, not merely adopted: theme/TUI changes are additive, the session format is unchanged (CURRENT_SESSION_VERSION = 3 in both 0.83.0 and 0.84.1 with an identical migrateV1ToV2/migrateV2ToV3 ladder, so existing transcripts are neither migrated nor at risk and pi-session-repair stays valid), and the Node engine floor is unmoved at >=22.19.0. CI resolves the atelier tag to its PEELED commit SHA — atelier uses annotated tags, so the unpeeled ref is a tag object, not a commit; pi-studio's lightweight tags never exposed that distinction. Also: docs for overriding the read-only ~/.ssh/config from the container — container-only keys in ~/.ssh-local, hardened authorized_keys, the fact that `from=` must allow the HOST's addresses because container egress is NAT'd through it, and the macOS-only-keyword trap (`UseKeychain` is fatal to Linux OpenSSH and takes out dssh/pi --ssh while the host keeps working). Corrects two claims in "Naming LAN peers": ssh-lan.conf is not ProxyJump-only, and first-time creation does need one restart because the Include is emitted only when the file already exists at start.	2026-08-07 21:34:41 +02:00
joakimp	1fd524e7fb	Give each variant its own image description label ... Both published variants inherited Dockerfile.base's description="pi-devbox — base image (variant-independent)", so v1.6.4 and v1.6.4-studio both advertised themselves on Docker Hub as the base image — misleading, and useless for telling the two apart. A LABEL cannot branch on INSTALL_STUDIO, so the text arrives as a build-arg: CI passes a variant-specific string (interpolating RELEASE_TAG, PI_VERSION and, for studio, STUDIO_TAG), and the Dockerfile default keeps a bare local `docker build -f Dockerfile.variant` honest instead of misleading. Also sets org.opencontainers.image.title/description alongside the legacy bare `description` key, so Hub and OCI-aware tooling both see it. ARGs stay in the last-declared block, so the label layer is still the only thing invalidated. Verified: hadolint 2.14.0 (the CI-pinned version) clean on both Dockerfiles; workflow YAML parses; check-workflow-shell.sh passes. Lands on the next release.	2026-07-30 07:59:41 +02:00
pi	38d8832d34	ci: record pi-studio version as image label ... Adds se.jordbo.pi-devbox.pi-studio-version (e.g. v0.9.36) alongside the existing SHA label, so 'docker inspect' shows the human-readable version. Plumbing: resolve-versions exposes studio_tag output -> both studio build steps pass --build-arg PI_STUDIO_VERSION -> Dockerfile.variant declares ARG PI_STUDIO_VERSION=none and emits the LABEL. Studio-variant only. Validated: yq parse OK, resolve run-script bash -n OK. No tag.	2026-07-13 17:59:59 +02:00
Joakim Persson	a7d6a7d235	feat(skills): bake pi-extensions + mempalace fallback skills ... The pi-toolkit global AGENTS.md tells every pi session to read ~/.agents/skills/pi-extensions/SKILL.md at start (the fork/recall under-utilisation fix), but that skill lived only in the private skillset repo — so the pointer dangled in any container started without skillset mounted. Bake fallbacks so the pointer always resolves. - pi-extensions (Option 1 + Option 2, layered): * Canonical skill promoted to the public pi-extensions package repo under skill/ (separate commit there); co-located with the code it documents. * rootfs/ carries a committed snapshot (the floor). * Dockerfile.variant copies /opt/pi-extensions/skill/ over the snapshot after the pinned clone, so a normal build ships the fresh package copy (recorded via PI_EXTENSIONS_REF) and an old-ref/mirror build still ships the snapshot. Helper evaluate-extension-usage.py travels with it. - mempalace (Option 2 only): snapshot in rootfs/. Its consumer skill has no public package home (mempalace-toolkit ships a different skill, opencode-mempalace-bridge), so no build-time refresh. - entrypoint links both (only-when-absent; mounted skillset still wins). - smoke-test: build-time presence + package-match check + runtime symlink assertions; readiness gate now waits on the last-linked skill. - docs: skills/VENDORED.md (provenance + refresh), README, AGENTS.md, CHANGELOG [Unreleased]. Note: shipped in the NEXT release; v1.2.0 (run 409) predates this.	2026-06-23 15:32:04 +02:00
Joakim Persson	2abfee141b	feat: image-baked agent skills + pi-devbox-environment skill (v1.2.0) ... Ship skills inside the image (independent of any mounted skillset repo): - rootfs/usr/local/share/pi-devbox/skills/<name>/ symlinked into ~/.agents/skills/ by entrypoint-user.sh (foreign-link, survives volume recreate, never clobbers a skillset/user skill of the same name). - New pi-devbox-environment skill: persistence model, host/LAN SSH reachability, split-DNS mechanisms, interactive-vs-tool-shell alias gotcha, tmux 0-index, uv-first Python, pi-studio reachability. Agnostic to host OS / hostnames / domains / nameservers (discovered at runtime). - Dockerfile.variant appends pi-global-AGENTS.append.md onto pi-toolkit's pi-global-AGENTS.md (single global slot) so the skill is loaded proactively; gated on /usr/local/lib/pi-devbox/. Idempotent. - smoke-test: baked-skill + append-snippet + merged-marker presence and a runtime symlink assertion. - docs: README 'Agent skills' section, AGENTS.md layout, DOCKER_HUB.md; moved studio-tex roadmap to v1.3.0. pi 0.79.7 -> 0.79.10 (auto-resolved from npm latest at build).	2026-06-23 12:49:13 +02:00
pi	9eff3f3c48	release: v1.1.6 — build provenance + reproducibility hardening; pi 0.79.7 → 0.79.8 ... Adds OCI labels + /etc/pi-devbox/build-manifest.json so a published tag is self-describing and reconstructable after CI logs rotate (manifest is written from the actual checked-out HEAD of each /opt clone + live pi --version, not just the intended build-args). Hardens the build plumbing: - scripts/check-base-hash.sh guards the base-rebuild invariant: every floating ARG *_REF in Dockerfile.base must be folded into the base_tag hash, else a ref-only change silently fails to rebuild the base (v1.1.2-class staleness footgun). Runs in base-decide and locally. - resolve-versions now fails loud instead of falling back to a floating main/master on a transient API failure — validates each ref is a 40-hex SHA (and pi a real semver) and aborts the release otherwise. - The three gitea companions (pi-toolkit, pi-extensions, mempalace-toolkit) gained overridable *_REPO build-args (defaulting to the canonical gitea origin) so a relocated/forked build can repoint them without editing the Dockerfiles — matching the existing PI_FORK_REPO/PI_OBSMEM_REPO pattern. README documents the forked/relocated build-arg trick and how to read the labels + manifest. smoke-test asserts the manifest + labels. pi bumps 0.79.7 → 0.79.8 (auto-resolved at build).	2026-06-19 18:23:11 +02:00
pi	a78e59fb5b	feat(studio): add :latest-studio variant (PR-3) ... Bundle pi-studio (omaclaren/pi-studio) as a new -studio image variant: browser prompt editor, KaTeX/Mermaid preview, tmux-backed literate REPLs, /studio command + studio_* agent tools. - Dockerfile.variant: INSTALL_STUDIO + PI_STUDIO_REPO/REF args; vendor pi-studio to /opt/pi-studio (no build step — prebuilt client in git; npm install --omit=dev for 3 prod deps). STUDIO_PORT=8765 advisory. - entrypoint-user.sh: register /opt/pi-studio via the existing pi install local-path loop (auto-skips in non-studio variant). - smoke-test.sh: auto-detected studio assertions (clone + prebuilt client + pi install registration). - CI: resolve PI_STUDIO_REF to a SHA; independent smoke-studio + build-variant-studio jobs that gate ONLY the -studio tags, so a studio failure never blocks the core :latest release. - README: 'Using pi-studio' section documenting the container access reality — pi-studio hard-binds 127.0.0.1 (index.ts .listen(port, '127.0.0.1'), no --host flag), so -p publish alone can't reach it. Documents host-networking and loopback-bridge paths, the remote ssh -L forward, and the mosh caveat (no port forwarding; run parallel ssh -L). - CHANGELOG/AGENTS/DOCKER_HUB updated. Will tag as v1.1.0 (minor). No tag created — stopping for review.	2026-06-10 23:15:29 +02:00
pi	8b69b3625b	fix: use git_fetch_ref for pi-toolkit and pi-extensions clones ... The previous clone helper for these two repos (git_clone_retry) used `git clone --branch <ref>`, which only accepts branch names or tags, NOT commit SHAs. Run 374 (the workflow_dispatch retry of v1.0.0) failed at smoke because the workflow's resolve-versions step had been extended to resolve PI_TOOLKIT_REF and PI_EXTENSIONS_REF to commit SHAs (commit b55b44e), and `git clone --branch <40-char-SHA>` fails with 'Remote branch not found'. Switching all four clones to git_fetch_ref (`git fetch + checkout FETCH_HEAD`) makes the build accept both branch names AND SHAs uniformly. Both Gitea and GitHub allow fetching arbitrary commits by default (uploadpack.allowReachableSHA1InWant). The unused git_clone_retry helper is removed; comment explaining the choice and the historical context is in its place. Image was published successfully on run 373; this only affects the v1.0.0-rerun path (description fix). Image bytes unchanged because the SHAs being passed match what run 373 cloned by branch name.	2026-06-10 12:28:09 +02:00
pi	c1154f1fa6	v1.0.0: decouple from opencode-devbox ... Self-contained build chain — own Dockerfile.base + Dockerfile.variant + entrypoint scripts + rootfs + CI pipeline. Previously v0.79.0 and earlier were thin re-brands of opencode-devbox's pi-only variant (joakimp/pi-devbox:base-pi-only built by opencode-devbox CI). Architectural changes: - Replace 5-line Dockerfile shim with full base+variant pair. - Adapt CI workflow from opencode-devbox/docker-publish-split.yml, simplified to a single variant. Includes content-addressed base hash, PI_VERSION concrete-resolution to defeat registry-buildcache footgun, crane-based base-latest promotion, and the c6f9d11 smoke-test gate. - pi-devbox releases no longer require rebuilding opencode-devbox first. Base image additions: - pandoc, graphviz, imagemagick, yq — broadly useful, ~260 MB total. - tldr (tealdeer) — Rust port replaces Node tldr global, saves 135 MB. - /etc/tmux.conf with base-index 0 + pane-base-index 0 — required for the planned :latest-studio variant; pi-studio hard-codes :0.0 target. Smoke test: - New checks for pandoc, graphviz, imagemagick, yq, tldr, tmux config, /tmp/sshcm directory. - Image-size measurement now sums docker history layers (the prior inspect --format='{{.Size}}' returned only the variant-unique layer with the new base/variant split, understating by 2+ GB). - Threshold 2850 → 3500 MB to absorb base additions + arch margin. Image size: - Local arm64 build: 3.20 GB. ~390 MB up from prior pi-only equivalent. - Will tighten threshold once amd64 actuals settle in CI. Pre-1.0 history preserved at tag pre-v1.0.0-decouple-backup. Future work: - v1.1.0: :latest-studio variant (adds pi-studio). - v1.2.0: :latest-studio-tex variant (adds texlive-xetex for PDF). - opencode-devbox v2.0.0 will retire INSTALL_PI / pi-only paths.	2026-06-10 01:14:07 +02:00