Files
felhom.eu/documentation/tests/golden-0.210.0-2026-08-08
admin 4a4a1e245a
gates / gates (push) Successful in 32s
R-265 CI timeout + golden 0.210.0 baked; R-221/R-259/R-258 closed, R-266 minted, G-3 unblocked
Four defects of one family, all shipped today: something the box already knows, thrown away or drawn
as its opposite. Agent v0.128.0, controller v0.210.0. NO HUB CODE, no hub bump, no ArgoCD sync.

R-265 (this repo). timeout-minutes: 5 on the gates job — every honest run in the observed session
finished in 18-34s, so this is ~9x the slowest and far under whatever reaped run 264 at 834s with no
log. The alarm mail now carries Elapsed (start stamp via $GITHUB_ENV; an absent stamp prints
"unknown (no start stamp)", never a bogus 1.7-billion-second figure) and its "names itself in the run
log" sentence is qualified so it cannot mislead when there is no log.

⚠ THE UNKNOWN IS NOT CLOSED. Whether the if: failure() alarm fires for a REAPED job is still
unverified. The timeout makes the reap unreachable in practice; it does not answer what happens in
one. Demonstrating it means deliberately hanging a run on main, which would leave the branch red for
a parallel session. Said in the workflow comment, the changelog, R-265 and the report — none of them
claiming it is answered.

GOLDEN 0.210.0 baked, published, round-trip verified, NOT VOUCHED. The currency gate went red the
moment the controller was bumped — correct — and is closed by the bake, never --no-verify. No
--no-verify anywhere this session.

⚠ 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 hand-deployed
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 — the golden would have carried the controller fixes and NOT the one the
headline defect needed. Caught by checking each Day-0 value was FETCHABLE rather than assuming.
Published from the live-deployed bytes, sha-verified across the hop first.

Registers. R-221, R-259, R-258, R-265 CLOSED. R-266 MINTED (READY): the failed root statfs still
travels to the hub as a 0-of-0 disk; ranked LOW because it is the quiet direction — it can only miss
a true alarm, never raise a false one — and it is now a two-repo wire change governed by G-1's gate.
Highest ID moved R-265 -> R-266.

CONTEXT S-39 rules the convention this project was missing: "we do not know" is never drawn as
"fine", and the codebase has ONE way of saying it — an explicit ...Known bool companion checked in
the template. ROADMAP G-3 was explicitly blocked on that decision and is unblocked; what remains
there is a survey-and-convert of existing sites, not the gate.

Capability map row 93 CHECKED and it was NOT claiming something untrue — it is about the operator
notification path. But its narrative ("the page you open to ask whether ONE app is backed up")
invites the wrong reading, and the adjacent thing WAS false until v0.210.0, so the row now records
that the two halves disagreed and only the operator half was true.

Six red-proofs across the two code repos, each with the mutation asserted applied. The one that
matters: Part 1 Scenario A FAILED against today's tree, with the intended message.

Part 1's operator-present live validation is OWED and is the session's STOP.

repo_gates --fast: all 8 OK.
2026-08-08 16:52:39 +02:00
..

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 GETHTTP 200; hub dropdown offers it with data-sha=b9f701fa… matching the bake
agent_version 0.127.0 0.128.0 package GETHTTP 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.