# REPORT — bake and vouch golden 0.216.0, closing R-334 (2026-08-18, afternoon) **Outcome: R-334 CLOSED.** Golden **0.216.0** baked, published, and **vouched by the operator**. `golden_currency_gate.py` is green for the first time since 2026-08-14, and `repo_gates.py` is **fully green — all nine gates, rc=0**. Run against the existing `documentation/runbooks/RUNBOOK-manual-build.md` §4.0 + §4.1; the run sheet pinned this run's numbers and the stop. Evidence: `documentation/tests/golden-0.216.0-2026-08-18/`. --- ## 1. Baselines, re-read on the machine | item | value | source | |---|---|---| | newest released controller | **v0.216.0** | `felhom-controller/CHANGELOG.md` head | | its floor | **`MinAgent: 0.129.0`** | second line of that header | | newest agent release | **v0.129.0** | `felhom-agent/CHANGELOG.md` head | | newest golden before this run | **0.214.0** | `documentation/tests/golden-0.214.0-2026-08-12` | **All four match the run sheet's §1 — no disagreement to report.** All three repos were clean with `HEAD == origin/main` before starting. ## 2. The published agent artifact exists Checked against the **package registry**, not inferred from a CHANGELOG: `generic felhom-agent 0.129.0` is published. Vouching `agent_version` at a version that was never published would point day-0 installs at a 404. **The R-216 check passed on the machine rather than on the coincidence.** `MinAgent` (0.129.0) is **equal to**, not above, the newest published agent (0.129.0). Had it read higher, hub v0.97.0 would hold the fleet against a version nobody has. ## 3. Identity, and a verification beyond what was asked ``` GOLDEN_VERSION = 0.216.0 GOLDEN_SHA256 = ac004dc90d8cefccc5448377892f9cff3a4c3e1e27d0e11129120e38ac31c34b URL = https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.216.0/golden.tar.zst archive = 656,970,239 bytes (rootfs 32G + ONE data volume 24G @ /var/lib/felhom) controller = gitea.dooplex.hu/admin/felhom-controller:0.216.0 template = debian-13-standard_13.6-1_amd64.tar.zst (listed live per §4.1 step 2, not reused) ``` The URL resolves (HTTP 206 on a range request). **I did not stop at the script's printed hash**: the artifact was downloaded back out of Gitea and hashed, and it matches `GOLDEN_SHA256` exactly. The script reporting a digest and the registry serving those bytes are two different claims, and only the second one is what a new install actually receives. ## 4. Pass markers — the corrected list, quoted from the real log ``` 82 : docker OK (overlay2; data-root /var/lib/docker) 313 : INFO: including mount point rootfs ('/') in backup 314 : INFO: including mount point mp0 ('/var/lib/felhom') in backup 319 : [golden] pre-delete existing: HTTP 404 (404/204 expected) 320 : [golden] upload OK (HTTP 201) ``` `excluding` and `FATAL`: **absent**. There is no mp1 — R-165 collapsed the two data volumes into one, which is exactly why the pre-2026-08-06 marker list could never match and why R-233 rewrote it. ## 5. Token handling, and why the control is not ceremony Copied **file → file** by `scp`; the runner script inside the VM read it from `/root/.gitea-token` itself, so the value never reached a command line or a unit's properties: ``` systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "" = 0 ``` Token-leak grep on the **committed** log, positive control run **first**: ``` seeded throwaway copy = 1 ← proves the grep can see a token when one is present committed bake.log = 0 ← the real measurement, now worth believing ``` **A `grep -c` that matches nothing returns `0`, which is indistinguishable from a clean file.** Without the control, the `0` is an assumption wearing a number's clothes. Both figures are from the copy that is committed to the repository, not only the one inside the VM. ## 6. Teardown `pct destroy 9100 --purge` (both LVs removed, CT purged) → `shred -u` on the token, runner, build script and log **after** the log was copied out (standing rule 5) → all four confirmed absent → `poweroff` → waited for qemu to exit using `ps -eo comm` (**not** `pgrep -f`, which self-matches and reports a false "still running") → `qemu-img snapshot -a virgin`, disk reverted, snapshot list shows the single `virgin` entry. **Nothing was provisioned that outlives this run.** ## 7. The vouch, and its verification **Performed by the operator (Viktor)** in the hub, Configuration → Day-0 artifacts. Verified afterwards by reading the hub's own store rather than trusting the save: | field | value | recorded | |---|---|---| | `artifact_golden_version` | **0.216.0** | 2026-08-18 11:00:59 | | `artifact_agent_version` | **0.129.0** | 2026-08-18 11:00:59 | | `artifact_min_agent` | **0.129.0** | 2026-08-18 11:01:00 | | `artifact_golden_sha256` | `ac004dc9…c34b` | 2026-08-18 11:01:00 | The recorded sha256 **matches the artifact I downloaded and hashed independently** — so the hub is vouching the bytes that are actually published, not merely a matching version string. **This separate check was necessary, and the gate says so itself.** `golden_currency_gate.py`'s own pass line reads *"this checks the BAKE, not the vouch"*. A green gate on an unvouched bake is exactly the "baked-but-unvouched golden is worse than none" state R-334 warned about, so the gate alone could not have closed this row. ## 8. Gates ``` golden_currency_gate.py rc=0 newest released controller : 0.216.0 newest golden baked : 0.216.0 repo_gates.py --fast rc=0 site OK · hostinstall OK · hub-confirm OK · manifest-bearer OK · reuse-refs OK instructions OK · golden-currency OK · wire-contract OK · hub-copy OK all felhom.eu gates OK ``` **This is the first fully green gate run since 2026-08-14**, and it is the point of the run: the CI failure mail that has been arriving since then should now stop. ## 9. Documentation not changed, deliberately **`documentation/architecture/00-capability-map.md` — no change, and the reason matters.** The run sheet said to update it *if the day-0 install row's evidence citation names the golden version*. It does not: that row cites `DRILL-day0-vm-2026-07-12` / `DRILL-day0-take2-2026-07-12`. The only golden version literal in the map is `tests/golden-0.205.0-2026-08-07` on the **recovery-journey** row, which is a **dated historical citation** of what a fresh install landed on during the 2026-08-07 walk. Bumping it to 0.216.0 would falsify a record of what happened on a specific date — `docs.md` permits historical citations precisely because they cannot go stale. ## 10. Observations, not acted on - **`min_controller_version` in the hub still reads `0.214.0`** (last touched 2026-08-12). That is a different field from the three vouched here — it is the floor the fleet is held to, not the day-0 golden — and it was outside this run's scope. But it is now two releases behind the golden a new box receives, and STATUS.md's "approved pair" line describes it. Worth a decision; **not** changed here, because widening scope past the three named fields is how a vouch goes wrong. - **`pveam available` still offers `debian-13-standard_13.6-1_amd64.tar.zst`** — the same point release the runbook recorded on 2026-07-31. Listed live rather than assumed, per §4.1 step 2; the instruction stands even when the answer happens not to have moved. - **The bake ran in ~5 minutes** (12:49 launch → 12:54:14 archive), well inside the drill VM's normal envelope; no timeout or retry was needed.