Files
felhom.eu/documentation/tests/golden-0.218.0-2026-08-22
…
..
…
…

Golden bake — 0.218.0 (2026-08-22)

Baked in the drill VM on DooPlex per documentation/runbooks/RUNBOOK-manual-build.md §4.0/§4.1, carrying controller v0.218.0 (R-354 + R-355).

GOLDEN_VERSION 0.218.0
GOLDEN_SHA256 8e427869d13eafb71562b77d1535eef6c7f32b4db24f659b988ec6d7db8f478b
package https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.218.0/golden.tar.zst
size 657 026 013 B (archive 626 MB)
controller image gitea.dooplex.hu/admin/felhom-controller:0.218.0
template debian-13-standard_13.6-1_amd64.tar.zst (listed fresh, not assumed)
MinAgent 0.129.0 (from the controller CHANGELOG header — unchanged)

Pass markers — each checked, with the negative controls

docker OK (overlay2      : 1     ->  "  docker OK (overlay2; data-root /var/lib/docker)"
including mount point    : 2     ->  rootfs ('/') and mp0 ('/var/lib/felhom')  [there is no mp1]
upload OK (HTTP 201)     : 1     ->  pre-delete returned HTTP 404 (404/204 expected)
excluding                : 0     <- negative control
FATAL                    : 0     <- negative control

Token hygiene

The Gitea token was copied file → file (scp) and read by a runner script inside the VM, so it never crossed a shell or a unit property. Verified: systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0.

The leak grep on this committed log was itself proven before its zero was believed: the token was appended to a throwaway copy, grepped (1), the copy shredded, and only then was the committed log's 0 accepted.

Teardown

pct destroy 9100 --purge; token, runner, build script and in-VM log shred -u'd after this log was copied out; VM powered off; qemu exited; qemu-img snapshot -a virgin restored.

NOT vouched

The hub's Day-0 artifact manifest was not changed and the floor was not raised — both are the operator's decision. See REPORT.md §12.