joakimp/pi-devbox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(deps): node 22->24, actionlint 1.7.12, hadolint 2.15.1, skillset ref

Browse Source 
Audited every component the image obtains OUTSIDE debian/apt. Of ~23, the 19
that resolve `latest` at build time were already current or refresh themselves
on the next rebuild, and the hard pins for pi (0.85.1), mempalace (3.9.0) and
pi-atelier (v0.10.1) were already newest. Four needed a human.

NODE_VERSION 22 -> 24 (LTS "Krypton"). This was a latent defect rather than
housekeeping: agent-browser publishes engines.node ">=24.0.0", so the image sat
BELOW a declared requirement -- v1.8.14 shipped node 22.23.2 with agent-browser
0.37.1, so every build installed it with an npm EBADENGINE warning and ran the
baked browser automation outside its supported range. pi (">=22.19.0") and
playwright (">=20") are satisfied either way. Verified before bumping, since a
missing NodeSource suite breaks every arch at once: setup_24.x returns HTTP 200
and node_24.x advertises `Architectures: amd64 arm64 armhf x86_64`, covering
the arm64 fleet and the amd64 CI runners. Nothing else pinned the node major.

actionlint 1.7.7 -> 1.7.12 and hadolint 2.14.0 -> 2.15.1, each RUN AGAINST THIS
TREE at the new version before being pinned -- both clean, no new findings. A
linter bump is the one dependency update that can turn CI red on unchanged
code, so it is verified locally rather than discovered on a round trip.

SKILLSET_SNAPSHOT_REF e9e09d9 -> 4d7c0ea via scripts/vendor-mempalace-skill.sh,
never by hand: that script is the only thing permitted to write the ARG,
because a cp without a matching bump yields a manifest that confidently lies.
This proved PROVENANCE-ONLY -- the ref was 6 commits behind, but
skills/mempalace/SKILL.md is byte-identical at both (3675bfab), so the snapshot
was already correct and only its recorded origin was stale. No rootfs/ bytes
changed, the smoke-test phrase canary stays valid, and this ARG alone would not
force a base rebuild (the node bump does).

Two measurement traps worth recording, since both would have produced a wrong
answer: GitHub's releases/latest reports pi-atelier v0.10.0 as newest because
v0.10.1 is a TAG WITH NO RELEASE OBJECT -- the pin was already current, and
`git ls-remote --tags` is the instrument that shows it. And gitea-mcp is hosted
on gitea.com, not GitHub, so querying api.github.com returned nothing at all
rather than an error.

Verified with every gate this repo owns, all green, using the NEW linter pins:
lint-shell.sh (15 files), check-workflow-shell.sh, check-base-hash.sh,
actionlint 1.7.12, hadolint 2.15.1, check-skill-floor.sh, and
vendor-mempalace-skill.sh --check.
This commit is contained in:
Joakim Persson
2026-09-10 20:17:32 +02:00
parent cac5e00a31
commit edc7659add
4 changed files with 49 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+35
View File
@@ -152,6 +152,41 @@ stale — and it needs no secret, since `pi-extensions` is anonymously clonable
> alongside the existing `skillset_snapshot_tree_sha256`, which this change does
> not add.
**Four pinned dependencies bumped, after an audit of everything the image gets
from outside apt.** The audit itself is the useful part: of ~23 externally-managed
components, the 19 that resolve `latest` at build time were already current or
refresh themselves on the next rebuild, and the hard pins for `pi` (0.85.1),
`mempalace` (3.9.0) and `pi-atelier` (v0.10.1) were all already the newest
available. Only four needed a human.
**`NODE_VERSION` 22 → 24 (LTS "Krypton") — this one was a latent defect, not
housekeeping.** `agent-browser` publishes `engines.node ">=24.0.0"`, so the image
was *below a declared requirement*: v1.8.14 shipped node 22.23.2 with
`agent-browser` 0.37.1, meaning every build installed it with an npm `EBADENGINE`
warning and then ran the baked browser automation outside its supported range.
The other two npm consumers are satisfied either way — `pi` declares `>=22.19.0`,
`playwright` `>=20`. Verified before bumping, because a missing NodeSource suite
would break every architecture at once: `setup_24.x` returns HTTP 200 and the
`node_24.x` suite advertises `Architectures: amd64 arm64 armhf x86_64`, covering
both the arm64 fleet and the amd64 CI runners. Nothing else in the repo pinned the
node major.
**`actionlint` 1.7.7 → 1.7.12 and `hadolint` 2.14.0 → 2.15.1**, each run against
the current tree at the new version *before* being pinned — both clean, no new
findings. That ordering is the point: a linter bump is the one dependency update
that can turn CI red on unchanged code, so discovering it locally costs a minute
and discovering it in CI costs a round trip.
**`SKILLSET_SNAPSHOT_REF` `e9e09d9` → `4d7c0ea`**, via
`scripts/vendor-mempalace-skill.sh` rather than by hand, because that script is
the only thing that may write the ARG — a `cp` without a matching bump produces a
manifest that confidently lies. This turned out to be **provenance-only**: the
recorded ref was 6 commits behind, but `skills/mempalace/SKILL.md` is byte-identical
at both (`3675bfab…`), so the vendored snapshot was already correct and only its
recorded origin was stale. Consequently no `rootfs/` bytes changed, the
smoke-test phrase canary stays valid, and this ARG alone would not have forced a
base rebuild — the node bump does that anyway.
---
## v1.8.14 — 2026-09-08