# 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.