# Golden bake 0.228.0 — 2026-08-31

Baked, published, round-trip verified, **vouched**, and the fleet floor raised. `demo-felhom` picked
up the new controller **by itself** in under a minute.

## What was produced

| | |
|---|---|
| `GOLDEN_VERSION` | **0.228.0** |
| `GOLDEN_SHA256` | `76a3a98b9e7cc23bf8ae51b38a6272f576df285cb34cd22235ac3f06a31e53ec` |
| size | **658 079 744 B** |
| package URL | `…/api/packages/admin/generic/felhom-golden/0.228.0/golden.tar.zst` |
| baked controller | `gitea.dooplex.hu/admin/felhom-controller:0.228.0` |
| `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.228.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.227.1` 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 : 658079744          bake reported : 658079744
downloaded sha  : 76a3a98b…a31e53ec  bake reported : 76a3a98b…a31e53ec
```

**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.228.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.

## The vouch — three fields, all checked

| field | value | why it is right |
|---|---|---|
| `golden_version` | 0.228.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. `wrapper_sha256` was carried through explicitly, because the handler
clears it when omitted. **Verified by RE-READING the manifest, not by trusting the flash**
(`303 → ?flash=artifacts_set`): golden option `0.228.0 SELECTED`, agent option `0.130.0 SELECTED`, and
all four shas matching what was posted.

The hub's own dropdown independently read `data-sha="76a3a98b…"` for 0.228.0 straight from Gitea —
the same sha as the round-trip download, from a different reader.

The **R-120 gate** on this POST refuses a golden below the newest controller the fleet reports; fleet
newest was 0.228.0 and the golden is 0.228.0, 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.228.0"}`.
Re-read after: `min_controller_version value="0.228.0"`, `DB override: v0.228.0`.

**`demo-felhom` self-updated and re-registered its jobs by itself, in under a minute:**

```
[INFO] [selfupdate] Post-update startup: update successful (0.227.1 → 0.228.0)
[INFO] [scheduler] Daily job offsite-integrity scheduled for 2026-09-01 06:00 CEST
[INFO] [offsite-apply] settle-gate: GO — at/above floor 0.228.0 (we are 0.228.0), no managed update running
```

Nobody deployed to that box. Only `demo-hp` was ever touched by hand. Both demo machines are on
0.228.0, so **both now re-read their whole off-site store on the weekly check** — which is the point
of R-399 reaching the fleet, observed rather than assumed.

`golden_currency_gate.py` went **red → green** on this bake being recorded.

## 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. Nothing else provisioned: no hub record, no host record, no storage entry.