admin
db0812b6f2
Second full delivery of the day. golden_currency_gate.py went red -> green on the same command, so the --no-verify bypass declared on the previous push is now historical rather than standing. GOLDEN_VERSION 0.227.1 GOLDEN_SHA256 66754491dc9bd0130ef8ded9562f63c53a5ffdcfd91baa551141e55fa083ea32 size 657 403 203 B baked gitea.dooplex.hu/admin/felhom-controller:0.227.1 MinAgent 0.129.0 (read from the controller CHANGELOG header, not assumed) THE EVIDENCE IS THE ROUND TRIP. The published bytes were downloaded back -- size and sha256 identical to what the bake reported -- and ./etc/felhom-controller- image was read OUT of the downloaded archive: felhom-controller:0.227.1. That is the delivered artifact naming the controller it will start, from the bytes a customer's box would actually fetch. Markers counted: docker OK (overlay2 = 1, mount point rootfs = 1, mp0 = 1, upload OK (HTTP 201) = 1; excluding = 0, FATAL = 0, mp1 = 0. 404 pre-gate passed before the run and the script's own pre-delete agreed, so nothing was overwritten. Three-field vouch, all three checked: agent_version 0.130.0 >= min_agent 0.129.0 (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. The R-120 gate on that POST passed on its own terms rather than being worked around. AND THE LINE WORTH KEEPING. demo-felhom self-updated 0.226.1 -> 0.227.1 in under 30 seconds and then logged: [INFO] [scheduler] Daily job offsite-integrity scheduled for 2026-08-31 06:00 CEST A box nobody deployed to now runs today's off-site integrity check on its own schedule. That is a floor DELIVERING rather than merely recording, observed instead of assumed -- and it is the strongest evidence R-242 has carried. Token hygiene: 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. Teardown: guest 9100 destroyed --purge, secrets shredded AFTER the log was copied out, VM powered off, disk reverted to virgin. R-242 now records the cadence as MEASURED: five convictions and two full bakes in one day. Every bypass declared, every debt paid -- and the pattern the row exists to name is exactly that a release and its delivery are separate acts. Its other half stays open: nothing gates the VOUCH itself.
Golden bake 0.227.1 — 2026-08-30
Baked, published, round-trip verified, vouched, and the fleet floor raised — the second full delivery of the day, and the first one where a box picked up the new controller and its new job entirely by itself.
What was produced
GOLDEN_VERSION |
0.227.1 |
GOLDEN_SHA256 |
66754491dc9bd0130ef8ded9562f63c53a5ffdcfd91baa551141e55fa083ea32 |
| size | 657 403 203 B |
| package URL | …/api/packages/admin/generic/felhom-golden/0.227.1/golden.tar.zst |
| baked controller | gitea.dooplex.hu/admin/felhom-controller:0.227.1 |
MinAgent |
0.129.0 — read from the controller CHANGELOG.md header, not assumed |
| script | build-golden.sh v3.0.0 |
| venue | the drill VM on DooPlex, reverted to virgin and cold-booted first |
| template | debian-13-standard_13.6-1_amd64.tar.zst, after pveam update (the virgin snapshot's INDEX is stale too, and the failure reads as a bogus 400 no such template) |
Acceptance markers — counted, not eyeballed
docker OK (overlay2 : 1 ← " docker OK (overlay2; data-root /var/lib/docker)"
including mount point rootfs : 1
including mount point mp0 : 1
upload OK (HTTP 201) : 1
--- must be ZERO ---
excluding : 0
FATAL : 0
mount point mp1 : 0 ← mp1 stopped existing in build-golden.sh v3.0.0 (R-165)
felhom-controller:0.227.1 appears 4 times in the bake log. 404 pre-gate before the run, and
the script's own pre-delete reported HTTP 404 (404/204 expected) — nothing was overwritten.
The evidence is the ROUND TRIP, not the build log
downloaded size : 657403203 bake reported : 657403203
downloaded sha : 66754491…083ea32 bake reported : 66754491…083ea32
And the delivered artifact was asked what it will start — ./etc/felhom-controller-image read
out of the downloaded archive:
gitea.dooplex.hu/admin/felhom-controller:0.227.1
That is the golden naming the controller it will run, read from the bytes a customer's box would actually fetch — not from the build host, and not from the local file.
The vouch — three fields, all checked
| field | value | why it is right |
|---|---|---|
golden_version |
0.227.1 | baked and round-trip verified above |
agent_version |
0.130.0 | published, and ≥ min_agent |
min_agent |
0.129.0 | read from the golden's controller CHANGELOG header |
agent_version (0.130.0) ≥ min_agent (0.129.0) — not the R-216 shape, where a floor points above
the agent it is served with. wrapper_sha256 was carried through explicitly, because the handler
clears it when omitted. Verified by RE-READING the manifest, not by trusting the flash: golden
option 0.227.1 SELECTED, all four shas matching.
The R-120 gate on this POST refuses a golden below the newest controller the fleet reports; fleet newest was 0.227.1 and the golden is 0.227.1, so it passed rather than being bypassed.
The floor is ACTING, not merely set
Impact preview before the change: {"below":3,"valid":true,"version":"0.227.1"}.
demo-felhom self-updated in under 30 seconds and registered the new job by itself:
[INFO] [selfupdate] Post-update startup: update successful (0.226.1 → 0.227.1)
[INFO] [scheduler] Daily job offsite-integrity scheduled for 2026-08-31 06:00 CEST
That second line is the one worth keeping. A box nobody deployed to now runs the off-site
integrity check on its own schedule — which is the whole point of a floor, observed rather than
assumed. Both demo machines are on 0.227.1; only demo-hp was ever touched by hand.
golden_currency_gate.py went red → green on the same command.
Token hygiene
Copied file → file (scp), never crossing a shell on either side; the bake ran through a runner
script inside the VM that reads the token itself, so it never reached a command line or a transient
unit's properties:
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-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 shred -u'd, and only then was the real log's 0
taken as evidence. A 0 from an untested grep is not a measurement.
Teardown
Build guest 9100 destroyed --purge; token, runner, script and log shred -u'd after the log
was copied out (standing rule 5); VM powered off; disk reverted to virgin. Nothing else provisioned:
no hub record, no host record, no storage entry.