51 Commits

Author	SHA1	Message	Date
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	852f900b53	test(smoke): make CI prove the natives still work — the runbook check didn't ... The post-boot check v1.9.1 left for the next machine was node -e 'require("esbuild").transformSync("const x:number=1",{loader:"ts"})' with "if this fails, the prune removed something needed on arm64 -> revert to v1.8.14 and fix" attached. Run from /workspace on the freshly recreated v1.9.1 image it fails with MODULE_NOT_FOUND — on a perfectly healthy image. require() resolves by walking up from the CURRENT DIRECTORY, esbuild is nested inside the two pi trees, and a global install is not on node's require path (NODE_PATH is unset). The version that "verified the prune" last night only passed because the shell happened to sit inside the tree. So the check was CWD-dependent, its red meant nothing, and the remedy it prescribed was reverting a good release. Path-qualified, both sites compile TS today. Rather than leave a fragile command in a note for a human to paste, CI now owns it: - esbuild must transformSync at EVERY install site found in the image - @mariozechner/clipboard must load with its native binding attached at every site — for the clipboard prune that IS the proof, since napi-rs resolves the platform package at require() time Sites are discovered with find, so the studio variant's third site is covered without naming it. Verified as a four-way matrix, not just a green run: both assertions pass against the real image FROM /workspace (the cwd that broke the old command), and both fail (exit 1, "The package \"@esbuild/linux-arm64\" could not be found, and is needed by esbuild") against copies of the same packages with the host platform binary removed. An assertion never observed failing is not evidence. Also documents both failure shapes in AGENTS.md next to the size gate: this one, and the mode-700 /root one where `test ! -d` passes on a permission error.	2026-09-11 11:06:18 +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
joakimp	15a3728ae9	feat: bake shellcheck and add a client-side pre-push lint gate ... v1.8.14 made shell lint a RELEASE gate (scripts/lint-shell.sh, shared by lint.yml and the new lint-gate job that resolve-versions depends on), and that script correctly exits 2 when shellcheck is absent -- "a gate that cannot run must not pass". Measured on v1.8.14 on 2026-09-09 by three routes (command -v, dpkg -l, a filesystem search): shellcheck was NOT IN THE IMAGE AT ALL. So the gate could not be run by a developer in any container, only in CI, and the loop stayed write-shell -> push -> wait for CI -> discover. That is the loop the gate was added to shorten, after v1.8.14's first attempt burned ~46 min on a tree whose lint had already been red for 24 hours. shellcheck 0.10.0-1 added to the Dockerfile.base apt block: ~39 MB installed (Installed-Size 40112 KB), measured to pull ZERO additional packages under --no-install-recommends because libc6/libffi8/libgmp10 are already present. NOTE this forces one full base rebuild -- base-decide hashes Dockerfile.base + rootfs/, so unlike a scripts/ change it cannot reuse the existing base- layer. hooks/pre-push is opt-in per clone (git config core.hooksPath hooks), bypassable with --no-verify, and execs scripts/lint-shell.sh rather than reimplementing it -- one copy, because a duplicated check that drifts is the failure this repo keeps paying for. Matches the idiom skillset/ and myconfigs/ already use. WHY THIS REPO HAD NO HOOKS, since it was reported as drift and is not: a peer asked tor-ms22 for core.hooksPath per clone on the premise that unset meant the gates were unverified there. Measured: pi-devbox unset, skillset hooks, myconfigs common/hooks, pi-toolkit unset -- but `git ls-files | grep -i hook` is EMPTY in both pi-devbox and pi-toolkit, so there was nothing to point at on any machine and unset was the only correct value. This closes the real half for pi-devbox; pi-toolkit still ships none. Verified, expected result written down before each check: * refusal paths -- shellcheck absent => rc 2 with the remedy named; linter missing => rc 2. Never waved through on the assumption CI will catch it. * the hook is IN the scan set -- "Checking 14 shell file(s)" with it present, 13 with it moved aside, so the extensionless file is found by the shebang half of the linter's two-signal union. This check exists because the first attempt was ambiguous: a planted `[ $UNSET_VAR = "x" ]` was not reported, which could equally have meant "not scanned" or "below -S error". It was the latter. A count that moves is unambiguous; a clean run is not. * it catches the REAL v1.8.14 defect -- planting `echo 'the fleet\'s thing'` in hooks/pre-push yields SC1073/SC1072 at severity error, rc=1. And the gate earned its keep inside this commit: the first version of the smoke-test assertion carried a comment beginning "# shellcheck is a GATE DEPENDENCY", and a comment whose first word is the tool's name is parsed as a DIRECTIVE, not a comment. The new gate failed it with SC1073/SC1072 before the push -- same family as the v1.8.14 apostrophe, a line that reads as prose to a human and as syntax to the parser.	2026-09-09 08:57:34 +02:00
joakimp	70e675afee	fix(smoke): keep prose out of the single-quoted exec_test body ... The agent-browser execution guard added on 2026-09-07 carried its explanation INSIDE the single-quoted script body, and the explanation contained an apostrophe ("the fleet\'s only recurring amd64 runtime proof"). Inside '...' bash treats a backslash as literal, so \' does not escape the quote -- it CLOSES the string. The body truncated at that point and the remaining lines were parsed by the calling shell. Consequences, both measured rather than inferred: - exec_test received 12 arguments instead of 2 (verified two-sided: the fixed tree yields argc=2, HEAD yields argc=12). - the leaked `v=$(agent-browser --version)` ran on the CI RUNNER instead of inside the image. The runner has no agent-browser, so smoke and smoke-studio both failed with "line 770: command not found" after build-base had already spent ~46 minutes. Every downstream job was skipped. - the truncated body still passed inside the container and printed its green tick first, so the log shows a PASS immediately followed by the failure -- the tick was real, it just no longer covered the assertion. The prose now sits above the exec_test call, where an apostrophe cannot terminate anything, and a comment at that spot records why it must stay there. Not a new failure class: shellcheck flagged it as SC2289 at severity error the same day, so the lint job has been red since run 186 (2026-09-07 21:21) and was not read. The gate did its job; nobody looked.	2026-09-08 23:31:48 +02:00
joakimp	6bd8b79d3a	test(smoke): assert agent-browser EXECUTES — it was the discarded amd64 proof ... Second instance of the same bug class as the node line, in the same file, found the same way. The agent-browser guard captured the version inside an echo with 2>/dev/null: echo "resolved=[$r] version=[$(agent-browser --version 2>/dev/null|head -n1)]" >&2 so the exit code was discarded and a binary that could not execute at all still PASSED, printing version=[]. Verified two-sided: a stub exiting 127 passes the old form and is caught by the new one. Why this exit code matters more than most: smoke runs platforms: linux/amd64 on an x86 runner, i.e. NATIVE amd64, so this line is the fleet's only recurring amd64 runtime proof for agent-browser's linux-x64 ELF. NO DEVBOX CAN EVER SUPPLY THAT PROOF. Every machine in the pi fleet is an Apple Silicon Mac: mbp-m1-2020; tor-ms22 = Mac Studio Mac13,1 M1 Max (fleet-ops hosts/tor-ms22.md, verified 2026-08-17 with system_profiler); emb-7kj4vr4g = Apple Silicon, verified 4 routes 2026-09-07. The open "amd64 runtime proof still needed" ask sent to two devices was asking for the impossible, and emb's reply naming tor-ms22 as "the only remaining candidate" is wrong for the same reason. CI had the answer all along and was throwing it away. Dockerfile.base:607 DOES assert it (`agent-browser --version && \`), but only when the base rebuilds, and v1.8.13's base was cached — so smoke is where the recurring gate belongs.	2026-09-07 21:21:16 +02:00
joakimp	5972a2c535	test+docs: assert the node major in smoke, and correct v1.8.13's agent-browser version ... Two findings from a delegated read-only audit of this repo, both verified from the filesystem before patching. 1. No test asserted the node major, so a node-24 bump would have passed the smoke suite SILENTLY. scripts/smoke-test.sh:94 was a bare `run "node" "node --version"` — exit-0 and non-empty output only, the printed version compared to nothing — while the line above it uses run_expect against $EXPECTED_PI_VERSION for pi. A reader skimming the suite would reasonably assume node regressions were covered. Worse, this is where the "node v22.23.2 verified" line in the v1.8.13 recreate notes came from: printed output, not an assertion. Now gated on EXPECTED_NODE_MAJOR, which CI derives from Dockerfile.base's ARG NODE_VERSION — the single source of truth (Dockerfile.base:557 is the ONLY hard pin in the repo; Dockerfile.variant has no node install at all). That also catches a stale cached layer whose node disagrees with the declared ARG. Unset => previous behaviour, so this is backward compatible. Verified two-sided rather than assumed: the sed derivation yields 22 (empty would have silently disabled the assertion, reintroducing the bug); grep -Fq "v22." matches v22.23.2; "v24." does NOT match, so a wrong major is caught; and "v2." does not prefix-collide. Workflow YAML re-parsed after editing (9 jobs). 2. The v1.8.13 entry claimed "the image's own 0.35.2" for agent-browser. The image ships 0.36.0: /usr/lib/node_modules/agent-browser/package.json says version 0.36.0, engines.node >=24.0.0, and no 0.35.2 exists anywhere in the image. The claim was also internally incoherent, contrasting 0.36.0 against a version that is not present. Corrected in place with a visible note, since the entry is already released. The reasoning survives untouched: the engines floor really is vestigial, because /usr/bin/agent-browser is a prebuilt aarch64 ELF invoked directly and never through node — which is why 0.36.0 runs fine on 22.23.2.	2026-09-07 21:05:24 +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	36e65fe657	skills: add credential-incident-response, and assert it stays baked ... Carries the facts a two-day credential incident produced, not the discipline: probe the issuer FIRST (11 of 13 "exposed" credentials were already dead at the provider, which cost five HTTP requests to learn and was never checked), the 403-vs-401 trap that scoped tokens introduce into liveness probes, revocation beats deletion for anything already replicated, the three places a secret hides in a Chroma palace (FTS content, metadata, raw bytes) in coverage order, scope derivation from measured consumers, and this fleet's age store with its single-recipient weakness. Facts transfer between sessions; exhortations do not — hence a separate skill for the domain knowledge and a one-line pointer in the always-loaded block. Authored here, so baked is canonical and it is NOT added to skillset-owned.txt. Skill dirs are picked up by a glob in entrypoint-user.sh, so no registration is needed — verified rather than assumed, since an enumerated list would have left the skill inert, a fitting failure given its subject. Three smoke assertions extended so a future rebuild cannot silently drop it.	2026-08-30 00:50:11 +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
pi	f645e6654f	smoke: fix the snapshot canary that blocked v1.8.7, and make it bidirectional ... Run 589 built the base cleanly and then failed both smoke jobs 81-passed/1-failed on 'mempalace skill snapshot is current'. That canary greps a phrase from the vendored mempalace skill to detect a stale snapshot, and the phrase it pinned was 'Attribute what you file yourself' — the heading of the hand-stamping instruction that THIS release withdraws. So it fired correctly: the snapshot changed and the expectation did not. Every publish job was skipped, so nothing reached the registry and v1.8.7 was never consumed. Rather than bump the string: * the assertion is now BIDIRECTIONAL — the new phrase must be present AND the withdrawn one absent. A one-way canary only catches half the drift: it cannot notice a re-vendored stale snapshot that happens to contain the pinned phrase. Verified against v1.8.6's snapshot, which now correctly fails. * the comment records the structural limit rather than just the fix: a phrase canary can only ever detect 'older than what I remembered to pin', never 'older than skillset main'. Only a diff against the skillset repo can do that, which is now a Still-open item — it needs a CI clone credential for a private repo, i.e. a policy decision, not a code change. Changelog consolidated: the SSH sidecar multiplexing default moves from Unreleased into v1.8.7, since the retag will sit on a commit that contains it, and the v1.8.7 summary now records the failed first attempt rather than quietly presenting the second one as the whole story.	2026-08-26 08:09:09 +02:00
joakimp	2b8c3a4db4	ci: audit MEMPALACE_VERSION the way PI_VERSION is audited ... Closes the item v1.8.6 (and v1.8.5 before it) listed as "Still open": the palace pin was a literal string in Dockerfile.base with zero references in docker-publish.yml, while PI_VERSION had a concreteness gate, a published-on-registry check and a never-silently-adopt drift warning. resolve-versions now applies all of those to MEMPALACE_VERSION, read from Dockerfile.base so a local `docker build` and CI install the same version by construction, plus one gate pi does not need: a YANKED release is refused, because an exact pin installs one silently under PEP 592 and would have shipped a withdrawn palace client to the whole fleet. smoke gains `installed mempalace matches CI's audited pin` via a new EXPECTED_MEMPALACE_VERSION threaded into both smoke jobs. It is not redundant with `manifest mempalace_version matches the installed core`: that compares two properties of one image and cannot notice that both are the wrong version. The case this covers is a variant built FROM a cached base carrying an older pin — internally consistent, silently stale. Mutation-tested by extracting the shipped block out of the YAML and stubbing curl: 9 cases covering every gate, then once end-to-end against live PyPI. That found a real defect in the first draft — the yank message inlined a jq program inside $(...) inside a double-quoted string, where the escaping broke the filter (jq compile error) while the surrounding `exit 1` still fired: a gate that looked correct and reported garbage. Note: correcting Dockerfile.base's now-false "known gap, carried forward" comment forces a base rebuild (~67 min) on the next tag. Leaving a comment asserting the audit does not exist was the worse option.	2026-08-25 20:33:19 +02:00
joakimp	cb7b8ad2ae	smoke: assert manifest VALUES, not the presence of field names ... Four build-provenance assertions grepped the manifest for a field name and never looked at the value: run_expect "manifest records pi_version" "cat …manifest.json" '"pi_version"' which passes on {"pi_version": ""} and on {"pi_version": null}. The tell was in its own passing output the whole time — `✅ manifest records pi_version (got "pi_version")` echoes the key back as the thing it claims to have found. Found while reading run 579's smoke log to confirm v1.8.6's new assertions had really executed rather than merely gone green. Now checked against values, and against ground truth where it exists: - every required component key present, naming the one that vanished - every component value a full 40-hex SHA (null allowed for pi-studio alone, which is legitimately absent in the non-studio variant) - pi_version equal to `pi --version`, mirroring the mempalace ground-truth check - release_tag non-empty; source_revision 40-hex and build_date ISO-8601 *when populated*, since both default empty on a plain local `docker build` and demanding them would fail honest local smoke runs - --json compared byte-for-byte with the file, which is assertable because that mode is a verbatim cat; the old form grepped its output for "release_tag" Key presence and value shape are deliberately SEPARATE assertions: a single "all values are valid SHAs" loop passes vacuously on components:{}, because jq's all() over an empty list is true. Combining them would reproduce the same shape of hole as the three false greens already recorded in CHANGELOG.md. Dropped `manifest has no unresolved ('unknown') components`: the 40-hex check strictly subsumes it ("unknown" is not 40-hex, and only rev() emits it, feeding components{} exclusively). Removed rather than kept, because a check that can no longer fail independently is one more green tick that means nothing. Mutation-tested twice rather than reasoned about: nine fabricated manifests through the raw jq filters, then twelve through the shipped assertions using the real `run` helper's `sh -c` quoting path — the quoting is load-bearing, since a jq filter dying on a quoting error exits non-zero and looks exactly like a caught defect. Measured on the same twelve defects: old caught 3, missed 9; new catches 12. Three legitimate variations stay green (empty source_revision, empty build_date, null pi-studio). Also corrects a factually wrong "Still open" bullet in the released v1.8.6 entry, which claimed pi-devbox-version's human output does not show mempalace_version and that only --json surfaces it. Both halves are false: it prints a `palace:` line with live-vs-baked drift annotation, verified against fabricated manifests (match, skew, and pre-v1.8.6 absent-field cases). Left as a struck-through correction rather than deleted, since v1.8.6 is published.	2026-08-25 17:15:39 +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
joakimp	b5810654f6	skills: let the skillset own the skills it owns, and stop a dangling link from killing boot ... Baked skill links won over the live skillset clone for all three vendored skills, so a pushed edit to skills/mempalace/SKILL.md was invisible in every container until the next image build -- measured on two hosts (live md5 129bcc4752 vs baked 5236024fef). Cause was ordering, not intent: the baked links are created early with a create-only-when-absent guard to close a smoke readiness race, and the skillset deploy runs last and treats them as foreign. The comment claimed the opposite of the behaviour. The fix is not "skillset always wins". Ownership is per-skill: pi-extensions is owned by its package repo and copied over the snapshot at build time, so the skillset's lagging duplicate must keep losing; pi-devbox-environment is authored here. Only mempalace is skillset-owned. devbox-skill-reconcile therefore runs after the deploy and repoints only the names in skills/skillset-owned.txt, replacing a link solely when it points into the baked tree, so a real directory or a link pointing elsewhere is never disturbed. Precedence is now user override -> live clone (owned names) -> baked snapshot, with the early links intact as the fallback so the readiness race stays closed. Reviewing that turned up a latent boot-abort in the pre-existing baked-link block: `[ ! -e "$link" ]` is TRUE for a dangling symlink, so once a link can point into /workspace/skillset, a vanished mount makes plain `ln -s` fail with "File exists" -- and under `set -euo pipefail` that aborts container start before `exec "$@"`. Reachable on `docker restart` or a host reboot, not on a recreate, since ~/.agents is not a volume on any host. Now `ln -sfn`, which heals the link back to the baked fallback. Smoke additions cover what let this ship: the stale-snapshot canary grepped a phrase present in BOTH the stale and fresh copies, so it passed throughout; it now pins the newest section. Link targets are asserted, not just `test -L`; the owned-list content is asserted both ways; and the reconciler's replace path -- which no CI container exercises, since none mounts a skillset -- is covered by fabricating one. A mutation test showed the obvious three assertions still pass with the "is this link ours?" guard deleted, so a discriminating case was added: an owned name whose link is a user override outside the baked tree. Also refreshes the mempalace snapshot to skillset 670f7f1 (without it the fix helps only hosts that mount skillset) and corrects README, which documented the old, wrong precedence in three places. Verified with 12 fixture cases plus 2 mutants: ownership respected against the real trees, user overrides preserved, relative/trailing-slash/CRLF/space/glob inputs handled, dangling link healed, read-only skills dir exits 0, idempotent.	2026-08-23 20:59:14 +02:00
Joakim Persson	3a509077c2	v1.8.3: mempalace 3.7.1, refreshed skill snapshot, census on PATH ... mempalace 3.6.0 -> 3.7.1. Verified against the 3.7.1 source rather than its changelog, because the risk lands on palaces users cannot reconstruct: legacy drawers lack the new chunk_total marker and both decision sites trust them, so no mass re-mine; NORMALIZE_VERSION is 2 in both; chromadb stays <2 so no index-format migration; no auto-migration exists; logstream.sqlite3 is created lazily. Downgrade remains possible (3.6.0 has zero references to chunk_total). Two behaviour changes documented in the CHANGELOG: ALLOW_PEER_WRITER no longer works on local/chroma palaces, and writer-lock setup failures fail closed. Neither affects this image's MCP-server-plus-CLI-feeder pattern, which already serialised on the same lock under 3.6.0 -- the upstream "process-lifetime single-writer" entry describes tightened escape hatches, not a new lease. The motivation is the shared central palace: 3.7.1 drops the stale chromadb SharedSystemClient cache on reconnect (3.6.0 could let a stale in-memory HNSW segment overwrite a peer's writes, "index count going backwards"), releases the writer lease on SIGTERM/SIGHUP, and stops treating an interrupted mine as complete. The fleet primary was upgraded to 3.7.1 and restarted before this tag, because 3.7.1 refuses writes when the served library drifts and reconnect cannot clear that. opencode-devbox still pins 3.6.0, so the lockstep is broken until it cuts its own release. Vendored mempalace skill snapshot refreshed to skillset 936fed8 (was 63f3bf5). This closes a gap that had been invisible for two commits: ~/.agents/skills/ mempalace symlinks to the IMAGE-BAKED copy, entrypoint-user.sh creates that link first, and the skillset deploy never clobbers an existing name -- so in a devbox container the vendored snapshot always wins and editing skillset alone changes nothing a container reads. Brings the multi-machine shared-palace section and the hand-crafted-provenance guard. pi-global-AGENTS.append.md already carried the three shared-palace damage rules (a55f636); this tags them into a release. mempalace-census gets the /usr/local/bin symlink its three siblings have had all along, plus chmod and a build-time --help smoke check, so RFC-002 Phase A censuses no longer need an absolute path. Two new smoke assertions, both confirmed to FAIL against a v1.8.2 container so they are not tautological: the vendored snapshot must contain the multi-machine section (a stale manual snapshot is otherwise invisible), and mempalace-census must be on PATH. No other pins move: pi stays 0.84.2 (npm latest), pi-atelier v0.8.1, and every git-ref component was checked against its upstream head and is unchanged.	2026-08-16 23:30:01 +02:00
Joakim Persson	d8b745c164	smoke+docs: pin the feeder's failed-remote-mine detection; REMOTE_PATH is server-visible ... First boot of the 2026-08-15 image on EMB-7KJ4VR4G shipped 7 transcripts to the palace host and filed none. Two causes, neither visible in the log: - MEMPALACE_PI_REMOTE_PATH was unset, so the feeder used its /data/feed default, which assumes a CONTAINERIZED palace server. That fleet's primary runs natively (systemd user unit + uv tool), so it only sees host paths and the mine died with "source directory not found". rsync had already succeeded. - The feeder decided success with `'"error"' in body`, but MCP escapes the tool's JSON inside result.content[].text, so the check was blind and the catch-up log said "Done. Wing updated." Fixed in mempalace-toolkit 6e1f4f3, which ships `--self-test` with fixtures pinning that exact response body. - smoke-test.sh: run `mempalace-pi-session --self-test` against the BAKED toolkit, so a stale or reverted MEMPALACE_TOOLKIT_REF cannot reintroduce a feeder that mines nothing while reporting success. - .env.example: spell out that MEMPALACE_PI_REMOTE_PATH is the path the SERVER PROCESS can open — container path for a dockerized server, and identical to the ssh-target path for a native one — and that a mismatch fails quietly.	2026-08-16 00:30:51 +02:00
Joakim Persson	53b41cd76b	smoke: assert the pi stage $HOME-relative, and add a smoke_only dispatch ... v1.8.0 never shipped: smoke (67/68) and smoke-studio (70/71) each failed the same single assertion, so build-variant and everything downstream skipped and latest stayed on v1.7.0. The assertion was wrong, not the product. It grepped for a literal stage=/home/developer/.mempalace/pi-stage/, but run() invokes docker run --rm --entrypoint="" "$IMAGE" sh -c "$cmd" and neither Dockerfile sets USER or ENV HOME — the published base image config has no HOME at all; it is normally set by entrypoint-user.sh, which --entrypoint="" skips on purpose. So the assertion executed as root with HOME=/root, mempalace-pi-session correctly resolved stage=/root/.mempalace/pi-stage/... (the stage is $HOME-relative by design), and the literal grep could never match under any circumstances. The tell was one line below in the log: the sibling assertion "pi stage follows MEMPALACE_PALACE_PATH" PASSED, because it sets the variable explicitly and never consults HOME. Default fails + explicit passes = wrong HOME, not broken staging. Now asserts the invariant actually intended — the stage sits beside the resolved palace, sharing its lifetime — which is user-independent: case "$stage" in "stage=$HOME/.mempalace/pi-stage/"*) exit 0 ;; *) exit 1 ;; esac $HOME is expanded by the container's own shell, so it holds as root, as developer, or under any future user. Verified all four cases against the real bin/mempalace-pi-session by extracting the committed assertion bodies and running them under sh -c: virgin HOME -> exit 0; HOME=/home/developer -> exit 0; MEMPALACE_PI_STAGE pinned to a .cache path -> exit 1 (the regression this assertion exists to catch still fails it); developer-identity companion -> 0. Added that companion assertion, "pi stage is palace-adjacent for the developer user", which covers the deployment-specific path properly by SUPPLYING HOME=/home/developer rather than assuming it. Why this took a release to surface: docker-publish.yml triggers on push tags v* only. The assertion was added on a push to main (7c00dd6), where only lint.yml runs, so v1.8.0 was its first execution ever. Any smoke assertion written outside a release was unvalidated until a release consumed it. New workflow_dispatch input smoke_only probes/builds the base, runs both smoke jobs against HEAD, and stops before publishing. Implemented as `if: inputs.smoke_only != 'true'` on build-variant and build-variant-studio, deliberately WITHOUT always() so the implicit needs-succeeded gate survives and a red smoke still blocks a release. promote-base-latest and update-description already require build-variant success, so they skip on their own. On a tag push inputs is unset and null != 'true' is true, so releases are unaffected. Finally, run() no longer discards output. A red ❌ carried zero diagnostic weight: explaining this one-line failure needed a CI-log dig plus a registry image-config inspection, when the container had already printed the answer. Failures now show the last lines of output (guarded with `if`, not a trailing `&&`, which would abort under set -e), and the stage assertions echo the resolved stage and the HOME they saw to stderr — invisible while they pass.	2026-08-15 12:29:32 +02:00
Joakim Persson	cbd7cf5c67	entrypoint: announce the "remote palace, no inbox" skip instead of vanishing ... When MEMPALACE_REMOTE_URL is set but MEMPALACE_PI_SSH_TARGET is not, the feeder has nowhere to ship staged transcripts, so skipping is correct. The problem was that the branch was a bare `:` AND the skip happens before the subshell that writes ~/.pi/agent/mempalace-catchup.log -- so a container in that state contributed nothing to the palace and left no artifact at all, not even an empty log, to explain why. It is indistinguishable from a healthy run that had nothing to file, which is the worst property a memory system can have: the failure looks exactly like success. Surfaced while flipping the first client onto the shared palace, where this is the single most likely way to end up quietly memory-less -- the palace is the only thing that survives a container recreate. The notice goes to both the container start output (docker logs) and the log path anyone debugging looks at first. It names both variables, says what still works (MCP tools read/write the shared palace; only this container's own conversations go nowhere), and points at MEMPALACE_FEED=0 for anyone who meant it -- "HTTPS first, mining later" is a documented interim state, so the notice has to be silenceable without being ignorable. Guarded against becoming a startup failure. mkdir -p in a branch that previously touched no filesystem is a new risk: an unwritable ~/.pi (root-owned volume, a classic Docker accident) fails under set -e and would abort the entire entrypoint. It now degrades to stdout-only. Verified all five paths by executing the extracted block under `set -euo pipefail`: the trap prints and writes the log; unwritable ~/.pi still exits 0 and still prints; MEMPALACE_FEED=0 stays completely silent (no message, no file); and both normal-remote and local mode still background the feeder with no notice. Two smoke assertions guard against a regression to the silent no-op. They test the entrypoint as shipped in the image rather than behaviour, because this branch only runs at container start and a `docker run` one-shot cannot reach it. entrypoint-user.sh is COPY'd in Dockerfile.base, so this rides the base rebuild the Unreleased feeder work already needs.	2026-08-13 16:30:55 +02:00
Joakim Persson	7c00dd6001	mempalace: drop the stage ENV pin, fix the shared-server compose ... The feeder now defaults to <palace-root>/pi-stage upstream, so pinning MEMPALACE_PI_STAGE into ~/.pi here is unnecessary -- and was actively wrong. It created a second convention that could still diverge from the palace: keep the devbox-palace volume, drop devbox-pi-config, and a scoped `mempalace sync` prunes every conversation drawer, because dedup keys on the staged path. Both the ENV and the entrypoint export are gone; a comment explains why adding one back re-introduces the split it was meant to fix. docker-compose.mempalace.yml was broken on mempalace 3.6.0 in both directions: - `--host 0.0.0.0` with no token in the environment makes the server refuse to start, crash-looping under `restart: unless-stopped`. - Supply a token and the healthcheck's unauthenticated `tools/list` POST 401s, marking a perfectly healthy server unhealthy forever. Now the token is required via ${MEMPALACE_REMOTE_TOKEN:?...} so it fails fast at `docker compose up` with a readable message, and the healthcheck probes the deliberately token-free /healthz. The "no authentication of its own" security note has been stale since 3.6.0 and is replaced with the actual posture (bearer token + Host pin + Origin allowlist), including why browser-shaped auth must not be put in front of it. Dockerfile.base: mempalace-pi-session symlinked onto PATH, with a build-time `--help` check so a broken feeder fails the image build rather than the first session. smoke-test: assert the stage resolves beside the palace (default, and following $MEMPALACE_PALACE_PATH) instead of asserting the removed ENV pin. The two behavioural guards -- a synthetic session that must be captured, an abandoned one that must not be -- are unchanged. .env.example: recommend `mempalace serve` on the docker0 gateway rather than `mempalace-mcp --transport http --host 0.0.0.0`, with the two binds to avoid.	2026-08-12 17:04:14 +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	8248688d58	fix(entrypoint,tests): register pi-fork — guard matched its own config block ... The `pi install /opt/<pkg>` loop in entrypoint-user.sh guarded on a whole-file substring grep of ~/.pi/agent/settings.json. settings.example.json ships a top-level "pi-fork" CONFIG block (fork effort profiles, pi-toolkit adb6907, 2026-06-17), so `grep -q pi-fork settings.json` matched the config key itself and `pi install /opt/pi-fork` never ran — on fresh or preserved volumes. The `fork` tool has therefore been absent since v1.0.0. The non-destructive template merge runs earlier in the same startup than the install loop, so the mechanism that delivers new template keys to an old volume is what plants the string that defeats the guard. pi-observational- memory and pi-studio escaped only by luck: the template key is "observational-memory" (no pi- prefix) and there is no studio block. Guard now inspects the `packages` array via jq, with a grep fallback on the stored `.../opt/<name>"` path form, which a config key can never produce. Existing volumes self-heal on the next container start. Both test suites asserted the bug as green — smoke-test.sh:244 and recreate-sanity-check.sh:204 used the same whole-file grep, so "pi-fork registered (fork tool)" passed on every build and recreate while the tool was missing. Both now assert against packages[] with the entrypoint's predicate, labels say packages[], and the smoke readiness wait loop uses the array check plus `docker exec -u developer` + $HOME instead of a hard-coded /home/developer path. Evidence: zero `fork` tool calls across all 19 sessions on this volume; the v1.6.3 session that tuned pi-fork.deep to opus-5 was configuring a tool that never loaded.	2026-07-29 19:21:49 +02:00
joakimp	6dfbded9c8	release: v1.6.2 — lift smoke size threshold (3500→3800) ... Completes v1.6.1's studio publish. Run 512 shipped v1.6.1 non-studio (3411 MB) cleanly, but smoke-studio failed the size gate at 3574 MB vs the 3500 MB threshold. Threshold was set in v1.0.0 pre-agent-browser (baseline was 3.20 GB local arm64 + 300 MB margin); v1.6.0 baked in agent-browser + Chromium (+~291 MB net) but the threshold was never lifted. v1.6.0 never got to smoke because of the network fault, so nothing surfaced this until v1.6.1's smoke-studio. Bump SIZE_THRESHOLD_MB to 3800 (~225 MB margin above observed studio number, tight enough to still catch a genuine +GB regression). Refresh the comment above the constant with the current baseline + run 512 actuals so future readers know where the number came from. CI-only change; image bytes identical to v1.6.1 except for the manifest's release_tag/source_revision. Not base-affecting.	2026-07-23 08:43:57 +02:00
joakimp	45b6239777	test(smoke): don't hard-code a 'v' prefix on release_tag ... The smoke workflow deliberately passes RELEASE_TAG=smoke to the variant build so smoke images don't collide with real vX.Y.Z tags. The variant bakes that into /etc/pi-devbox/build-manifest.json, and pi-devbox-version prints 'pi-devbox smoke' — correct behaviour. But the smoke assertion required substring 'pi-devbox v', which only holds for real releases. Assertion never fired before because pi-devbox-version was added after v1.5.0 (fb49828, 2026-07-15) and every CI attempt since was blocked before smoke ran (v1.6.0 network flake, v1.6.1 first successful base build hit this). CI run 509 (v1.6.1) surfaced it. Fix: require the substring 'pi-devbox ' (space, no v). The two neighbouring assertions on --json and --quiet already cover the value of release_tag; this one just verifies the human line renders. Everything else in 55/56 checks passed on run 509 including pi 0.81.1 reported and base-229f04e5d021 pushed OK.	2026-07-23 07:58:22 +02:00
joakimp	fb49828826	base: add pi-devbox-version command + startup banner ... Wraps /etc/pi-devbox/build-manifest.json (already written at docker-build time in Dockerfile.variant) into a human-readable summary instead of requiring users to know the manifest path and pipe it through jq themselves. - rootfs/usr/local/bin/pi-devbox-version: human (default) / --json / --quiet output modes. Also flags live drift — compares the baked pi_version against the actually-running `pi --version` and warns on mismatch rather than trusting the manifest blindly (same ground-truth philosophy as the manifest generation itself). Exits 1 with a short stderr notice on images built before the manifest existed, instead of failing silently. - entrypoint-user.sh: calls it as the very first line. CMD is `bash -l` with tty:true in compose, so this banner lands directly above the first prompt on container start — no separate motd/bashrc hook needed (deliberately not wired into .bash_aliases, which would reprint on every docker exec -it). - Dockerfile.base: COPY + chmod, same pattern as dot-watch/studio-expose. - scripts/smoke-test.sh: 4 new checks (binary present+executable, human output has release tag, --json round-trips the manifest, --quiet is a single line). - README.md / AGENTS.md / CHANGELOG.md updated.	2026-07-15 14:50:47 +02:00
pi	8c27894cf2	base: support modern terminals (ncurses-term + xterm-ghostty alias) ... The base only shipped ncurses-base (xterm-256color, tmux), so SSHing in from WezTerm/Alacritty/foot/Ghostty degraded to a dumb TERM fallback. Following the maintainer's ansible common role: - Dockerfile.base: install ncurses-term (terminfo for wezterm, alacritty, foot, st, base ghostty entry, and many more). - rootfs/.../terminfo-src/ghostty.terminfo: thin xterm-ghostty alias (use=ghostty) — Ghostty connects as TERM=xterm-ghostty, which no distro packages. Compiled into the system db with 'tic -x'; build asserts it resolved via infocmp. - kitty (xterm-kitty) already covered by kitty-terminfo; iTerm2 uses xterm-256color (ncurses-base). - smoke-test: assert ncurses-term emulators + xterm-ghostty alias resolve. Validated end-to-end in a throwaway container: ncurses-term brings the entries, the alias compiles and equals the ghostty capability set. hadolint clean, bash -n OK. Base-affecting, rebuilds base-<hash>. No tag.	2026-07-13 18:45:38 +02:00
pi	aaf1be0bcb	base: readable Neovim colours out of the box (termguicolors + kitty-terminfo) ... Vanilla Neovim fell back to a 256-colour palette over ssh/kitty and rendered strings/comments in a muddy, low-contrast colour. Fix, all base-affecting: - rootfs/etc/xdg/nvim/sysinit.vim: system vimrc enabling termguicolors. Loads for every user before any personal ~/.config/nvim; overridable per-user. - Dockerfile.base: install kitty-terminfo (TERM=xterm-kitty understood; lets Neovim auto-detect true colour) and set ENV COLORTERM=truecolor. - smoke-test.sh: assert xterm-kitty terminfo present and nvim tgc default on. - CHANGELOG (Unreleased/Added) + README editor note. No tag — lands on the next base-<hash> rebuild.	2026-07-12 23:19:19 +02:00
pi	67da05b99b	feat(base): ship typst as lightweight pandoc PDF engine ... pandoc has been in the base since v1.0.0 but only as a front-end; PDF export (studio_export_pdf / pandoc -o out.pdf) failed with 'xelatex not found' because no back-end engine was installed. Ship typst (~30 MB static Rust binary, no LaTeX) as the default engine via `pandoc --pdf-engine=typst`, chosen over a ~600 MB TeX Live install. texlive-xetex remains the higher-fidelity install-on-demand fallback. - Dockerfile.base: install typst (latest GitHub-release idiom, pin via TYPST_VERSION); add xz-utils (typst ships .tar.xz); bump BASE_REBUILD_DATE. Lands in base-<hash>. - smoke-test.sh: verify typst + a real pandoc --pdf-engine=typst render. - README/AGENTS/CHANGELOG: typst now shipped (supersedes the planned :latest-studio-tex variant). No tag pushed — CI build intentionally deferred.	2026-07-11 17:04:19 +02:00
pi	3a59e15563	feat: ship nano + micro (non-modal editors) alongside nvim ... The image shipped only nvim (EDITOR=nvim), a modal vi-style editor. Not everyone is comfortable with vi keybindings, so add both a classic and a modern non-modal option: - nano (apt): ~2.8 MB installed; deps (libc6, libncursesw6, libtinfo6) already present via nvim/less/htop/tmux, so no extra packages pulled in. - micro: ~12 MB single static Go binary from GitHub releases (same pattern as bat/eza/zoxide). Desktop-style keys (Ctrl+S/Ctrl+Q), mouse, syntax highlighting. ARG MICRO_VERSION pins; defaults to latest. Combined ~15 MB (<0.5% of the ~3.2 GB image). EDITOR stays nvim; both new editors are opt-in (export EDITOR=micro | nano). Uses the canonical micro-editor/micro URL because the old zyedidia/micro org rename makes /releases/latest redirect to another /latest, defeating the tag-parsing latest-resolution idiom. Base-image change, so it lands on the next base-<hash> rebuild. Updates README tool table + EDITOR note, CHANGELOG (Unreleased/Added), and smoke-test.sh (nano + micro presence checks).	2026-07-01 23:11:25 +02:00
pi	cda488c565	base: yq follows latest (was pinned v4.53.3), gate on major v4 ... Match the repo's latest-following convention (tealdeer/uv/etc.) and keep the container in sync with the Mac's brew yq. smoke-test now asserts mikefarah AND major v4, so a surprise yq v5 fails CI instead of silently breaking provision.sh. Pin still available via --build-arg YQ_VERSION=vX.Y.Z.	2026-06-25 16:33:27 +02:00
pi	9ab9a28458	base: install mikefarah yq (pinned v4.53.3), drop Debian python yq ... Debian/Ubuntu `apt install yq` is kislyuk/yq (Python, v3.x), incompatible with the mikefarah v4 syntax the cloud-init repo's provision.sh/deploy.sh require. Replace the apt package with a pinned mikefarah Go binary, mirroring the existing tealdeer ARG (latest-or-pin) pattern, multi-arch amd64/arm64. smoke-test.sh now asserts `yq --version` reports mikefarah so CI catches a regression. CHANGELOG: Unreleased entry.	2026-06-25 16:29:51 +02:00
Joakim Persson	7551947466	feat(skills): add mempalace proactive-load directive for containers ... Baking the mempalace fallback skill fixed *availability*, but mempalace had no proactive-load directive anywhere (pi-toolkit's global AGENTS.md only points to pi-extensions), so a new container would still surface it only via description-matching — the same under-utilisation the pi-extensions directive was created to fix. Add a session-start pointer to the pi-devbox managed AGENTS.md block (pi-global-AGENTS.append.md): gated to pi-devbox containers and conditional on the MemPalace MCP tools being present. Memory continuity matters most in a frequently-recreated container — the palace is its only cross-recreate memory. - pi-global-AGENTS.append.md: '## Session start: load the mempalace skill'. - smoke-test: assert the pointer merges into the global AGENTS.md at build. - docs: VENDORED.md, README, CHANGELOG [Unreleased]. Now both skills are complete in pi-devbox: directive + skill file. pi-extensions = directive (pi-toolkit) + baked skill; mempalace = directive (this block) + baked skill.	2026-06-23 15:54:13 +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	d619a6e2ec	fix(entrypoint,smoke): link image-baked skills early to fix smoke race ... The runtime 'pi-devbox-environment skill linked' smoke assertion failed in CI run 408 (gating build-variant). Root cause: the skill-linking block ran AFTER the pi-toolkit/extensions deploy, but the smoke readiness gate only waits on pi-deploy markers (keybindings.json, mempalace.ts) — which land before the skill symlink — so the assertion sampled too early. - entrypoint-user.sh: move the image-baked-skills symlink loop to run early (before the pi deploy block), so it completes before any readiness marker. Still before the skillset deploy, so foreign-link semantics are unchanged. - smoke-test.sh: add the skill symlink to the readiness gate as well. Build-time checks (baked skill, append snippet, merged AGENTS marker) all passed in 408; only the timing of the runtime check was wrong.	2026-06-23 14:29:52 +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	7d8ee4cea1	feat(studio): bundle studio-expose bridge + socat (opt-in STUDIO_EXPOSE) ... pi-studio binds the container's 127.0.0.1, which a published Docker port can't reach. Add a robust, portable bridge rather than a doc-only one-liner: - Dockerfile.base: add socat (~1 MB, generally useful TCP relay). - rootfs/usr/local/bin/studio-expose: socat TCP relay listening on the container's egress IPv4 (not 0.0.0.0 — that would EADDRINUSE against Studio's loopback listener) forwarding to 127.0.0.1:PORT on the SAME port, so Studio's printed token URL works verbatim. Robust egress-IP detection (hostname -I, loopback-filtered; ip route get fallback), --help, port validation, foreground. - entrypoint-user.sh: opt-in STUDIO_EXPOSE=1 auto-starts the bridge in the background (studio variant only). Default OFF — Studio stays loopback-only (its secure default) unless explicitly opted in. - README: 'Using pi-studio' now documents host-networking (A) and the studio-expose/STUDIO_EXPOSE bridge (B) with a security note; ssh -L for remote, mosh caveat retained. - smoke-test: assert socat + studio-expose present (base-level). - CHANGELOG/AGENTS updated. No tag — stopping for review.	2026-06-10 23:33:44 +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	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
pi	36afd3c716	Release v0.79.0 — pi 0.78.1 -> 0.79.0 ... First build on pi 0.79.0. Built FROM the republished base-pi-only from opencode-devbox v1.16.2 (carries pi 0.79.0). Bump smoke size threshold 2750 -> 2850 MB in lockstep with opencode-devbox's pi-only variant. Promote CHANGELOG Unreleased -> v0.79.0.	2026-06-08 22:00:24 +02:00
pi	1d1283f942	refactor: FROM opencode-devbox:latest-pi-only (lean, no opencode) ... Re-point the re-brand at the new pi-only variant instead of with-pi, so pi-devbox stays a lean pi-focused image (no opencode) while the pi install logic still lives in one place upstream. This keeps pi-devbox meaningfully distinct from opencode-devbox:latest-with-pi. - Dockerfile: BASE_IMAGE default -> joakimp/opencode-devbox:latest-pi-only. - smoke-test.sh: size threshold 2900 -> 2750 MB (pi-only = with-pi minus opencode's ~145 MB binary). - Docs (README/AGENTS/DOCKER_HUB/CHANGELOG/docker-compose): drop the 'also contains opencode' notes; describe pi-only basis and the distinction from with-pi. Publish ordering unchanged: release opencode-devbox first so latest-pi-only carries the target pi version, then tag here (smoke asserts pi --version).	2026-06-03 16:14:05 +02:00
pi	c139be326f	refactor: re-brand the opencode-devbox with-pi variant (single source of truth) ... pi-devbox no longer installs pi itself. The Dockerfile is now a thin FROM joakimp/opencode-devbox:latest-with-pi (overridable via BASE_IMAGE), inheriting pi + pi-toolkit + pi-extensions + pi-fork (fork) + pi-observational-memory (recall) + the LAN-access helper + all base tooling from the single source of truth. Eliminates the install-logic duplication that drifted against opencode-devbox/Dockerfile.variant (decision #3). Consequences (documented in CHANGELOG/AGENTS): - The image now ALSO contains opencode (with-pi has INSTALL_OPENCODE=true). A leaner pi-only image would need a dedicated pi-only variant upstream. - Publish ordering: release opencode-devbox first so latest-with-pi carries the target pi version, THEN tag this repo. The smoke test asserts pi --version matches the tag (EXPECTED_PI_VERSION) and fails loudly if the base is stale — turning the version coupling into an enforced ordering guard. CI: drop PI_VERSION build-arg (Dockerfile installs nothing); keep tag->version resolution to feed the smoke base-freshness guard. Smoke adds fork/recall clone + node_modules + settings.json registration checks; size threshold 2200 -> 2900 MB (now tracks with-pi). Docs updated across README, AGENTS, DOCKER_HUB, .env.example, docker-compose.	2026-06-03 15:51:41 +02:00
joakimp	34cae2a1d2	Cut v0.75.5b — fix cache-hit silent same-bytes regression ... ALL FOUR releases v0.74.0 -> v0.75.5 had been shipping the same image bytes due to a Docker layer-cache hit on the bare 'npm install -g @earendil-works/pi-coding-agent' command (when PI_VERSION=latest). The command string is identical across builds, so the layer-hash is identical, so registry buildcache (cache-from/cache-to) silently reuses the layer from whatever pi version was current when the cache was first populated. Verification: docker manifest inspect joakimp/pi-devbox:vX.Y.Z showed identical SHA256 digests on both linux/amd64 and linux/arm64 for v0.74.0, v0.75.3, v0.75.4, v0.75.5. Users on :latest were getting whatever pi version was baked into the v0.74.0 build. DISCOVERED 2026-05-23 by user trying to update pi-devbox on MBP-M1 and seeing pi 0.74.0 reported despite pulling v0.75.5. CHANGES .gitea/workflows/docker-publish.yml — both smoke and publish jobs get a new 'Resolve PI_VERSION from tag' step that strips the leading 'v' and any trailing letter suffix from github.ref_name. Result is passed as a build-arg to docker/build-push-action so the npm install layer's hash includes the concrete version, forcing cache miss when pi bumps. scripts/smoke-test.sh — new run_expect helper that asserts pi --version contains the EXPECTED_PI_VERSION env var. Smoke job sets this from the resolve step output. Would have caught this regression on v0.75.3. Dockerfile — comment block above ARG PI_VERSION=latest documenting the cache-hit footgun. The 'if latest' branch in the install RUN is preserved for local dev convenience but never fires in CI now. AGENTS.md — new convention bullet explaining the cache-hit class of bug and noting the latent same-bug in opencode-devbox's with-pi variants (currently masked by OPENCODE_VERSION bumps; will manifest when cutting a vN.N.Nb-style opencode-version-unchanged release that only bumps pi). CHANGELOG.md — full entry under v0.75.5b describing the recovery, the silent-failure mechanism, and the verification steps. NO IMAGE-CONTENT CHANGES vs v0.75.5 INTENT. This build produces the actual pi 0.75.5 image content that v0.75.5 was supposed to ship. NEXT FOLLOWUP (parked, not in this commit) opencode-devbox should get the same workflow change for its build-variant-with-pi and build-variant-omos-with-pi jobs. Currently masked because every release also bumps OPENCODE_VERSION which invalidates the cache, but that masking would fail on a pi-only bump release.	2026-05-23 22:10:08 +02:00
joakimp	8ab0f9c760	smoke-test: docker exec -u developer for runtime deployment checks ... Without -u, docker exec runs as root and $HOME expands to /root, so the test looks for ~/.pi/agent/keybindings.json under /root instead of /home/developer. install.sh actually deploys correctly — the test was just probing the wrong home directory. Match opencode-devbox/scripts/smoke-test.sh's pattern.	2026-05-15 01:01:54 +02:00
joakimp	aa3f4b7b90	smoke-test: keep baked entrypoint when probing runtime deployment ... The previous `docker run -d --entrypoint="" ... sleep 60` bypassed the entrypoint chain entirely, so entrypoint-user.sh never ran, so pi-toolkit/install.sh never deployed keybindings + extensions to ~/.pi/agent/. Result: 4/14 smoke checks always failed. Match opencode-devbox's pattern: `docker run -d --rm "$IMAGE" tail -f /dev/null` keeps the entrypoint chain intact and overrides only CMD.	2026-05-15 00:52:14 +02:00
joakimp	9302b3ebb9	smoke-test: replace ((VAR++)) with VAR=$((VAR+1)) to avoid set -e exit ... ((VAR++)) returns the OLD value, so when PASS=0 the first ✅ check caused exit code 1, killing the script under set -e. Use VAR=$((VAR+1)) which always returns 0. Same pattern as opencode-devbox's smoke-test.	2026-05-15 00:40:28 +02:00