Golden bake 0.227.1 — 2026-08-30

Baked, published, round-trip verified, vouched, and the fleet floor raised — the second full delivery of the day, and the first one where a box picked up the new controller and its new job entirely by itself.

What was produced


`GOLDEN_VERSION`	0.227.1
`GOLDEN_SHA256`	`66754491dc9bd0130ef8ded9562f63c53a5ffdcfd91baa551141e55fa083ea32`
size	657 403 203 B
package URL	`…/api/packages/admin/generic/felhom-golden/0.227.1/golden.tar.zst`
baked controller	`gitea.dooplex.hu/admin/felhom-controller:0.227.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` (the virgin snapshot's INDEX is stale too, and the failure reads as a bogus `400 no such template`)

Acceptance markers — counted, not eyeballed

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)

felhom-controller:0.227.1 appears 4 times in the bake log. 404 pre-gate before the run, and the script's own pre-delete reported HTTP 404 (404/204 expected) — nothing was overwritten.

The evidence is the ROUND TRIP, not the build log

downloaded size : 657403203          bake reported : 657403203
downloaded sha  : 66754491…083ea32   bake reported : 66754491…083ea32

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

The vouch — three fields, all checked

field	value	why it is right
`golden_version`	0.227.1	baked and round-trip verified above
`agent_version`	0.130.0	published, and ≥ `min_agent`
`min_agent`	0.129.0	read from the golden's controller CHANGELOG header

agent_version (0.130.0) ≥ min_agent (0.129.0) — not the R-216 shape, where a floor points above the agent it is served with. wrapper_sha256 was carried through explicitly, because the handler clears it when omitted. Verified by RE-READING the manifest, not by trusting the flash: golden option 0.227.1 SELECTED, all four shas matching.

The R-120 gate on this POST refuses a golden below the newest controller the fleet reports; fleet newest was 0.227.1 and the golden is 0.227.1, so it passed rather than being bypassed.

The floor is ACTING, not merely set

Impact preview before the change: {"below":3,"valid":true,"version":"0.227.1"}.

demo-felhom self-updated in under 30 seconds and registered the new job by itself:

[INFO] [selfupdate] Post-update startup: update successful (0.226.1 → 0.227.1)
[INFO] [scheduler] Daily job offsite-integrity scheduled for 2026-08-31 06:00 CEST

That second line is the one worth keeping. A box nobody deployed to now runs the off-site integrity check on its own schedule — which is the whole point of a floor, observed rather than assumed. Both demo machines are on 0.227.1; only demo-hp was ever touched by hand.

golden_currency_gate.py went red → green on the same command.

Token hygiene

Copied file → file (scp), never crossing a shell on either side; the bake ran through a runner script inside the VM that reads the token 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 with the token appended grepped 1, was shred -u'd, and only then was the real log's 0 taken as evidence. A 0 from an untested grep is not a measurement.

Teardown

Build guest 9100 destroyed --purge; token, runner, script and log shred -u'd after the log was copied out (standing rule 5); VM powered off; disk reverted to virgin. Nothing else provisioned: no hub record, no host record, no storage entry.