# Golden bake 0.214.0 — 2026-08-12

Per `RUNBOOK-manual-build.md` §4.0/§4.1. Drill VM reverted to `virgin` before and after; guest 9100
destroyed `--purge`; `/root` residue shredded.

| | |
|---|---|
| `GOLDEN_VERSION` | **0.214.0** |
| `GOLDEN_SHA256` | **3a40379cb00d98c6f9550815b2b024783f153e9eef9be2b3252253d24d8d2c4d** |
| controller baked | `gitea.dooplex.hu/admin/felhom-controller:0.214.0` |
| `MinAgent` (CHANGELOG header) | **0.129.0** |
| published | 656 392 524 B, `upload OK (HTTP 201)` |

## Acceptance markers (`grep -F`, quoted loop variable)

`docker OK (overlay2` 1 · `including mount point rootfs` 1 · `including mount point mp0` 1 ·
`upload OK (HTTP 201)` 1 · `FATAL` 0 · `excluding` 0

## Fetchability — the SERVED bytes

```
downloaded: 656392524 bytes
sha256:     3a40379cb00d98c6f9550815b2b024783f153e9eef9be2b3252253d24d8d2c4d
```
Identical to `GOLDEN_SHA256`.

## The template index was STALE, and it would have baked the wrong base

`pveam available` on the freshly reverted `virgin` listed only `debian-13-standard_13.1-2` — the point
release our own memory records as 404-ing since 2026-07-15. **`pveam update` first**, and the real
current one is `debian-13-standard_13.6-1_amd64.tar.zst`. The runbook says the point release rots; what
it does not say is that the VM's cached index rots too, and reading it without refreshing produces a
confident answer that is a fortnight out of date.

## Secret handling

Token file→file, read inside the VM by a runner script, never on a command line.
`systemctl show golden-bake -p Environment -p ExecStart | grep -c -F <token>` = **0**. Leak grep on the
committed log = **0**, believable because a planted-token control on a copy grepped **1**. All in-VM
artefacts `shred -u`'d.

## NOT DONE

The Day-0 vouch — the operator's, and deliberately so. Three fields, each already verified downloadable
and selectable: **golden 0.214.0**, **agent 0.129.0**, **min agent 0.129.0**.