# Golden 0.210.0 — baked, published, round-trip verified, **NOT VOUCHED** (2026-08-08)

Bumping the controller to **v0.210.0** (R-259 / R-258) made `golden_currency_gate.py` correctly red
and it refused the `felhom.eu` push. The answer to that gate is the bake, never `--no-verify`.

**Vouched on arrival at this session: golden 0.209.0, agent 0.127.0** — read live from the hub, not
from a document. The operator vouched 0.209.0 during the previous session, so that approval is
closed and this one supersedes it.

## Where it ran

The **drill VM on DooPlex** (`/mnt/5_hdd/felhom.eu/drill/drill.qcow2`, snapshot `virgin`) — the
accepted Tier-2 exception for bakes. Canonical §4.0 launch line, cold-booted, **restored to `virgin`
afterwards** and the snapshot list re-read. Liveness via `ps -eo comm | grep -c qemu-system-x86`.

## The inputs

| | |
|---|---|
| host | `drill-pve`, `pve-manager/9.2.2` |
| template | **`debian-13-standard_13.6-1_amd64.tar.zst`** — listed with `pveam available` on the day; checksum verified on download |
| build script | `felhom-agent/configs/build-golden.sh` v3.0.0, clean tree at `28ba859` |
| controller baked | `gitea.dooplex.hu/admin/felhom-controller:0.210.0`, built and pushed from a clean tree at `c732fe1` |

## The token never crossed a shell

`scp` file → file into a `0600` file, read by a runner script **inside** the VM.
`systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)"` → **0**.

## The 404 pre-gate, with a control

```
felhom-golden/0.209.0/golden.tar.zst → 200   ← the control: the URL SHAPE is right
felhom-golden/0.210.0/golden.tar.zst → 404   ← the pre-gate: nothing to overwrite
```

## Acceptance markers — grepped verbatim against this run's log

| marker | count |
|---|---|
| `docker OK (overlay2` | **1** |
| `including mount point` (rootfs **and** mp0) | **2** |
| `upload OK (HTTP 201)` | **1** |
| `excluding` | **0** |
| `FATAL` | **0** |
| `mp1` | **0** |

`Result=success`, `ExecMainStatus=0`. Archive 626 MB.

## The publish, and the round trip — the published BYTES

```
GOLDEN_VERSION=0.210.0
GOLDEN_SHA256=b9f701fab813c051dd4be348a4e301f0e32518b811920406b7bdf8b3dd4c0a00
```

| | |
|---|---|
| size | **656 787 777 B** |
| sha256 | **`b9f701fa…4c0a00`** — hashed independently on DooPlex; identical |
| **`./etc/felhom-controller-image` read OUT of the downloaded archive** | **`gitea.dooplex.hu/admin/felhom-controller:0.210.0`** |

## ⚠ THE AGENT WAS NOT PUBLISHED UNTIL THIS SESSION CHECKED — and it mattered

R-221's fix is in the **agent**, and a fresh install takes its agent from the Day-0 manifest. The
binary had been deployed by hand to `felhom-pve` and **never published**, so `agent_version 0.128.0`
was not selectable and a fresh install would have received 0.127.0 — i.e. **the golden would have
carried the controller fixes and not the one this session's headline defect needed.**

Caught by checking each Day-0 value was *fetchable* rather than assuming it. Published from the
**live-deployed bytes**, sha-verified across the hop first:

```
sha on felhom-pve : c6eba73bf9b9ad6980cfef57bfb3db31581abc9d643de2ff50d4254576fc1a59
sha on DooPlex    : c6eba73bf9b9ad6980cfef57bfb3db31581abc9d643de2ff50d4254576fc1a59   ← identical
publish           : upload OK (HTTP 201), round-trip GET verified (sha256 matches)
```

## The vouch — the three values, each verified downloadable AND selectable

| field | now | **set to** | check that was run |
|---|---|---|---|
| `golden_version` | 0.209.0 | **0.210.0** | package `GET` → **HTTP 200**; hub dropdown offers it with `data-sha=b9f701fa…` matching the bake |
| `agent_version` | 0.127.0 | **0.128.0** | package `GET` → **HTTP 200** (after the publish above); hub dropdown offers it with `data-sha=c6eba73b…` matching the deployed binary |
| `min_agent` | 0.127.0 | **0.127.0** (unchanged) | read from the controller CHANGELOG header written this session: `## v0.210.0 — … — MinAgent 0.127.0` |

**Why `min_agent` stays 0.127.0 and is not raised to 0.128.0.** `MinAgent` declares what *this
controller* requires, and controller v0.210.0's changes (R-259, R-258) need nothing from the agent —
raising it would claim a coupling that does not exist. **R-221's fix is delivered by
`agent_version 0.128.0`, not by the floor.** Setting `min_agent` above `agent_version` is the R-216
shape, which hub v0.97.0 holds rather than serving past.

Hub → Configuration → Day-0 artifacts → set all three → Save. The R-120 gate sits on that save and
refuses a golden older than the newest controller the fleet reports. **Reversible** — re-select the
previous values and Save; no package is deleted by a bake.

## Teardown

`pct destroy 9100 --purge` · token, runner, build script and in-VM log `shred -u`'d, `/root` residue
clean · `poweroff` · qemu confirmed gone (**0**) · `qemu-img snapshot -a virgin` restored.

**Token-leak grep on the log COMMITTED here, with the control that makes a `0` mean something:**

```
grep -c -F "<token>" bake.log                       → 0
grep -c -F "<token>" <copy with the token appended> → 1   ← the control; copy then shredded
```

## What this does and does not change

**Does:** `golden_currency_gate.py` is green; the push it was blocking can proceed.

**Does NOT:** a fresh Day-0 install still lands on **0.209.0** and **agent 0.127.0** until the
operator saves. The gate checks the BAKE, not the vouch — R-242's untouched half, unchanged.