felhom.eu/documentation/tests/golden-0.229.0-2026-08-31/README.md

Golden bake 0.229.0 — 2026-08-31

Baked, published, round-trip verified, vouched, and the fleet floor raised. demo-felhom picked up the new controller by itself, unattended.

What was produced

GOLDEN_VERSION	0.229.0
GOLDEN_SHA256	39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87
size	656 864 331 B
package URL	…/api/packages/admin/generic/felhom-golden/0.229.0/golden.tar.zst
baked controller	gitea.dooplex.hu/admin/felhom-controller:0.229.0
MinAgent	0.129.0 — read from the controller CHANGELOG.md header, not assumed
script	build-golden.sh v3.0.0, sha256 7b0fb5cf…73b6a1 — compared across the hop, identical on DooPlex and inside the VM
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)
archive volid	local:backup/vzdump-lxc-9100-2026_08_31-12_30_37.tar.zst

Acceptance markers — counted on the COMMITTED log, not eyeballed

docker OK (overlay2             : 1
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.229.0 appears 4 times in the bake log.

The 404 pre-gate was PROVEN TO WORK before its 404 was believed. The target URL returned 404 and, on the same command, the existing 0.228.0 package returned 200 — a positive control, because a 404 from a check that cannot see anything is not a measurement. The script's own pre-delete then reported HTTP 404 (404/204 expected): nothing was overwritten.

The evidence is the ROUND TRIP, not the build log

downloaded size : 656864331          bake reported : 656864331
downloaded sha  : 39aa886d…d7bdae87  bake reported : 39aa886d…d7bdae87

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

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.

A third, independent reader agreed. The hub's own Day-0 dropdown read data-sha="39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87" for 0.229.0 straight from Gitea, before anything was vouched — same sha, different reader, different code path.

The vouch — three fields, all checked

field	value	why it is right
golden_version	0.229.0	baked and round-trip verified above
agent_version	0.130.0	published, unchanged, 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. agent_sha256 and wrapper_sha256 were carried through explicitly, because the handler clears a field it is not sent. Verified by RE-READING the manifest, not by trusting the flash (303 → ?flash=artifacts_set):

agent_version    0.130.0    SELECTED  sha=a56a92a7…eaefabc3
golden_version   0.229.0    SELECTED  sha=39aa886d…d7bdae87
agent_sha256     a56a92a7bd68f5b46736eaec4806c3d26c16ccb35118c4ac0e3d8094eaefabc3
golden_sha256    39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87
min_agent        0.129.0
wrapper_sha256   104db0a4401f65bbc476e82bfb1796433bcb36f8f8cce69efb3bb5c40fcb16b3

The R-120 gate on this POST refuses a golden below the newest controller the fleet reports; fleet newest was 0.229.0 and the golden is 0.229.0, so it passed rather than being bypassed — a refusal would have redirected to ?flash=golden_behind_fleet and written nothing.

The floor is ACTING, not merely set

Blast radius before the change: {"below":3,"valid":true,"version":"0.229.0"}. Re-read after (not the flash): min_controller_version value="0.229.0", Effective floor v0.229.0, DB override: v0.229.0.

demo-felhom self-updated and re-registered its jobs by itself:

[INFO] [selfupdate] Post-update startup: update successful (0.228.0 → 0.229.0)
[INFO] [scheduler] Registered periodic job: selfupdate-check (every 6h0m0s)
[INFO] [offsite-apply] settle-gate: GO — at/above floor 0.229.0 (we are 0.229.0), no managed update running

Nobody deployed to that box. Only demo-hp was ever touched by hand. Both demo machines are now on 0.229.0, so both carry the Tier-2 unit restore (R-102/R-103) — which is the point of this release reaching the fleet, observed rather than assumed.

golden_currency_gate.py went red → green on this bake being recorded, which is its proof that it measures something real.

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 (pct list then empty); token, runner script, bake script and log shred -u'd after the log was copied out (standing rule 5); VM powered off, qemu confirmed gone from ps -eo comm (never pgrep -f, which self-matches), disk reverted to virgin, pidfile removed, /root left holding only its stock dotfiles. Nothing else provisioned: no hub record, no host record, no storage entry.