130 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Joakim Persson	cbd7cf5c67	entrypoint: announce the "remote palace, no inbox" skip instead of vanishing ... When MEMPALACE_REMOTE_URL is set but MEMPALACE_PI_SSH_TARGET is not, the feeder has nowhere to ship staged transcripts, so skipping is correct. The problem was that the branch was a bare `:` AND the skip happens before the subshell that writes ~/.pi/agent/mempalace-catchup.log -- so a container in that state contributed nothing to the palace and left no artifact at all, not even an empty log, to explain why. It is indistinguishable from a healthy run that had nothing to file, which is the worst property a memory system can have: the failure looks exactly like success. Surfaced while flipping the first client onto the shared palace, where this is the single most likely way to end up quietly memory-less -- the palace is the only thing that survives a container recreate. The notice goes to both the container start output (docker logs) and the log path anyone debugging looks at first. It names both variables, says what still works (MCP tools read/write the shared palace; only this container's own conversations go nowhere), and points at MEMPALACE_FEED=0 for anyone who meant it -- "HTTPS first, mining later" is a documented interim state, so the notice has to be silenceable without being ignorable. Guarded against becoming a startup failure. mkdir -p in a branch that previously touched no filesystem is a new risk: an unwritable ~/.pi (root-owned volume, a classic Docker accident) fails under set -e and would abort the entire entrypoint. It now degrades to stdout-only. Verified all five paths by executing the extracted block under `set -euo pipefail`: the trap prints and writes the log; unwritable ~/.pi still exits 0 and still prints; MEMPALACE_FEED=0 stays completely silent (no message, no file); and both normal-remote and local mode still background the feeder with no notice. Two smoke assertions guard against a regression to the silent no-op. They test the entrypoint as shipped in the image rather than behaviour, because this branch only runs at container start and a `docker run` one-shot cannot reach it. entrypoint-user.sh is COPY'd in Dockerfile.base, so this rides the base rebuild the Unreleased feeder work already needs.	2026-08-13 16:30:55 +02:00
Joakim Persson	7c00dd6001	mempalace: drop the stage ENV pin, fix the shared-server compose ... The feeder now defaults to <palace-root>/pi-stage upstream, so pinning MEMPALACE_PI_STAGE into ~/.pi here is unnecessary -- and was actively wrong. It created a second convention that could still diverge from the palace: keep the devbox-palace volume, drop devbox-pi-config, and a scoped `mempalace sync` prunes every conversation drawer, because dedup keys on the staged path. Both the ENV and the entrypoint export are gone; a comment explains why adding one back re-introduces the split it was meant to fix. docker-compose.mempalace.yml was broken on mempalace 3.6.0 in both directions: - `--host 0.0.0.0` with no token in the environment makes the server refuse to start, crash-looping under `restart: unless-stopped`. - Supply a token and the healthcheck's unauthenticated `tools/list` POST 401s, marking a perfectly healthy server unhealthy forever. Now the token is required via ${MEMPALACE_REMOTE_TOKEN:?...} so it fails fast at `docker compose up` with a readable message, and the healthcheck probes the deliberately token-free /healthz. The "no authentication of its own" security note has been stale since 3.6.0 and is replaced with the actual posture (bearer token + Host pin + Origin allowlist), including why browser-shaped auth must not be put in front of it. Dockerfile.base: mempalace-pi-session symlinked onto PATH, with a build-time `--help` check so a broken feeder fails the image build rather than the first session. smoke-test: assert the stage resolves beside the palace (default, and following $MEMPALACE_PALACE_PATH) instead of asserting the removed ENV pin. The two behavioural guards -- a synthetic session that must be captured, an abandoned one that must not be -- are unchanged. .env.example: recommend `mempalace serve` on the docker0 gateway rather than `mempalace-mcp --transport http --host 0.0.0.0`, with the two binds to avoid.	2026-08-12 17:04:14 +02:00
Joakim Persson	7649d53f3b	.env.example: say why GIT_USER_* must be set ... Both keys shipped empty with no explanation, so they read as optional. They are not: ~/.gitconfig is not on a persistent mount, so with these unset every repo in the container fails "Author identity unknown" on first commit after every recreate — and an agent asked to commit then infers an identity from git log and picks the wrong one. Observed today across three repos on one machine (two wrong-address commits, plus older `pi <pi@devbox>` fossils from earlier sessions guessing the same way). Also records that the address is per-machine (corporate vs private), so it belongs in the per-machine .env rather than a skill or a repo-local override.	2026-08-09 15:42:29 +02:00
joakimp	ade58131d6	docs(readme): use mkdir -p instead of install -d for the peer's ~/.ssh ... `install -d -m 700 ~/.ssh` was correct but wrong for the audience. This snippet gets pasted onto an arbitrary peer — a NAS, a router, a BSD box — and `install` is not in POSIX, so it is not guaranteed to be there. `mkdir -p` + `chmod` is POSIX, present everywhere, and self-evidently idempotent to a reader deciding whether it is safe to run on a machine that already has keys. Behaviour was checked rather than assumed, on both coreutils and BSD/macOS `install`: on an existing ~/.ssh it exits 0 and leaves authorized_keys intact in content and mode, but it also silently chmods the directory (755 -> 700). Desirable here, yet invisible in a doc — which is the second reason to prefer the explicit two-step form, and why the surrounding text now states outright that re-running is safe on an already-configured peer: mkdir -p is a no-op, the chmods only tighten, and appending never touches keys already listed. Verified the whole block end-to-end against a fresh HOME and one with a pre-existing 755 ~/.ssh and an older key: 700/600 in both cases, older key preserved, new line appended.	2026-08-08 01:24:51 +02:00
joakimp	ffd44ad9cf	docs(readme): say where the authorized_keys line actually goes ... Step 2 of "Giving the container its own key for a peer" showed a correctly narrowed authorized_keys line but never named the file it belongs in, and never said which account's — the only mention of authorized_keys was an aside 35 lines further down about revoking one key per machine. A reader following the steps had a public key, a line to construct, and nowhere to put it. Now explicit: append to ~/.ssh/authorized_keys of the account named as `User` in step 3, via a heredoc that shows `>>` rather than `>` (the truncation that revokes every other key on that account), with `install -d -m 700 ~/.ssh` and `chmod 600` so the file is created correctly the first time. Adds the three failure modes that make a good key look broken, none of which announce themselves on the client: the options prefix must be on the same physical line as the key (a wrapped paste is the usual culprit), `ssh-copy-id` cannot add that prefix at all so the line must be appended by hand, and sshd's StrictModes silently ignores authorized_keys when the home directory, ~/.ssh or the file is group- or world-writable — reporting it only in the peer's own log.	2026-08-08 01:17:48 +02:00
joakimp	43cd6e22f2	v1.7.0: bundle pi-atelier at a pinned tag; pin pi to an audited 0.84.1 ... Two changes that belong together, because the first is what makes the second dangerous to get wrong. pi-atelier (TUI sidebar + status rail) is now vendored to /opt/pi-atelier at PI_ATELIER_REF=v0.8.0 and registered by entrypoint-user.sh — the pi-fork / pi-observational-memory / pi-studio pattern, deliberately NOT `pi install npm:pi-atelier`, which writes into ~/.pi/npm-global on the config volume where it shadows the image and pins nothing. Unlike its siblings it gets no `npm install`: atelier declares zero runtime deps (peerDeps only, satisfied by the baked pi) and has no build step, so pi loads its TypeScript straight from the checkout via package.json `pi.extensions`. pi is no longer resolved to npm `latest` at build time. The pin lives in Dockerfile.variant and CI reads it from there, so a local `docker build` and a CI release ship the same versions by construction. The pin is a CHECKPOINT, NOT A FREEZE: bumping stays a one-line change; what stops is *unreviewed* adoption of whatever shipped that morning, in the same build that then gets tagged and published. CI fails when a pin is not concrete or not actually published on npm, and warns — never adopts — when npm latest moves ahead, naming what to re-check. Why this pairing needed care: pi-atelier 0.6.0/0.7.0 wrap pi's PRIVATE TUI renderer, and under pi 0.84 that wrapper recurses — pi hangs at startup burning CPU with no error. Upstream fixed the recursion in 0.7.1 and restored the non-overlapping split in 0.7.2; 0.8.0 is additive on top. atelier's own peerDependencies still say >=0.80.7, which does not express that floor, so nothing in npm metadata could have warned us. The floor is therefore encoded as an executable rule — pi >= 0.84 => pi-atelier >= 0.7.1 — asserted in both smoke-test.sh (build time) and recreate-sanity-check.sh (after a real recreate), verified against a 4x4 version matrix. Existing volumes needed migration, not just vendoring: a hand-installed `npm:pi-atelier` entry is counted as already-registered by the entrypoint guard, so every existing volume would have kept its unpinned npm copy — and a 0.6.x copy next to pi 0.84 is exactly the startup hang. The entrypoint now drops that one exact string (settings.json.bak.atelier.<ts> backup, distinct prefix so it cannot clobber the template merge's backup in the same second) and lets the pinned /opt copy register. Tested against a real settings.json: only that entry removed, other packages and all keys intact, idempotent, and unparseable JSON leaves the file untouched. DEVBOX_ATELIER=0 opts out entirely — in the entrypoint rather than via `pi uninstall`, because this component's failure mode is "pi will not start", which cannot be repaired from inside pi. 0.84.1 was audited for this release, not merely adopted: theme/TUI changes are additive, the session format is unchanged (CURRENT_SESSION_VERSION = 3 in both 0.83.0 and 0.84.1 with an identical migrateV1ToV2/migrateV2ToV3 ladder, so existing transcripts are neither migrated nor at risk and pi-session-repair stays valid), and the Node engine floor is unmoved at >=22.19.0. CI resolves the atelier tag to its PEELED commit SHA — atelier uses annotated tags, so the unpeeled ref is a tag object, not a commit; pi-studio's lightweight tags never exposed that distinction. Also: docs for overriding the read-only ~/.ssh/config from the container — container-only keys in ~/.ssh-local, hardened authorized_keys, the fact that `from=` must allow the HOST's addresses because container egress is NAT'd through it, and the macOS-only-keyword trap (`UseKeychain` is fatal to Linux OpenSSH and takes out dssh/pi --ssh while the host keeps working). Corrects two claims in "Naming LAN peers": ssh-lan.conf is not ProxyJump-only, and first-time creation does need one restart because the Include is emitted only when the file already exists at start. v1.7.0	2026-08-07 21:34:41 +02:00
pi	62a2a79b1c	ci(lint): correct the rationale comment — runner contention was overstated ... The previous commit justified excluding tag pushes partly on runner contention: that the duplicate lint run stole one of two self-hosted runners from the release build. Measured, that is false for THIS repo — pi-devbox lint runs take 0.3-0.9 min (ids 529/531/532/533) against a 77.6 min release build (id=530). I imported the claim from opencode-devbox, where actionlint apt-installs shellcheck inside the container and takes 6-15 min, so contention there is real. The change stands on its actual merits: duplicate lint of an identical tree, and release-run discovery ambiguity (the substantive one — it is what made the naive "first run matching refs/tags/<tag>" rule pick lint over the publish run). No functional change; comment only.	2026-08-04 18:08:28 +02:00
pi	f20b2a7926	ci(lint): don't re-lint on tag pushes ... `on: push:` with no filter also fires on refs/tags/v*, which is duplicate work: the tagged tree was already linted when that same commit was pushed to main (v1.6.4 sha e86e5df linted as id=529 on main, then again as id=531 on the tag). Two costs beyond the wasted run. It consumed one of the two self-hosted runners while the release pipeline wanted both for its parallel multi-arch variant builds; and it made release-run discovery ambiguous, since the newest-first runs listing puts the tag-ref lint run above the publish run. `branches: ['**']` keeps the documented intent exactly — lint fires early on every branch push and PR, rather than only at tag time — while excluding tag refs. docker-publish.yml is untouched and still tag-scoped.	2026-08-04 18:06:34 +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
pi	572430237f	Bump mempalace pin 3.5.0 → 3.6.0 (lockstep with opencode-devbox v2.9.0) ... 3.6.0 (2026-07-17, PyPI latest) is additive/reliability only: secure `mempalace serve` remote mode, optional Milvus backend, atomic KG supersede(), conversation chronology, mining exclusions, plus recovery and locking fixes. Reviewed for MCP tool-schema changes before bumping — that being the exact regression class this pin exists to catch, after an unpinned install once swept in the broken 3.3.x/3.4.0 diary_write schema. There are none, and nothing touches diary_write, so the perl workaround removed in v1.2.2 stays removed. Two fixes matter for how this image uses mempalace: read-only mode now covers checkpoint + delete_by_source in _MUTATING_TOOLS (#1930), and agent attribution is preserved in mempalace_checkpoint (#2023/#2034) — the latter because the diary protocol relies on per-agent attribution. Also adds a CHANGELOG Unreleased block that backfills the per-variant image description labels (1fd524e), pushed after the v1.6.4 tag without an entry. Not tagged: more changes are queued for the next release. Pushing to main triggers only lint.yml (actionlint + hadolint) — the image build/publish workflow is tag-only. Verified clean against the CI-pinned hadolint 2.14.0.	2026-08-04 16:01:39 +02:00
joakimp	1fd524e7fb	Give each variant its own image description label ... Both published variants inherited Dockerfile.base's description="pi-devbox — base image (variant-independent)", so v1.6.4 and v1.6.4-studio both advertised themselves on Docker Hub as the base image — misleading, and useless for telling the two apart. A LABEL cannot branch on INSTALL_STUDIO, so the text arrives as a build-arg: CI passes a variant-specific string (interpolating RELEASE_TAG, PI_VERSION and, for studio, STUDIO_TAG), and the Dockerfile default keeps a bare local `docker build -f Dockerfile.variant` honest instead of misleading. Also sets org.opencontainers.image.title/description alongside the legacy bare `description` key, so Hub and OCI-aware tooling both see it. ARGs stay in the last-declared block, so the label layer is still the only thing invalidated. Verified: hadolint 2.14.0 (the CI-pinned version) clean on both Dockerfiles; workflow YAML parses; check-workflow-shell.sh passes. Lands on the next release.	2026-07-30 07:59:41 +02:00
joakimp	e86e5df327	release: v1.6.4 — fork tool actually loads, pi 0.83.0 audited clean ... Headline is the fork-guard fix (the `fork` tool had never loaded since v1.0.0 because the registration guard grepped the whole settings.json and matched the pi-fork *config block* the template merge itself plants). pi 0.82.1 -> 0.83.0 is a clean hop with no intermediates. 0.83.0 carries an upstream Breaking Change (bundled TypeBox 1.1.38 -> 1.3.7, deprecated APIs removed) that cannot reach us: pi-fork vendors @sinclair/typebox (a different package name), obsmem's use is type-only, studio and atelier don't use TypeBox. Verified from source rather than from the audit narrative: extension-facing dist/core/extensions/*.d.ts declarations diff clean between the two versions, all six CLI flags pi-fork passes to child processes are present, and SESSION_VERSION is 3 in both so transcript tooling is unaffected. No PI_VERSION pin needed. Recorded for the release notes: the Bedrock poison pill is NOT fixed in pi-ai 0.83.0 (unsanitised input: c.arguments moved 634 -> 644), so pi-session-repair stays the recovery path. v1.6.4	2026-07-30 01:10:07 +02:00
joakimp	fa04d2083d	docs(rootfs): re-sync pi-extensions skill snapshot (fork boundary mechanism) ... Vendored floor snapshot re-synced from pi-extensions 98eb07b, which documents the mechanism behind fork boundary violations (full parent-transcript inheritance via index.ts:47) plus the corrected claims about tool restriction and narrative invention. CI resolves PI_EXTENSIONS_REF from main HEAD, so a normal build ships the package-owned copy; this keeps the committed floor identical so scripts/smoke-test.sh's cmp assertion holds either way.	2026-07-30 00:50:49 +02:00
joakimp	209f2c2f67	docs(rootfs): re-sync mempalace snapshot from skillset 63f3bf5 ... Closes the drift found in 4d4abd9's investigation: the Temporal grounding guidance was authored straight into this vendored fallback (904fe85) and never returned to skillset, the declared owner. skillset 63f3bf5 now carries it (with the wording generalized from "a pi-devbox container" to "a devbox container (pi-devbox or opencode-devbox)", since opencode-devbox vendors the same skill), so this snapshot is a pure mirror of the owner again. VENDORED.md: refresh commands now copy each snapshot FROM ITS OWNER. The pi-extensions lines previously pointed at <skillset>/skills/pi-extensions/, which has been a downstream duplicate since a7f3044 co-located the canonical skill in the package repo — following the old instruction would have silently regressed the snapshot (e.g. undoing pi-extensions e73cb9f). Provenance bumped to skillset 63f3bf5 / pi-extensions pkg e73cb9f.	2026-07-29 19:44:36 +02:00
joakimp	4d4abd9a9f	skill(pi-devbox-environment): resolve a skill symlink before editing it ... ~/.agents/skills/ lives in the ephemeral container layer and is rebuilt by entrypoint-user.sh on every start from two sources, so an edit made through the symlink may vanish on the next recreate. Adds to §1 (persistence tiers): - `readlink -f ~/.agents/skills/<name>` as the first move, with a tier table: resolves under /workspace/skillset → edit in place; resolves under /usr/local/share/pi-devbox/skills → image layer, edit the canonical repo and `sudo cp` to activate for the running session. - Canonical owner per baked skill (pi-devbox-environment → this repo; pi-extensions → the package repo's skill/, plus this repo's floor snapshot; mempalace → the private skillset repo), pointing at VENDORED.md as authoritative. - The shadowing gotcha: image-baked links are created first and only when absent, and deploy-skills.sh --prune-stale leaves foreign links alone, so for a name present in BOTH sources the image copy wins and a skillset edit has no effect in the container. Documented with the live example found while writing this: the baked mempalace snapshot carries a Temporal grounding section (904fe85) that skillset at its snapshot point (8e8db64) lacks. - Checklist gets a matching line. Found while adding session findings to the pi-extensions skill (e73cb9f), where the same resolve-first step was what kept the edit out of the image layer.	2026-07-29 19:37:59 +02:00
joakimp	d5c5da3f6c	docs(rootfs): refresh vendored pi-extensions skill snapshot ... Sync the image-baked "floor" copy at rootfs/usr/local/share/pi-devbox/skills/pi-extensions/SKILL.md with pi-extensions e73cb9f, which documents package-registration forensics (packages[] vs whole-file grep), that /reload suffices for a newly installed package, and a fork-output caveat — the findings from the fork-guard bug fixed in 8248688. Dockerfile.variant copies the pinned package's skill/ over this snapshot at build time, so the vendored copy is only the fallback floor; it was byte- identical to the package copy before this change, and keeping it in sync prevents a silent divergence for builds whose PI_EXTENSIONS_REF predates the skill.	2026-07-29 19:34:00 +02:00
joakimp	8248688d58	fix(entrypoint,tests): register pi-fork — guard matched its own config block ... The `pi install /opt/<pkg>` loop in entrypoint-user.sh guarded on a whole-file substring grep of ~/.pi/agent/settings.json. settings.example.json ships a top-level "pi-fork" CONFIG block (fork effort profiles, pi-toolkit adb6907, 2026-06-17), so `grep -q pi-fork settings.json` matched the config key itself and `pi install /opt/pi-fork` never ran — on fresh or preserved volumes. The `fork` tool has therefore been absent since v1.0.0. The non-destructive template merge runs earlier in the same startup than the install loop, so the mechanism that delivers new template keys to an old volume is what plants the string that defeats the guard. pi-observational- memory and pi-studio escaped only by luck: the template key is "observational-memory" (no pi- prefix) and there is no studio block. Guard now inspects the `packages` array via jq, with a grep fallback on the stored `.../opt/<name>"` path form, which a config key can never produce. Existing volumes self-heal on the next container start. Both test suites asserted the bug as green — smoke-test.sh:244 and recreate-sanity-check.sh:204 used the same whole-file grep, so "pi-fork registered (fork tool)" passed on every build and recreate while the tool was missing. Both now assert against packages[] with the entrypoint's predicate, labels say packages[], and the smoke readiness wait loop uses the array check plus `docker exec -u developer` + $HOME instead of a hard-coded /home/developer path. Evidence: zero `fork` tool calls across all 19 sessions on this volume; the v1.6.3 session that tuned pi-fork.deep to opus-5 was configuring a tool that never loaded.	2026-07-29 19:21:49 +02:00
joakimp	e274510fd1	docs(changelog): unreleased — settings template defaults to Opus 5 ... Records the pi-toolkit 926f738 template change (defaultModel + pi-fork deep tier -> eu.anthropic.claude-opus-5). No tag, no build: CI resolves the pi-toolkit SHA from main at build time, so whichever release builds next picks it up.	2026-07-26 00:30:54 +02:00
joakimp	9ef7a92dce	docs(changelog): v1.6.3 — pi 0.81.1→0.82.1 ... Pure pi version bump (variant-only rebuild). CI resolves pi@latest=0.82.1 at build. 0.82.0/0.82.1 audited: additive, no breaking changes to the extension execution API (pi-observational-memory) or pi-agent-core types (pi-fork). v1.6.3	2026-07-25 22:35:51 +02:00
joakimp	6dfbded9c8	release: v1.6.2 — lift smoke size threshold (3500→3800) ... Completes v1.6.1's studio publish. Run 512 shipped v1.6.1 non-studio (3411 MB) cleanly, but smoke-studio failed the size gate at 3574 MB vs the 3500 MB threshold. Threshold was set in v1.0.0 pre-agent-browser (baseline was 3.20 GB local arm64 + 300 MB margin); v1.6.0 baked in agent-browser + Chromium (+~291 MB net) but the threshold was never lifted. v1.6.0 never got to smoke because of the network fault, so nothing surfaced this until v1.6.1's smoke-studio. Bump SIZE_THRESHOLD_MB to 3800 (~225 MB margin above observed studio number, tight enough to still catch a genuine +GB regression). Refresh the comment above the constant with the current baseline + run 512 actuals so future readers know where the number came from. CI-only change; image bytes identical to v1.6.1 except for the manifest's release_tag/source_revision. Not base-affecting. v1.6.2	2026-07-23 08:43:57 +02:00
joakimp	45b6239777	test(smoke): don't hard-code a 'v' prefix on release_tag ... The smoke workflow deliberately passes RELEASE_TAG=smoke to the variant build so smoke images don't collide with real vX.Y.Z tags. The variant bakes that into /etc/pi-devbox/build-manifest.json, and pi-devbox-version prints 'pi-devbox smoke' — correct behaviour. But the smoke assertion required substring 'pi-devbox v', which only holds for real releases. Assertion never fired before because pi-devbox-version was added after v1.5.0 (fb49828, 2026-07-15) and every CI attempt since was blocked before smoke ran (v1.6.0 network flake, v1.6.1 first successful base build hit this). CI run 509 (v1.6.1) surfaced it. Fix: require the substring 'pi-devbox ' (space, no v). The two neighbouring assertions on --json and --quiet already cover the value of release_tag; this one just verifies the human line renders. Everything else in 55/56 checks passed on run 509 including pi 0.81.1 reported and base-229f04e5d021 pushed OK. v1.6.1	2026-07-23 07:58:22 +02:00
joakimp	d00eef2acb	docs(changelog): v1.6.1 — pi 0.80.6→0.81.1 (skips 0.81.0) ... v1.6.0 was tagged 2026-07-17 but never reached Docker Hub (variant publish blocked by a site-network SYN-drop fault, since fixed). Cut v1.6.1 to land v1.6.0's content (agent-browser + pi-devbox-version) alongside a first pi bump since v1.5.0. 0.81.0 is skipped deliberately: it removed the default stream fallback for extensions using the pre-0.81 pi-agent-core API, which pi-observational-memory relies on via agentLoop + stream.result(). 0.81.1 restored the fallback (earendil-works/pi#6915), so 0.81.1 — but not 0.81.0 — is a safe drop-in. pi-fork only imports types; unaffected. Audit of 0.80.7–0.81.1 vs the two baked extensions and the base image: no breaking changes affect pi-devbox. Node engine bumped to >=22.19.0 in 0.81.0 (nodesource 22.x currently 22.23.1, so no engine bump needed). Base-affecting via the npm install line, so base-<hash> rebuilds.	2026-07-22 22:53:55 +02:00
joakimp	fb35c549b5	fix(base): locate agent-browser's chrome arch-agnostically ... v1.6.0's first build failed on amd64: playwright@latest fetches Chrome for Testing, which extracts to chromium-<rev>/chrome-linux64/ on amd64 (vs chrome-linux/ on arm64). The hardcoded chrome-linux/ glob matched only arm64, so amd64 built no /usr/local/bin/agent-chrome symlink and 'test -x' failed (agent-browser --version had already printed 0.32.1 — the tell). Replace the glob with an arch-agnostic 'find -name chrome -path */chromium-*/*' (skips the chrome-headless-shell binary and the chromium_headless_shell dir), guarded by [ -n ] + the existing test -x. Verified locally: resolves the CfT chrome and agent-browser drives it headless. hadolint clean. v1.6.0	2026-07-17 17:55:21 +02:00
joakimp	649fc44c5b	chore(release): v1.6.0 ... Roll the unreleased changes into v1.6.0 (minor — significant base addition: agent-browser + headless Chromium baked into every variant for browser automation/front-end verification). Also includes the pi-devbox-version command and the bundled pi-toolkit sonnet-5 template bump. No pi bump — CI resolves latest pi from npm at build time (verified: 0.80.6→0.80.10 has no breaking changes affecting pi-devbox).	2026-07-17 17:19:56 +02:00
joakimp	89a8dc7fab	perf(base): trim agent-browser footprint ~960MB→~625MB before release ... Size concern ahead of the v1.6.0 base rebuild. agent-browser drives the full chrome (verified headless: open/title/eval with the headless_shell removed), so Playwright's chromium_headless_shell-* build is dead weight — drop it (~334MB), and clean apt/npm caches in-layer. Net browser footprint ~625MB/arch. CI disk is otherwise fine: build-base's 'Reclaim runner disk' step frees ~20-30GB (hostedtoolcache/dotnet/android/jvm) + docker prune before buildx. hadolint clean.	2026-07-17 17:19:20 +02:00
joakimp	6625d66f3a	docs(agents): point the global AGENTS.md managed block at agent-browser ... Discoverability follow-up to baking agent-browser into the base: agents won't reach for a browser they don't know they have (the exact gap that made this capability easy to miss). Add a short pointer section to the pi-devbox managed block — capability, the preset AGENT_BROWSER_EXECUTABLE_PATH, and `agent-browser skills get core --full` for the command set. Pointer only; depth stays in the skill. rootfs change → folds into the same base-<hash> rebuild. CHANGELOG note updated.	2026-07-17 17:15:09 +02:00
joakimp	8caafc3f49	base: bake agent-browser + Playwright Chromium (headless browsing, all variants) ... Gives the agent a real browser it can drive so front-end work involving live DOM/WebGL can be VERIFIED, not guessed. The agent-browser skill (from the skillset repo) was a no-op without the binary; it now works out of the box. - agent-browser CLI (standalone Rust, ships no browser) via npm, prefixed NPM_CONFIG_PREFIX=/usr so it survives the ~/.pi/npm-global volume. - Chromium fetched with 'playwright install --with-deps chromium' into PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/ms-playwright — a system path that the /home/developer volume can't shadow (unlike agent-browser's own ~/.agent-browser/browsers default, which WOULD vanish on recreate). - Stable /usr/local/bin/agent-chrome symlink, exported as AGENT_BROWSER_EXECUTABLE_PATH, insulates the ENV from Playwright's per-version chromium-<rev> dir name. Verified end-to-end (this session): agent-browser drives the baked Chromium headless (open + title + screenshot + eval into a WebGL SPA); doctor launch test passes in ~0.5s. Debian trixie --with-deps resolution verified (exit 0; t64 lib renames handled). hadolint clean; check-base-hash OK (only *_VERSION args added). Cost ~960 MB (Chromium + headless shell). Base-affecting → rebuilds base-<hash> on next release.	2026-07-17 16:12:47 +02:00
joakimp	71b12a9ed4	docs(skill): note macOS NFD-filename gotcha for dscp/scp ... Accented filenames on a macOS host are stored decomposed (NFD), so a precomposed (NFC) remote path in scp/dscp silently fails with 'No such file or directory'. Document the wildcard / list-first workaround in the pi-devbox-environment skill, next to the dssh/dscp alias table. (Hit while copying a screenshot named 'Skärmavbild ….png' from the host.)	2026-07-17 13:06:22 +02:00
joakimp	fb49828826	base: add pi-devbox-version command + startup banner ... Wraps /etc/pi-devbox/build-manifest.json (already written at docker-build time in Dockerfile.variant) into a human-readable summary instead of requiring users to know the manifest path and pipe it through jq themselves. - rootfs/usr/local/bin/pi-devbox-version: human (default) / --json / --quiet output modes. Also flags live drift — compares the baked pi_version against the actually-running `pi --version` and warns on mismatch rather than trusting the manifest blindly (same ground-truth philosophy as the manifest generation itself). Exits 1 with a short stderr notice on images built before the manifest existed, instead of failing silently. - entrypoint-user.sh: calls it as the very first line. CMD is `bash -l` with tty:true in compose, so this banner lands directly above the first prompt on container start — no separate motd/bashrc hook needed (deliberately not wired into .bash_aliases, which would reprint on every docker exec -it). - Dockerfile.base: COPY + chmod, same pattern as dot-watch/studio-expose. - scripts/smoke-test.sh: 4 new checks (binary present+executable, human output has release tag, --json round-trips the manifest, --quiet is a single line). - README.md / AGENTS.md / CHANGELOG.md updated.	2026-07-15 14:50:47 +02:00
pi	02be95ac1f	docs(changelog): note bundled pi-toolkit sonnet-5 template bump (Unreleased)	2026-07-13 23:13:24 +02:00
pi	d68674d11e	chore(release): v1.5.0 ... Roll the 7 unreleased commits since v1.4.0 into v1.5.0 (minor — significant base additions: readable Neovim true-colour, broad terminal terminfo support). Also includes: typst PDF template font fix, .claude gitignore seed, pi-studio semver-tag pin + version label, and repo hygiene (LICENSE, THIRD_PARTY.md, .dockerignore, hadolint lint, IDEAS backlog). No pi bump — CI resolves latest pi from npm at build time as usual. v1.5.0	2026-07-13 18:56:51 +02:00
pi	8c27894cf2	base: support modern terminals (ncurses-term + xterm-ghostty alias) ... The base only shipped ncurses-base (xterm-256color, tmux), so SSHing in from WezTerm/Alacritty/foot/Ghostty degraded to a dumb TERM fallback. Following the maintainer's ansible common role: - Dockerfile.base: install ncurses-term (terminfo for wezterm, alacritty, foot, st, base ghostty entry, and many more). - rootfs/.../terminfo-src/ghostty.terminfo: thin xterm-ghostty alias (use=ghostty) — Ghostty connects as TERM=xterm-ghostty, which no distro packages. Compiled into the system db with 'tic -x'; build asserts it resolved via infocmp. - kitty (xterm-kitty) already covered by kitty-terminfo; iTerm2 uses xterm-256color (ncurses-base). - smoke-test: assert ncurses-term emulators + xterm-ghostty alias resolve. Validated end-to-end in a throwaway container: ncurses-term brings the entries, the alias compiles and equals the ghostty capability set. hadolint clean, bash -n OK. Base-affecting, rebuilds base-<hash>. No tag.	2026-07-13 18:45:38 +02:00
pi	291ae5345e	repo: add LICENSE, THIRD_PARTY.md, .dockerignore, hadolint lint, IDEAS backlog ... Repo/CI hygiene batch (none base-affecting; image contents unchanged): - LICENSE: actual MIT file (repo previously declared MIT only in prose). - THIRD_PARTY.md: notes bundled software + licenses (pi/pi-fork/pi-obsmem/ pi-studio MIT, gosu Apache-2.0, Debian packages under their own terms). - .dockerignore: trims build context to what the Dockerfiles COPY (rootfs/ + entrypoint*.sh); keeps .git/docs/scripts/compose out. Verified it excludes none of the required COPY sources. - lint.yml: new hadolint job (pinned v2.14.0) lints both Dockerfiles; .hadolint.yaml grandfathers deliberate choices (DL3008/DL3016/DL4006/DL3003/ SC2086, mirroring the shellcheck excludes), fails on anything new at warning+. Verified hadolint exit 0 and the repo shell-guard passes with the new job. - IDEAS.md: parks deferred follow-ups (SHA-pin actions, trivy, buildx SBOM/ provenance, Makefile, renovate). - README/DOCKER_HUB License sections now link LICENSE + THIRD_PARTY.md. No tag.	2026-07-13 18:20:44 +02:00
pi	38d8832d34	ci: record pi-studio version as image label ... Adds se.jordbo.pi-devbox.pi-studio-version (e.g. v0.9.36) alongside the existing SHA label, so 'docker inspect' shows the human-readable version. Plumbing: resolve-versions exposes studio_tag output -> both studio build steps pass --build-arg PI_STUDIO_VERSION -> Dockerfile.variant declares ARG PI_STUDIO_VERSION=none and emits the LABEL. Studio-variant only. Validated: yq parse OK, resolve run-script bash -n OK. No tag.	2026-07-13 17:59:59 +02:00
pi	32586f19e7	ci: pin pi-studio to newest semver tag, not main HEAD ... Upstream omaclaren/pi-studio stopped publishing GitHub Releases at v0.5.55 but keeps tagging every version (v0.9.36 now) and pushing to main. Tracking main HEAD risked baking half-finished commits that land after a tag. resolve-versions now lists all tags via a single git ls-remote (the REST tags API paginates at 100 and the repo has >140 tags, so a single page can miss the newest), picks the highest X.Y.Z with sort -V (pre-releases excluded), and peels it to a commit SHA for PI_STUDIO_REF. SHA (not moving tag) keeps cache-busting + reproducibility; require_sha still enforced. Studio-variant only, not base-affecting. No change to the resolved commit today (v0.9.36 == current main HEAD). Validated: yq parse OK, bash -n OK, live git ls-remote -> v0.9.36 -> 2ef38ef. No tag.	2026-07-13 17:54:56 +02:00
pi	aaf1be0bcb	base: readable Neovim colours out of the box (termguicolors + kitty-terminfo) ... Vanilla Neovim fell back to a 256-colour palette over ssh/kitty and rendered strings/comments in a muddy, low-contrast colour. Fix, all base-affecting: - rootfs/etc/xdg/nvim/sysinit.vim: system vimrc enabling termguicolors. Loads for every user before any personal ~/.config/nvim; overridable per-user. - Dockerfile.base: install kitty-terminfo (TERM=xterm-kitty understood; lets Neovim auto-detect true colour) and set ENV COLORTERM=truecolor. - smoke-test.sh: assert xterm-kitty terminfo present and nvim tgc default on. - CHANGELOG (Unreleased/Added) + README editor note. No tag — lands on the next base-<hash> rebuild.	2026-07-12 23:19:19 +02:00
pi	92212fa447	base: seed global gitignore with .claude/settings.local.json ... Claude Code's per-machine local settings can carry credentials and should never be committed. Add the pattern to the seeded ~/.gitignore_global so fresh containers match a host global that already ignores it. Existing containers are unaffected (seed copied only when absent). Base-affecting; rebuilds base-<hash>.	2026-07-11 22:29:28 +02:00
pi	3d46c6615e	fix(base): default pandoc typst template font so PDF export works without -V mainfont ... pandoc's bundled typst template defaults the document font to an empty tuple (font: ()), so a naked `pandoc --pdf-engine=typst` fails with "font fallback list must not be empty". Patch the template default to Libertinus Serif (typst's own bundled default) at build time so PDF export works out of the box. Document usage in README and note the fix in CHANGELOG (Unreleased). Base-affecting.	2026-07-11 20:55:50 +02:00
pi	fa6e9dc9d6	release: v1.4.0 — typst PDF engine + host SSH startup check ... Finalize the Unreleased batch as v1.4.0 (minor — significant base additions). Base rebuilds (Dockerfile.base for typst/xz-utils; .bash_aliases for the SSH check). pi auto-resolves latest (0.80.3 -> 0.80.6); mempalace stays 3.5.0 (current). v1.4.0	2026-07-11 17:15:11 +02:00
joakimp	bd0627a557	docs: note host SSH startup check in CHANGELOG Unreleased	2026-07-11 17:07:55 +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
joakimp	4563b4d76d	feat: warn at shell startup if Mac host SSH is not reachable ... Adds a _devbox_check_host_ssh() check to ~/.bash_aliases (baked into the image). On first bash session of each container it tries a quick SSH probe to the Mac host; if it fails it prints a clear one-time warning with the exact two steps needed to fix it: 1. Enable Remote Login in macOS System Settings 2. echo '<public key>' >> ~/.ssh/authorized_keys The check is guarded: - only runs inside a container (/.dockerenv) - only when the jump key exists (~/.ssh-local/devbox_jump_ed25519.pub) - only once per container lifetime (/tmp flag, cleared on recreate) After --force-recreate the key changes, the flag is gone, and the check runs again on the first bash window. Subsequent windows are silent.	2026-07-11 15:26:23 +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
pi	6002c6299d	release: v1.3.0 — shared/external MemPalace + nano/micro editors + CI lint ... Promotes the Unreleased block to v1.3.0. Bundled contents: - feat: shared/external MemPalace — mempalace.ts bridge honours MEMPALACE_REMOTE_URL; adds docker-compose.mempalace.yml. - feat: nano + micro non-modal editors (Dockerfile.base → base rebuild). - ci: lint.yml (sh-vs-bash guard + actionlint/shellcheck), docker-publish.yml bash defaults, promote-base-latest shell fix. pi stays 0.80.3 (== npm latest). Base rebuilds (mempalace-toolkit ref advanced + Dockerfile.base nano/micro), so the new bridge + editors land in base-<hash>. v1.3.0	2026-07-02 14:50:17 +02:00
pi	d73bf2e9d3	feat: optional shared/external MemPalace via MEMPALACE_REMOTE_URL ... Wire the shared-palace option (implemented in mempalace-toolkit's mempalace.ts) into the container: - .env.example: document MEMPALACE_REMOTE_URL / MEMPALACE_REMOTE_TOKEN (env_file-only, per this repo's convention). - docker-compose.mempalace.yml: optional shared server (mempalace-mcp --transport http), loopback-bound by default. - docker-compose.yml: local-vs-external note on the palace-volume comment. - README + CHANGELOG (Unreleased).	2026-07-02 13:09:29 +02:00
pi	3a59e15563	feat: ship nano + micro (non-modal editors) alongside nvim ... The image shipped only nvim (EDITOR=nvim), a modal vi-style editor. Not everyone is comfortable with vi keybindings, so add both a classic and a modern non-modal option: - nano (apt): ~2.8 MB installed; deps (libc6, libncursesw6, libtinfo6) already present via nvim/less/htop/tmux, so no extra packages pulled in. - micro: ~12 MB single static Go binary from GitHub releases (same pattern as bat/eza/zoxide). Desktop-style keys (Ctrl+S/Ctrl+Q), mouse, syntax highlighting. ARG MICRO_VERSION pins; defaults to latest. Combined ~15 MB (<0.5% of the ~3.2 GB image). EDITOR stays nvim; both new editors are opt-in (export EDITOR=micro | nano). Uses the canonical micro-editor/micro URL because the old zyedidia/micro org rename makes /releases/latest redirect to another /latest, defeating the tag-parsing latest-resolution idiom. Base-image change, so it lands on the next base-<hash> rebuild. Updates README tool table + EDITOR note, CHANGELOG (Unreleased/Added), and smoke-test.sh (nano + micro presence checks).	2026-07-01 23:11:25 +02:00
pi	d1db595f17	ci(lint): pass explicit workflow paths to actionlint ... actionlint's no-arg project auto-detection looks for .github/workflows and hard-fails (exit 3, 'no project was found') on this .gitea/workflows layout — observed on run 420. Glob the workflow files explicitly. The Gitea shell guard step already passed in that run; only the actionlint invocation needed the path fix.	2026-07-01 22:06:40 +02:00
pi	26384fe9f1	ci: eliminate the sh-vs-bash footgun class (defaults + lint guard) ... Root cause of the recurring 'Illegal option -o pipefail' failures (ed49b8d resolve-versions; b7197e8 promote-base-latest, run 418): docker-publish.yml had no workflow-level default shell, so Gitea's sh/dash default applied and every bash-syntax step had to individually remember 'shell: bash'. - docker-publish.yml: add 'defaults: run: shell: bash' — fixes the whole class; all pre-existing dash steps are POSIX so bash runs them unchanged. - lint.yml: new workflow, runs on every push/PR (not just release tags): * scripts/check-workflow-shell.sh — Gitea-accurate guard: fails if any run: step doesn't resolve to bash. Catches the omit-shell+bash-syntax case that actionlint MISSES (actionlint models GitHub, where the default shell is bash, so a shell-less step is assumed bash). * actionlint + shellcheck — catches explicit 'shell: sh' + bash syntax (SC3040) and general workflow errors. Verified locally: guard + actionlint pass current workflows; guard fails a synthetic omit-shell+pipefail workflow; shellcheck clean.	2026-07-01 22:05:04 +02:00
pi	b33e9dc592	fix(ci): promote-base-latest re-tag step needs shell: bash (set -o pipefail) ... b7197e8 moved the digest-compare into the re-tag step with 'set -euo pipefail' but no 'shell: bash'; Gitea's default sh (dash) aborts on -o pipefail, leaving base-latest un-promoted on the v1.2.4 release (run 418). Same footgun as ed49b8d. Consumer tags unaffected (they FROM base-<hash>, not base-latest).	2026-07-01 17:57:13 +02:00
pi	3cdc2069db	release: v1.2.4 — pi 0.80.2 → 0.80.3; global gitignore, env_file-only secrets, promote-base-latest CI fix v1.2.4	2026-07-01 16:49:25 +02:00