71 Commits

Author	SHA1	Message	Date
pi	49d3e113ee	docs: complete CHANGELOG/AGENTS + promote Unreleased -> v1.15.13e ... - CHANGELOG: add the missing entry for the ~/.config/devbox-shell compose-doc commit (440218f); promote Unreleased -> v1.15.13e (2026-06-04) with a release summary (letter-suffix rebuild on opencode 1.15.13, picks up pi 0.78.1 + LAN key persistence + devbox-ssh-local chown fix + validate.yml false-neg fix). - AGENTS.md: document the STRICT_REGISTRATION smoke-gate knob under CI quirks (kept in lockstep with the validate.yml/docker-publish-split.yml change). Docs only; no image/behavior change. Tagging v1.15.13e after this lands.	2026-06-04 22:41:30 +02:00
pi	f1e879ca6c	docs: per-host ControlPath under ~/.ssh breaks pi --ssh (read-only mount) ... The bind-mounted ~/.ssh/config is read before the baked Host * default and SSH uses the first ControlPath it sees. A per-host block pointing ControlPath under ~/.ssh/ (CGNAT-multiplexing pattern) wins but fails in-container because ~/.ssh is read-only, silently breaking pi --ssh <host> (falls back to local tools). Documented the host-side fix: drop the override or repoint at the writable /tmp/sshcm/. README + CHANGELOG only, no image change.	2026-06-04 22:31:54 +02:00
pi	9c31c641d6	smoke: gate fork/recall registration checks behind STRICT_REGISTRATION (#12) ... validate.yml builds variants FROM the published base-latest, which lags the entrypoint in the current commit until a release tag rebuilds the base. The fork/recall registration smoke checks depend on the base entrypoint running 'pi install /opt/<pkg>', so a stale base-latest reded push-to-main runs with a false negative even when the variant layer was correct. smoke-test.sh now gates the two registration assertions behind STRICT_REGISTRATION (warn-only when unset). validate.yml leaves it unset; docker-publish-split.yml, which builds the base fresh in the same run, sets STRICT_REGISTRATION=1 on the pi-bearing smoke jobs. Build-time /opt + node_modules checks stay hard in both paths.	2026-06-04 21:59:39 +02:00
pi	d9dc85d825	entrypoint: chown devbox-ssh-local volume so jump key generates ... The named-volume persistence change for ~/.ssh-local did not update the entrypoint's volume-ownership loop. Docker creates named volumes as root:root, so setup-lan-access.sh (running as developer) silently failed to mkdir/ssh-keygen, leaving no jump key and breaking LAN access on the first --force-recreate. Add ~/.ssh-local to the chown list.	2026-06-04 14:59:46 +02:00
pi	0b78ab4a94	LAN jump key: persist via named volume + one-line authorize hint ... Persist ~/.ssh-local (devbox-ssh-local named volume) so the generated LAN-jump key survives 'docker compose up --force-recreate'. Authorize it on the host once per machine instead of after every container update. setup-lan-access.sh now prints a copy-paste 'echo <pubkey> >> ~/.ssh/authorized_keys' line whenever it generates a new key (not only when HOST_SSH_USER is unset), and stays silent once the key is persisted. README + CHANGELOG updated.	2026-06-04 14:33:58 +02:00
pi	a56a5846a5	LAN-access: fix Include scope + read-only ControlPath, add ssh-lan.conf & RFC1918 autojump ... - Fix: Include ~/.ssh/config was scoped to the Host host/mac block, so dssh <peer> by name fell back to SSH defaults. Emit Host * scope reset before every Include. - Fix: redirect ControlPath to writable ~/.ssh-local sidecar (Mac config's ~/.ssh/cm path is read-only in the container, broke multiplexed hosts). - Add: Include host-owned ~/.config/devbox-shell/ssh-lan.conf for named-peer ProxyJump overrides (keeps image generic; peer names stay host-side). - Add: opt-in DEVBOX_LAN_AUTOJUMP_PRIVATE=1 RFC1918 catch-all for roaming. - Docs: README/.env.example/AGENTS/CHANGELOG + new ssh-lan.conf.example.	2026-06-04 00:52:42 +02:00
pi	053dac5308	docs: promote CHANGELOG Unreleased -> v1.15.13c	2026-06-03 21:46:37 +02:00
pi	c71c03f0f1	fix: bump base smoke size threshold 2500->2600 MB ... v1.15.13b's base crept to 2506 MB (LAN-access script + updated entrypoint + apt drift), tripping the zero-headroom 2500 ceiling. smoke-base failed, which cascaded into skipping build-variant-base AND promote-base-latest, so base-latest never advanced. All functional checks passed — this is a guardrail bump, not a real regression. base-<hash> and the omos/with-pi/ omos-with-pi/pi-only variants did publish on the fresh base in run 354.	2026-06-03 21:46:15 +02:00
pi	1e98b53113	feat: publish pi-only build into the pi-devbox repo, not opencode-devbox (Option B) ... The pi-only variant was published as opencode-devbox:latest-pi-only — an 'opencode-devbox' tag containing no opencode, which confused users. - build-variant-pi-only now pushes joakimp/pi-devbox:base-pi-only[-vX.Y.Z] instead of opencode-devbox:*-pi-only. New PI_IMAGE workflow env. - Still built from the same Dockerfile.variant (single source of truth), still smoke-tested by smoke-pi-only / validate-pi-only before publish. - De-advertised pi-only from README, DOCKER_HUB (HUB_TEMPLATE), AGENTS, .gitea/README. opencode-devbox now publishes 8 tags + base-latest. - Documented in CHANGELOG (Unreleased) and the plan doc. Note: old opencode-devbox:{latest,vX.Y.Z}-pi-only tags from v1.15.13b are superseded and should be deleted from Docker Hub.	2026-06-03 17:04:21 +02:00
pi	30380abdef	Cut v1.15.13b — LAN access + fork/recall + pi-only variant ... Container-level rebuild on opencode 1.15.13 / pi 0.78.0 (both unchanged): host-OS-agnostic LAN access (base), pi-fork (fork) + pi-observational-memory (recall) in pi variants, and the new pi-only variant (basis for pi-devbox).	2026-06-03 16:40:22 +02:00
pi	fc034ceade	feat: add pi-only variant (pi without opencode) as basis for pi-devbox ... All opencode-devbox variants set INSTALL_OPENCODE=true, so pointing pi-devbox at with-pi dragged opencode along and made it ~a re-tag of latest-with-pi. Add a 5th variant pi-only (INSTALL_OPENCODE=false, INSTALL_PI=true): pi + companions (toolkit, extensions, fork, recall) + base tooling, no opencode (~145 MB lighter than with-pi). - Dockerfile.variant: document pi-only in the variant table. - CI docker-publish-split.yml: new smoke-pi-only + build-variant-pi-only jobs (tags :VERSION-pi-only / :latest-pi-only, multi-arch); wired into promote-base-latest and update-description needs. - validate.yml: new validate-pi-only main-branch gate job. - smoke-test.sh: accept --variant pi-only; threshold 2750 MB; opencode-absent path already handled. - Docs: HUB_TEMPLATE (regenerated DOCKER_HUB.md), README, AGENTS (variant/tag counts 4->5, 8->10 tags), .gitea/README, manual-host-publish.sh (5 variants), plan doc implementation note. This is the single source of truth for joakimp/pi-devbox, which now FROMs latest-pi-only. Versions unchanged (opencode 1.15.13, pi 0.78.0).	2026-06-03 16:13:44 +02:00
pi	f09a4f382a	feat: host-agnostic LAN access (base) + fork/recall in pi variants ... Item A — LAN access (base image): - New rootfs/usr/local/lib/opencode-devbox/setup-lan-access.sh, invoked non-fatally from entrypoint-user.sh. On VM-backed hosts (macOS OrbStack / Docker Desktop, detected via host.docker.internal) it generates a writable ~/.ssh-local/config that uses the host as an SSH jump to reach LAN peers; no-op on native Linux. Ships the mechanism (generic 'host' jump alias), not policy (targets stay in the user's bind-mounted ~/.ssh/config). - New env knobs: DEVBOX_LAN_ACCESS (auto|jump|off), HOST_SSH_USER, DEVBOX_HOST_ALIAS. dssh/dscp aliases in .bash_aliases (guarded). Item B — pi-fork (fork) + pi-observational-memory (recall) in pi variants: - Dockerfile.variant clones both elpapi42 repos to /opt and runs npm install there at build time (local-path 'pi install' does not npm-install, so deps must be present to load). New args PI_FORK_REPO/REF, PI_OBSMEM_REPO/REF. - entrypoint-user.sh registers them at runtime via 'pi install /opt/<pkg>' (instant, in-place, idempotent; tools bind on next pi start). - CI resolve-versions resolves each repo's master HEAD to a commit SHA and passes PI_FORK_REF/PI_OBSMEM_REF — same cache-hit guard as PI_VERSION. - smoke-test asserts /opt clones + node_modules + settings.json registration; size thresholds bumped (with-pi 2700->2900, omos-with-pi 3700->3900). Versions unchanged (opencode 1.15.13, pi 0.78.0 — both still latest). Docs: README LAN section + env table, .env.example, AGENTS.md, CHANGELOG. Plan recorded in docs/plan-lan-access-and-pi-extensions.md.	2026-06-03 15:45:45 +02:00
pi	f61b5a4977	Cut v1.15.13 — opencode 1.15.12→1.15.13 upstream, pi 0.77.0→0.78.0	2026-05-31 22:26:21 +02:00
pi	870da12c92	Cut v1.15.12 — opencode 1.15.11→1.15.12 upstream, pi 0.76.0→0.77.0 ... opencode-ai actually released 1.15.12 upstream (2026-05-28); this is the genuine first container build on it, plus the pi 0.77.0 bump (Claude Opus 4.8, --exclude-tools, headless Codex subscription login, streaming-aware extension input, plus a long fix list). Re-uses the v1.15.12 git tag, force-overwriting the historical artifact tag at be2a168 from the 2026-05-28 versioning slip (caught same day and re-cut as v1.15.11c; corresponding Hub images already manually deleted). Commit be2a168 and the v1.15.11c CHANGELOG block referencing the slip remain in history. No base-image change — unchanged Dockerfile.base/rootfs/entrypoint will hit base-decide cache-hit short-circuit; only the four variant builds + manifest tagging will run. See CHANGELOG v1.15.12 for the full upstream notes.	2026-05-29 09:06:54 +02:00
pi	cb50e6ea60	Cut v1.15.11c — re-tag of v1.15.12 to fix versioning-scheme violation ... The 2026-05-28 morning v1.15.12 release violated the project's v{opencode_version}[letter] tagging scheme: opencode-ai stayed at 1.15.11 upstream (no 1.15.12 exists on npm), so the third container build on opencode 1.15.11 should have been v1.15.11c. The commit message of the slipped tag (be2a168) itself said 'OPENCODE_VERSION stays at 1.15.11 (no upstream change)' — the slip was caught the same afternoon during a versioning audit. This release re-cuts at HEAD and supersedes v1.15.12. The slipped git tag and the eight v1.15.12* / latest* Docker Hub images remain as historical artifacts. Future builds on opencode 1.15.11 continue the letter sequence as v1.15.11d, v1.15.11e, etc; v1.15.12 will only be reused if and when opencode upstream actually releases 1.15.12. Includes everything in v1.15.12 plus the afternoon followup work: - CI: registry cache-export disabled (Hub 400 root-cause fix) - Docs: manual host-publish runbook + script archive - CI: workflow-level 3-attempt retry around buildx build --push AGENTS.md: new pre-flight check requirement under Versioning scheme documenting the slip as a cautionary example. Mandatory 'npm view opencode-ai version' check before any non-letter-suffix tag. CHANGELOG: new v1.15.11c block with full content list; v1.15.12 block gets a note documenting the supersession.	2026-05-28 16:54:23 +02:00
pi	1fe5b5df91	ci: workflow-level 3-attempt retry around buildx build --push ... Belt-and-braces against transient registry-1.docker.io blips (rate limits, brief 5xx, CDN flap). Replaces all five push docker/build-push- action@v7 invocations (1 base + 4 variants) with shell: bash steps that run docker buildx build --push in a for-loop with backoff (15s, 30s). Smoke build steps (load: true, no push) are untouched. Does NOT mask deterministic failures: a true regression (e.g. the cache-export 400 we hit 2026-05-23..28) fails all 3 attempts identically and the job still fails by design. Orthogonal layer to both cache-export disablement and the ci-release-watcher skill's transient-rerun heuristic. - AGENTS.md: new Critical conventions bullet documenting the retry pattern, the consistency rule across push steps, and why it's duplicated rather than factored (Gitea Actions doesn't support reusable composite shell steps cleanly). - CHANGELOG.md: Unreleased section addendum, no image-side change. No image-side change.	2026-05-28 16:32:41 +02:00
joakimp	51ec4a88cf	CI: drop registry cache-export from build-base (Hub 400 root cause) ... Diagnosed during manual v1.15.12 publish: buildkit's mode=max cache export to registry-1.docker.io reproducibly returns HTTP 400 with HTML body on the resumable-upload PUT. Image push (layers + manifest) works fine in parallel; only --cache-to fails. Removing cache-from/cache-to lets the publish complete. This explains all four prior CI failures (runs 332/333/334/336) which shared the exact same failure shape. Action-pin hypothesis (setup-buildx-action v4.1.0) was correctly disproven by run 336 with v4.0.0 pinned. Trade-off: every Dockerfile.base change now pays the full ~3 min multi-arch build. Unchanged bases short-circuit at the content-addressed probe step in base-decide and never re-build, so day-to-day cost is zero. Re-enable when moby/buildkit upstream resolves the cache-export protocol mismatch with Hub CDN, or when we can switch to a non-registry cache backend. CHANGELOG.md: full root-cause writeup in Unreleased section, including status update on every prior suspect (all ruled out).	2026-05-28 10:40:08 +00:00
joakimp	be2a16834c	Cut v1.15.12 — revert v4.0.0 pin (busted), bump pi to 0.76.0 ... The v1.15.11b experiment confirmed setup-buildx-action@v4.1.0 is NOT the regressor: pinning all 9 references to @v4.0.0 reproduced the exact same '400 Bad request' from registry-1.docker.io on the first layer-blob PUT. CI run #336 failed twice (original + Gitea auto-rerun), both with HTML 400 bodies (CDN-tier rejection) at Offset:0. UUIDs and _state signatures differ across attempts; only the failure pattern is stable. Reverting all 9 pins back to @v4 — keeping a wrong pin holds us off action improvements with no benefit. Real suspects now narrow to: runner-image (catthehacker:act-latest, floating), runner-2 host network egress, buildx 0.34.x signed _state token format, or per-repo Hub-side state. Investigation deferred; this release ships via manual docker buildx build --push from a developer Orbstack to bypass the broken runner-network → Hub-CDN combo (we know that path works in ~25s for the same multi-arch build to the same Hub account). PI_VERSION=latest resolves to pi-coding-agent 0.76.0 (published 2026-05-27 20:03 UTC). OPENCODE_VERSION stays at 1.15.11 (no upstream bump since 1.15.11 was published 2026-05-27 03:59 UTC). Files: - .gitea/workflows/docker-publish-split.yml: 9 setup-buildx-action references reverted from @v4.0.0 to @v4 - CHANGELOG.md: v1.15.12 entry with regression triage status (ruled-out vs still-suspect)	2026-05-28 08:11:00 +00:00
joakimp	a16da2f041	Cut v1.15.11b — pin setup-buildx-action@v4.0.0 ... The v1.15.11 publish failed three times in a row (runs #332/333/334) with identical '400 Bad request' from registry-1.docker.io on the multi-arch buildx layer-blob PUT. Triage on 2026-05-27 confirmed: - Multi-arch buildx push from a developer host: succeeds in 25s (same Hub account, same multi-arch path) - Account / repo / Hub-CDN: all healthy - Last known-good Gitea-runner Hub push: 2026-05-23 ~20:26 UTC (pi-devbox v0.75.5b) — predates docker/setup-buildx-action v4.1.0 by <24h - docker/setup-buildx-action@v4 floats to v4.1.0 (published 2026-05-22 16:00 UTC), bundling a newer buildx/buildkit whose push protocol may trip Hub's CDN URI-length cap on the ~1.4 KB _state query string in resumable-upload PUT URLs. Pinning all nine setup-buildx-action references to @v4.0.0 to test the hypothesis. setup-qemu-action@v3 left floating since QEMU wasn't in the suspected blast radius. If v4.0.0 publishes cleanly we keep the pin and file an upstream buildkit/buildx issue. No source changes — same OPENCODE_VERSION=1.15.11, same Dockerfile.base and Dockerfile.variant. v1.15.11 (original tag) is preserved as a historical marker of the first publish attempt; v1.15.11b becomes the canonical release.	2026-05-27 21:05:17 +00:00
joakimp	608304c3de	Bump opencode 1.15.10 -> 1.15.11 + cut v1.15.11 ... First release on opencode 1.15.11. Also ships the four devbox-side fixes accumulated since v1.15.10: - 668592d Base: SSH ControlMaster default on a writable socket path - 73a7f96 Base: gitleaks added; git-crypt confirmed installed - 3cbcb44 CI: fix resolve-versions to use curl+jq instead of npm view - f7c3409 CI: preventative fix for PI_VERSION/OMOS_VERSION cache-hit regression Downstream pi-devbox inherits all of these on its next build against base-latest. Upstream release notes: https://github.com/anomalyco/opencode/releases/tag/v1.15.11	2026-05-27 15:02:24 +00:00
joakimp	668592da0d	Base: SSH ControlMaster default on a writable socket path ... Devboxes typically mount ~/.ssh from the host read-only (security: keys readable, but agents can't tamper with config / known_hosts / authorized_keys / plant a malicious ProxyCommand). OpenSSH's default ControlPath is ~/.ssh/cm/... which is unwritable on such mounts, so any attempt to multiplex fails with: unix_listener: cannot bind to path .../cm/...: Read-only file system kex_exchange_identification: Connection closed by remote host The second line is downstream — when ControlMaster fails, ssh falls back to fresh TCP connections, and on residential CGNAT (most European ISPs) the per-(src,dst) concurrent-flow cap (~4) silently drops further SYNs once exceeded, manifesting as banner-exchange timeouts that look like a remote problem. Fix: bake /etc/ssh/ssh_config.d/00-devbox-controlmaster.conf in the base image with Host * defaults — ControlPath rooted at /tmp/sshcm/ (per-container, always writable), ControlMaster auto, ControlPersist 10m, ServerAlive{Interval=30,CountMax=6}. Companion entrypoint-user.sh creates /tmp/sshcm mode 700 on each container start (/tmp is per-container so the dir can't be baked into a layer; mode 700 is required by OpenSSH for ControlPath dirs). Debian's stock ssh_config sources ssh_config.d/*.conf before its own Host * block, so user ~/.ssh/config overrides still win. Two smoke assertions catch regressions: (a) the conf file exists, (b) ssh -G reports a controlpath rooted at /tmp/sshcm/ — second one catches the silent case where something later in the config chain shadows the bake-in. Discovered while running a recon shell from inside pi-devbox to a Proxmox node — fresh ssh hit banner-exchange timeout, debug output pointed at the read-only socket dir as the actual root cause. Cascades to all variants and to pi-devbox automatically on next build against base-latest. No size/threshold impact (~250-byte conf file).	2026-05-24 19:51:38 +00:00
joakimp	73a7f96056	Base: add gitleaks; surface git-crypt in smoke + docs ... Both tools are used as part of the secret-management setup in several of the repos this devbox operates on (gitleaks pre-commit hook + git-crypt for selectively-encrypted canonical config). Having them in the container means hooks fire correctly inside instead of warning 'gitleaks not installed' on every commit. git-crypt was already installed via apt in Dockerfile.base (line 58), just unasserted by smoke and unmentioned in user-facing docs. gitleaks is new: Go-compiled binary fetched from GitHub releases via the same /releases/latest redirect-resolution pattern as gosu, fzf, git-lfs, etc. Arch suffix is 'x64' (not 'x86_64' / 'amd64') on this project — flagged in the Dockerfile comment and in AGENTS.md's floated-binaries gotcha list. Adds ~21 MB to the base layer (gitleaks 8.30.1 binary). No variant threshold bumps needed (2500–3700 MB envelope, 21 MB is noise). CHANGES Dockerfile.base — new GITLEAKS_VERSION=latest ARG + install RUN right after the git-lfs block. Multi-arch (linux/amd64=x64, linux/arm64=arm64). Echoes resolved version + runs 'gitleaks version' to fail the build on any install error. scripts/smoke-test.sh — git-crypt and gitleaks added to the 'Resolved component versions' table (printed first thing in CI logs) and to the 'Core binaries' assertion list (run helper). Smoke now fails fast if either binary regresses. README.md — 'What's in the image' tree line names gitleaks alongside the existing git-crypt. AGENTS.md — gitleaks added to the 'GitHub-sourced binaries float by default' list with a new clause flagging project-specific arch-name deviations (gitleaks=x64, bat/eza/zoxide=x86_64/aarch64, gosu= amd64/arm64). Saves the next person from the 'why does this not download' debugging session. CHANGELOG.md — sub-entry under existing Unreleased, before the PI_VERSION/OMOS_VERSION cache-hit fix entry. DOWNSTREAM IMPACT This is a base-layer change — base-decide will compute a fresh base-<hash>, build-base will run (no cache hit), all four variants will rebuild. First real base rebuild since v1.14.50b. Pi-devbox's next FROM base-latest pull picks up gitleaks automatically with no Dockerfile change there. Verified end-to-end on host: gitleaks 8.30.1 21 MB binary extracts cleanly from the URL the Dockerfile constructs and 'gitleaks version' prints '8.30.1'. Holding off on tagging — opencode + pi upstreams unchanged at 1.15.10 and 0.75.5 respectively. Will ride along with the next upstream-bump release rather than burning a base rebuild on a no-upstream-change container-only roll.	2026-05-24 15:49:38 +00:00
joakimp	f7c34091b1	CI: preventative fix for PI_VERSION/OMOS_VERSION cache-hit silent regression ... Mirrors the pi-devbox v0.75.5b fix (2026-05-23) onto the four-variant pipeline here. The with-pi, omos, and omos-with-pi variants install upstream npm packages whose *_VERSION build-args defaulted to 'latest'. When the build-arg string is byte-identical across builds, the layer hash is identical and the registry buildcache silently reuses the layer from whatever upstream version was current when the cache was first populated — same mechanism that shipped pi-devbox v0.74.0..v0.75.5 with identical image bytes. Currently masked here because OPENCODE_VERSION is a hard-coded ARG that bumps every release; parent-chain cache invalidation flushes the downstream pi/omos layers. Masking would fail on any vN.N.Nb opencode- version-unchanged release that only bumps pi or omos. Filed last night as parked followup; fixing preventatively now that #5 (AWS SSO inside tor-ms22 container) cleared. CHANGES .gitea/workflows/docker-publish-split.yml — new resolve-versions job running 'npm view @earendil-works/pi-coding-agent version' and 'npm view oh-my-opencode-slim version', exposing concrete strings as job outputs. All six affected jobs (smoke-omos, smoke-with-pi, smoke-omos-with-pi, build-variant-omos, build-variant-with-pi, build-variant-omos-with-pi) now consume them as PI_VERSION / OMOS_VERSION build-args. smoke-base / build-variant-base unaffected. scripts/smoke-test.sh — new run_expect helper asserting an expected substring in command output. The pi check uses EXPECTED_PI_VERSION; the omos check uses EXPECTED_OMOS_VERSION against npm ls -g. Both env vars are wired from resolve-versions outputs in the smoke jobs. Catches this regression class on the next release, not four releases later. Dockerfile.variant — comment blocks above OPENCODE_VERSION (source- pinned, not subject to the bug), PI_VERSION (CI-resolved), and OMOS_VERSION (CI-resolved) explaining the cache-hit footgun. AGENTS.md — new convention bullet under 'Critical conventions' naming the resolve-versions job + EXPECTED_*_VERSION wiring as the contract to keep in lockstep when modifying variant build-args. .gitea/README.md — Step 1 expanded to cover the parallel resolve- versions job alongside base-decide; pipeline diagram updated. CHANGELOG.md — Unreleased entry describing the fix, masking mechanism, and audit footprint. No image-content change expected on the next release vs what 'latest' would have resolved to anyway. Purely makes the cache invalidate correctly going forward.	2026-05-24 15:38:36 +00:00
joakimp	72d2c99885	docs: enrich v1.15.10 CHANGELOG with actual upstream release notes ... The v1.15.10 release commit (80e57d7) said upstream releases ship empty bodies — that was incorrect. I was checking sst/opencode which is a fork; the canonical upstream this devbox tracks is github.com/anomalyco/opencode (per user correction). Three of the four versions (1.15.7, 1.15.9, 1.15.10) have rich release notes; only 1.15.8 is empty. Expanded the v1.15.10 CHANGELOG entry with per-version summaries: - v1.15.7: Grok OAuth + device-code login, v2 session API safe-error responses with reference IDs, Codex OAuth refresh dedup, restored OpenAI OAuth + reasoning streams, friendly tool-schema errors, Grok PDF attachments, several TUI and desktop improvements. - v1.15.8: empty release body (assumed internal/no user-visible). - v1.15.9: redesigned diff viewer with file tree + enabled by default, MCP OAuth callbackPort and scope-in-clientMetadata, Vertex Anthropic multi-region endpoint fix, many 'show clearer error' improvements, native reasoning metadata preservation across turns, TUI worktree- copy shortcut, desktop titlebar tab navigation. - v1.15.10: single fix — restored legacy production desktop flows for opening projects and starting sessions. Doc-only commit on main. The v1.15.10 tag snapshot is unchanged because CI is mid-flight against it (5 jobs running at the time of this correction); cancelling and re-tagging would cost ~50 min of CI re-run for changelog wording with no image-content effect. The Hub description for v1.15.10 will reflect the thin tag-snapshot CHANGELOG; main has the correct content for the next release and for anyone reading current docs.	2026-05-23 19:19:19 +02:00
joakimp	80e57d732b	Bump opencode 1.15.6 -> 1.15.10 + cut v1.15.10 ... Four upstream patch releases over two days. Upstream releases ship empty bodies and no CHANGELOG; the patch sequence (1.15.7-1.15.10) is fixes only per typical sst/opencode cadence. The with-pi and omos-with-pi variants will also implicitly bump pi 0.75.4 -> 0.75.5 since PI_VERSION=latest resolves at build time. omos-with-pi smoke threshold remains 3700 MB (set v1.15.4b 2026-05-18). Four opencode patches plus one pi patch typically add only a few MB across both, not expected to trip. If it does, recovery is the well-worn letter-suffix pattern (v1.15.10b with threshold bump). Cache hit expected on base-35ee5fe7861a since neither Dockerfile.base nor rootfs/ have changed since v1.14.50b. Built on the same CI path as v1.15.6 — pinned-crane install (T14), skip-promote-on-cache-hit (T15), and update-description-always-on-base-success (v1.15.4b) all expected to remain quiet on this cache-hit run.	2026-05-23 19:14:58 +02:00
joakimp	19f8c043bd	Bump opencode 1.15.4 -> 1.15.6 + cut v1.15.6 ... Two upstream patch releases since v1.15.4b. Plus this release picks up two workflow improvements that landed on main between v1.15.4b and now (b6e4d89 pycache/DS_Store filter in base-decide, 90e5a1f doc-drift sweep clause in AGENTS.md). No image-content changes beyond the version bump; cache hit expected on base-35ee5fe7861a since neither Dockerfile.base nor rootfs/ have changed. The with-pi and omos-with-pi variants will also implicitly bump pi 0.75.3 -> 0.75.4 because PI_VERSION=latest resolves at build time. The omos-with-pi smoke threshold (3700 MB after the v1.15.4b bump) should accommodate two opencode patch versions plus one pi patch without recurrence of the trip; a future bump-bump pattern would push it again. First release on the new CI path that exercises: - pinned crane install (T14, v1.15.3) - only fires on real base rebuild, cache-hit on base means it stays unexercised this run too - skip promote-base-latest on cache-hit (T15, v1.15.4) - active - update-description always-and-success-of-base wrap (v1.15.4b) - active, will run since base variant publishes	2026-05-21 00:09:15 +02:00
joakimp	8f2c9f5112	v1.15.4b: omos-with-pi threshold bump + update-description partial-publish fix ... Recovery for v1.15.4's partial publish (omos-with-pi exceeded 3500 MB smoke threshold; other 3 variants published cleanly). Two changes: 1. omos-with-pi threshold 3500 -> 3700 MB. Compounded growth from opencode 1.15.0 -> 1.15.4 (4 patch versions) plus pi 0.74.0 -> 0.75.3 (minor + 3 patches) summed in the omos-with-pi variant, just over the existing limit. Same pattern as prior threshold bumps (v1.14.31c, v1.15.0b). Restores ~150 MB headroom for routine apt-upgrade drift. 2. update-description workflow bug fix. Pre-existing latent bug exposed by v1.15.4's partial publish: update-description.needs includes all 4 build-variant-* jobs, and gitea Actions' default behavior is 'skipped need => skip dependent' \u2014 even when the job's own if: condition is satisfied. So when build-variant-omos-with-pi was skipped (because its smoke failed), update-description cascaded into a skip too, and Hub description didn't refresh on v1.15.4 despite 3 variants publishing. Fix: wrap if: in always() + explicit success check on the base variant. Same fix applied to promote-base-latest preemptively (it has the same latent bug, currently masked by the cache-hit gate). No image-side changes \u2014 cache hit on base-35ee5fe7861a.	2026-05-18 22:30:59 +02:00
joakimp	60eb49469e	v1.15.4: bump opencode 1.15.3 -> 1.15.4 ... Bundles with the CI hardening landed on main since v1.15.3 (T14/T15 in the operator backlog): - Pinned crane install in promote-base-latest (replaces flaky imjasonh/setup-crane@v0.4 that depends on api.github.com/releases/latest at runtime and periodically rate-limits) - Skip promote-base-latest on cache-hit base builds (need_build='false') These will be exercised on this release run \u2014 if the base hash hasn't drifted since v1.15.3 (likely cache hit), promote-base-latest should SKIP rather than RUN, and update-description picks up the new tag.	2026-05-18 21:51:15 +02:00
joakimp	18b9c9c549	CI: harden promote-base-latest (pinned crane + skip on cache-hit) ... Two workflow-only changes for promote-base-latest, no image-side impact: T14 \u2014 replace imjasonh/setup-crane@v0.4 with direct pinned crane install. The action's bootstrap script calls api.github.com/.../releases/latest at every run to discover the crane version. That call periodically rate-limits and returns JSON without .tag_name, jq emits 'null', the action then downloads .../releases/download/null/... \u2192 404 \u2192 'gzip: unexpected end of file' \u2192 exit 2. We hit this on the v1.15.3 release (2026-05-16) where it was cosmetic only \u2014 base-latest was already correct from cache hit \u2014 but the red-X is annoying. Replaced with curl + tar pinned to crane v0.21.6 (latest at time of change). Same pattern as other GitHub-sourced binaries in the Dockerfile layer (gosu, fzf, eza etc.); operator bumps CRANE_VERSION deliberately when wanting updates. T15 \u2014 gate promote-base-latest on need_build == 'true'. When the base layer's content hash hasn't changed (cache hit on existing base-<hash> from a prior run), base-latest already points at the correct digest. The retag is a tautology, and any transient failure of it produces a red-X for an operation that didn't need to happen. Skipping the job entirely on cache-hit is correct and removes a whole class of cosmetic failure. Manual workflow_dispatch with promote_latest=true still bypasses the gate as an escape hatch (e.g., if base-latest got hand-deleted and needs regeneration without rebuilding the base). This will not trigger a CI publish run (main-branch commit, no tag).	2026-05-18 21:45:10 +02:00
joakimp	ad4a12b3ab	v1.15.3: bump opencode 1.15.0 -> 1.15.3	2026-05-16 19:54:15 +02:00
joakimp	d293ddc202	v1.15.0b: bump omos smoke threshold 3200->3300, omos-with-pi 3400->3500 ... opencode 1.15.0 grew the omos image to 3206 MB, 6 MB over the existing 3200 MB threshold, causing smoke-omos to fail and build-variant-omos to be skipped in v1.15.0. Bump thresholds with ~100 MB headroom for routine apt-get upgrade drift. No image-side changes — pure smoke threshold update. v1.15.0b will hit the base hash cache and run only the variant deltas.	2026-05-15 10:35:08 +02:00
joakimp	910378fe06	v1.15.0: opencode bump + git clone retry + pi-devbox sibling mention ... - Bump OPENCODE_VERSION 1.14.50 -> 1.15.0 in Dockerfile.variant. - Wrap pi-toolkit/pi-extensions git clone in Dockerfile.variant in a 5-attempt retry loop with linear backoff (matches pi-devbox pattern). gitea.jordbo.se occasionally returns transient HTTP 500s that previously broke with-pi/omos-with-pi variant builds. - Add 'Sibling images' section to DOCKER_HUB.md mentioning joakimp/pi-devbox as the pi-only counterpart. - CHANGELOG entry for v1.15.0 with full notes.	2026-05-15 09:56:01 +02:00
joakimp	f06a70a3bc	v1.14.50c: tag-only retag to recover v1.14.50b's missing variants ... CHANGELOG entry for v1.14.50c with full postmortem on the v1.14.50/50b runner-fleet incident (AVX shadowing + containerd race + Proxmox CPU default + base-latest auto-promote gap). No container-side code changes \u2014 the rebuild on the now-healthy fleet is sufficient.	2026-05-14 23:32:46 +02:00
joakimp	8359fef949	Force fresh base rebuild for v1.14.50b ... Add BASE_REBUILD_DATE comment to Dockerfile.base to invalidate the content hash and trigger a full base rebuild. Picks up ~5 days of Debian trixie security updates since the previous base-bf9df274db7a was built on 2026-05-09. The comment also documents the pattern for future intentional base-rebuilds without other code changes — recommended cadence is once per release for security currency. Required because v1.14.50 hash inputs were unchanged from v1.14.44, hitting the existing base-bf9df274db7a cache and shipping stale apt packages. v1.14.50 also failed mid-flight before promote-base-latest could publish base-latest to Hub — pi-devbox and other downstream images that FROM base-latest were blocked.	2026-05-14 20:17:37 +02:00
joakimp	07e07ec611	Bump opencode 1.14.44 -> 1.14.50; cut over to split-base pipeline ... - Bump OPENCODE_VERSION 1.14.44 -> 1.14.50 in Dockerfile.variant - Cut over: docker-publish-split.yml now triggers on push: tags: v* (was workflow_dispatch only). RELEASE_TAG and PROMOTE_LATEST derived from github.ref_type/ref_name for tag-push; inputs still available for manual workflow_dispatch runs. - Delete docker-publish.yml (retired, replaced by split-base pipeline) - Delete Dockerfile (retired, replaced by Dockerfile.base + Dockerfile.variant) - Update CHANGELOG: promote Unreleased -> v1.14.50 - Update AGENTS.md, .gitea/README.md, validate.yml: remove all references to the old single-Dockerfile pipeline and WIP migration plan	2026-05-14 19:39:45 +02:00
joakimp	a3ff601bf0	Bump opencode 1.14.42 -> 1.14.44; close v1.14.42 omos-with-pi gap ... opencode-ai 1.14.44 published 20:26 UTC (1.14.43 skipped upstream). Bumping to 1.14.44 instead of re-running the failed v1.14.42 build gives us the same 3h CI cost and picks up upstream bug fixes. Closes the v1.14.42 omos-with-pi gap. The v1.14.42 tag's build-omos-with-pi job failed during publish: oh-my-opencode-slim@1.0.7 had been published with a dependency on @opencode-ai/sdk@1.14.44, and our build hit the npm registry within ~2 minutes of that SDK version landing -- before the tarball had propagated across npm's CDN. The manifest's dist-tags.latest pointed at 1.14.44 but a tarball fetch on /-/sdk-1.14.44.tgz returned 404. Tarball is now fully fetchable. Result on Docker Hub once v1.14.44 publishes: v1.14.42 / latest -> stable (3 of 4 variants) v1.14.42-omos / latest-omos -> stable v1.14.42-with-pi / latest-with-pi -> stable v1.14.42-omos-with-pi -> NEVER PUBLISHED (404 if pulled) latest-omos-with-pi -> still v1.14.41b until v1.14.44 v1.14.44 / latest -> NEW (replaces latest) v1.14.44-omos / latest-omos -> NEW v1.14.44-with-pi / latest-with-pi -> NEW v1.14.44-omos-with-pi / latest-omos-with-pi -> NEW (closes the gap) CHANGELOG: v1.14.44 entry added with the propagation-race rationale, v1.14.42 entry annotated with the known gap. Reverse-chrono preserved.	2026-05-09 22:33:16 +02:00
joakimp	6fde27c212	Document the build pipeline architecture in .gitea/README.md ... The split-base build architecture, the NPM_CONFIG_PREFIX gotcha, the hash-driven base cache reuse mechanism, and the cutover plan from docker-publish.yml to docker-publish-split.yml were previously scattered across: - inline Dockerfile.base / Dockerfile.variant comments - CHANGELOG Unreleased entries - AGENTS.md mentions - docker-publish-split.yml header comment - my own session notes Consolidate into .gitea/README.md as the canonical architectural doc. Gitea (like GitHub) auto-renders this when navigating to .gitea/ in the web UI, so anyone investigating 'why is CI shaped this way?' finds it on the first click. Cross-referenced from AGENTS.md as the first thing to read when touching CI. Covers: - The two release pipelines and why both exist - Why split-base: cross-variant cache misses on layer-hash-divergence - The 6 phases of the split-base pipeline with an ASCII diagram - base-decide hash inputs and Docker Hub probe logic - NPM_CONFIG_PREFIX variant-override pattern (the volume-shadow trap) - Registry cache strategy (mode=max for cross-arch reuse) - Wall-clock estimates: version-bump vs base-touching releases - Validate workflow role - Runner expectations: catthehacker image, disk reclaim, concurrency, Gitea Actions @v4 artifact incompatibility - 4-step migration plan from docker-publish.yml to .split.yml - Cross-refs to related docs Does not duplicate AGENTS.md content; links to it for domain facts and release-day checklist.	2026-05-09 19:28:03 +02:00
joakimp	b30ffc83bd	Bump opencode 1.14.41 -> 1.14.42 ... opencode-ai 1.14.42 was released; bump OPENCODE_VERSION default in Dockerfile and Dockerfile.variant. Container changes accumulated since v1.14.41b ride along with this tagged release: pi package rename to @earendil-works/*, npm-prefix-on-volume fix, smoke-test query fix, Hub doc rewrite, README/AGENTS docs catchup. CHANGELOG promoted: Unreleased -> v1.14.42 (2026-05-09). The split-base build pipeline note stays under a fresh Unreleased \u2014 it's merged to main but not yet validated end-to-end via dispatch test, so it does not ship with v1.14.42 (the production docker-publish.yml on tag push is still authoritative). Release contents: - Bump: opencode 1.14.41 -> 1.14.42 - Rename: @mariozechner/pi-coding-agent -> @earendil-works/pi-coding-agent - Fix: NPM_CONFIG_PREFIX on volume so 'pi install npm:<pkg>' as developer survives container recreate AND image rebuild - Fix: smoke-test queries /usr prefix for npm ls -g check - Docs: Hub doc rewrite (24997 -> 5529 bytes), README pi section catchup (6 -> 7 extensions, mcp-loader documented), AGENTS release-day checklist updates	2026-05-09 19:17:10 +02:00
joakimp	896380bb9c	Rename @mariozechner/pi-coding-agent to @earendil-works/pi-coding-agent ... Pi moved to its new home at earendil-works on 2026-05-07 (https://pi.dev/news/2026/5/7/pi-has-a-new-home). The old @mariozechner/pi-coding-agent npm package is deprecated with the explicit message 'please use @earendil-works/pi-coding-agent instead going forward', and the version stream has moved on (old top-out 0.73.1; new currently 0.74.0). Anyone npm-installing the old name today gets a deprecation warning + a stale binary, so this is a non-optional migration before the next tagged release. Sweep: - Dockerfile (production single-Dockerfile path) and Dockerfile.variant (split-base path on main): npm install -g target updated. - README, AGENTS, HUB_TEMPLATE: github.com/mariozechner/pi-coding-agent URL refs (which now 404) -> github.com/earendil-works/pi. - DOCKER_HUB.md regenerated (5529 bytes, ~78% headroom). - CHANGELOG Unreleased: rename entry added with migration context. Brew install references (`brew install pi-coding-agent`) left as-is: formula still works at 0.73.1 and a homebrew tap update is tracked upstream at earendil-works/pi#2755. Historical CHANGELOG entries: only github URL refs updated (the package name was never spelled out in those entries; we're correcting dead hyperlinks, not rewriting feature descriptions).	2026-05-09 17:58:07 +02:00
joakimp	4c27e6fd8a	feat: split-base build pipeline (parallel, manual-trigger only) ... Two-Dockerfile split-base build alongside the existing single-Dockerfile pipeline. Goal: cut CI wall clock from ~165-180min to ~30-40min on typical version-bump-only releases by reusing a base image across the four variants. Files added: - Dockerfile.base variant-independent layers (apt, locales, AWS CLI, Node.js, mempalace, gitea-mcp, user setup, chromadb prewarm, ENVs, entrypoints). - Dockerfile.variant FROMs ${BASE_IMAGE} and adds opencode / pi / omos / Go installs gated by INSTALL_* args. Each npm install -g uses NPM_CONFIG_PREFIX=/usr per-RUN to keep baked binaries off the volume- shadowed ~/.pi/npm-global path inherited from base. - .gitea/workflows/docker-publish-split.yml workflow_dispatch-only pipeline: base-decide -> build-base (conditional) -> smoke-* (4 parallel) -> build-variant-* (4 parallel) -> promote-base-latest -> update-description. Hash-driven base reuse: if base-<sha> already exists on Docker Hub, the build is skipped entirely. Inputs: release_tag (test tag suffix, default v0.0.0-split-test) and promote_latest (default false; gates latest-* aliases and Hub description update). Files unchanged: - Dockerfile, docker-publish.yml, validate.yml all left in place so the production tag-push pipeline keeps working untouched. Migration plan (in CHANGELOG Unreleased): 1. workflow_dispatch test run with promote_latest=false; verify the four variant images smoke-pass and have plausible sizes. 2. Compare manifest digests against the same-version output from the production pipeline (independent test run on the same commit). 3. Once verified across 1-2 release cycles, swap docker-publish-split.yml to on: push: tags: v* and retire docker-publish.yml. AGENTS.md and CHANGELOG.md updated with file roles and the migration plan. Production pipeline behavior is bit-for-bit unchanged on this branch.	2026-05-09 16:16:25 +02:00
joakimp	b5da6a5cf8	README: pi 'What gets installed' section catchup ... Was stale: - Claimed 6 pi-extensions (actually 7 — mcp-loader was added in pi-extensions 141bf64 / 7eec49b / 37cc49e but the count was never propagated here). - No mention of mcp-loader's dual-transport (local stdio + remote streamable-HTTP per MCP spec 2025-03-26) or the /mcp slash command. - Mempalace bridge bullet didn't note that it coexists with mcp-loader rather than being replaced by it (don't list mempalace in mcp block). - No explicit 'no MCP servers baked in' line, leaving readers to guess whether searxng/context7 ship by default. Each extension now gets a one-line description; mcp-loader gets a paragraph covering its capabilities and a link to the pi-extensions AGENTS for transport detail. Added an opt-in note for MCP servers.	2026-05-09 15:54:48 +02:00
joakimp	f86c4b18cf	Rewrite DOCKER_HUB.md as a hand-maintained slim template ... The previous derive-from-README mechanism (split_sections, SECTION_RULES, TRIM_SUBSECTIONS, REPLACEMENTS) generated a 24 997 byte Hub doc with 3 byte headroom against the 25 kB Hub limit. Every README addition forced a 'trim something else first' exercise, and the resulting copy was awkward (terse, repetitive linkbacks injected mid-section). Replace with a single hand-maintained HUB_TEMPLATE constant. The Hub doc is now intentionally slim (~5.5 kB, ~78 percent headroom) and focuses on what Hub readers actually need: elevator pitch, image variants, quick start, what's inside, auth, persistence, and link-outs to the gitea README for depth. Trade-off: when image-variants or quick-start change, update HUB_TEMPLATE here too. That coupling is now explicit and local rather than spread across SECTION_RULES + REPLACEMENTS + TRIM machinery, and most README edits no longer require regenerating DOCKER_HUB.md at all. Generator simplified from 323 lines to 199 lines (270-line net reduction across the script + DOCKER_HUB.md). README and Hub doc are now independent surfaces. CHANGELOG and AGENTS updated to reflect the new coupling. Release-day checklist tightened: README -> regenerate DOCKER_HUB ONLY if HUB_TEMPLATE changed -> promote CHANGELOG -> grep AGENTS -> commit -> tag.	2026-05-09 15:49:43 +02:00
joakimp	9df126c7a9	Fix: developer-writable npm prefix for pi install ... NPM_CONFIG_PREFIX is now /home/developer/.pi/npm-global, with that prefix's bin/ prepended to PATH. Without this, 'pi install npm:<pkg>' (and any 'npm install -g') by the developer user would EACCES against the system prefix (/usr). The new prefix lives on the devbox-pi-config named volume, so: - User-installed pi packages (themes, skills, extensions) survive container recreate AND image rebuild, complementing pi's auto- restore from settings.json with one less cold-start step. - A user-driven 'npm install -g @mariozechner/pi-coding-agent' lands on the volume and wins over the baked pi via PATH order. Build-time 'npm install -g' calls (opencode, pi, oh-my-opencode-slim) are unaffected: the new ENVs are declared after those steps in the Dockerfile, so the baked binaries still install to /usr at build time and are not shadowed by the volume mount at runtime. Verified end-to-end with a Bun-driven smoke test: as developer, 'npm install -g cowsay' inside the container succeeds, the binary lands on PATH, and survives a fresh container against the same volume. DOCKER_HUB.md regenerated (24997/25000 bytes, 3-byte headroom — was 138 before; future README additions to the persistence section need to trim something else first). Docs updated: Dockerfile inline comments, README persistence section, AGENTS install contract, DOCKER_HUB persistence table, .env.example notes, CHANGELOG Unreleased entry.	2026-05-09 15:41:33 +02:00
joakimp	cc98722d84	docs: catch up CHANGELOG and AGENTS.md with v1.14.41b reality ... CHANGELOG drift: - 'Unreleased' still claimed 'Will become v1.14.41b on release' even though the tag was cut and shipped today. Promoted to a proper '## v1.14.41b — 2026-05-08' release header (re-ordered above v1.14.41 to keep reverse-chronological invariant). - New 'Unreleased' entry records today's docs-only updates (commits 8083cd1, d01cff3, this commit) which were patched to Docker Hub via the API rather than re-tagging. AGENTS.md drift introduced by the v1.14.41b CI matrix expansion: - 'CI produces four Docker Hub tags per release' → eight (one tag pair per build variant: base, omos, with-pi, omos-with-pi). - 'all four `load: true` jobs (validate-base, validate-omos, smoke-base, smoke-omos)' → all eight (added validate-with-pi, validate-omos-with-pi, smoke-with-pi, smoke-omos-with-pi). DOCKER_HUB.md unchanged (already in sync, regenerator confirms).	2026-05-08 21:32:11 +02:00
joakimp	bf811f2170	Merge main (v1.14.41 bump) into feat/install-pi ... # Conflicts: # CHANGELOG.md	2026-05-08 13:46:03 +02:00
joakimp	c76b1e8aa3	Bump opencode to 1.14.41 ... Restored formatter output handling for stdout/stderr-writing formatters; warping a session to another workspace can now carry over uncommitted file changes; restored custom provider setup in /connect; macOS Settings menu entry; desktop local server split into a separate utility process; ACP clients restore last model/mode/effort when loading sessions and can close sessions cleanly. No container-level changes.	2026-05-08 13:08:50 +02:00
joakimp	5006b01170	Pre-warm chromadb embedding model at build time ... Mempalace's embedding function is chromadb's ONNXMiniLM_L6_V2, which downloads ~80 MB of all-MiniLM-L6-v2 ONNX weights from chromadb's CDN on first use. Without pre-warming this happened silently in the entrypoint init step (output redirected to /dev/null) and stalled first container start by multiple minutes on slow networks — the symptom user reported as 'hangs at Initializing MemPalace for workspace'. Fix: invoke the embedding function once at build time as gosu developer so the cache lands at the runtime user's ~/.cache/chroma/onnx_models/all-MiniLM-L6-v2/ with correct ownership and survives container recreate (cache path is not on a named volume, so it lives in the image layer). Build-time cost: ~3-5 s to download. Runtime saving: minutes per fresh container. Image size: 2110 → 2277 MB for the with-pi variant. Still within the 2700 MB smoke-test threshold.	2026-05-08 00:25:22 +02:00
joakimp	f51e9f52a1	Add INSTALL_PI build arg for pi as second harness ... Optional integration of pi-coding-agent alongside opencode in the same container. Both harnesses share the mempalace install and palace path — wing/diary entries are mutually visible. Build: --build-arg INSTALL_PI=true # opt-in --build-arg PI_VERSION=0.73.1 # pin a version (default: latest) --build-arg INSTALL_OPENCODE=false # build pi-only image Dockerfile: • New INSTALL_PI block: npm install -g @mariozechner/pi-coding-agent + git-clones pi-toolkit and pi-extensions to /opt/. • Existing opencode install gated behind new INSTALL_OPENCODE arg (default true; existing builds unaffected). • mkdir adds ~/.pi/agent/extensions for the named volume mount root. • CMD changed from ['opencode'] to ['bash', '-l']. compose run --rm devbox now drops to a login shell so users pick the harness; pass 'opencode' or 'pi' explicitly to launch directly. compose exec workflows are unaffected (bypass entrypoint+CMD). entrypoint.sh: • Adds ~/.pi to volume ownership loop. entrypoint-user.sh: • New 'pi: deploy toolkit + extensions + mempalace bridge' block runs pi-toolkit/install.sh, pi-extensions/install.sh, settings.json template bootstrap, then symlinks the mempalace.ts bridge directly. Order: toolkit before extensions before bridge. mempalace-toolkit's full install.sh is intentionally NOT called (its install_skill would race with skillset auto-deploy --prune-stale). docker-compose.yml: • New devbox-pi-config named volume mounted at /home/developer/.pi. Persists user toggles (/ext-disabled extensions) and settings.json edits across container recreate. Mirrors devbox-opencode-config pattern from v1.14.33. scripts/smoke-test.sh: • New --variant with-pi (threshold 2700 MB) and --variant omos-with-pi (3400 MB). • Pi assertions gated on `command -v pi`: version, /opt/pi-toolkit clone HEAD, /opt/pi-extensions clone HEAD, deployed keybindings symlink, ≥4 extension symlinks, mempalace.ts bridge symlink, settings.json bootstrap. • Pi state assertions use docker exec from the host (not 'run'), since the container has no docker CLI. • opencode core test now gated on INSTALL_OPENCODE presence. scripts/generate-dockerhub-md.py: • SECTION_RULES adds 'pi (alternative/complementary harness)': drop. Section stays in README; dropped from DOCKER_HUB.md to keep under the 25 kB Docker Hub limit. Docs: • README adds full 'pi (alternative/complementary harness)' section. • AGENTS.md codifies pi install contract, deploy ordering, named volume rationale, and CMD change. • CHANGELOG.md gets an Unreleased entry. • .env.example documents new build args. • docker-compose.yml example args block updated. Verification (local builds on arm64): • Default (INSTALL_PI=false): 1871 MB, all assertions pass — no regression. • INSTALL_PI=true: 2110 MB (within 2700 threshold), 37 assertions pass including pi version, all 7 extensions deployed (6 from pi-extensions + mempalace.ts bridge), settings.json bootstrap. Not yet: • CI workflow updates to add -with-pi tag variants. Deferred until local path stabilizes through user testing. • pi-devbox separate repo for fully stripped pi-only image. Phase 2.	2026-05-07 23:58:37 +02:00
joakimp	a208b073b0	Bump opencode to 1.14.40 ... Rolls up upstream v1.14.34 through v1.14.40 (no v1.14.36 was published). Highlights: .well-known/opencode remote config support; HTTP_PROXY honored in desktop app; CORS/CSP fixes; warp-session-to-workspace feature; PTY auth tickets; v2 session failure events; debug info CLI command. No container-level changes.	2026-05-07 10:52:50 +02:00
joakimp	79b697dea0	Bump opencode to 1.14.33	2026-05-03 10:31:17 +02:00