29 Commits

Author	SHA1	Message	Date
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	cb6d9e5dd0	check-doc-drift: check 9 — what the next build bakes differently must be named in the CHANGELOG ... The two most recent Unreleased entries (pi-extensions 25c1265: task tool + fork-gate; mempalace-toolkit 817b3a8: the mine deadline that never reached the transport) reached this image through floating *_REF=main ARGs. Neither produced a diff here, so nothing asked for a CHANGELOG line, and neither had one until a reader asked. Same class as check 8 — a claim with no in-repo anchor rots — and the hand practice that covered it (the per-release "Dependency audit" table, Baked-in vs Upstream-now) is a someone-remembers mechanism that had lapsed. Method, no docker/crane/token: last published vX.Y.Z from Hub's tag list (one request, now shared with check 8); its amd64 config blob via the anonymous registry API carries one se.jordbo.pi-devbox.<name>-ref label per component with the SHA the build-args baked. "Would bake" is resolved the way resolve-versions does it: 40-hex ARG is itself, branch/tag via git ls-remote with the peeled ^{} form preferred, pi-studio = highest semver tag (label on <tag>-studio), PI_VERSION as a literal against the pi-version label. Nine components, ~7.5 s. Unchanged: OK. Moved: the new value's 7-char prefix (tag for studio, version for pi) must appear above the last published version's "## " heading — Unreleased plus any not-yet-published section, which is what the release commit turns Unreleased into, so the tag build passes on the same text. A published tag with no heading is a failure, not a skip. First run found a move nobody had recorded: pi-observational-memory 7b397f4 -> cba0334 (6 commits, 3.1.1 -> 3.1.3; memory workers now routed by the model's exact provider instead of the first registered provider with a matching api — upstream #70). Named in the CHANGELOG with the honest scope: no expected effect on the shipped bedrock-only configuration, unmeasured. Sabotage-tested, expectation written before each run: obsmem SHA removed from CHANGELOG ............ rc=1 DRIFT Unreleased renamed to "## v1.9.3 — …" ........ rc=0 (release-commit shape) "## v1.9.2" heading mangled to v1.9.2-typo .... rc=1 — this one FAILED first: \b accepted "v1.9.2-typo" as v1.9.2's heading; now (\s|$) bare "## v1.9.2" (no date) ................... rc=0 ARG PI_OBSMEM_REPO renamed ................... rc=2 (blind gate must not pass; read_arg calls are bare top-level assignments on purpose — nested in a heredoc's $(...) the exit 2 is swallowed by cat) offline (proxy to a closed port) ............. rc=0, 2 SKIPs counted SKIP_REF_CHECK=1 ............................. rc=0, 1 SKIP counted restored ..................................... rc=0, files byte-identical GIT_TERMINAL_PROMPT=0 on ls-remote: a repo flipped private fails in 0.3 s as a SKIP instead of waiting for a username until the job times out. Header, lint.yml job comment and AGENTS.md all still said this gate "needs no network" — false since check 8 (2026-09-14). Now: two classes, hermetic 1-7 and published-state 8-9 that SKIP loudly and counted when offline. Considered and not added: compose <-> .env.example variable cross-check (the four mismatches are commented-out lines, the mempalace-server compose file's own variables, and entrypoint-consumed ones — it would fire on nothing wrong); "documented tag exists on Hub" (check 8 already SKIPs by name; a hard fail would misreport the tag-to-publish window).	2026-09-19 17:15:12 +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	3a44e81cad	feat(ci): gate documentation drift, and make docs a pre-tag release step ... Five doc claims had rotted by v1.9.0, all the same shape: a value written once by hand, in a file nothing verifies, about a number that lives elsewhere and moved. README pin table wrong on all three rows; a "Planned" section describing something already shipped; DOCKER_HUB.md claiming Node v22 against Node 24. DOCKER_HUB.md is why this is a gate and not a resolution to be careful: it is PUBLISHED (update-description POSTs it as Docker Hub full_description on every tag), it had gone eight releases untouched, nothing generates it, and it is read from the TAG -- so the stale page shipped with v1.9.0 regardless. scripts/check-doc-drift.sh: seven checks, all repo-local (no network, token, image, or sibling clone). Exit 0/1/2 matching lint-shell.sh; a renamed ARG is a red 2, not a green tick. Wired as a fourth lint.yml job so "the docs lie" is its own red name. Verified with 15 controls, including two false-positive controls: the first placeholder check flagged README.md:900, a Go template in a legitimate `docker inspect --format` example. The gate was wrong, not the doc, so the pattern is now anchored to the UPPER_SNAKE convention CI substitutes. Not gated, deliberately: counts/sizes needing a running image (they belong in smoke-test.sh -- a guessing gate is worse than none), and Dockerfile.base BASE_REBUILD_DATE, because base_tag hashes that file content-wise and demanding it be current would force a ~60 min rebuild on releases that touch no base files. Free during a rebuild, expensive otherwise. AGENTS.md step 3 rewritten around the mechanism: checkout@v4 with no ref: means every job reads github.ref, the tag. Docs must be right BEFORE tagging.	2026-09-10 22:01:49 +02:00
joakimp	aac4a1c323	release: v1.8.9 — the version flag that blamed the wrong component ... Two versions, two flags. `--expected-version` has only ever asserted `pi --version`, but AGENTS.md step 4 spelled it `X.Y.Z` inside a checklist where every other X.Y.Z is the pi-devbox tag. Run as documented for v1.8.8 the final runtime gate of the release printed ✗ pi version mismatch: expected 1.8.8, got 0.84.3 and exited 1 — a red accusing the image of being the wrong version. Not one reader's slip: the v1.8.8 release-readiness handoff from pi@emb-7kj4vr4g propagated the same wrong spelling twice while correctly calling step 4 "not ceremonial", so two independent readers converged on it. README.md had it right all along, which means the two documents disagreed. - new --expected-image-version asserts the pi-devbox release tag, read from release_tag in /etc/pi-devbox/build-manifest.json (no checkout, no network); leading `v` optional on either side - both flags detect being handed the other one's value, and the test is exact rather than heuristic: the value is compared against the other quantity the image itself reports, so it can only fire on a real mix-up - neither flag is required now. With none, live `pi --version` is asserted against the manifest's pi_version — not a tautology, since a stale pi in the ~/.pi/npm-global volume can shadow the baked one, exactly as a stale npm:pi-atelier can in packages[] - the header note replaced was stale and load-bearing: it claimed pi is resolved from 'latest' and cannot be self-derived, while Dockerfile.variant pins ARG PI_VERSION=0.84.3 and docker-publish.yml reads that ARG as its source of truth. The same withdrawn claim also sat in cli_utils' pi-devbox-sanity --help - argument parsing: a missing value, or a value that is another flag, is a usage error instead of silently consuming the next argument; --help works All fourteen flag combinations exercised by execution, including the two manifest-absent branches and the shadowing branch a healthy container cannot reach — mutation-tested with a doctored manifest so each failure branch was observed firing rather than assumed present. CHANGELOG also names what no commit here causes: mempalace-toolkit main moved e70bef2 -> 5b8d78f, so this tag ships the auto-delivered logstream mailbox because base_tag folds the resolved toolkit SHA. It would have landed either way; going unnamed is the 553d865 shape that already caused one cross-host misattribution. Component audit found nothing else to bump — pi, mempalace, pi-atelier all equal their upstream latest, and every other floating ref resolves to the commit already baked.	2026-08-26 18:47:03 +02:00
joakimp	e8ddeaf89f	skills: a gate that could pass without checking, and a mailbox that never empties ... Fixes the three blockers and seven should-fixes from pi@emb-7kj4vr4g's review (logstream correlation skills-provenance-review, full text in drawer_pi-devbox_reviews_e43e766641c9ec85217bc6ce). Every finding was reproduced by execution here before being fixed; two were refined by that reproduction rather than taken as given. BLOCKER 1 — the provenance gate could print OK and exit 0 without verifying. `git show <ref>:<path> | sha256sum` hashes EMPTY STDIN when the ref does not resolve, so at_ref was never empty and the UNKNOWN branch was dead code. Measured: a bogus ref reported MISMATCH — accusing the snapshot of lying when the real cause was an incomplete clone, and the operator's natural remedy for MISMATCH is to re-run the refresh, which rewrites provenance to silence the complaint; and with a 0-byte snapshot against a 0-byte upstream file it printed "OK: exactly skillset@aaaaaaa" with exit 0 for a ref that does not exist. The script already had the sha_empty idiom and had applied it to blob_sha but not to at_ref. Existence is now PROVEN with git cat-file -e before anything is hashed, at two levels (ref resolves / path exists at it) because those deserve different messages. Same defect class as the canary it replaces: a check that can succeed without checking. A second, unflagged instance of the same pipeline shape in blob_sha was found and fixed too. Exit codes split, because the old contract failed the sanctioned case: 0 truthful (including stale, with a NOTICE), 1 a lying record only, 2 cannot determine. AGENTS.md step 2 promised "the message distinguishes the two" and was the thing this branch was breaking; rewritten to state all three. BLOCKER 3 — VENDORED.md contradicted itself in the release whose stated invariant is non-contradiction: its hand-maintained provenance line named skillset 670f7f1, seven commits behind the ARG and itself the commit that told agents to hand-stamp added_by — the withdrawn instruction this work exists to stop shipping — while its cp recipe contradicted the "not cp" rule 20 lines above. Line removed (nothing forced it to move when the ARGs did); 670f7f1 kept only as a labelled cautionary example. The pi-extensions half was verified redundant (CI require_sha resolves PI_EXTENSIONS_REF) before removal. SHOULD-FIXES: `<root> --check`, the spelling VENDORED.md documented, silently ran a REFRESH because only $1 was parsed (both tools now parse all args and reject unknown ones); refresh at a detached/older HEAD silently rewound ref and bytes (now refused unless the recorded ref is an ancestor, --force to override); upstream_dirty was computed and never used in check mode; --no-skills --json printed human text and broke jq; --help was a hardcoded sed range this branch had already made stale; the fingerprint hashed SKILL.md alone so a live skill differing only in a sibling file reported "identical", and pi-extensions already ships two files, so it is now a per-skill TREE hash with the manifest field renamed skillset_snapshot_tree_sha256; the --no-skills smoke assertion was negative-only and passed on a crashed binary. mktemp+mv left files 0600 — CI was unaffected since the index records 100644, so the blast radius was local builds only, narrower than the review inferred. Snapshot resynced c04cd15 -> 5fd0d5c so the no-clone fallback carries the CORRECTED coordination protocol rather than the withdrawn one; --check is now OK with no staleness notice, and the bidirectional canary re-verified against the new bytes. Local validation is bash -n only (shellcheck, hadolint and actionlint are all absent in this container) — CI remains the shellcheck gate.	2026-08-26 14:38:07 +02:00
joakimp	49a6534093	docs: write down the coordination channel the fleet already runs on ... The logstream has carried cross-machine work since 2026-08-18 — patch handoff, review, a v1->v2 supersede — and nothing in this repo said it existed. That gap had a measurable cost this morning: another host addressed a retraction to pi@tor-ms22 by name and it was read only because the human said "read the logstream", while the agent was actively rebuilding the thing it warned about. Split by what each document is authoritative for, so there is one copy of each claim rather than three that drift: - README § Cross-machine agent coordination — what the CONTAINER needs. MEMPALACE_REMOTE_URL selects the shared palace; MEMPALACE_PI_DEVICE is what makes this machine reachable, because where every host is a thin client of one palace the stamped agent name is the only thing that distinguishes them. Stated as a rule with teeth: set both or neither, since a container missing the device var can read the log but is addressable by nobody. - AGENTS.md release checklist step 2 — the vendored-snapshot refresh, as a MECHANISM in the document a releasing agent actually reads, not a comment hoping to be noticed. It says the refresh costs a base rebuild, that skipping it is legitimate (every enrolled host reads its live clone), and that skipping it silently is not. - CHANGELOG — the three-way split itself, plus the measurement that shaped the ack contract: unfiltered, the mailbox returned 5 events, 4 of them finished broadcasts from eight days earlier; with status="open", exactly the 1 that needed an answer. Norms live in the skillset skill (82a8d3c, already live on every host that mounts the skillset — no rebuild) and mechanism in mempalace-toolkit's extensions/pi/README.md (e70bef2, which also documents the edge stamper that 553d8657 shipped undocumented). Deliberately NOT duplicated here. Consequence recorded rather than hidden: the skill edit lands in the skillset, so this repo's SKILLSET_SNAPSHOT_REF now honestly reports itself behind, and --check exits 1 with "has moved to 82a8d3c; the snapshot describes the older c04cd15". That message is also fixed in this commit — it previously blamed "the working tree" even when the tree was clean and only the ref had moved, which is the same defect class as a canary pinned to a phrase the release deleted: a message that names the wrong cause. Now distinguishes moved-HEAD from dirty-tree, verified against both plus the in-sync case.	2026-08-26 12:51:26 +02:00
Joakim Persson	fbc1f86612	docs: a negative result is usually your own filter (skill + AGENTS.md) ... Three false negatives in one session, all self-inflicted, all convincing because the command "succeeded": a `| head -20` proved an SSH peer absent that sits at line 454 of a ~500-line config; `ssh mac 'docker ps'` proved the host had no Docker, when the non-interactive PATH simply lacks /usr/local/bin; and `grep 'ssh '` proved no ControlMaster was running, when those processes rename themselves to `ssh: <path> [mux]`. Same root cause each time, so it goes in the skill rather than in a commit message: a positive result carries its own evidence, absence has to be earned. The skill (rootfs/, symlinked into ~/.agents/skills) is BAKED, so this is an image change and is logged in CHANGELOG Unreleased accordingly. Its §3 also now records that a live ControlMaster socket makes later commands authenticate not at all -- after editing a peer's authorized_keys, "it still works" proves nothing; prove it with -o ControlPath=none, or the breakage waits for a future session that has no memory of the edit. AGENTS.md: corrected a stale CI claim while placing the pointer. It said a tag push produces two runs including lint; lint.yml has since been scoped to branches: ['**'], which excludes tag refs, and refs/tags/v1.8.4 duly produced run 571 (publish) and nothing else. Kept the head_sha + workflow path filter advice, which is cheap and guards against a future v*-triggered workflow. Added a short section on verifying this repo from inside a container, including that docker-compose.yml here is a TEMPLATE pinning :latest while a real host runs its own per-machine file -- recreating from the repo copy can silently move a host off :latest-studio. Placement note: AGENTS.md is only auto-read when the cwd is this repo, so the durable rule lives in the skill, which loads by description match in any pi-devbox session.	2026-08-22 22:56:41 +02:00
pi	66a19aa394	docs(agents): how to find the release run (tag push fires two workflows) ... The release-day checklist said "Watch CI" without saying which run, and the Gitea API example used limit=5. Both are traps, because a tag push produces TWO runs here: lint.yml has a bare `push:` trigger so it fires on the tag ref as well, and docker-publish.yml fires on v*. The runs listing is newest-first and the lint run sorts ABOVE the publish run, so "first run matching refs/tags/<tag>" picks lint reliably. Verified against the real API for v1.6.4: id=531 #104 lint.yml@refs/tags/v1.6.4 <- picked by the naive rule id=530 #103 docker-publish.yml@refs/tags/v1.6.4 <- the actual release build id=529 #102 lint.yml@refs/heads/main <- same sha, already linted Lint goes green in minutes while the image is still building, so watching it makes a release look finished before anything is published. limit=5 compounds it: the publish run is already at position 4 of 5 in the current listing. Documents: head_sha-filtered discovery with limit=20; the jobs endpoint takes the internal id, never the run_number (silently returns another run's jobs); and the correct ci-release-watcher config for this repo — EXPECT_WORKFLOW, the studio tag pair, base-latest as existence-only, and CRITICAL_JOBS with build-variant-studio spelled out (job names are matched exactly, and the skill's default omits it) while excluding promote-base-latest, which legitimately skips on a base cache hit. Smoke-gate detail in step 5 is retained.	2026-08-04 18:06:34 +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	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	f19c35da32	docs: note lightweight PDF engine (typst) as preferred over full texlive ... PDF export from Studio/pandoc still isn't shipped. Record the engine decision in the living docs (README + AGENTS): pandoc is in the image but has no PDF back-end, so export fails with 'xelatex not found'. Prefer a lightweight engine — typst (~30 MB static binary, 'pandoc --pdf-engine=typst') which is small enough it could ship in base rather than needing a separate ':latest-studio-tex' variant; texlive-xetex (~600 MB) kept as the higher-fidelity fallback. Also drop stale 'v1.3.0' pins (v1.3.0 already shipped without PDF) in favour of 'a future release'. CHANGELOG history left untouched.	2026-07-09 16:25:54 +02:00
Joakim Persson	a7d6a7d235	feat(skills): bake pi-extensions + mempalace fallback skills ... The pi-toolkit global AGENTS.md tells every pi session to read ~/.agents/skills/pi-extensions/SKILL.md at start (the fork/recall under-utilisation fix), but that skill lived only in the private skillset repo — so the pointer dangled in any container started without skillset mounted. Bake fallbacks so the pointer always resolves. - pi-extensions (Option 1 + Option 2, layered): * Canonical skill promoted to the public pi-extensions package repo under skill/ (separate commit there); co-located with the code it documents. * rootfs/ carries a committed snapshot (the floor). * Dockerfile.variant copies /opt/pi-extensions/skill/ over the snapshot after the pinned clone, so a normal build ships the fresh package copy (recorded via PI_EXTENSIONS_REF) and an old-ref/mirror build still ships the snapshot. Helper evaluate-extension-usage.py travels with it. - mempalace (Option 2 only): snapshot in rootfs/. Its consumer skill has no public package home (mempalace-toolkit ships a different skill, opencode-mempalace-bridge), so no build-time refresh. - entrypoint links both (only-when-absent; mounted skillset still wins). - smoke-test: build-time presence + package-match check + runtime symlink assertions; readiness gate now waits on the last-linked skill. - docs: skills/VENDORED.md (provenance + refresh), README, AGENTS.md, CHANGELOG [Unreleased]. Note: shipped in the NEXT release; v1.2.0 (run 409) predates this.	2026-06-23 15:32:04 +02:00
Joakim Persson	2abfee141b	feat: image-baked agent skills + pi-devbox-environment skill (v1.2.0) ... Ship skills inside the image (independent of any mounted skillset repo): - rootfs/usr/local/share/pi-devbox/skills/<name>/ symlinked into ~/.agents/skills/ by entrypoint-user.sh (foreign-link, survives volume recreate, never clobbers a skillset/user skill of the same name). - New pi-devbox-environment skill: persistence model, host/LAN SSH reachability, split-DNS mechanisms, interactive-vs-tool-shell alias gotcha, tmux 0-index, uv-first Python, pi-studio reachability. Agnostic to host OS / hostnames / domains / nameservers (discovered at runtime). - Dockerfile.variant appends pi-global-AGENTS.append.md onto pi-toolkit's pi-global-AGENTS.md (single global slot) so the skill is loaded proactively; gated on /usr/local/lib/pi-devbox/. Idempotent. - smoke-test: baked-skill + append-snippet + merged-marker presence and a runtime symlink assertion. - docs: README 'Agent skills' section, AGENTS.md layout, DOCKER_HUB.md; moved studio-tex roadmap to v1.3.0. pi 0.79.7 -> 0.79.10 (auto-resolved from npm latest at build).	2026-06-23 12:49:13 +02:00
Joakim Persson	d902b2d056	v1.1.3: add actual pi 0.79.5 release notes + document GitHub releases URL in AGENTS.md	2026-06-16 23:56:52 +02:00
pi	777d53354f	docs(AGENTS): document GITEA_ACCESS_TOKEN env for general Gitea API access ... GITEA_ACCESS_TOKEN + GITEA_HOST (passed from host .env via compose, primarily for gitea-mcp) are also usable for any direct Gitea API work — run inspection, tag checks — not just ci-release-watcher. Prefer over a PAT file when present; host-managed lifecycle, nothing to revoke. Release checklist step 7 now notes the env-token alternative.	2026-06-15 22:30:36 +02:00
pi	c9534c639f	docs(AGENTS): add post-recreate sanity check to release-day checklist ... Step 3 now runs scripts/recreate-sanity-check.sh inside the running container after a local recreate — the runtime peer of the build-time smoke-test.sh gate. Verifies persisted volumes survived and pi wiring re-deployed, not just that the container booted.	2026-06-15 22:11:17 +02:00
pi	9ebb0643c7	docs: fix drift — sync compose/volumes, studio coverage, mempalace link ... Audit found README/AGENTS carried a stale compose/volume set that diverged from the shipped docker-compose.yml (DOCKER_HUB + compose + .env.example were already consistent — README was the outlier): - README compose block + 'Volumes and persistence' table: correct volume names (devbox-shell-history not -bash-history; devbox-uv at ~/.local/share/uv not devbox-uv-tools at /opt/uv-tools — the latter would SHADOW the baked mempalace install at UV_TOOL_DIR); add devbox-ssh-local + devbox-zoxide; mark devbox-palace/-chroma-cache optional; WORKSPACE_PATH/SSH_KEY_PATH (not HOST_WORKSPACE). - README quickstart: 'compose exec -u developer' (no USER in image; bare exec lands a root shell). - README: pi-studio now 'shipped' not 'planned'; build-pipeline + tag table cover -studio + smoke-studio/build-variant-studio. - AGENTS: backward-compat volume names corrected; repo-layout bullets cover pi-studio install + studio-expose + STUDIO_EXPOSE bridge. - DOCKER_HUB: MemPalace source link -> upstream MemPalace/mempalace (matches Dockerfile.base + CHANGELOG refs). Note: the shipped v1.0.0 CHANGELOG migration note still lists the old (incorrect) volume names; left as immutable released history.	2026-06-10 23:52:17 +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	03629cdac7	refactor: build FROM joakimp/pi-devbox:base-pi-only (Option B) ... The pi-only building block now lives in this repo as the internal base-pi-only tag (produced by opencode-devbox CI from Dockerfile.variant, INSTALL_OPENCODE=false) instead of opencode-devbox:latest-pi-only — so an 'opencode-devbox' tag never ships without opencode. - Dockerfile: BASE_IMAGE default joakimp/opencode-devbox:latest-pi-only -> joakimp/pi-devbox:base-pi-only. - Updated README, AGENTS, DOCKER_HUB, docker-compose, CHANGELOG. - Single source of truth unchanged (opencode-devbox/Dockerfile.variant); publish ordering + EXPECTED_PI_VERSION smoke guard unchanged.	2026-06-03 17:04:21 +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	dff3092338	AGENTS: note pi changelog source is npm-tarball CHANGELOG.md ... Companion to opencode-devbox's 'Upstream sources' section. Pi's npm package ships a rich CHANGELOG.md with New Features / Added / Changed / Fixed sections — but the npm registry metadata ('npm view') doesn't include the changelog body. Surface the 'npm pack + tar' recipe in the release-day checklist so future-pi (and human-pi) doesn't try to derive notes from npm view alone. Doc-only, no CI implications.	2026-05-23 19:26:48 +02:00
joakimp	ae6253ab23	AGENTS.md: documentation-drift sweep as explicit pre-commit step ... Companion to the same addition in the cloud-init and ansible repos. Caught real drift in those repos in a recent session only because the user explicitly asked. Codify the sweep with concrete, repo- specific drift hotspots rather than a vague 'watch for drift' rule that gets ignored. Each AGENTS.md addition lists the doc files most likely to fall behind code changes here, plus a quick-triage one-liner using 'git diff --name-only HEAD | xargs grep -l ...' so the rule is actionable not aspirational.	2026-05-20 23:11:59 +02:00
joakimp	7b634605b7	Initial commit: pi-devbox v0.74.0 ... pi coding-agent container built on opencode-devbox:base-latest. Includes Dockerfile, docker-compose, CI workflow, smoke-test, README, CHANGELOG, AGENTS.md.	2026-05-14 19:57:17 +02:00