43 Commits

Author	SHA1	Message	Date
Joakim Persson	31f36182bf	feat(base): add sqlite3, bc, dc and bsdextrautils ... sqlite3 is the only one of the four that was genuinely missing rather than merely absent. MemPalace keeps both the palace and the logstream as SQLite files (palace/chroma.sqlite3, logstream.sqlite3) and mempalace_status reports a sqlite_integrity block, so every integrity or forensics check on this fleet has so far gone through a python3 -c one-liner because the CLI was not in the image. bc and dc are low value on their own and the CHANGELOG says so plainly: awk, python3 and perl are all already baked and each is strictly more capable. They are here because copy-pasted shell snippets assume bc exists. What actually went wrong on 2026-09-28 was NOT bc's absence: printf '%6.2f' was handed the empty output of the missing bc and rendered it as a confident "0.00 days" for a figure that was really 4.81 days. No package fixes that failure mode -- only not taking a formatted number on trust does. bsdextrautils ships /usr/bin/column. Cost MEASURED rather than estimated: 1311 KB total (587 + 236 + 149 + 339) and ZERO transitive packages. libsqlite3-0, libreadline8t64, zlib1g, libsmartcols1 and libtinfo6 each already report "install ok installed", so nothing new is pulled under --no-install-recommends. Package names were verified with apt-cache and dpkg -S on a real trixie host instead of being inferred, which caught two traps that would each have produced either a build failure or a silently missing binary: dc is a SEPARATE binary package from bc on Debian, and column ships in bsdextrautils, not in the pre-bullseye bsdmainutils where it used to live. Declined at the same time, recorded so the omission reads as a decision rather than an oversight: datamash and xsv/csvkit. Python's stdlib csv module handled a real 7-file Excel-export concatenation that day -- UTF-8 BOM, no trailing newlines, and bare CR/LF inside quoted fields -- correctly and without them. Dockerfile.base is in the base hash, so the next tag rebuilds the base (~64 min) regardless of what else it carries.	2026-10-01 23:31:03 +02:00
joakimp	16fddebd43	docs(v1.9.4): the client/server skew is narrower than the release commit said ... e3b38cd named "the feeder against the 3.9.0 hub" as the one path to exercise before tagging, on the reasoning that 3.10.0's CLI writes now follow the daemon write-routing policy. That was a reading of the mempalace changelog, not a measurement of this image's feeder. Measured now: mempalace-pi-session in remote mode (MEMPALACE_REMOTE_URL set, which is how every fleet devbox runs) stages transcripts locally in python, rsyncs them to the hub host, and calls the hub's own `mempalace_mine` MCP tool over HTTP (run_remote_mine). The local `mempalace` CLI is required only in local mode (line 475) and invoked only on the local branch (line 1029). With a PATH shim logging every `mempalace` invocation, a 47-session `--dry-run` from this container logged ZERO calls; the shim's positive control logged one. The pi extension likewise speaks HTTP to the hub and spawns no local mempalace-mcp. So the 3.10.0 CLI never runs against the 3.9.0 hub from this image. In remote mode the client pin touches first-run `mempalace init` and the on-disk layout, nothing else -- which is exactly what the ENV MEMPALACE_CONFIG_DIR change is for. Both the Dockerfile.base comment and the CHANGELOG paragraph now say so, and the "Still open" item becomes the thing that is actually unmeasured: a first-boot acceptance of the built image from an empty ~/.mempalace volume. Gates re-run on this tree: check-doc-drift.sh rc=0, lint-shell.sh rc=0, hadolint 2.15.1 rc=0. lint.yml for e3b38cd: run 693, completed, success.	2026-09-22 14:51:22 +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
Joakim Persson	6c13f43ac8	release: date the v1.9.3 section for the tag ... CI checks out the tag, so the CHANGELOG heading has to name the version before the tag exists (same convention as v1.9.1/v1.9.2). check-doc-drift check 9 was sabotage-tested for exactly this rename and still passes: everything above the published v1.9.2 heading is the pending text. Contents of v1.9.3 (all measured, nothing inherited): - f25efa0 recreate-sanity-check resolves the ControlPath ssh actually uses (ssh -G); the ~/.pi/ssh/config hyphen typo deleted - b8d818e Hub size claims corrected; check 8 gates them against full_size - c7d369f promote-base-latest's conditional re-tag measured (run 669) - 50153e6 skill floor -> pi-extensions 25c1265 (task tool + fork-gate) - ea89605 changelog for the two floating-ref changes: pi-extensions 25c1265 and mempalace-toolkit 817b3a8 (mine deadline) - cb6d9e5 check 9: what the next build bakes differently must be named in the CHANGELOG; first run found pi-obsmem 7b397f4->cba0334 - b9057fd LABEL se.jordbo.pi-devbox.mempalace-version (inherited) - 960aada dependency audit 2026-09-19; mempalace 3.10.0 deferred Floating refs this tag will bake, named per check 9: pi-toolkit 9c87ee8, pi-extensions 25c1265, mempalace-toolkit 817b3a8, pi-observational-memory cba0334 (3.1.3). Base REBUILDS (Dockerfile.base + rootfs/ changed), so the BASE_REBUILD_DATE marker is refreshed now, when it is free -- it had been stale since 2026-07-13 through two rebuilds. Deliberately NOT in this tag: mempalace 3.10.0 (see the audit section for the three measured preconditions).	2026-09-19 17:45:50 +02:00
Joakim Persson	b9057fdc8c	Dockerfile.base: LABEL se.jordbo.pi-devbox.mempalace-version, inherited by both variants ... Closes the blind spot check 9 (cb6d9e5) named: no label recorded the palace pin, so a MEMPALACE_VERSION bump — the one component whose skew against the shared central palace is fleet-wide — could ship without a CHANGELOG line. In Dockerfile.base, not Dockerfile.variant, deliberately: the value sits next to the ARG that defines it (a copy in the variant is one more pin able to drift); labels are inherited by every image built FROM the base, so no build-arg to plumb through the variant's four call sites; and inheritance means the label states the pin of the base the image ACTUALLY built on, which is the question when base-decide cache-hits an older base. Both mechanisms measured on the published v1.9.2 config blob rather than assumed: maintainer + image.source (set only in Dockerfile.base) are present on the variant image, and pi-version=0.85.1 is an ARG expanded inside a LABEL. Intent, like every se.jordbo.pi-devbox.* label; the manifest's mempalace_version (read from the installed binary) stays the ground truth, and smoke-test.sh now asserts label == installed core — the one way they diverge is a base built with INSTALL_MEMPALACE=false or an off-pin install, both invisible to a label-only check. check-doc-drift check 9 gains the component (literal, against ARG MEMPALACE_VERSION in Dockerfile.base); the label-key rule generalises to "names ending in -version are the label itself". Until a release carries the label it reports a counted SKIP, not OK — measured: "v1.9.2 carries no se.jordbo.pi-devbox.mempalace-version label", summary says 1 SKIPPED. Costs nothing extra: this Unreleased already forces a base rebuild (50153e6 rootfs/ skill floor). check-base-hash unchanged (no new *_REF).	2026-09-19 17:27:34 +02:00
Joakim Persson	ea896054df	changelog: task tool + fork-gate (pi-extensions 25c1265), and the mine deadline that never reached the transport (mempalace-toolkit 817b3a8) ... Both land in the image through floating refs (PI_EXTENSIONS_REF=main, MEMPALACE_TOOLKIT_REF=main), so neither shows up as a diff in this repo — the changelog is the only place a reader of a pi-devbox tag learns that the container's delegation and feed behaviour changed. Recorded under Unreleased with the measurements: 5/5 real fork briefs redirected, live pi -p proof for gate and tool, 2-of-6 → 6-of-6 on the toolkit's new timeout test. Dockerfile.base: the "Stall protection" comment listed MEMPALACE_MCP_TIMEOUT_MS as THE tool-call deadline; it now says the feed's mine carries its own. Comment-only, but Dockerfile.base is hashed into base_tag; the rebuild was already forced by 50153e6 (rootfs/ skill floor).	2026-09-19 17:00:59 +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
Joakim Persson	cac5e00a31	feat(ci): gate the vendored pi-extensions skill floor, and bake python3-yaml ... Follows ecfd2fc, which refreshed the stale floor by hand. A one-off refresh fixes the symptom; this makes the drift impossible to reintroduce silently. scripts/check-skill-floor.sh compares the repo floor (rootfs/usr/local/share/pi-devbox/skills/pi-extensions/) against the package repo it is a snapshot of, wired in as a new `skill-floor` job in lint.yml. DIRECTORY hash, not `sha256sum SKILL.md`, using the same tree_sha256 pipeline Dockerfile.variant uses for skillset_snapshot_tree_sha256 and for the reason already documented there: a file-only compare answers "did this one file change", not "is this the same skill". Verified by NEGATIVE CONTROL rather than asserted -- with SKILL.md left byte-identical and only evaluate-extension-usage.py edited, the directory check fails (rc=1) where a file-only compare would have passed. Seven behaviour tests, each with its expected rc written down before running: in-sync via local dir (0), in-sync via anonymous remote clone (0), missing --package-dir (2), bad argument (2), content drift (1), the sibling-file case (1), and --warn-only over drift (0). Exit codes 0 in sync / 1 drift / 2 cannot-run, matching scripts/lint-shell.sh: a gate that cannot run must not pass, so an unreachable package repo is a red 2 and never a green tick. A ref with no skill/ is NOT drift -- that is the documented fallback -- but it emits ::warning:: because it is precisely the condition under which the floor ships. Gating on another repo is normally a smell. It is proportionate here because the check can only fire when skill/ itself changed, which is exactly when the floor has gone stale; pi-extensions commits that leave skill/ alone cannot turn this red. It also needs no secret: pi-extensions is anonymously clonable (verified with `git ls-remote` and no credentials), so it cannot start failing when a token expires. Also bakes python3-yaml (552 KB, zero extra deps) into Dockerfile.base. This is the shellcheck story repeating exactly: scripts/check-workflow-shell.sh -- the guard against the Gitea sh/dash footgun that broke resolve-versions (ed49b8d) and promote-base-latest (b7197e8) -- hard-exits with "python3 yaml module missing", so a gate this repo already owns could not be run locally by anyone. lint.yml installing it explicitly in CI was the evidence. Found while wiring the job above: the guard could not be run before pushing. CHANGELOG Unreleased updated for both this and ecfd2fc, including an explicit note on what is NOT fixed -- the silent-fallback half still has no manifest flag recording which copy was served. Verified locally with every gate this repo owns, all green: lint-shell.sh (15 files clean), check-workflow-shell.sh, check-base-hash.sh, actionlint 1.7.7 (pinned, same version as CI), hadolint 2.14.0, and the new check itself.	2026-09-10 19:14:01 +02:00
Joakim Persson	ecfd2fc2e5	feat: bake dig/ldapsearch/xxd and refresh the stale pi-extensions rootfs floor ... Two changes that share one forced base rebuild, hence one commit. 1. THREE PACKAGES, each closing a capability gap measured during the gitea.egl.lan/FreeIPA work on 2026-09-09..10 rather than a preference: bind9-dnsutils (~6.1 MB measured) -- dig/host/nslookup were ALL absent, so the container could resolve names but had no way to interrogate a SPECIFIC nameserver. `getent hosts` only follows the resolver's default path, so diagnosing "gateway 172.16.88.1 NXDOMAINs the egl.lan zone while 10.20.253.1 is authoritative for it" had to be hand-rolled in python3. Split-horizon DNS is a recurring class of bug on this fleet. Note the package name: plain `dnsutils` is transitional in trixie. ldap-utils (1244 KB, pulls nothing extra) -- the fleet authenticates against FreeIPA, yet every LDAP probe had to be run by SSHing to an already-enrolled host. Simple binds only; GSSAPI would additionally need krb5-user + libsasl2-modules-gssapi-mit, deliberately not added as that is a Kerberos-client decision, not a tool. xxd (198 KB) -- convenience for verifying git-crypt blob magic in myconfigs; `od -c` from coreutils already does the same job. netcat-openbsd was in the original proposal and is deliberately NOT here: measured redundant, because socat is already baked and bash's /dev/tcp does reachability checks with zero packages (verified against gitea.egl.lan:3000). Recorded in the Dockerfile so the omission reads as a decision rather than an oversight. 2. ROOTFS FLOOR REFRESH: rootfs/.../pi-extensions/SKILL.md was 34284 B, unchanged since fa04d20 (2026-07-30), while the canonical package copy is 38973 B. Dockerfile.variant copies the fresh package copy over the SERVED path at build time but never writes back to this floor, so the floor is a silent fallback: if that build-time copy is ever absent it ships the July skill with no log line or manifest flag to say which version deployed. Refreshed from pi-extensions@c64c122, verified byte-identical to both the canonical and the runtime-served copies. Why one commit: the base_tag hash folds in `cat Dockerfile.base` AND `find rootfs -type f | xargs cat` (.gitea/workflows/docker-publish.yml), so either change alone forces the same full base rebuild -- and that rebuild is precisely what re-bakes rootfs/ as it then stands. Emulating the workflow hash with a fixed toolkit ref: f3d6462c7416 -> fc4edda03c54. Verified: scripts/check-base-hash.sh passes (no new ARG *_REF added), and no shell scripts are touched so the lint-shell gate is unaffected. Sizes and dependency fan-out measured via apt-get --no-install-recommends --dry-run on Debian 13 trixie.	2026-09-10 18:56:11 +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	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	30094782df	shell: source cli_utils' functions, and install the iproute2 that one of them needs ... v1.8.11 linked cli_utils' bin/ COMMANDS onto PATH and stopped there. Nothing ever sourced cli_utils.sh, so its 14 FUNCTIONS were missing from every interactive shell whose $HOME has no zsh rc -- which is the normal case, not an edge case: the container's interactive shell is bash and zsh is not installed in the image. A symlink cannot carry a shell function and a function cannot be reached from a non-interactive shell, so the two mechanisms are disjoint and both are required. The image was already paying this layer's dependency cost (fzf, bat, fd, rg, jq are baked partly FOR these functions) while delivering none of its benefit. The two changes ship together because they are coupled: portcheck is one of the 14, and it was a hard stub in every image up to v1.8.11 -- neither ss nor ip nor lsof nor netstat was present, so it printed "portcheck requires at least one of: ss, lsof, netstat" and exited. Wiring the functions in without iproute2 would have shipped a visibly broken one. MEASURED, not assumed: - the loader is bash-safe despite the *.zsh filenames: `bash --noprofile --norc` exits 0, defines all 14, and they run (pathls, mkcd, up, extract, agents-sync, fhist verified). The tree's one zsh-only construct (print -z in fzf/fhist.zsh) is already guarded by [[ -n $ZSH_VERSION ]] with a bash fallback. - fresh-$HOME seeding resolves 14/14; CLI_UTILS_SOURCE=0 is honoured; an absent checkout is a genuinely silent no-op (no output, no leaked _cu). - interactive shell startup 12 ms -> 17 ms. - iproute2 is ~5.5 MB (4.2 MB itself + 6 libs under --no-install-recommends; libpam-cap is a Recommends and correctly dropped). ss lands at /usr/bin/ss, ip at /usr/sbin/ip, both already on the developer PATH, and `portcheck --all` then correctly identifies the socat listener on 8765. - hadolint clean on both Dockerfiles; repo-wide shellcheck -S error and bash -n clean. .bash_aliases is outside CI's discovery (no shebang, not *.sh), so it was checked by hand with -s bash at error AND warning level. Named explicitly per this repo's floating-ref rule: /workspace/cli_utils is a HOST BIND MOUNT, not a pinned ref, so the image now executes unpinned content in every interactive shell. Errors are left visible rather than sent to /dev/null so that a future zsh-only file in that repo is diagnosable rather than mysterious, and CLI_UTILS_SOURCE=0 is the documented escape hatch. It is deliberately independent of CLI_UTILS_LINK=0: the two disable independent mechanisms. Deployment: needs a rebuild AND a recreate. $HOME is the container's writable layer rather than a named volume (verified -- ~/.bash_aliases carries the container start mtime while ~/.bashrc carries the image's), so the skel file is re-seeded on every recreate; a host-bind-mounted ~/.bash_aliases is still never overwritten.	2026-08-30 11:48:03 +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	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	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
pi	572430237f	Bump mempalace pin 3.5.0 → 3.6.0 (lockstep with opencode-devbox v2.9.0) ... 3.6.0 (2026-07-17, PyPI latest) is additive/reliability only: secure `mempalace serve` remote mode, optional Milvus backend, atomic KG supersede(), conversation chronology, mining exclusions, plus recovery and locking fixes. Reviewed for MCP tool-schema changes before bumping — that being the exact regression class this pin exists to catch, after an unpinned install once swept in the broken 3.3.x/3.4.0 diary_write schema. There are none, and nothing touches diary_write, so the perl workaround removed in v1.2.2 stays removed. Two fixes matter for how this image uses mempalace: read-only mode now covers checkpoint + delete_by_source in _MUTATING_TOOLS (#1930), and agent attribution is preserved in mempalace_checkpoint (#2023/#2034) — the latter because the diary protocol relies on per-agent attribution. Also adds a CHANGELOG Unreleased block that backfills the per-variant image description labels (1fd524e), pushed after the v1.6.4 tag without an entry. Not tagged: more changes are queued for the next release. Pushing to main triggers only lint.yml (actionlint + hadolint) — the image build/publish workflow is tag-only. Verified clean against the CI-pinned hadolint 2.14.0.	2026-08-04 16:01:39 +02:00
joakimp	fb35c549b5	fix(base): locate agent-browser's chrome arch-agnostically ... v1.6.0's first build failed on amd64: playwright@latest fetches Chrome for Testing, which extracts to chromium-<rev>/chrome-linux64/ on amd64 (vs chrome-linux/ on arm64). The hardcoded chrome-linux/ glob matched only arm64, so amd64 built no /usr/local/bin/agent-chrome symlink and 'test -x' failed (agent-browser --version had already printed 0.32.1 — the tell). Replace the glob with an arch-agnostic 'find -name chrome -path */chromium-*/*' (skips the chrome-headless-shell binary and the chromium_headless_shell dir), guarded by [ -n ] + the existing test -x. Verified locally: resolves the CfT chrome and agent-browser drives it headless. hadolint clean.	2026-07-17 17:55:21 +02:00
joakimp	89a8dc7fab	perf(base): trim agent-browser footprint ~960MB→~625MB before release ... Size concern ahead of the v1.6.0 base rebuild. agent-browser drives the full chrome (verified headless: open/title/eval with the headless_shell removed), so Playwright's chromium_headless_shell-* build is dead weight — drop it (~334MB), and clean apt/npm caches in-layer. Net browser footprint ~625MB/arch. CI disk is otherwise fine: build-base's 'Reclaim runner disk' step frees ~20-30GB (hostedtoolcache/dotnet/android/jvm) + docker prune before buildx. hadolint clean.	2026-07-17 17:19:20 +02:00
joakimp	8caafc3f49	base: bake agent-browser + Playwright Chromium (headless browsing, all variants) ... Gives the agent a real browser it can drive so front-end work involving live DOM/WebGL can be VERIFIED, not guessed. The agent-browser skill (from the skillset repo) was a no-op without the binary; it now works out of the box. - agent-browser CLI (standalone Rust, ships no browser) via npm, prefixed NPM_CONFIG_PREFIX=/usr so it survives the ~/.pi/npm-global volume. - Chromium fetched with 'playwright install --with-deps chromium' into PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/ms-playwright — a system path that the /home/developer volume can't shadow (unlike agent-browser's own ~/.agent-browser/browsers default, which WOULD vanish on recreate). - Stable /usr/local/bin/agent-chrome symlink, exported as AGENT_BROWSER_EXECUTABLE_PATH, insulates the ENV from Playwright's per-version chromium-<rev> dir name. Verified end-to-end (this session): agent-browser drives the baked Chromium headless (open + title + screenshot + eval into a WebGL SPA); doctor launch test passes in ~0.5s. Debian trixie --with-deps resolution verified (exit 0; t64 lib renames handled). hadolint clean; check-base-hash OK (only *_VERSION args added). Cost ~960 MB (Chromium + headless shell). Base-affecting → rebuilds base-<hash> on next release.	2026-07-17 16:12:47 +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	3d46c6615e	fix(base): default pandoc typst template font so PDF export works without -V mainfont ... pandoc's bundled typst template defaults the document font to an empty tuple (font: ()), so a naked `pandoc --pdf-engine=typst` fails with "font fallback list must not be empty". Patch the template default to Libertinus Serif (typst's own bundled default) at build time so PDF export works out of the box. Document usage in README and note the fix in CHANGELOG (Unreleased). Base-affecting.	2026-07-11 20:55:50 +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	cc53877328	feat: bake global gitignore (core.excludesFile) into image ... Seed ~/.gitignore_global from /etc/skel-devbox (seed-if-absent, like .bash_aliases/.inputrc, so user edits survive recreate) and wire it via git config --global core.excludesFile, guarded so a user-set excludesFile is never overridden. Ignores *.bak, *.bak.*, *~, *.orig, *.swp, *.tmp across all repos without per-repo .gitignore entries.	2026-06-28 11:52:02 +02:00
pi	bff810c1eb	docs(dockerfile): sync mempalace stall-protection comment with self-heal ... mempalace.ts now self-heals (respawn with capped backoff) instead of latching unavailable, and the init-timeout default is 300000. Update the explanatory comment + tunable list (MEMPALACE_MCP_MAX_RESPAWNS, MEMPALACE_MCP_RESPAWN_BACKOFF_MS). Comment-only; no build/ENV change.	2026-06-26 00:22:43 +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
pi	d175b31207	release: v1.2.2 — pi 0.80.2 + mempalace 3.5.0, drop anyOf workaround ... - Bump mempalace pin 3.4.0 -> 3.5.0: 3.5.0 carries the upstream fix for the top-level-anyOf diary_write schema (issue #1728 / PR #1717, merged 2026-06-14). Verified against the published 3.5.0 wheel that mcp_server.py now advertises 'required: [agent_name]' with no root-level anyOf. - Remove the Dockerfile.base perl workaround that stripped the anyOf from the installed mcp_server.py — obsolete now the fix is upstream. - pi auto-resolves to npm latest (0.79.10 -> 0.80.2) at build. - CHANGELOG v1.2.2.	2026-06-25 07:56:55 +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
Joakim Persson	a0abacaafb	fix(ssh): survive read-only ~/.ssh ControlPath; render sidecar on all host OSes ... Coordinated with the pi-extensions ssh-controlmaster fix (picked up at build via PI_EXTENSIONS_REF=main), this makes `pi --ssh <host>` and `dssh`/`dscp` robust to a user ~/.ssh/config whose per-host ControlPath points under the read-only ~/.ssh bind-mount (e.g. `ControlPath ~/.ssh/cm/%r@%h:%p`). A system default can never override a user's per-host value, so the fix lives in two layers. - setup-lan-access.sh: always render the writable ~/.ssh-local/config sidecar (Host * ControlPath redirect into ~/.ssh-local/cm + Include ~/.ssh/config) on EVERY host OS. Previously the script exited early (no-op) on native Linux, leaving dssh/dscp broken when ~/.ssh was read-only there too. The host-jump block, its key generation, and the authorize hints stay gated on VM-backed detection / DEVBOX_LAN_ACCESS=jump (new NEED_JUMP flag). - Dockerfile.base: document that the /etc/ssh drop-in default cannot override a user per-host ControlPath; cross-ref the two handling layers. - entrypoint-user.sh: correct the now-stale "no-op on native Linux" comment. - README.md / DOCKER_HUB.md: document read-only-~/.ssh ControlPath handling. CHANGELOG: v1.1.5 (Fixed + Changed + pi 0.79.6 -> 0.79.7 auto-resolved bump).	2026-06-18 21:59:18 +02:00
pi	3eec9bc23c	docs: correct mempalace anyOf workaround watch-target (PR #1735 is dead) ... Parity with opencode-devbox: PR #1735 (the diary_write root-anyOf fix) was closed UNMERGED on 2026-06-11, so the old "remove once PR #1735 ships" TODO pointed at a dead PR. Issue #1728 is still open; PR #1717 is the current live candidate; mempalace PyPI latest is still 3.4.0 (== our pin), so the workaround stays. - Dockerfile.base: rewrite the upstream-tracking comment + TODO (#1735 dead, watch #1717, removal trigger = a PyPI release > 3.4.0 stripping root anyOf). - CHANGELOG: Unreleased Docs entry. Docs-only; no behavior change.	2026-06-14 15:52:34 +02:00
pi	4744f05232	ci: CI-resolve mempalace-toolkit to a pinned SHA ... mempalace-toolkit is the only companion cloned in Dockerfile.base (all others live in Dockerfile.variant), so it bypassed the resolve-versions -> build-arg plumbing and its ref stayed a literal `main`. Because the base only rebuilds on a content hash of Dockerfile.base + rootfs/* + entrypoints, a toolkit-only fix would silently fail to land unless Dockerfile.base itself changed (as it incidentally did in v1.1.1). Changes: - resolve-versions: new mempalace_toolkit_ref output (gitea commits API, mirrors pi-toolkit resolution; jq '.[0].sha // "main"' fallback). - base-decide: needs resolve-versions; fold the resolved SHA into the base-tag hash so a moved toolkit forces a base rebuild automatically. - build-base: needs resolve-versions; pass --build-arg MEMPALACE_TOOLKIT_REF. - Dockerfile.base: switch clone from `git clone --branch` to a SHA-capable `git fetch <ref> + checkout FETCH_HEAD` (the --branch <SHA> footgun already fixed in Dockerfile.variant, run 374). base_tag now reflects a live gitea lookup; on API blip it falls back to `main`, triggering one extra rebuild, never a missed one. No new tag — lands on the next v* release or workflow_dispatch.	2026-06-14 15:11:22 +02:00
pi	05e88c5c75	fix: mempalace-mcp uninterruptible hang resolved via toolkit ext timeout ... The per-request timeout + stall-kill landed in mempalace-toolkit's mempalace.ts pi extension (commit a3b8829), which the base clones at build via MEMPALACE_TOOLKIT_REF=main. A base rebuild picks it up. - CHANGELOG: move from 'Known issues' to 'Fixed'; document the env knobs (MEMPALACE_MCP_TIMEOUT_MS / MEMPALACE_MCP_INIT_TIMEOUT_MS) and why the standalone stdio-watchdog shim was dropped. - Dockerfile.base: replace the TODO with a note pointing at the fix.	2026-06-13 23:49:36 +02:00
pi	7f67c36a1c	docs: capture mempalace-mcp uninterruptible-hang diagnosis (2026-06-13) ... Symptom: pi TUI blocks on a mempalace tool call, ESC does not abort. Initial WAL-contention hypothesis ruled out (no other writer running). Likely cause: virtiofs cold open of chroma.sqlite3 stalls the JSON-RPC initialize handshake; pi has no per-call MCP timeout. Recovery today: docker exec <ctr> pkill -9 -f mempalace-mcp, restart pi. Planned fix (deferred until after opencode-devbox pi removal): stdio watchdog shim with per-REQUEST timeout. A naive process-lifetime timeout wrapper is wrong because mempalace-mcp is long-lived. Sharing the palace across harnesses remains the goal.	2026-06-13 16:18:45 +02:00
pi	ab5ff8ec56	feat: bundle dot-watch helper for live graphviz .dot -> PNG re-render in Studio ... pi-studio renders Mermaid natively but has no DOT renderer. Its markdown preview displays local PNG/JPG/GIF/WEBP images, so dot-watch closes the loop for Graphviz: edit .dot -> auto-render <name>.png -> Studio refresh-from-disk shows the update. Uses mtime polling (no inotify dep). - rootfs/usr/local/bin/dot-watch: the helper (executable) - Dockerfile.base: COPY + chmod, following the studio-expose pattern - README.md: 'Graphviz diagrams in Studio' subsection - CHANGELOG.md: Unreleased entry graphviz was already in the base image; no new package.	2026-06-11 16:25:27 +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	cf5c60a342	fix(base): work around mempalace diary_write top-level anyOf ... Anthropic's tools API rejects top-level anyOf/oneOf/allOf in input_schema. Mempalace 3.3.x/3.4.0 advertise diary_write with `anyOf: [{required:[entry]}, {required:[content]}]`, breaking pi on first prompt with: tools.<n>.custom.input_schema: input_schema does not support oneOf, allOf, or anyOf at the top level Patch the installed mcp_server.py after `uv tool install` to drop the anyOf block and require ["agent_name", "entry"] instead. The handler still accepts `content` server-side as a kwarg alias, so callers using either name keep working. The workaround is idempotent and self-deactivating: once upstream ships the fix the regex no longer matches and the RUN is a silent no-op. Also pin mempalace to 3.4.0 via a new MEMPALACE_VERSION build arg so future bumps are a deliberate, reviewable diff rather than an implicit pull of latest (an implicit upgrade is what swept the broken schema in unannounced). Refs MemPalace/mempalace#1728, MemPalace/mempalace#1735	2026-06-10 16:25:26 +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