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