165 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
joakimp	495b7e3859	vendor: resync mempalace skill snapshot to skillset a12fe5e ... scripts/vendor-mempalace-skill.sh, real refresh not --check: skillset moved 6eb20af -> a12fe5e (mermaid-diagrams cutU normalisation, and the from_agent identity rule this same release ships in RFC 003). --check reported stale-but-truthful (exit 0, the sanctioned skip) but this release's point is getting today's fixes live fleet-wide, and the base rebuild is already forced by the entrypoint change and the floating mempalace-toolkit ref moving -- so the incremental cost of also bumping this pin is zero. Phrase canary in scripts/smoke-test.sh unaffected: neither pinned phrase ('Provenance is stamped for you' present, 'Attribute what you file yourself' absent) is in the section that changed; both verified still correct in the new snapshot.	2026-08-27 23:36:03 +02:00
joakimp	45850bc973	entrypoint: put back the shell state a recreate eats ... cli_utils' install.sh reaches PATH by symlinking bin/ into ~/.local/bin. That is persistent on a host and ephemeral in a container, so the same installer produced opposite durability and every --force-recreate sent the human back to typing /workspace/cli_utils/bin/git-status-all. Re-link at start instead, and add a per-device boot hook so the next question of this shape needs no image change at all. Symlinks rather than a PATH edit in an rc file, deliberately: ~/.local/bin is already ahead of /usr/local/bin in ENV PATH, so links resolve in NON-interactive shells too (docker exec, agent tool shells, scripts). An rc-file PATH edit cannot reach those because ~/.bashrc returns early when not interactive — measured, that asymmetry is exactly why `command -v git-status-all` failed in one shell and worked in another on the same box. Shell FUNCTIONS remain the sourced file's job; a symlink cannot carry them. Guards, because ~/.local/bin is shared: a real file is never clobbered, a symlink pointing elsewhere is never stolen, ours are refreshed, and links into a cli_utils/bin whose target vanished are pruned — a dangling link on PATH reads as a broken container rather than a removed script. The hook (~/.config/devbox-shell/init.sh) adds no trust boundary: that dir is already sourced into every interactive shell by the baked bash_aliases, so it is already arbitrary code from the same owner. Only WHEN it runs is new. bash <file>, never sourced, exit status ignored, output to a log. Caught before commit, and the reason the loops use `if` bodies instead of `&&` chains: under `set -euo pipefail` a for-loop whose last command is a false test exits non-zero, and with no match the /workspace/*/cli_utils glob stays literal — so the first draft would have failed to START a container on every machine that does not have this repo, rather than merely skipping the links. Re-tested with set -e in place: no-cli_utils/empty-HOME no-op, guards, idempotence, CLI_UTILS_LINK=0, a hook that exits 7, and a hook that tries to mutate CLI_UTILS_BIN — all exit 0 with intact state. Not covered by CI: docker-publish.yml runs only on tags and lint.yml lints workflow run: steps, so neither executes this file. Validated by extracting both sections and running them against fixtures, then for real in a live v1.8.10 container. No smoke assertion added on purpose — the positive path needs a /workspace mount smoke does not have, and asserting it there would repeat the v1.8.0 mistake of a smoke check written against a stage that does not exist at run time. Moves the base hash (base-decide folds `cat entrypoint.sh entrypoint-user.sh`), so this rides along with the next tag's ~40-minute base rebuild rather than justifying a tag of its own.	2026-08-27 21:52:51 +02:00
joakimp	6891dc32b8	changelog: release v1.8.10 — deploy the scrubber, and name the check that must not be skipped ... Audited every component against upstream rather than assuming. Only two moved since v1.8.9: - mempalace-toolkit 5b8d78f -> b2b50af (ours): feeder scrubber, the symlink fix that stops it refusing to stage, hlc owed-set join, queued-delivery note, explicit MEMPALACE_MAILBOX_NOTIFY protocol modes, RFC 003 + fleet-memory docs. - pi-studio v0.9.48 -> v0.9.52 (upstream, studio variant only): 22 commits, all additive — PDF previews, hideable header, contextual side questions. No removals or renames. Its pi floor is >=0.84.3 against our exact 0.84.3 pin: satisfied, zero headroom, named as a watch item because the next floor bump breaks the studio job only, after core has already published. Verified unchanged, with dates proving they predate the v1.8.9 bake: pi 0.84.3 (= npm latest), mempalace 3.8.0 (= PyPI latest), pi-atelier v0.8.2, playwright 1.62.1 (no drift this cycle despite floating on latest), pi-fork bf702b4, pi-obsmem ce9fc98, pi-toolkit 0e1369e, pi-extensions 2022887. No breaking changes anywhere, so everything can ship in one tag. The reason for tagging now is not features. The scrubber has been live on exactly ONE device since this morning; every other device has kept staging unscrubbed transcripts into a shared palace, and cleanup after the fact is manual redaction (done twice today, with freed-page residue left behind by choice). The entry leads with the acceptance check instead of burying it, because this release's worst failure is silent: the feeder is fail-closed, so a packaging or path mistake stops the fleet's memory feed and nothing complains — refusing to stage looks exactly like a quiet session. f0bffd1 exists because that very bug was real (BASH_SOURCE reports the symlink path, not the target). First client on the new image must confirm a [scrub] summary line appears, the drawer count moves, and exit 3 did not fire. Silence is the failure signal, not success. v1.8.10	2026-08-27 17:51:46 +02:00
Joakim Persson	8a673ec143	docs: unclip the diagrams, and answer what compaction leaves behind ... Two problems reported against docs/observational-memory.md, one cosmetic and one substantive. Both turned out to be worth more than the fix. Clipping. Several boxes lost their bottom line of text in the viewer, and neither the source nor my own render showed it. Cause: Mermaid measures a node label with its own font metrics, commits to a box size, then renders that label as real HTML in a <foreignObject> — so any host stylesheet touching line-height or font-size inflates the text past a box that is already fixed, and the overflow is clipped. The error accumulates per line, which is why it always eats the last line of the tallest labels. Rejected the obvious fix after testing it rather than assuming it: %%{init: {'flowchart': {'htmlLabels': false}}}%% *is* honoured (labels switch from 16 foreignObject to 7 tspan) and clips identically, because inflated font-size inherits into SVG text too. The fix that works is a hard limit of two short lines per node, with the detail moved into prose under each diagram — one- and two-line boxes have the vertical slack to absorb inflation, three- and four-line boxes do not. The nodes were carrying paragraph-sized text; the diagrams are better for losing it. Regression harness: render every block with line-height: 1.7 !important forced onto the label HTML, screenshot, read it. That caught two survivors of the rewrite that looked fine in the clean render — a long unbreakable /opt path wrapping to a third line, and a cylinder shape whose curved bottom leaves less room than a rectangle for the same two lines. New §4, because the document explained that compaction folds the ledger and never said what that leaves in the context. Asked directly: is the session back to knowing nothing? No. A verbatim tail survives, sized by keepRecentTokens (20k) and cut only at turn boundaries; the system prompt and AGENTS.md were never in the compacted region because they are rebuilt from disk each request; nothing is deleted from disk, since compaction appends a compaction entry rather than rewriting lines; and recall keeps resolving ids whose sources left the context because it reads the full branch via sessionManager.getBranch() and never consults the context window. Repeated compaction renders from live records, not from the previous summary's prose, so there is no generation-loss spiral. Also corrects this repo's own "compaction calls no model" to the steady-state claim it actually is: with an empty ledger the hook returns nothing and explicitly declines ownership, and pi's native model-based summariser runs. Snippet quoted in the doc. And a bug shipped in the first version: §9 said the ledger entries are custom_message and specifically not custom. Exactly backwards, so the one grep that section existed to get right was the one it got wrong. Verified empirically against the live session file — 11 om.observations.recorded and 6 om.reflections.recorded, all "type":"custom", next to "type":"custom_message" entries whose customType is mempalace-mailbox and mempalace-wakeup. That is where the confusion came from, and the distinction is load-bearing rather than cosmetic: the mailbox uses the context-visible append API, om's ledger uses the invisible one. Which makes it a feature the doc now advertises — the ledger costs zero context until it is folded.	2026-08-27 14:24:19 +02:00
joakimp	cdb6fc0950	changelog: name what the floating toolkit ref will pull into the next tag ... MEMPALACE_TOOLKIT_REF=main floats and docker-publish.yml resolves it to a SHA at build time, so toolkit main moving 5b8d78f -> f0bffd1 (10 commits) ships in the next tagged image whether or not this repo has a commit. v1.8.9 adopted the rule after that shape bit twice (553d865, 5b8d78f): name the behaviour change BEFORE tagging. This is that rule obeyed rather than re-learned — the work was pushed to toolkit main earlier today and this entry was missing, which is exactly the gap that caused a cross-host misattribution in v1.8.7. Contents: the feeder-side secret scrubber (three tiers, T3 report-only after a measured 403 -> 29 false-positive calibration on 52 MB of real transcripts, fail closed); the symlink near-miss that fail-closed would have turned into a fleet-wide silent memory outage at bake time, caught before tagging; the mailbox work (hlc owed-set join, queued-until-next-turn note, explicit notify protocol modes, tmux path documented unverified); and the documentation set (RFC 003, fleet-memory.md, secret-hygiene.md). Also states what remains unscrubbed: the opencode bridge write path and the unbuilt server-side layer. No tag pushed — per the release protocol, no tag means no build.	2026-08-27 14:20:35 +02:00
Joakim Persson	14371e2da6	docs: explain the memory that runs itself, and fix a claim the mailbox falsified ... `pi-observational-memory` is baked, registered in the seeded settings.json, and handed a cheaper model than the session it serves — and the only description in this repo was five words in a feature list. Someone meeting `/om:status` or a "compacted memory" block had nothing to read that said whether to leave any of it on. New docs/observational-memory.md, 272 lines and five diagrams. Scoped by who is authoritative, so there is one copy of each claim: - Upstream (/opt/pi-observational-memory/docs/) already documents the mechanism well — concepts.md, how-it-works.md, configuration.md, including a v3 lifecycle diagram that matches the deployed code. Linked, not re-derived. - This document takes the four facts pi-devbox owns and can change: the pinned commit it bakes (v3.0.4 ce9fc98, matching build-manifest.json), the packages[] entry that decides which copy loads, the Haiku-workers-vs-Opus-session split, and the devbox-pi-config volume that makes the ledger outlive the container. - Plus the confusion this image creates by shipping two things called memory: a section contrasting it with MemPalace, on the line "observational memory keeps a session coherent, the palace keeps the fleet coherent". Placement follows the split fleet-ops states for itself — reusable mechanism is not deployment data — so a "why is this in my container" document belongs in the repo that pins and wires the component. Linked twice from the README, because until this commit the README referenced docs/ zero times and the file already sitting there was reachable only by listing the directory. Numbers were read out of the live container and the baked tree rather than out of release notes, which caught one thing the pi-extensions skill still has wrong: the dropper is gated on a successful same-turn reflection, not on a token threshold of its own. Also fixes a README sentence that v1.8.9 made false. § Cross-machine agent coordination ended with "Nothing in this image polls the log on the agent's behalf"; the mailbox has shipped since aac4a1c. Replaced with the three knobs and their defaults, derived-not-read owed-ness, and the queued-into-the-next-turn delivery measured on two devices — and dated to "as baked in v1.8.9 (mempalace-toolkit 5b8d78f)", pointing at RFC 003 §7.11–§7.12 for the mechanism, because toolkit main is already ahead (a92c75d pings the human who is not looking) and describing that here would trade a stale-behind claim for a stale-ahead one. The cause is worth more than the fix: the behaviour arrived through the floating MEMPALACE_TOOLKIT_REF, so no diff in this repo ever touched the paragraph making the claim. v1.8.9's own rule fired for the CHANGELOG and nobody swept the README. The CHANGELOG records what changed, the README asserts what is true, and only the first is reviewed at release time — so the rule now extends to grepping the README for absolute claims (nothing, never, does not, only) about a component whose SHA moved. Diagrams were verified by rendering, not by parsing. Both comparison diagrams parsed clean and rendered with their meaning reversed: Mermaid laid the second declared subgraph out first, putting "with observational memory" before "without" and MemPalace before observational memory in the diagram whose entire job was that contrast. Rebuilt as declaration-ordered chains and re-rendered at mermaid@11 — the version pi-studio pins — in the baked headless browser, then read back as an image. mermaid.parse() proves syntax and says nothing about layout.	2026-08-27 13:55:55 +02:00
joakimp	aac4a1c323	release: v1.8.9 — the version flag that blamed the wrong component ... Two versions, two flags. `--expected-version` has only ever asserted `pi --version`, but AGENTS.md step 4 spelled it `X.Y.Z` inside a checklist where every other X.Y.Z is the pi-devbox tag. Run as documented for v1.8.8 the final runtime gate of the release printed ✗ pi version mismatch: expected 1.8.8, got 0.84.3 and exited 1 — a red accusing the image of being the wrong version. Not one reader's slip: the v1.8.8 release-readiness handoff from pi@emb-7kj4vr4g propagated the same wrong spelling twice while correctly calling step 4 "not ceremonial", so two independent readers converged on it. README.md had it right all along, which means the two documents disagreed. - new --expected-image-version asserts the pi-devbox release tag, read from release_tag in /etc/pi-devbox/build-manifest.json (no checkout, no network); leading `v` optional on either side - both flags detect being handed the other one's value, and the test is exact rather than heuristic: the value is compared against the other quantity the image itself reports, so it can only fire on a real mix-up - neither flag is required now. With none, live `pi --version` is asserted against the manifest's pi_version — not a tautology, since a stale pi in the ~/.pi/npm-global volume can shadow the baked one, exactly as a stale npm:pi-atelier can in packages[] - the header note replaced was stale and load-bearing: it claimed pi is resolved from 'latest' and cannot be self-derived, while Dockerfile.variant pins ARG PI_VERSION=0.84.3 and docker-publish.yml reads that ARG as its source of truth. The same withdrawn claim also sat in cli_utils' pi-devbox-sanity --help - argument parsing: a missing value, or a value that is another flag, is a usage error instead of silently consuming the next argument; --help works All fourteen flag combinations exercised by execution, including the two manifest-absent branches and the shadowing branch a healthy container cannot reach — mutation-tested with a doctored manifest so each failure branch was observed firing rather than assumed present. CHANGELOG also names what no commit here causes: mempalace-toolkit main moved e70bef2 -> 5b8d78f, so this tag ships the auto-delivered logstream mailbox because base_tag folds the resolved toolkit SHA. It would have landed either way; going unnamed is the 553d865 shape that already caused one cross-host misattribution. Component audit found nothing else to bump — pi, mempalace, pi-atelier all equal their upstream latest, and every other floating ref resolves to the commit already baked. v1.8.9	2026-08-26 18:47:03 +02:00
joakimp	34cf1e3810	release: v1.8.8, and a notice that named the wrong remedy ... Freezes the v1.8.8 section and clears the two non-code checklist items pi@emb-7kj4vr4g handed over (evt_20260826T134919_a614ecfc2d4f), plus the two carried nits from its round-2 verification (evt_20260826T133356_d56792791a49). Every claim below was re-measured here rather than taken from the handoff. THE STALENESS NOTICE ASSERTED A DIRECTION IT NEVER TESTED — Blocker 1's shape, one layer down, in the message I added to replace the message that named the wrong cause. The notice fired on "recorded != HEAD" and then announced HEAD as the newer side without testing ancestry, so a clone that was merely BEHIND got "has moved to 82a8d3c; the snapshot describes the older 5fd0d5c" when 82a8d3c is 5fd0d5c's ANCESTOR. Found by EMB against the real state of its own host, not a fabrication. The verdict was never wrong (rc 0, nothing mis-verified) but the remedy it implies is a ~67-minute base rebuild when the actual fix is `git pull` — the only one of the two carried nits with a price tag, which is why it went first. Now tests ancestry with the merge-base --is-ancestor primitive the refresh path 60 lines below already used, and reports three verdicts: stale (refresh), clone behind (pull, do NOT refresh), diverged (reconcile). All three verified by execution; only the first was correct before. --help no longer errors on the one script whose argument order was itself a landmine. The `-s "$VENDORED"` guard is now commented as load-bearing: it makes the empty-stdin collision unreachable by construction, which also means no test below exercises it any more, so deleting it as "redundant with the probes" would silently restore the false OK. CHANGELOG: retitled, and three stale spots fixed in what becomes the permanent record. It cited the skill at 82a8d3c (twice superseded); it RE-ASSERTED the retracted mailbox measurement as live evidence 200 lines after withdrawing it, which is the exact non-contradiction failure this release exists to fix; and its warning block still described the pre-e8ddeaf world ("still records c04cd15", "now exits 1") while quoting as exemplary the very notice whose direction was unverified. Per EMB's steer the conclusion was kept and only the evidence replaced: the status filter does drop broadcast noise, it just never computed owed-ness. Honest replacement, measured on both machines: raw filter returns 2 here and 1 there, EVERY ONE already answered, derivation returns 0 for both. SNAPSHOT RESYNCED AGAIN, 5fd0d5c -> 6eb20af, because skillset 6eb20af adds the limit of my own seq ordering test: seq is REPLICA-LOCAL, equal to origin_seq only because one replica authors for all four machines, so use hlc once mesh_peers reports a peer. Recorded as reasoning not measurement — a second replica cannot be stood up here. The durable half is the asymmetry: seq skew makes an ANSWERED item resurface (noise, visible, self-correcting) while created_at SUPPRESSES AN UNANSWERED ask forever (silent, permanent), so the skill now says outright that "fixing" a resurfacing item with a timestamp trades the safe failure for the dangerous one. The resync was free: rootfs/ was already changing, so the base rebuild was forced regardless — the ordering warning about accidental staleness does not apply to a deliberate refresh before the tag. --check is a clean OK at 6eb20af with no notice, canary re-verified bidirectionally (present 3, withdrawn 0), baked snapshot 0644, tree hash recomputed at build time and re-verified in-container. bash -n clean; shellcheck/hadolint/actionlint remain absent locally, so CI is still the only evidence for those. v1.8.8	2026-08-26 15:56:03 +02:00
joakimp	e8ddeaf89f	skills: a gate that could pass without checking, and a mailbox that never empties ... Fixes the three blockers and seven should-fixes from pi@emb-7kj4vr4g's review (logstream correlation skills-provenance-review, full text in drawer_pi-devbox_reviews_e43e766641c9ec85217bc6ce). Every finding was reproduced by execution here before being fixed; two were refined by that reproduction rather than taken as given. BLOCKER 1 — the provenance gate could print OK and exit 0 without verifying. `git show <ref>:<path> | sha256sum` hashes EMPTY STDIN when the ref does not resolve, so at_ref was never empty and the UNKNOWN branch was dead code. Measured: a bogus ref reported MISMATCH — accusing the snapshot of lying when the real cause was an incomplete clone, and the operator's natural remedy for MISMATCH is to re-run the refresh, which rewrites provenance to silence the complaint; and with a 0-byte snapshot against a 0-byte upstream file it printed "OK: exactly skillset@aaaaaaa" with exit 0 for a ref that does not exist. The script already had the sha_empty idiom and had applied it to blob_sha but not to at_ref. Existence is now PROVEN with git cat-file -e before anything is hashed, at two levels (ref resolves / path exists at it) because those deserve different messages. Same defect class as the canary it replaces: a check that can succeed without checking. A second, unflagged instance of the same pipeline shape in blob_sha was found and fixed too. Exit codes split, because the old contract failed the sanctioned case: 0 truthful (including stale, with a NOTICE), 1 a lying record only, 2 cannot determine. AGENTS.md step 2 promised "the message distinguishes the two" and was the thing this branch was breaking; rewritten to state all three. BLOCKER 3 — VENDORED.md contradicted itself in the release whose stated invariant is non-contradiction: its hand-maintained provenance line named skillset 670f7f1, seven commits behind the ARG and itself the commit that told agents to hand-stamp added_by — the withdrawn instruction this work exists to stop shipping — while its cp recipe contradicted the "not cp" rule 20 lines above. Line removed (nothing forced it to move when the ARGs did); 670f7f1 kept only as a labelled cautionary example. The pi-extensions half was verified redundant (CI require_sha resolves PI_EXTENSIONS_REF) before removal. SHOULD-FIXES: `<root> --check`, the spelling VENDORED.md documented, silently ran a REFRESH because only $1 was parsed (both tools now parse all args and reject unknown ones); refresh at a detached/older HEAD silently rewound ref and bytes (now refused unless the recorded ref is an ancestor, --force to override); upstream_dirty was computed and never used in check mode; --no-skills --json printed human text and broke jq; --help was a hardcoded sed range this branch had already made stale; the fingerprint hashed SKILL.md alone so a live skill differing only in a sibling file reported "identical", and pi-extensions already ships two files, so it is now a per-skill TREE hash with the manifest field renamed skillset_snapshot_tree_sha256; the --no-skills smoke assertion was negative-only and passed on a crashed binary. mktemp+mv left files 0600 — CI was unaffected since the index records 100644, so the blast radius was local builds only, narrower than the review inferred. Snapshot resynced c04cd15 -> 5fd0d5c so the no-clone fallback carries the CORRECTED coordination protocol rather than the withdrawn one; --check is now OK with no staleness notice, and the bidirectional canary re-verified against the new bytes. Local validation is bash -n only (shellcheck, hadolint and actionlint are all absent in this container) — CI remains the shellcheck gate.	2026-08-26 14:38:07 +02:00
joakimp	49a6534093	docs: write down the coordination channel the fleet already runs on ... The logstream has carried cross-machine work since 2026-08-18 — patch handoff, review, a v1->v2 supersede — and nothing in this repo said it existed. That gap had a measurable cost this morning: another host addressed a retraction to pi@tor-ms22 by name and it was read only because the human said "read the logstream", while the agent was actively rebuilding the thing it warned about. Split by what each document is authoritative for, so there is one copy of each claim rather than three that drift: - README § Cross-machine agent coordination — what the CONTAINER needs. MEMPALACE_REMOTE_URL selects the shared palace; MEMPALACE_PI_DEVICE is what makes this machine reachable, because where every host is a thin client of one palace the stamped agent name is the only thing that distinguishes them. Stated as a rule with teeth: set both or neither, since a container missing the device var can read the log but is addressable by nobody. - AGENTS.md release checklist step 2 — the vendored-snapshot refresh, as a MECHANISM in the document a releasing agent actually reads, not a comment hoping to be noticed. It says the refresh costs a base rebuild, that skipping it is legitimate (every enrolled host reads its live clone), and that skipping it silently is not. - CHANGELOG — the three-way split itself, plus the measurement that shaped the ack contract: unfiltered, the mailbox returned 5 events, 4 of them finished broadcasts from eight days earlier; with status="open", exactly the 1 that needed an answer. Norms live in the skillset skill (82a8d3c, already live on every host that mounts the skillset — no rebuild) and mechanism in mempalace-toolkit's extensions/pi/README.md (e70bef2, which also documents the edge stamper that 553d8657 shipped undocumented). Deliberately NOT duplicated here. Consequence recorded rather than hidden: the skill edit lands in the skillset, so this repo's SKILLSET_SNAPSHOT_REF now honestly reports itself behind, and --check exits 1 with "has moved to 82a8d3c; the snapshot describes the older c04cd15". That message is also fixed in this commit — it previously blamed "the working tree" even when the tree was clean and only the ref had moved, which is the same defect class as a canary pinned to a phrase the release deleted: a message that names the wrong cause. Now distinguishes moved-HEAD from dirty-tree, verified against both plus the in-sync case.	2026-08-26 12:51:26 +02:00
joakimp	e070e0bcbf	skills: record the vendored snapshot's provenance, and report which copy wins ... Found while verifying v1.8.7 from inside a fresh container: the baked mempalace snapshot is read by no host on this fleet. devbox-skill-reconcile repoints ~/.agents/skills/mempalace at the mounted live clone (the v1.8.5 fix working as designed), and all four compose stacks mount a workspace containing the skillset. So the phrase canary that blocked v1.8.7's first tag polices a file nobody opens, while the drift that could actually mislead an agent — a git pull nobody ran in /workspace/skillset — was invisible from inside the container and is invisible to CI by construction. Record provenance instead of policing it, and move the check to where the skillset actually is: - Dockerfile.variant: ARG SKILLSET_SNAPSHOT_REF (the claim) + a sha256 of the shipped bytes measured in the manifest layer (the fact), as manifest siblings rather than components{} members, plus an OCI label. An ARG default, not a CI-resolved output: no credential for the private skillset, no change at any of the four variant build call sites, and a local docker build records what CI does. Variant-only, so no base rebuild — check-base-hash.sh scans Dockerfile.base alone, verified by running it. - pi-devbox-version: a skills: section naming baked vs live <repo> @ <sha> per vendored skill, and for mempalace whether the live copy is identical to the baked fingerprint, at the same commit with uncommitted edits, or divergent. entrypoint-user.sh passes the new --no-skills, because the banner prints before the links exist and long before the reconcile runs. - scripts/vendor-mempalace-skill.sh: refresh the file and rewrite the ref together (a cp without an ARG bump makes the manifest lie, which is worse than anonymity); --check verifies the claim against a real clone. - 5 new smoke assertions (78 -> 83), mutation-tested through the real sh -c path: 6 fabricated manifests, where a well-formed hash of the wrong file proves the two manifest assertions are not redundant; the all-baked reporting test verified to FAIL against a live-skillset environment. Reviewed mid-flight by pi@emb-7kj4vr4g over the logstream (correlation skillset-vendor-drift), which retracted its own earlier recommendation of a build-time byte-compare against skillset HEAD and supplied the better framing: the invariant is NON-CONTRADICTION, not currency. Byte parity on a fallback would have cost a resync commit plus a ~67-min base rebuild for each of the four skillset commits pushed in one evening. Its warning also found a real bug here: the script now CONSTRUCTS the snapshot from `git show HEAD:<path>` instead of copying the working tree, because a clean `git diff` says nothing about an untracked file — the one input the first draft would have recorded a false ref for. Tested: untracked, unstaged and staged-but-uncommitted all refuse, atomically. Also fixes three stale in-repo markers of the same class the canary belongs to (true when written, silently false at release): two dangling "Unreleased" pointers and a typst line still marked Unreleased five releases after v1.4.0.	2026-08-26 10:30:27 +02:00
pi	dbb78798fb	vendor: resync mempalace skill snapshot to skillset c04cd15 ... c04cd15 ('the withdrawal only holds where the bridge is live') landed after the v1.8.7 snapshot was taken, so the baked fallback was already 4 lines behind the skillset within hours of publishing. It adds the caveat this fleet is currently living in: the bridge is baked at image build, so a container on an image older than the stamping commit satisfies both env gates while stamping nothing, and hand-stamping is still the only signal a hand-filed drawer gets there. It also gives the one-line test — grep -c MEMPALACE_PI_DEVICE "$(readlink -f ~/.pi/agent/extensions/mempalace.ts)" which returns 0 on this v1.8.6 container, confirming the gap empirically. Note what this instance proves about the canary fixed one commit ago: it still PASSES on the refreshed copy, because both pinned phrases survived the edit. A phrase canary cannot detect 'older than skillset main' — only a diff can. This is the second drift in 24h and is the argument for the Still-open item (a CI job diffing this file against the skillset repo, blocked on a clone credential for a private repo). No re-pin was needed here.	2026-08-26 09:41:02 +02:00
pi	f645e6654f	smoke: fix the snapshot canary that blocked v1.8.7, and make it bidirectional ... Run 589 built the base cleanly and then failed both smoke jobs 81-passed/1-failed on 'mempalace skill snapshot is current'. That canary greps a phrase from the vendored mempalace skill to detect a stale snapshot, and the phrase it pinned was 'Attribute what you file yourself' — the heading of the hand-stamping instruction that THIS release withdraws. So it fired correctly: the snapshot changed and the expectation did not. Every publish job was skipped, so nothing reached the registry and v1.8.7 was never consumed. Rather than bump the string: * the assertion is now BIDIRECTIONAL — the new phrase must be present AND the withdrawn one absent. A one-way canary only catches half the drift: it cannot notice a re-vendored stale snapshot that happens to contain the pinned phrase. Verified against v1.8.6's snapshot, which now correctly fails. * the comment records the structural limit rather than just the fix: a phrase canary can only ever detect 'older than what I remembered to pin', never 'older than skillset main'. Only a diff against the skillset repo can do that, which is now a Still-open item — it needs a CI clone credential for a private repo, i.e. a policy decision, not a code change. Changelog consolidated: the SSH sidecar multiplexing default moves from Unreleased into v1.8.7, since the retag will sit on a commit that contains it, and the v1.8.7 summary now records the failed first attempt rather than quietly presenting the second one as the whole story. v1.8.7	2026-08-26 08:09:09 +02:00
pi	657b1ad856	ssh sidecar: default to multiplexing, as a default and not an override ... A target whose ~/.ssh/config entry never mentioned ControlMaster got no multiplexing from the sidecar (only ControlPath was supplied), so every ssh call opened a fresh TCP connection. On 2026-08-25 that produced ~12 connections to one host in 15 min and a fail2ban block that looked like an outage — the tell being that HTTPS to the same estate stayed healthy. The correctness of this depends entirely on WHERE the block goes. ssh_config is first-value-wins: ControlPath before the Include -> override (the user's value points at read-only ~/.ssh and cannot work in the container) ControlMaster after the Include -> default (an explicit per-host 'ControlMaster no' must keep winning) Force what is broken, default what is merely absent. The first draft put both in the leading block and would have silently overridden an explicit 'no'. Verified with ssh -G rather than from the man page, including the counterfactual: under the shipped layout an explicit 'no' resolves to controlmaster false while a silent host resolves to auto; under the rejected layout the 'no' host flips to auto. So the test discriminates position, not presence. Plus a sandbox render of the real script, bash -n, and shellcheck -S error (the v1.8.7 gate) clean. Effect measured on 41 real host aliases: 22 silent entries gain auto+10m, 0 overridden. Note the fleet's one deliberate opt-out is written as absence plus a comment ('# No ControlMaster — VPN means direct route'), which ssh cannot distinguish from no opinion; that host now multiplexes, which its own comment says is unnecessary rather than harmful. Skill documents the sidecar-vs-~/.ssh trap (the failure misleads: read-only ControlPath makes multiplexing look impossible rather than misconfigured) and the stale-master recovery, ssh -O check / -O exit.	2026-08-25 23:09:46 +02:00
pi	ebd0de0be2	changelog: v1.8.7 — device provenance reaches the fleet ... The provenance fix's client half lives in mempalace-toolkit, which the image clones at build time, so it only reaches the fleet through a tag. Records both routes (extension via MEMPALACE_TOOLKIT_REF folded into base_tag; vendored skill via rootfs), the three design points (stamp in the client not the agent; diary marker in TEXT because metadata is invisible to readers; solitary devbox stamps nothing), and why the allowlist is per tool (3.8.0 hard-fails -32602 on undeclared args). Carries the CI-hardening work already sitting in Unreleased, and a Still open block for the three known bounds.	2026-08-25 22:47:53 +02:00
pi	4f1aa0d0dd	skills: refresh the vendored mempalace snapshot (withdrawn hand-stamping) ... VENDORED.md's freshness model for `mempalace` is "Option 2 only — refreshed manually per release", and it had drifted since 2026-08-23. The stale snapshot still carried the instruction to hand-stamp added_by="<harness>@<device>", which skillset 73c7c8e withdrew: the pi bridge now stamps at the edge (mempalace-toolkit 553d865), and RFC 001 §7.3.2 ranks agent-side stamping ❌ worst-possible. That matters specifically for the fallback case this snapshot exists to serve — a container started WITHOUT the private skillset mounted would otherwise be the only kind of container still being taught to do it by hand.	2026-08-25 22:27:04 +02:00
joakimp	9e744d701f	lint: shellcheck the repo's own shell scripts, not just workflow run: steps ... lint.yml has shellchecked every workflow `run:` step since the dash-vs-bash incidents, but nothing had ever pointed shellcheck at entrypoint.sh, scripts/*.sh or the extensionless tools under rootfs/usr/local/bin/. That gap is not hypothetical: the skillset repo's ci-release-watcher template shipped `echo "$json" | python3 <<'EOF' ... json.load(sys.stdin)` for two months, where the heredoc IS python's stdin (no script arg) so the load hit EOF and the function silently returned nothing. shellcheck names exactly that at severity ERROR — SC2259, "This redirection overrides piped input" — and could have named it the whole time. New step in the existing actionlint job, so no second container pull: shellcheck -S error plus bash -n over every shell file, discovered as *.sh UNION a shebang scan (the glob alone misses pi-devbox-version, devbox-skill-reconcile, dot-watch and studio-expose; a shebang scan alone would miss a sourced fragment without one). Fails loudly on a zero-file match, because a green tick over an empty set is not a check. Severity chosen by measurement, not taste: -S error is 0 findings across all 11 shell files today, so the gate is green on arrival with no cleanup, while -S warning is NOT free (19x SC2088 tilde-in-quotes in recreate-sanity-check.sh plus assorted SC2016, all intentional) and would train everyone to ignore the job — the same reasoning as the SHELLCHECK_OPTS exclusions already on the actionlint step.	2026-08-25 21:11:55 +02:00
joakimp	2b8c3a4db4	ci: audit MEMPALACE_VERSION the way PI_VERSION is audited ... Closes the item v1.8.6 (and v1.8.5 before it) listed as "Still open": the palace pin was a literal string in Dockerfile.base with zero references in docker-publish.yml, while PI_VERSION had a concreteness gate, a published-on-registry check and a never-silently-adopt drift warning. resolve-versions now applies all of those to MEMPALACE_VERSION, read from Dockerfile.base so a local `docker build` and CI install the same version by construction, plus one gate pi does not need: a YANKED release is refused, because an exact pin installs one silently under PEP 592 and would have shipped a withdrawn palace client to the whole fleet. smoke gains `installed mempalace matches CI's audited pin` via a new EXPECTED_MEMPALACE_VERSION threaded into both smoke jobs. It is not redundant with `manifest mempalace_version matches the installed core`: that compares two properties of one image and cannot notice that both are the wrong version. The case this covers is a variant built FROM a cached base carrying an older pin — internally consistent, silently stale. Mutation-tested by extracting the shipped block out of the YAML and stubbing curl: 9 cases covering every gate, then once end-to-end against live PyPI. That found a real defect in the first draft — the yank message inlined a jq program inside $(...) inside a double-quoted string, where the escaping broke the filter (jq compile error) while the surrounding `exit 1` still fired: a gate that looked correct and reported garbage. Note: correcting Dockerfile.base's now-false "known gap, carried forward" comment forces a base rebuild (~67 min) on the next tag. Leaving a comment asserting the audit does not exist was the worse option.	2026-08-25 20:33:19 +02:00
joakimp	cb7b8ad2ae	smoke: assert manifest VALUES, not the presence of field names ... Four build-provenance assertions grepped the manifest for a field name and never looked at the value: run_expect "manifest records pi_version" "cat …manifest.json" '"pi_version"' which passes on {"pi_version": ""} and on {"pi_version": null}. The tell was in its own passing output the whole time — `✅ manifest records pi_version (got "pi_version")` echoes the key back as the thing it claims to have found. Found while reading run 579's smoke log to confirm v1.8.6's new assertions had really executed rather than merely gone green. Now checked against values, and against ground truth where it exists: - every required component key present, naming the one that vanished - every component value a full 40-hex SHA (null allowed for pi-studio alone, which is legitimately absent in the non-studio variant) - pi_version equal to `pi --version`, mirroring the mempalace ground-truth check - release_tag non-empty; source_revision 40-hex and build_date ISO-8601 *when populated*, since both default empty on a plain local `docker build` and demanding them would fail honest local smoke runs - --json compared byte-for-byte with the file, which is assertable because that mode is a verbatim cat; the old form grepped its output for "release_tag" Key presence and value shape are deliberately SEPARATE assertions: a single "all values are valid SHAs" loop passes vacuously on components:{}, because jq's all() over an empty list is true. Combining them would reproduce the same shape of hole as the three false greens already recorded in CHANGELOG.md. Dropped `manifest has no unresolved ('unknown') components`: the 40-hex check strictly subsumes it ("unknown" is not 40-hex, and only rev() emits it, feeding components{} exclusively). Removed rather than kept, because a check that can no longer fail independently is one more green tick that means nothing. Mutation-tested twice rather than reasoned about: nine fabricated manifests through the raw jq filters, then twelve through the shipped assertions using the real `run` helper's `sh -c` quoting path — the quoting is load-bearing, since a jq filter dying on a quoting error exits non-zero and looks exactly like a caught defect. Measured on the same twelve defects: old caught 3, missed 9; new catches 12. Three legitimate variations stay green (empty source_revision, empty build_date, null pi-studio). Also corrects a factually wrong "Still open" bullet in the released v1.8.6 entry, which claimed pi-devbox-version's human output does not show mempalace_version and that only --json surfaces it. Both halves are false: it prints a `palace:` line with live-vs-baked drift annotation, verified against fabricated manifests (match, skew, and pre-v1.8.6 absent-field cases). Left as a struck-through correction rather than deleted, since v1.8.6 is published.	2026-08-25 17:15:39 +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. v1.8.6	2026-08-25 15:29:22 +02:00
joakimp	26f223568d	.env.example: document MEMPALACE_PALACE_PATH and why nothing exports it ... The only MemPalace variable the template never mentioned, and the one that moves the feeders' stage as a side effect: the palace root resolves as $MEMPALACE_PALACE_PATH -> $MEMPAL_PALACE_PATH -> ~/.mempalace/config.json -> ~/.mempalace/palace, and the stage is derived from it (<palace-root>/pi-stage). The comment states that precedence, records why neither the image nor the entrypoint exports it (pinning the palace without carrying the stage along re-creates the split a shared root removed, v1.8.2), warns that a stage whose persistence differs from the palace makes a scoped `mempalace sync` prune conversation drawers whose dedup key is the staged path, and notes it is a path INSIDE the container unlike the host-side WORKSPACE_PATH/SSH_KEY_PATH above it. Found while auditing a live host whose .env sets it redundantly to the default value.	2026-08-23 23:27:42 +02:00
joakimp	01abda3456	v1.8.5: the skillset owns its skills, and a dangling link no longer kills boot ... No pin moved except mempalace-toolkit fd8b15f5 -> 0fe64c4 (feeder defaults --agent to pi@$MEMPALACE_PI_DEVICE, so hand-filed palace writes carry provenance; $USER remains the fallback when the var is unset). pi 0.84.2 and mempalace 3.7.1 are still upstream-latest, atelier v0.8.2 keeps the >=0.7.1 floor for pi >=0.84, and om master is still ce9fc982 -- nothing landed after the merge that fixed the eight-week silent-observation bug. Expect a full multi-arch base rebuild: entrypoint-user.sh, rootfs/** and the resolved toolkit SHA all feed the base hash. v1.8.5	2026-08-23 21:00:21 +02:00
joakimp	b5810654f6	skills: let the skillset own the skills it owns, and stop a dangling link from killing boot ... Baked skill links won over the live skillset clone for all three vendored skills, so a pushed edit to skills/mempalace/SKILL.md was invisible in every container until the next image build -- measured on two hosts (live md5 129bcc4752 vs baked 5236024fef). Cause was ordering, not intent: the baked links are created early with a create-only-when-absent guard to close a smoke readiness race, and the skillset deploy runs last and treats them as foreign. The comment claimed the opposite of the behaviour. The fix is not "skillset always wins". Ownership is per-skill: pi-extensions is owned by its package repo and copied over the snapshot at build time, so the skillset's lagging duplicate must keep losing; pi-devbox-environment is authored here. Only mempalace is skillset-owned. devbox-skill-reconcile therefore runs after the deploy and repoints only the names in skills/skillset-owned.txt, replacing a link solely when it points into the baked tree, so a real directory or a link pointing elsewhere is never disturbed. Precedence is now user override -> live clone (owned names) -> baked snapshot, with the early links intact as the fallback so the readiness race stays closed. Reviewing that turned up a latent boot-abort in the pre-existing baked-link block: `[ ! -e "$link" ]` is TRUE for a dangling symlink, so once a link can point into /workspace/skillset, a vanished mount makes plain `ln -s` fail with "File exists" -- and under `set -euo pipefail` that aborts container start before `exec "$@"`. Reachable on `docker restart` or a host reboot, not on a recreate, since ~/.agents is not a volume on any host. Now `ln -sfn`, which heals the link back to the baked fallback. Smoke additions cover what let this ship: the stale-snapshot canary grepped a phrase present in BOTH the stale and fresh copies, so it passed throughout; it now pins the newest section. Link targets are asserted, not just `test -L`; the owned-list content is asserted both ways; and the reconciler's replace path -- which no CI container exercises, since none mounts a skillset -- is covered by fabricating one. A mutation test showed the obvious three assertions still pass with the "is this link ours?" guard deleted, so a discriminating case was added: an owned name whose link is a user override outside the baked tree. Also refreshes the mempalace snapshot to skillset 670f7f1 (without it the fix helps only hosts that mount skillset) and corrects README, which documented the old, wrong precedence in three places. Verified with 12 fixture cases plus 2 mutants: ownership respected against the real trees, user overrides preserved, relative/trailing-slash/CRLF/space/glob inputs handled, dangling link healed, read-only skills dir exits 0, idempotent.	2026-08-23 20:59:14 +02:00
Joakim Persson	4f6f470518	changelog: file the vendored-skill shadowing bug for v1.8.5 ... ~/.agents/skills is asymmetric: the three pi-devbox-specific skills resolve to the baked copies while all others resolve to the live skillset clone. Root cause is ordering in entrypoint-user.sh -- baked links are created early (line 65) with a create-only-when-absent guard, and the skillset deploy runs last (line 387) and leaves them alone as foreign links. The comment at line 61 states the intent as protecting the skillset skill from being clobbered, but the effect is the reverse. Cost measured on two hosts: a pushed edit to the mempalace skill (live md5 129bcc4752) was invisible to both containers, which kept loading the baked copy (md5 5236024fef). Editing those three skills appears to work and silently does nothing until a rebuild. Filed as a known issue with a proposed fix rather than fixed here: changing symlink precedence is image behaviour and wants its own review plus a smoke assertion, and the early-link ordering exists to close a readiness race that must not regress.	2026-08-23 20:05:38 +02:00
Joakim Persson	fbc1f86612	docs: a negative result is usually your own filter (skill + AGENTS.md) ... Three false negatives in one session, all self-inflicted, all convincing because the command "succeeded": a `| head -20` proved an SSH peer absent that sits at line 454 of a ~500-line config; `ssh mac 'docker ps'` proved the host had no Docker, when the non-interactive PATH simply lacks /usr/local/bin; and `grep 'ssh '` proved no ControlMaster was running, when those processes rename themselves to `ssh: <path> [mux]`. Same root cause each time, so it goes in the skill rather than in a commit message: a positive result carries its own evidence, absence has to be earned. The skill (rootfs/, symlinked into ~/.agents/skills) is BAKED, so this is an image change and is logged in CHANGELOG Unreleased accordingly. Its §3 also now records that a live ControlMaster socket makes later commands authenticate not at all -- after editing a peer's authorized_keys, "it still works" proves nothing; prove it with -o ControlPath=none, or the breakage waits for a future session that has no memory of the edit. AGENTS.md: corrected a stale CI claim while placing the pointer. It said a tag push produces two runs including lint; lint.yml has since been scoped to branches: ['**'], which excludes tag refs, and refs/tags/v1.8.4 duly produced run 571 (publish) and nothing else. Kept the head_sha + workflow path filter advice, which is cheap and guards against a future v*-triggered workflow. Added a short section on verifying this repo from inside a container, including that docker-compose.yml here is a TEMPLATE pinning :latest while a real host runs its own per-machine file -- recreating from the repo copy can silently move a host off :latest-studio. Placement note: AGENTS.md is only auto-read when the cwd is this repo, so the durable rule lives in the skill, which loads by description match in any pi-devbox session.	2026-08-22 22:56:41 +02:00
Joakim Persson	2ebf00d6d4	v1.8.4: the om fix lands upstream, pi-atelier v0.8.2, todo edit ... Headline: pi-observational-memory 37986b6 -> ce9fc98. The ambient-credential gate fix (6f694e6 + 699ccc7) was merged upstream as PR #52 on 2026-08-22, closing issue #51, so this release picks it up through the ordinary PI_OBSMEM_REF=master path with nothing carried locally. Every image up to and including v1.8.3 silently recorded zero observations on a Bedrock host using ambient AWS credentials; from this one on, /opt is the fix and the settings.json packages[] workaround should be deleted (verify against /etc/pi-devbox/build-manifest.json first). npm still ships the broken 3.0.4, which does not matter here because the image clones the ref instead. Pin bump: PI_ATELIER_REF / PI_ATELIER_VERSION v0.8.1 -> v0.8.2, audited per the floor note above the ARG. The only version in between is 0.8.2 itself and both its entries are Workspace-Pulse-internal (inspection coalescing and serialization; fresh inspection guaranteed at Turn end, retired sessions can no longer publish stale results). Nothing touches pi's private TUI renderer, which is the coupling behind the 0.6.0/0.7.0-under-pi-0.84 startup hang, and pi is unchanged at 0.84.2 - so the bump stays outside that risk class. Also baked by this build, no pin needed: pi-extensions 98eb07b -> 2022887 (the todo edit action), pi-fork 4a09af4 -> f1ff808, pi-studio 0.9.44 -> v0.9.48, mempalace-toolkit b609cf5 -> fd8b15f (docs only - the pi-session false-success guard was already baked in v1.8.3, confirmed by ancestry), aws-cli 2.36.24 -> 2.36.29 and the other *_VERSION=latest tools. README: the pin table also said mempalace 3.6.0, stale since v1.8.3 bumped it to 3.7.1. Fixed in passing. Unchanged and verified current: pi 0.84.2 (npm latest, published 2026-08-14), MEMPALACE_VERSION 3.7.1 (PyPI latest), pi-toolkit 0e1369e. v1.8.4	2026-08-22 21:19:48 +02:00
joakimp	c3b6d36778	docs(CHANGELOG): Unreleased — the todo extension gains an edit action ... The commit itself lives in pi-extensions (2022887), but /opt/pi-extensions is baked into this image, so "which todo behaviour does this image have" is an image question. PI_EXTENSIONS_REF=main means the next build picks it up with no pin to bump -- worth stating explicitly, since a reader who expects a version bump will otherwise go looking for one. Also recorded, because it confused a session today: pi-atelier's tool_result hook replaces todo output with "N/M done - see sidebar" whenever the sidebar panel is visible, so an agent sees the counter and not the item text. Upstream's list returns every item; the terseness is atelier's deliberate context saving, not a limitation of the tool.	2026-08-17 22:49:13 +02:00
Joakim Persson	3a509077c2	v1.8.3: mempalace 3.7.1, refreshed skill snapshot, census on PATH ... mempalace 3.6.0 -> 3.7.1. Verified against the 3.7.1 source rather than its changelog, because the risk lands on palaces users cannot reconstruct: legacy drawers lack the new chunk_total marker and both decision sites trust them, so no mass re-mine; NORMALIZE_VERSION is 2 in both; chromadb stays <2 so no index-format migration; no auto-migration exists; logstream.sqlite3 is created lazily. Downgrade remains possible (3.6.0 has zero references to chunk_total). Two behaviour changes documented in the CHANGELOG: ALLOW_PEER_WRITER no longer works on local/chroma palaces, and writer-lock setup failures fail closed. Neither affects this image's MCP-server-plus-CLI-feeder pattern, which already serialised on the same lock under 3.6.0 -- the upstream "process-lifetime single-writer" entry describes tightened escape hatches, not a new lease. The motivation is the shared central palace: 3.7.1 drops the stale chromadb SharedSystemClient cache on reconnect (3.6.0 could let a stale in-memory HNSW segment overwrite a peer's writes, "index count going backwards"), releases the writer lease on SIGTERM/SIGHUP, and stops treating an interrupted mine as complete. The fleet primary was upgraded to 3.7.1 and restarted before this tag, because 3.7.1 refuses writes when the served library drifts and reconnect cannot clear that. opencode-devbox still pins 3.6.0, so the lockstep is broken until it cuts its own release. Vendored mempalace skill snapshot refreshed to skillset 936fed8 (was 63f3bf5). This closes a gap that had been invisible for two commits: ~/.agents/skills/ mempalace symlinks to the IMAGE-BAKED copy, entrypoint-user.sh creates that link first, and the skillset deploy never clobbers an existing name -- so in a devbox container the vendored snapshot always wins and editing skillset alone changes nothing a container reads. Brings the multi-machine shared-palace section and the hand-crafted-provenance guard. pi-global-AGENTS.append.md already carried the three shared-palace damage rules (a55f636); this tags them into a release. mempalace-census gets the /usr/local/bin symlink its three siblings have had all along, plus chmod and a build-time --help smoke check, so RFC-002 Phase A censuses no longer need an absolute path. Two new smoke assertions, both confirmed to FAIL against a v1.8.2 container so they are not tautological: the vendored snapshot must contain the multi-machine section (a stale manual snapshot is otherwise invisible), and mempalace-census must be on PATH. No other pins move: pi stays 0.84.2 (npm latest), pi-atelier v0.8.1, and every git-ref component was checked against its upstream head and is unchanged. v1.8.3	2026-08-16 23:30:01 +02:00
Joakim Persson	a55f6369b3	AGENTS.md: three damage-prevention rules for a shared central palace ... The managed block already tells agents to load the mempalace skill, but said nothing about the palace being shared with other machines. Three failure modes observed tonight while onboarding tor-ms22's feeders, all of which do damage rather than merely confuse: - `mempalace sync` prunes drawers whose source files look gitignored, deleted or moved. On a central palace that describes most of the content, including every other machine's. Compounded by RFC-001 7.2: feeders now stage inside the palace root, so a scoped sync can delete the drawers it just filed. - A client-side timeout is not a failure. The palace is single-writer and one large mine blocks every client for minutes, so `[mempalace ext] feed (tick) failed: mine timed out after 30000ms` usually means the mine COMPLETED. Verified: drawers from a timed-out tick were present 35 s after the client gave up. A blind retry files a duplicate. - The `mempalace` CLI has zero references to MEMPALACE_REMOTE_URL, so it always opens a palace on local disk and can silently disagree with the MCP tools. Orientation depth stays in the skill; only damage-prevention belongs here, because this file is always read and the skill's later sections often are not.	2026-08-16 22:32:09 +02:00
Joakim Persson	ffd54750b9	docs: CHANGELOG for v1.8.2 — the silent transcript-feed failure and its guard v1.8.2	2026-08-16 00:53:46 +02:00
Joakim Persson	d8b745c164	smoke+docs: pin the feeder's failed-remote-mine detection; REMOTE_PATH is server-visible ... First boot of the 2026-08-15 image on EMB-7KJ4VR4G shipped 7 transcripts to the palace host and filed none. Two causes, neither visible in the log: - MEMPALACE_PI_REMOTE_PATH was unset, so the feeder used its /data/feed default, which assumes a CONTAINERIZED palace server. That fleet's primary runs natively (systemd user unit + uv tool), so it only sees host paths and the mine died with "source directory not found". rsync had already succeeded. - The feeder decided success with `'"error"' in body`, but MCP escapes the tool's JSON inside result.content[].text, so the check was blind and the catch-up log said "Done. Wing updated." Fixed in mempalace-toolkit 6e1f4f3, which ships `--self-test` with fixtures pinning that exact response body. - smoke-test.sh: run `mempalace-pi-session --self-test` against the BAKED toolkit, so a stale or reverted MEMPALACE_TOOLKIT_REF cannot reintroduce a feeder that mines nothing while reporting success. - .env.example: spell out that MEMPALACE_PI_REMOTE_PATH is the path the SERVER PROCESS can open — container path for a dockerized server, and identical to the ssh-target path for a native one — and that a mismatch fails quietly.	2026-08-16 00:30:51 +02:00
Joakim Persson	ae13c2264e	ci: survive a revoked GITEA_BUILD_TOKEN on public commit reads ... Follow-up to a2f0a4a, which documented the hazard; this removes it. resolve-versions read three PUBLIC Gitea repos with `curl -sf -H "$AUTH_HEADER"`. Gitea rejects an invalid token rather than ignoring it, so the token turned a read that works anonymously into a hard failure: no Authorization header 200 empty token (secret unset) 200 <- absent secret was always safe garbage/revoked token 401 <- stale secret broke the release A revoked GITEA_BUILD_TOKEN therefore failed resolve-versions via require_sha, presenting as connectivity or an API fault, on data any anonymous client could fetch. Hit exactly that failure mode today with an expired PAT. New gitea_sha() helper tries authed, and on 401/403 retries anonymously with a loud stderr warning naming the token as the cause. Deliberate choices: - non-200 after the retry emits nothing and returns 0, so require_sha still raises the explicit abort — the helper never invents a fallback ref, which is the property the surrounding code exists to guarantee - warnings go to stderr, NOT as ::warning:: annotations: the function's stdout IS the SHA, so an annotation there would be captured into the ref - the header is still sent first, so a private repo keeps working Verified by extracting the function from the YAML step body (so the test ran the committed text, not a copy) and calling it against live Gitea: valid token -> 0e1369e6b496 (pi-toolkit) REVOKED token -> warns, retries anon, f60cf9c73205 (mempalace-toolkit) unset secret -> 98eb07bce60a (pi-extensions) nonexistent repo -> empty + HTTP 404 warning, so require_sha aborts Behaviour unchanged on the happy path: all three SHAs are byte-identical to the ones the v1.8.1 release run resolved with the old curl code. `bash -n` clean on the extracted step body; YAML re-parsed.	2026-08-15 14:27:18 +02:00
Joakim Persson	a2f0a4a441	ci: correct the false "Gitea requires auth for public reads" comment ... resolve-versions claimed "Gitea API requires auth even for public-repo commit listing" above the pi-toolkit / pi-extensions curls. Measurably false for the repos it guards. Verified 2026-08-15, unauthenticated vs authenticated GET of /api/v1/repos/joakimp/<repo>/commits?limit=1&sha=main: pi-toolkit private=false unauth=200 auth=200 sha 0e1369e6b496 identical pi-extensions private=false unauth=200 auth=200 sha 98eb07bce60a identical mempalace-toolkit private=false unauth=200 auth=200 sha f60cf9c73205 identical Only /api/v1/repos/*/actions/* refuses anonymous reads with 401 — almost certainly what the claim was over-generalised from. (Same over-generalisation I nearly committed to opencode-devbox's AGENTS.md today; 69fc80a there narrowed it to the actions endpoints for the same reason.) Checked the three repos actually queried rather than reusing the pi-devbox result — if any had been private the comment would have been TRUE, and the correction wrong. Behaviour deliberately unchanged: the header still gets passed. It survives a repo being flipped private, and an unset secret degrades cleanly because Gitea ignores an empty `token ` value and serves anonymously: no header 200 empty token (secret unset) 200 garbage token 401 That last row is the fragility now documented: a REVOKED or malformed token returns 401 where anonymous returns 200, so a stale GITEA_BUILD_TOKEN converts a healthy public read into a require_sha failure that presents as an API or network fault. Encountered exactly that today with an expired PAT on the actions endpoints, so the note tells the next reader to suspect the token first. Comment-only: no non-comment line changed, YAML re-parsed.	2026-08-15 14:21:25 +02:00
Joakim Persson	53b41cd76b	smoke: assert the pi stage $HOME-relative, and add a smoke_only dispatch ... v1.8.0 never shipped: smoke (67/68) and smoke-studio (70/71) each failed the same single assertion, so build-variant and everything downstream skipped and latest stayed on v1.7.0. The assertion was wrong, not the product. It grepped for a literal stage=/home/developer/.mempalace/pi-stage/, but run() invokes docker run --rm --entrypoint="" "$IMAGE" sh -c "$cmd" and neither Dockerfile sets USER or ENV HOME — the published base image config has no HOME at all; it is normally set by entrypoint-user.sh, which --entrypoint="" skips on purpose. So the assertion executed as root with HOME=/root, mempalace-pi-session correctly resolved stage=/root/.mempalace/pi-stage/... (the stage is $HOME-relative by design), and the literal grep could never match under any circumstances. The tell was one line below in the log: the sibling assertion "pi stage follows MEMPALACE_PALACE_PATH" PASSED, because it sets the variable explicitly and never consults HOME. Default fails + explicit passes = wrong HOME, not broken staging. Now asserts the invariant actually intended — the stage sits beside the resolved palace, sharing its lifetime — which is user-independent: case "$stage" in "stage=$HOME/.mempalace/pi-stage/"*) exit 0 ;; *) exit 1 ;; esac $HOME is expanded by the container's own shell, so it holds as root, as developer, or under any future user. Verified all four cases against the real bin/mempalace-pi-session by extracting the committed assertion bodies and running them under sh -c: virgin HOME -> exit 0; HOME=/home/developer -> exit 0; MEMPALACE_PI_STAGE pinned to a .cache path -> exit 1 (the regression this assertion exists to catch still fails it); developer-identity companion -> 0. Added that companion assertion, "pi stage is palace-adjacent for the developer user", which covers the deployment-specific path properly by SUPPLYING HOME=/home/developer rather than assuming it. Why this took a release to surface: docker-publish.yml triggers on push tags v* only. The assertion was added on a push to main (7c00dd6), where only lint.yml runs, so v1.8.0 was its first execution ever. Any smoke assertion written outside a release was unvalidated until a release consumed it. New workflow_dispatch input smoke_only probes/builds the base, runs both smoke jobs against HEAD, and stops before publishing. Implemented as `if: inputs.smoke_only != 'true'` on build-variant and build-variant-studio, deliberately WITHOUT always() so the implicit needs-succeeded gate survives and a red smoke still blocks a release. promote-base-latest and update-description already require build-variant success, so they skip on their own. On a tag push inputs is unset and null != 'true' is true, so releases are unaffected. Finally, run() no longer discards output. A red ❌ carried zero diagnostic weight: explaining this one-line failure needed a CI-log dig plus a registry image-config inspection, when the container had already printed the answer. Failures now show the last lines of output (guarded with `if`, not a trailing `&&`, which would abort under set -e), and the stage assertions echo the resolved stage and the HOME they saw to stderr — invisible while they pass. v1.8.1	2026-08-15 12:29:32 +02:00
Joakim Persson	29b62093f0	v1.8.0: bump pi 0.84.1 → 0.84.2 and pi-atelier v0.8.0 → v0.8.1, audited ... pi 0.84.2 closes the Amazon Bedrock tool-argument poison pill that v1.6.4 recorded as "Not fixed upstream". pi-ai 0.84.2 adds a recursive sanitizeBedrockDocument() and applies it at exactly the site that entry named (dist/api/bedrock-converse-stream.js, line 692 -> 704; upstream PR #7882): - toolUse: { ..., input: c.arguments }, + toolUse: { ..., input: sanitizeBedrockDocument(c.arguments) }, It strips object members whose key is the empty string, recursing through arrays and nested objects. It runs at request-build time, so it covers the live turn and a resume alike: a session already bricked by an empty-key tool argument now replays instead of dying on a Bedrock ValidationException. pi-session-repair is therefore no longer the recovery path on this image -- it stays useful for older images and for inspection, since the fix sanitises what is sent, not what was recorded. Bumping PI_VERSION is the ONLY way to get that fix: pi publishes an npm-shrinkwrap.json, so pi 0.84.1 pins pi-ai to exactly 0.84.1 even though its package.json range (^0.84.1) would admit 0.84.2. Transitive upstream fixes never leak into this image. pi-atelier v0.8.1 is the matching companion -- both sides changed fullscreen input handling within three days. Its only code change (src/split-pane.ts) stops atelier writing its own 1002h/1006h pair around a sidebar resize under pi's fullscreen renderer, which had been tearing down the mouse reporting pi itself enabled and leaving the wheel dead. Audited against the surfaces the pin policies name: - session .jsonl: identical migrateV1ToV2/migrateV2ToV3 ladder - node engine floor: unchanged >=22.19.0 (image ships 22.23.2) - atelier's three private couplings all intact in pi-tui 0.84.2 -- class TuiAltScreen extends TuiBase (detected by constructor NAME, so a rename would fail silently), inputListeners still `new Set()` at the same line 103, own render(width) descriptor still present - pi's mouse sequences byte-identical between 0.84.1 and 0.84.2 - atelier metadata unchanged: engines >=22.19.0, peerDeps >=0.80.7, zero runtime deps, so the "no npm install step" note holds Not proven by execution: CI smoke does not drive the TUI, and 0.84.2 adds a focused fullscreen search overlay that also participates in input handling. The pairing is reasoned from the diffs. Worth an alt+a plus a sidebar resize and wheel scroll in fullscreen on first use. v1.8.0	2026-08-15 00:22:08 +02:00
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