v1.9.1 bakes mempalace-toolkit e68ee20, which contains e2b060a. Requester-side
ask withdrawal has therefore been LIVE on every v1.9.1 device since 2026-09-10,
while the v1.9.0 section of CHANGELOG.md still read "not yet pinned ... this
image still pins e45f6b4", and the mempalace skill still told every agent at
session start that a withdrawal is impossible.
Measured, two independent routes, expectation recorded before looking:
- published image label, :v1.9.1-studio and :latest-studio (same digest):
se.jordbo.pi-devbox.mempalace-toolkit-ref = e68ee2071ca3ad39...
- ancestry: e2b060a is an ancestor of e68ee20
- baked mempalace.ts sha 7c16fe14 != v1.8.14's dfca71e9 (different bytes)
- grep -c isWithdrawn on this container's baked copy = 0 (v1.8.14, so
tor-ms22 cannot exercise the behaviour it is documenting)
The first label read came back EMPTY, and that empty was a claim about the
request rather than the image: Hub redirects blob fetches to a CDN and curl
without -L returns 0 bytes at exit 0. Recorded in the notes, because a registry
audit reporting "no labels" is missing -L until proven otherwise.
Changes:
- CHANGELOG Unreleased: the floating-ref mechanism, which is the reusable
part. ARG MEMPALACE_TOOLKIT_REF=main + CI resolving it to a SHA at build
time means a release absorbs whatever toolkit main holds, and "what
behaviour did this image gain" is a question nobody is forced to answer.
The fleet rule (name the pickup before tagging) was honoured for the
feed-tick commits v1.9.1 names, and missed for one in the same range.
- CHANGELOG v1.9.0: the stale caveat is ANNOTATED, not rewritten. The
sentence is the evidence for how the drift happened; deleting it would
destroy the only trace. Same discipline as fleet-ops d42412c.
- CHANGELOG Unreleased: corrected the size entry's "needs no base rebuild"
claim. True of that entry alone, false of the release now that the
vendored skill snapshot -- a base_tag input -- moves with it (~67 min).
- rootfs mempalace skill snapshot 44472 -> 46045 B, refreshed via
scripts/vendor-mempalace-skill.sh so the bytes and SKILLSET_SNAPSHOT_REF
(4d7c0ea -> e9e45f7) move together; --check confirms exact match.
- scripts/smoke-test.sh canary RE-PINNED. The retired pair was still green
against the new snapshot, i.e. blind to this refresh for the same reason
the pre-v1.8.13 pair was blind to that one. The replacement is stronger
than any predecessor here because BOTH witnesses come from the same
upstream commit: e9e45f7 added "Withdrawing an ask you sent" and deleted
"nothing anyone can do about it from the other end", the sentence the new
bullet contradicts. Directions measured against both files, then the
canary body EXECUTED against each: new -> rc=0 "ok", old -> rc=1 empty.
A canary whose negative witness was removed by the commit it pins fails
loudly on stale bytes instead of merely failing to notice them.
Gates: check-doc-drift OK, check-skill-floor OK, vendor --check OK,
hooks/pre-push OK (16 shell files clean at severity error).
Not fixable here: isWithdrawn is deployed and UNPROVEN. 17 assertions and 4
mutation kills, never once exercised on a released image against the live
logstream. Ask routed to a v1.9.1 device.
joakimp
9aaff26e3a