Golden bake 0.226.1 — 2026-08-30

Baked to close golden_currency_gate.py, which had been CONVICTED across three controller releases (0.224.0 R-330, 0.225.0 R-331, 0.226.0/0.226.1 R-353/357/358/360). One bake covers all three.

What was produced


`GOLDEN_VERSION`	0.226.1
`GOLDEN_SHA256`	`70ed8e9377dec22a9b493e55f222b0e25a49d7f3caec8c506e0412fd6baefe69`
size	657 197 592 B
package URL	`https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.226.1/golden.tar.zst`
baked controller	`gitea.dooplex.hu/admin/felhom-controller:0.226.1`
`MinAgent`	0.129.0 (read from the controller `CHANGELOG.md` header, not assumed)
script	`build-golden.sh v3.0.0`
venue	the drill VM on DooPlex, reverted to `virgin` and cold-booted first
template	`debian-13-standard_13.6-1_amd64.tar.zst` — after `pveam update`, because the virgin snapshot's INDEX is stale too and the failure reads as a bogus `400 no such template`

Acceptance markers — counted, not eyeballed

Each string was captured from this run's own log rather than paraphrased from the runbook (two of the three markers the runbook named until 2026-08-06 could not match anything the script prints — R-233):

docker OK (overlay2             : 1     ← "  docker OK (overlay2; data-root /var/lib/docker)"
including mount point rootfs    : 1
including mount point mp0       : 1
upload OK (HTTP 201)            : 1
--- must be ZERO ---
excluding                       : 0
FATAL                           : 0
mount point mp1                 : 0     ← mp1 stopped existing in build-golden.sh v3.0.0 (R-165)

404 pre-gate before the run: HTTP 404 on the package URL, so nothing was overwritten. The script's own pre-delete then reported HTTP 404 (404/204 expected).

The evidence is the ROUND TRIP, not the build log

The published bytes were downloaded back and compared to what the bake reported:

downloaded size : 657197592          bake reported : 657197592
downloaded sha  : 70ed8e93…baefe69   bake reported : 70ed8e93…baefe69

And the delivered artifact was asked what it will start — ./etc/felhom-controller-image read out of the downloaded archive:

gitea.dooplex.hu/admin/felhom-controller:0.226.1

That is the golden naming the controller it will run, read from the bytes a customer's box would actually fetch — not from the build host, and not from the local file.

Token hygiene

The Gitea token was copied file → file (scp), never crossing a shell on either side, and the bake ran through a runner script inside the VM that reads it itself — so it never reached a command line or a transient unit's properties:

systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)"  → 0

The leak grep on the committed log was PROVEN TO WORK before its 0 was believed. A throwaway copy had the token appended, was grepped (1), and was shred -u'd; only then was the real log's 0 taken as evidence. A 0 from an untested grep is not a measurement.

POSITIVE CONTROL (token appended) : 1
THE COMMITTED bake.log            : 0

Teardown

Build guest 9100 destroyed --purge; token, runner and log shred -u'd after this log was copied out (standing rule 5: evidence leaves at the end of the phase that produced it, not at the end of the session); VM powered off and the disk reverted to virgin.