18 Commits

Author	SHA1	Message	Date
Joakim Persson	12f99c49e3	docs(v1.10.0): adopt pi's fullscreen default and document the way back ... Decision: keep pi 1.0.0's default (tuiMode "fullscreen"). No tuiMode is baked, so the image follows upstream rather than pinning the fleet to either mode - but "we inherited a changed default" is only acceptable if the revert is written down, so it now is. README gains a "Terminal UI mode" section ahead of the pi-atelier section, because the two interact. It gives all three scopes, taken from pi 1.0.0's own docs/settings.md and docs/cli.md rather than from the changelog prose: - permanent: "tuiMode": "regular" in ~/.pi/agent/settings.json - one session: pi --tui-mode regular (the flag is real: cli.md:221) - one project: the same key in .pi/settings.json, which overrides the agent directory It also documents the four related settings (fullscreenExitOutput, fullscreenScrollbar, fullscreenCopyOnSelect, fullscreenWheelScrollLines) and two things specific to this image: - tmux: fullscreen uses the alternate screen, so tmux copy-mode shows the pane history AROUND pi, not pi's transcript. That is the concrete reason someone here would want "regular" back. - fullscreenWheelScrollLines "auto" behaves differently over SSH (caps fast wheel spins at 6 lines/event) than in a local macOS terminal (1 line) - worth naming because this container is normally driven over SSH. - pi-atelier works in BOTH modes (upstream has handled regular vs fullscreen renderers separately since pi 0.84), so reverting costs nothing. Stated so nobody assumes the sidebar is the price of the old scrollback. The python3 merge snippet in that section was RUN before being documented: against a realistic settings.json under an overridden HOME, twice, confirming it is idempotent and preserves sibling keys including nested objects and the _comment fields the seeded file uses. Documented code that has never been executed is a guess. DOCKER_HUB.md gets a short version of the same note, because CI reads it from the TAG and POSTs it to Docker Hub as full_description - a behaviour change this visible should not require reading the repo to undo. Gates: doc-drift 23 OK / 0 DRIFT / 0 SKIP / 0 FAIL; base-hash, workflow-shell, skill-floor, lint-shell all rc=0.	2026-10-02 09:00:51 +02:00
Joakim Persson	93eb3dbca7	docs(v1.10.0): name sqlite3/bc/dc/column in the Hub description tool list ... DOCKER_HUB.md is POSTed to Docker Hub as full_description by the update-description job, and CI reads it from the TAG, not from main. Its "Modern CLI tooling" list said "Data: jq, yq" while this release adds sqlite3, bc, dc and column to the base - so the public page would have shipped incomplete for the whole v1.10.0 cycle and the fix could not land until the next tag. Caught by the pre-tag doc sweep rather than by a gate: check-doc-drift.sh verifies version CLAIMS (pins, Node major) against the build files, but it cannot know that a hand-written feature list grew stale, because nothing declares that list's contents. Same failure shape as the v1.9.0 Node 22/24 mismatch that shipped eight releases running. README carries no equivalent list, so there is nothing to mirror.	2026-10-02 08:20:01 +02:00
joakimp	b8d818ed99	fix(docs): correct the Hub size claims, and gate them so they cannot rot again ... DOCKER_HUB.md claimed ~1.1 GB for :latest while Docker Hub served 1.37 GB -- 20% wrong, drifting quietly across eight releases, and POSTed to Docker Hub by update-description every time. It is the first number a stranger reads about this image. Root cause is structural, not carelessness: every OTHER claim check-doc-drift.sh guards is anchored to a build file (a pin, an ARG, a placeholder), so it cannot rot without someone editing the thing it describes. Nothing in this repo states the image size, so nothing measured it. Corrected against measured full_size after v1.9.2 published (amd64/arm64): :latest ~1.1 -> ~1.23 GB (1.228 / 1.211) :latest-studio ~1.15 -> ~1.25 GB (1.255 / 1.238) :base-latest ~1.0 -> ~1.17 GB (1.167 / 1.151) full_size tracks the FIRST manifest entry (amd64), not the sum across arches -- measured: full_size=1.228, amd64=1.228, arm64=1.211, sum=2.439 -- which is what the table's per-arch "Size (compressed)" column claims. New check 8 gates those claims against Hub. Fails on drift; SKIPS LOUDLY via a new skip() helper (counted, named in the summary) when curl/python3 are absent, the API is unreachable, or SKIP_SIZE_CHECK=1. A skip is deliberately neither OK nor a failure: printing an unverified claim as OK is the habit this file exists to break, and failing on Docker Hub's uptime would hold releases hostage to a third party. Not wired into hooks/pre-push, so pushes stay offline. Two bugs caught by writing the expected exit code down before running the check: 1. The tolerance would have missed its own motivating case. The percentage is computed against the MEASURED size, but the 20% first chosen came from the claim-relative figure; the real drift was |1.1-1.37|/1.37 = 19.7% and would have passed. Now 15%, inside a window with both bounds measured: above the largest legitimate skew (11.4%, a claim describing the published release while the next tag changes the size) and below the rot it must catch. 2. A `|| true` on the python invocation made the gate FAIL OPEN -- it printed DRIFT and exited 0. Removed; the outer `|| SIZE_RC=$?` satisfies set -e without swallowing the code. Verified two-sided: 19% drift exits 1 at the default tolerance and 0 at SIZE_TOLERANCE_PCT=25, so the threshold does the work rather than the ordering. NOT covered, and the script says so where a reader will see it: README.md's ~3.2 GB figures are UNCOMPRESSED and the registry exposes compressed sizes only, so measuring them needs a real pull. A green check 8 says nothing about them. Verified: check-doc-drift.sh rc=0 on the corrected tree, rc=1 on injected drift, rc=0 with --warn-only, SKIP+rc=0 on the offline path (proxy to a dead port); shellcheck clean at default severity (the sed single-quote SC2016 carries a disable with its reason); lint-shell.sh 16 files clean.	2026-09-14 20:33:40 +02:00
Joakim Persson	35964abd01	docs(hub): the Docker Hub page claimed Node v22; v1.9.0 ships Node 24 ... DOCKER_HUB.md is hand-maintained (no generator: CI only substitutes {{PI_VERSION}} and POSTs the file as Docker Hub full_description), and it was last touched at v1.8.6 -- eight releases ago. The Node claim is now false as of this release, and unlike README.md this file IS published, so a stale claim here is user-visible rather than internal. Verified countable claims rather than assuming: "7 user-facing extensions" is correct (7 files in pi-extensions/extensions/). The "29 mempalace_* tools" claim is suspect -- this session sees 45 -- but left alone because I cannot attribute that count to the baked 3.9.0 server without measuring it.	2026-09-10 21:43:17 +02:00
joakimp	93f986e90e	v1.8.6: adopt pi 0.84.3 + mempalace 3.8.0, close the v1.8.5 doc/observability gaps ... Three coupled pieces of work, all of which ride on the base rebuild that the mempalace bump forces anyway. DRIFT ADOPTED - pi 0.84.2 -> 0.84.3. Its release notes carry a "Breaking Changes" line (GoogleThinkingLevel -> GoogleApiThinkingLevel). Audited before adopting: zero references across all four vendored companions (pi-fork, pi-observational-memory, pi-atelier, pi-studio), so it is inert for us. The reason to adopt is two skill-discovery fixes that land directly on v1.8.5's vendored-skill work: nested Markdown skills inside grouping directories were not discovered, and root README.md/AGENTS.md in skill dirs were reported as broken skills. - mempalace core 3.7.1 -> 3.8.0. Additive/reliability only. Its sync fix (#2320/#2322) stops sync --apply deleting drawers whose source_file was unreachable *at that moment* -- which does NOT relax the standing landmine against sync on the shared palace, because that landmine is about paths permanently absent from whichever host runs the sync. Different failure shape; the caution stands. DOCS -- three defects, one of them public - DOCKER_HUB.md advertised "neovim (LazyVim defaults)". Nothing in the image installs LazyVim; the only nvim config is a 19-line sysinit.vim. CI PATCHes this file into the Docker Hub description on every release, so this was a false claim published to the world. Removed. - agent-browser + Playwright + Chromium is the single largest addition in the image (~625 MB) and had zero mentions in README, DOCKER_HUB or THIRD_PARTY -- it was documented only to agents, in the AGENTS.md managed block. Now documented to humans, including the Chromium licence dimension. - typst and socat appeared in README prose but not in the "What's inside" inventory. Added. OBSERVABILITY -- the three gaps v1.8.5 listed as still open - build-manifest.json now records mempalace core, read from the live binary (ground truth, not the build ARG). Placed as a sibling of pi_version rather than inside components{}, because pi-devbox-version renders that map through [0:12] and would truncate a version string. - smoke asserts the pi-observational-memory clone actually CONTAINS the ce9fc98 auth fix, pinned to src/runtime.ts. Deliberately not a repo-wide grep: two of the three markers also live under tests/, so the repo-wide form stays green with the fix site reverted. That is the third false-green of this exact family in this repo (canary phrase in both snapshots; reconciler fixture using a non-owned name; now this) -- pin containment checks to the fix site. - smoke asserts the feeder's pi@<device> agent default behaviourally. The earlier audit concluded this needed a --print-config added upstream; it does not. AGENT is assigned before arg parsing, so `bash -x mempalace-pi-session --help` observes the real resolution with no toolkit change. Two-sided: device set => pi@<device>, unset => must not be pi@*. - pi-devbox-version now prints a palace: line with the same live-vs-baked drift detection pi already had. This matters more than it looks: mempalace is the one component that is both client (here) and server (synlig), so skew between them is a real failure mode. Degrades quietly on pre-v1.8.6 images. Deferred deliberately: a native arm64 act_runner on tor-ms22 (the current runner is on synlig, x86_64, so every arm64 layer ships QEMU-emulated). Analysis and caveats filed to the palace rather than actioned here.	2026-08-25 15:29:22 +02:00
joakimp	43cd6e22f2	v1.7.0: bundle pi-atelier at a pinned tag; pin pi to an audited 0.84.1 ... Two changes that belong together, because the first is what makes the second dangerous to get wrong. pi-atelier (TUI sidebar + status rail) is now vendored to /opt/pi-atelier at PI_ATELIER_REF=v0.8.0 and registered by entrypoint-user.sh — the pi-fork / pi-observational-memory / pi-studio pattern, deliberately NOT `pi install npm:pi-atelier`, which writes into ~/.pi/npm-global on the config volume where it shadows the image and pins nothing. Unlike its siblings it gets no `npm install`: atelier declares zero runtime deps (peerDeps only, satisfied by the baked pi) and has no build step, so pi loads its TypeScript straight from the checkout via package.json `pi.extensions`. pi is no longer resolved to npm `latest` at build time. The pin lives in Dockerfile.variant and CI reads it from there, so a local `docker build` and a CI release ship the same versions by construction. The pin is a CHECKPOINT, NOT A FREEZE: bumping stays a one-line change; what stops is *unreviewed* adoption of whatever shipped that morning, in the same build that then gets tagged and published. CI fails when a pin is not concrete or not actually published on npm, and warns — never adopts — when npm latest moves ahead, naming what to re-check. Why this pairing needed care: pi-atelier 0.6.0/0.7.0 wrap pi's PRIVATE TUI renderer, and under pi 0.84 that wrapper recurses — pi hangs at startup burning CPU with no error. Upstream fixed the recursion in 0.7.1 and restored the non-overlapping split in 0.7.2; 0.8.0 is additive on top. atelier's own peerDependencies still say >=0.80.7, which does not express that floor, so nothing in npm metadata could have warned us. The floor is therefore encoded as an executable rule — pi >= 0.84 => pi-atelier >= 0.7.1 — asserted in both smoke-test.sh (build time) and recreate-sanity-check.sh (after a real recreate), verified against a 4x4 version matrix. Existing volumes needed migration, not just vendoring: a hand-installed `npm:pi-atelier` entry is counted as already-registered by the entrypoint guard, so every existing volume would have kept its unpinned npm copy — and a 0.6.x copy next to pi 0.84 is exactly the startup hang. The entrypoint now drops that one exact string (settings.json.bak.atelier.<ts> backup, distinct prefix so it cannot clobber the template merge's backup in the same second) and lets the pinned /opt copy register. Tested against a real settings.json: only that entry removed, other packages and all keys intact, idempotent, and unparseable JSON leaves the file untouched. DEVBOX_ATELIER=0 opts out entirely — in the entrypoint rather than via `pi uninstall`, because this component's failure mode is "pi will not start", which cannot be repaired from inside pi. 0.84.1 was audited for this release, not merely adopted: theme/TUI changes are additive, the session format is unchanged (CURRENT_SESSION_VERSION = 3 in both 0.83.0 and 0.84.1 with an identical migrateV1ToV2/migrateV2ToV3 ladder, so existing transcripts are neither migrated nor at risk and pi-session-repair stays valid), and the Node engine floor is unmoved at >=22.19.0. CI resolves the atelier tag to its PEELED commit SHA — atelier uses annotated tags, so the unpeeled ref is a tag object, not a commit; pi-studio's lightweight tags never exposed that distinction. Also: docs for overriding the read-only ~/.ssh/config from the container — container-only keys in ~/.ssh-local, hardened authorized_keys, the fact that `from=` must allow the HOST's addresses because container egress is NAT'd through it, and the macOS-only-keyword trap (`UseKeychain` is fatal to Linux OpenSSH and takes out dssh/pi --ssh while the host keeps working). Corrects two claims in "Naming LAN peers": ssh-lan.conf is not ProxyJump-only, and first-time creation does need one restart because the Include is emitted only when the file already exists at start.	2026-08-07 21:34:41 +02:00
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
Joakim Persson	2abfee141b	feat: image-baked agent skills + pi-devbox-environment skill (v1.2.0) ... Ship skills inside the image (independent of any mounted skillset repo): - rootfs/usr/local/share/pi-devbox/skills/<name>/ symlinked into ~/.agents/skills/ by entrypoint-user.sh (foreign-link, survives volume recreate, never clobbers a skillset/user skill of the same name). - New pi-devbox-environment skill: persistence model, host/LAN SSH reachability, split-DNS mechanisms, interactive-vs-tool-shell alias gotcha, tmux 0-index, uv-first Python, pi-studio reachability. Agnostic to host OS / hostnames / domains / nameservers (discovered at runtime). - Dockerfile.variant appends pi-global-AGENTS.append.md onto pi-toolkit's pi-global-AGENTS.md (single global slot) so the skill is loaded proactively; gated on /usr/local/lib/pi-devbox/. Idempotent. - smoke-test: baked-skill + append-snippet + merged-marker presence and a runtime symlink assertion. - docs: README 'Agent skills' section, AGENTS.md layout, DOCKER_HUB.md; moved studio-tex roadmap to v1.3.0. pi 0.79.7 -> 0.79.10 (auto-resolved from npm latest at build).	2026-06-23 12:49:13 +02:00
Joakim Persson	a0abacaafb	fix(ssh): survive read-only ~/.ssh ControlPath; render sidecar on all host OSes ... Coordinated with the pi-extensions ssh-controlmaster fix (picked up at build via PI_EXTENSIONS_REF=main), this makes `pi --ssh <host>` and `dssh`/`dscp` robust to a user ~/.ssh/config whose per-host ControlPath points under the read-only ~/.ssh bind-mount (e.g. `ControlPath ~/.ssh/cm/%r@%h:%p`). A system default can never override a user's per-host value, so the fix lives in two layers. - setup-lan-access.sh: always render the writable ~/.ssh-local/config sidecar (Host * ControlPath redirect into ~/.ssh-local/cm + Include ~/.ssh/config) on EVERY host OS. Previously the script exited early (no-op) on native Linux, leaving dssh/dscp broken when ~/.ssh was read-only there too. The host-jump block, its key generation, and the authorize hints stay gated on VM-backed detection / DEVBOX_LAN_ACCESS=jump (new NEED_JUMP flag). - Dockerfile.base: document that the /etc/ssh drop-in default cannot override a user per-host ControlPath; cross-ref the two handling layers. - entrypoint-user.sh: correct the now-stale "no-op on native Linux" comment. - README.md / DOCKER_HUB.md: document read-only-~/.ssh ControlPath handling. CHANGELOG: v1.1.5 (Fixed + Changed + pi 0.79.6 -> 0.79.7 auto-resolved bump).	2026-06-18 21:59:18 +02:00
pi	9ebb0643c7	docs: fix drift — sync compose/volumes, studio coverage, mempalace link ... Audit found README/AGENTS carried a stale compose/volume set that diverged from the shipped docker-compose.yml (DOCKER_HUB + compose + .env.example were already consistent — README was the outlier): - README compose block + 'Volumes and persistence' table: correct volume names (devbox-shell-history not -bash-history; devbox-uv at ~/.local/share/uv not devbox-uv-tools at /opt/uv-tools — the latter would SHADOW the baked mempalace install at UV_TOOL_DIR); add devbox-ssh-local + devbox-zoxide; mark devbox-palace/-chroma-cache optional; WORKSPACE_PATH/SSH_KEY_PATH (not HOST_WORKSPACE). - README quickstart: 'compose exec -u developer' (no USER in image; bare exec lands a root shell). - README: pi-studio now 'shipped' not 'planned'; build-pipeline + tag table cover -studio + smoke-studio/build-variant-studio. - AGENTS: backward-compat volume names corrected; repo-layout bullets cover pi-studio install + studio-expose + STUDIO_EXPOSE bridge. - DOCKER_HUB: MemPalace source link -> upstream MemPalace/mempalace (matches Dockerfile.base + CHANGELOG refs). Note: the shipped v1.0.0 CHANGELOG migration note still lists the old (incorrect) volume names; left as immutable released history.	2026-06-10 23:52:17 +02:00
pi	a78e59fb5b	feat(studio): add :latest-studio variant (PR-3) ... Bundle pi-studio (omaclaren/pi-studio) as a new -studio image variant: browser prompt editor, KaTeX/Mermaid preview, tmux-backed literate REPLs, /studio command + studio_* agent tools. - Dockerfile.variant: INSTALL_STUDIO + PI_STUDIO_REPO/REF args; vendor pi-studio to /opt/pi-studio (no build step — prebuilt client in git; npm install --omit=dev for 3 prod deps). STUDIO_PORT=8765 advisory. - entrypoint-user.sh: register /opt/pi-studio via the existing pi install local-path loop (auto-skips in non-studio variant). - smoke-test.sh: auto-detected studio assertions (clone + prebuilt client + pi install registration). - CI: resolve PI_STUDIO_REF to a SHA; independent smoke-studio + build-variant-studio jobs that gate ONLY the -studio tags, so a studio failure never blocks the core :latest release. - README: 'Using pi-studio' section documenting the container access reality — pi-studio hard-binds 127.0.0.1 (index.ts .listen(port, '127.0.0.1'), no --host flag), so -p publish alone can't reach it. Documents host-networking and loopback-bridge paths, the remote ssh -L forward, and the mosh caveat (no port forwarding; run parallel ssh -L). - CHANGELOG/AGENTS/DOCKER_HUB updated. Will tag as v1.1.0 (minor). No tag created — stopping for review.	2026-06-10 23:15:29 +02:00
pi	efd254f4e6	docs: rewrite DOCKER_HUB.md for v1.0.0 reality + auto-inject pi version ... The Hub description still described the pre-v1.0.0 reality (tags follow pi npm version, builds FROM joakimp/pi-devbox:base-pi-only, opencode- devbox lineage as source of truth) — none of that has been true since v1.0.0 decoupled. End users on Hub got a misleading story. DOCKER_HUB.md changes: - Versioning section rewritten: semver from v1.0.0, with a deprecation note for the pre-v1.0.0 v{pi_version}[letter] scheme. - New 'Build pipeline' section briefly explains the two-phase base/variant content-addressed structure so users understand what base-<hash> and base-latest tags are for. - New 'Document and image tooling' section (pandoc, graphviz, imagemagick) added since these are new in v1.0.0 and broadly useful. - Tealdeer noted (vs the old Node tldr). - Tmux 0-indexing called out (relevant for future :latest-studio variant). - Removed all 'pi-only build' / 'FROM base-pi-only' / 'opencode-devbox bakes the pi version' framing — pi-devbox is now self-contained. - New {{PI_VERSION}} placeholder in 4 locations so the Hub description always shows which pi is in :latest. Workflow change: - update-description step now substitutes {{PI_VERSION}} placeholders in DOCKER_HUB.md before sending to Hub. PI_VERSION comes from the resolve-versions output (same one baked into the image), so the page and image can never disagree. Sanity-check fails the step if any unsubstituted placeholder remains.	2026-06-10 12:34:37 +02:00
pi	03629cdac7	refactor: build FROM joakimp/pi-devbox:base-pi-only (Option B) ... The pi-only building block now lives in this repo as the internal base-pi-only tag (produced by opencode-devbox CI from Dockerfile.variant, INSTALL_OPENCODE=false) instead of opencode-devbox:latest-pi-only — so an 'opencode-devbox' tag never ships without opencode. - Dockerfile: BASE_IMAGE default joakimp/opencode-devbox:latest-pi-only -> joakimp/pi-devbox:base-pi-only. - Updated README, AGENTS, DOCKER_HUB, docker-compose, CHANGELOG. - Single source of truth unchanged (opencode-devbox/Dockerfile.variant); publish ordering + EXPECTED_PI_VERSION smoke guard unchanged.	2026-06-03 17:04:21 +02:00
pi	1d1283f942	refactor: FROM opencode-devbox:latest-pi-only (lean, no opencode) ... Re-point the re-brand at the new pi-only variant instead of with-pi, so pi-devbox stays a lean pi-focused image (no opencode) while the pi install logic still lives in one place upstream. This keeps pi-devbox meaningfully distinct from opencode-devbox:latest-with-pi. - Dockerfile: BASE_IMAGE default -> joakimp/opencode-devbox:latest-pi-only. - smoke-test.sh: size threshold 2900 -> 2750 MB (pi-only = with-pi minus opencode's ~145 MB binary). - Docs (README/AGENTS/DOCKER_HUB/CHANGELOG/docker-compose): drop the 'also contains opencode' notes; describe pi-only basis and the distinction from with-pi. Publish ordering unchanged: release opencode-devbox first so latest-pi-only carries the target pi version, then tag here (smoke asserts pi --version).	2026-06-03 16:14:05 +02:00
pi	c139be326f	refactor: re-brand the opencode-devbox with-pi variant (single source of truth) ... pi-devbox no longer installs pi itself. The Dockerfile is now a thin FROM joakimp/opencode-devbox:latest-with-pi (overridable via BASE_IMAGE), inheriting pi + pi-toolkit + pi-extensions + pi-fork (fork) + pi-observational-memory (recall) + the LAN-access helper + all base tooling from the single source of truth. Eliminates the install-logic duplication that drifted against opencode-devbox/Dockerfile.variant (decision #3). Consequences (documented in CHANGELOG/AGENTS): - The image now ALSO contains opencode (with-pi has INSTALL_OPENCODE=true). A leaner pi-only image would need a dedicated pi-only variant upstream. - Publish ordering: release opencode-devbox first so latest-with-pi carries the target pi version, THEN tag this repo. The smoke test asserts pi --version matches the tag (EXPECTED_PI_VERSION) and fails loudly if the base is stale — turning the version coupling into an enforced ordering guard. CI: drop PI_VERSION build-arg (Dockerfile installs nothing); keep tag->version resolution to feed the smoke base-freshness guard. Smoke adds fork/recall clone + node_modules + settings.json registration checks; size threshold 2200 -> 2900 MB (now tracks with-pi). Docs updated across README, AGENTS, DOCKER_HUB, .env.example, docker-compose.	2026-06-03 15:51:41 +02:00
joakimp	973c2efd5c	Expand README + tweak DOCKER_HUB.md for users not cloning the repo ... README rewrite: - Two quick-start paths: 'no git clone' (curl docker-compose.yml + .env.example) and 'with git clone' for hackers/forkers - New 'Authentication' section with subsections per provider (Anthropic, OpenAI, Gemini, AWS Bedrock static, AWS Bedrock SSO). AWS SSO path documents the ~/.aws bind-mount. - Persistent state expanded: 5-row volume table + optional volumes table. Annotated what survives what. - Configuration reference: full .env table. - Versioning, building from source (with build args table), troubleshooting FAQ, related projects, license. - 11 kB total — comprehensive but readable. DOCKER_HUB.md tweaks: - Quick-start now has a 'no git clone' path (curl two files), pointing users at the gitea README for the full setup guide. The git-clone path was overkill for the 90% case (just want to docker run). - Explicit link to gitea README at the end of the quick-start block.	2026-05-15 17:58:06 +02:00
joakimp	5d472bd41f	DOCKER_HUB.md: expand from stub to full Hub description ... Replace the 1-line placeholder with a proper Hub README: image variants table, quick start (docker run + docker compose), inherited-from-base + added-by-pi-devbox feature lists, versioning scheme, persistent volumes table, user-installed pi packages note, source links. Already PATCH'd live on Docker Hub manually — this commit keeps the in-repo file in sync so the next tag-triggered update-description job won't roll it back to the stub.	2026-05-15 08:47:23 +02:00
joakimp	7b634605b7	Initial commit: pi-devbox v0.74.0 ... pi coding-agent container built on opencode-devbox:base-latest. Includes Dockerfile, docker-compose, CI workflow, smoke-test, README, CHANGELOG, AGENTS.md.	2026-05-14 19:57:17 +02:00