Golden 0.258.0 — baked, published and vouched 2026-09-20
Baked as Phase 0 of localisation slice 6's fresh-install drill (R-561). The cadence ruling (R-468, 2026-09-13) is weekly, and always before any drill or fresh install — this is the second half of that sentence. It also means the drill's box boots at the version under test instead of installing an eleven-version-old controller and self-updating.
GOLDEN_VERSION |
0.258.0 (controller image gitea.dooplex.hu/admin/felhom-controller:0.258.0) |
GOLDEN_SHA256 |
49d765d29dc013e8e270204cadaa6f3df96e8f26b11ff18796f5cab3efe6a6cc |
| archive | 654 443 692 B · rootfs 32G + one data volume 24G @ /var/lib/felhom |
| template | debian-13-standard_13.6-1_amd64.tar.zst, container architecture amd64 |
| markers | docker OK (overlay2 1 · including mount point rootfs 1 · including mount point mp0 1 · upload OK (HTTP 201) 1 · excluding 0 · FATAL 0 |
| token leak | 0 in the committed bake.log; the planted control (a throwaway copy with the token appended) read 1, so the grep was shown to work before the 0 was believed |
| registry | …/generic/felhom-golden/0.258.0/golden.tar.zst → 200, and only then teardown |
| teardown | CT 9100 destroyed --purge; token, runner and log shredded inside the VM (/root left with only its dotfiles); qemu exited; drill.qcow2 reverted to virgin |
| vouched | Artifact manifest set: agent=0.132.0 golden=0.258.0 min_agent="0.131.0" wrapper_sha=false — read back from the form: golden 49d765d2… selected, agent 0.132.0 selected, min_agent 0.131.0 |
The three-field vouch, and why all three moved together: golden_version → 0.258.0,
agent_version → 0.132.0 (unchanged, and ≥ the release's MinAgent), min_agent → 0.131.0, read
from v0.258.0's CHANGELOG header. golden_version alone would ship a controller onto an older agent
than it declares it needs.
One run, no aborted attempts. The 0.246.0 bake's two traps were both avoided by following its
record: the template was chosen by NAME (debian-13-standard_13.6-1_amd64), not by a sort -V that
ranks arm64 after amd64; and the bake ran as a transient unit inside the VM, so nothing on the host
could kill it.
The waiver was NOT retired, and that is deliberate
The task that commissioned this bake said the drill "retires" golden-waiver.yml. It is left in
place, and here is the one line saying why: the waiver is the mechanism of operator ruling R-468
(goldens on a weekly cadence, the gate advisory in between), not a note about this particular golden.
Deleting it would turn the next release without a bake red immediately — that is a reversal of a
documented operator decision, which is not a session's to make. It is also not load-bearing today:
with golden 0.258.0 recorded, golden_currency_gate.py passes on its own merits, and the waiver's
line in the output reads "VALID until 2026-09-27 (7 days left)" beside a gate that no longer needs it.
Files
bake.log— the full bake, copied off the VM before teardown (R-320), token-grepped with a control.