golden_currency_gate.py had been CONVICTED four times today across three
controller releases. One bake covers all three, and the gate went red -> green
on the same command, which is its proof that it measures something real. THE
THREE DECLARED BYPASSES ARE NOW HISTORICAL RATHER THAN STANDING.
GOLDEN_VERSION 0.226.1
GOLDEN_SHA256 70ed8e9377dec22a9b493e55f222b0e25a49d7f3caec8c506e0412fd6baefe69
size 657 197 592 B
baked gitea.dooplex.hu/admin/felhom-controller:0.226.1
MinAgent 0.129.0 (read from the controller CHANGELOG header, not assumed)
THE EVIDENCE IS THE ROUND TRIP, NOT THE BUILD LOG. The published bytes were
downloaded back -- size and sha256 both identical to what the bake reported --
and ./etc/felhom-controller-image was read OUT of the downloaded archive:
`felhom-controller:0.226.1`. That is the delivered artifact naming the
controller it will start, from the bytes a customer's box would actually fetch.
Acceptance markers counted, not eyeballed, each string captured from this run's
own log rather than paraphrased from the runbook (two of the three the runbook
named until R-233 could not match anything the script prints): docker OK
(overlay2 = 1, including mount point rootfs = 1, mp0 = 1, upload OK (HTTP 201) =
1; excluding = 0, FATAL = 0, mp1 = 0. The 404 pre-gate passed before the run, so
nothing was overwritten.
THE VOUCH IS A THREE-FIELD CHANGE AND ALL THREE WERE CHECKED: agent_version
0.130.0 >= min_agent 0.129.0, so NOT the R-216 shape; wrapper_sha256 carried
through explicitly because the handler clears it when omitted. Verified by
RE-READING the manifest rather than trusting the flash -- golden option 0.226.1
SELECTED, all four shas matching.
THE FLOOR IS PROVEN ACTING, NOT MERELY SET. demo-felhom self-updated within 30
seconds: "[selfupdate] Post-update startup: update successful (0.225.0 ->
0.226.1)". Both demo machines now run 0.226.1 and only one of them was deployed
to by hand.
Token hygiene: copied file->file, read inside the VM by a runner script, never
on a command line (systemctl show ... | grep -c -F 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 shredded, and only then was the real
log's 0 taken as evidence.
Teardown: build guest 9100 destroyed --purge, secrets shredded AFTER the log was
copied out (standing rule 5), VM powered off, disk reverted to virgin.
R-242's OTHER half is untouched and still open: nothing gates the VOUCH itself.
