admin
2ce3c2a0f2
The G-1 session released controller v0.209.0 (R-247), which made golden_currency_gate.py correctly red and REFUSED THE PUSH: no golden carried the newest release. The honest answer to that is the bake it asks for, not --no-verify. The gate's own docstring says the cost of a trip is one bake, which is the operation this project wants to be routine. 656 697 956 B, sha256 c9c4bcd6..e818ff. Round-tripped: the published bytes downloaded back, hashed independently, size and sha identical, and ./etc/felhom-controller-image read OUT of the downloaded archive says felhom-controller:0.209.0 — the delivered artifact naming the controller it will start. Acceptance markers all green (overlay2 x1, mount points x2 rootfs+mp0, upload HTTP 201 x1, excluding/FATAL/mp1 x0), Result=success, ExecMainStatus=0. 404 pre-gate with a 200 control on 0.208.0 so a 404 could not mean "wrong URL". Token file->file into a 0600 file read inside the VM; systemctl show grep = 0; committed-log grep = 0 WITH a control returning 1 to prove the grep works. Bake VM destroyed, /root residue clean, qemu confirmed gone, drill disk restored to virgin. IT ALSO CONSOLIDATES THE OPERATOR'S APPROVAL. Golden 0.208.0 was baked last night and never vouched; 0.209.0 contains everything it did plus R-247, so it supersedes rather than wastes it. One Save, not two — STATUS.md updated accordingly and back to its 93-line screen. NOT VOUCHED. Fresh installs still land on 0.207.0 until the operator saves. And R-242's untouched half showed itself again: this gate flipped green on the presence of the evidence DIRECTORY, with no vouch anywhere near it. Recorded, not built — ROADMAP G-8. repo_gates --fast: all 8 OK, including wire-contract and golden-currency.
Golden 0.209.0 — baked, published, round-trip verified, NOT VOUCHED (2026-08-08)
Why this bake exists, and why it supersedes last night's. The G-1 session released controller
v0.209.0 (R-247), which made golden_currency_gate.py correctly red and refused the push —
no golden carried the newest release. The honest answer to that gate is the bake it asks for, not
--no-verify; the gate's own docstring says the cost of a trip is "one bake, which is the operation
the project wants to be routine anyway".
This also consolidates the operator's approval into ONE. Golden 0.208.0 was baked last night and never vouched. It is superseded rather than wasted: 0.209.0 contains everything 0.208.0 did, plus R-247. Vouch 0.209.0 and 0.208.0 needs no separate decision.
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,
never pgrep -f.
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 6981450 (git status --porcelain empty) |
| controller baked | gitea.dooplex.hu/admin/felhom-controller:0.209.0, built and pushed from a clean tree at fcffaf5 |
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.208.0/golden.tar.zst → 200 ← the control: the URL SHAPE is right
felhom-golden/0.209.0/golden.tar.zst → 404 ← the pre-gate: nothing to overwrite
Acceptance markers — grepped verbatim against this run's log
| marker | count | verbatim |
|---|---|---|
| storage driver | 1 | docker OK (overlay2; data-root /var/lib/docker) |
| mount points — rootfs and mp0, no mp1 | 2 | INFO: including mount point rootfs ('/') in backup · INFO: including mount point mp0 ('/var/lib/felhom') in backup |
| upload | 1 | [golden] upload OK (HTTP 201) |
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.209.0
GOLDEN_SHA256=c9c4bcd6d9f53dcaf3c7a56ffce1c401864a5564af4eca8ff5efd8d5eae818ff
| size | 656 697 956 B — identical to what the bake reported |
| sha256 | c9c4bcd6…e818ff — hashed independently on DooPlex; identical |
./etc/felhom-controller-image read OUT of the downloaded archive |
gitea.dooplex.hu/admin/felhom-controller:0.209.0 |
The delivered artifact saying which controller it will start — not a claim about what was built.
The vouch, awaiting the operator
MinAgent read from the golden's controller CHANGELOG.md header, not assumed:
## v0.209.0 — … — MinAgent 0.127.0.
| field | now (live hub_settings) |
after | why |
|---|---|---|---|
golden_version |
0.207.0 | 0.209.0 | the only field that moves |
agent_version |
0.127.0 | 0.127.0 | already ≥ MinAgent 0.127.0 — checked |
min_agent |
0.127.0 | 0.127.0 | equals the declared MinAgent; not above agent_version (the R-216 shape hub v0.97.0 holds) |
Hub → Configuration → Day-0 artifacts → Golden 0.209.0 → 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 value 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, and a 0 is evidence only because the grep was shown to
work:
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.207.0. The gate checks the BAKE, not the vouch — R-242's untouched half, demonstrated again here: the gate flips green on the presence of this directory, with no vouch anywhere near it.