admin
b7fb2117ae
Part 1. Golden 0.208.0 baked on the drill VM, published and ROUND-TRIP VERIFIED — 656 150 362 B, sha256 ba668f59..5ffb82, and ./etc/felhom-controller-image read OUT of the downloaded archive says felhom-controller:0.208.0. Acceptance markers all green (overlay2 x1, mount points x2 rootfs+mp0, upload HTTP 201 x1, excluding/FATAL/mp1 x0), Result=success. Token file->file, read inside the VM; systemctl show grep = 0; committed-log grep = 0 WITH a control proving the grep works. Bake VM destroyed, drill disk restored to virgin. NOT VOUCHED — the campaign halts there deliberately. golden_currency_gate.py was correctly RED on arrival and is green after the bake. No --no-verify was needed anywhere in this session. Parts 2-4. Seven defect classes swept for siblings by class rather than by feature. Analysis only: no product code, nothing deployed, no machine touched beyond the bake VM. Eight new rows R-256..R-263 (ceiling moved from R-255), grouped by class in OPEN-ITEMS.md. C1 produced no new instance and has no row. The sharpest is R-260: the agent reports operator_key_configured every heartbeat, the hub has no field for it, so the check that answers "can the operator get into this box" returns ok for a box with no operator key installed. Every class states whether its method re-found the known instances, because a method that cannot re-find them has not been shown to work: C1 2/3 (verified by replaying the pre-fix templates), C2 2/2, C3 2/3 + 1 as fixed, C4 fix-pattern re-found, C5 re-found, C6 deadcode 0/2 and bespoke 1/2, C7 weakest and said so. Blind spots stated per class; seven suspicions investigated and DISPROVED, including two of my own methods. Part 4's ranking is in ROADMAP.md as G-1..G-8. Gate C5 (cross-repo tag reachability — cheap, --fast-eligible, would have caught every R-260 instance on the introducing commit). Do NOT gate C6: golang.org/x/tools/cmd/deadcode was measured against a PLANTED probe and is blind to unreachable METHODS on widely-used types, which is exactly the shape both known instances have. R-242's untouched half is recorded, not built: this bake demonstrated it, the currency gate flipping green the moment the evidence DIRECTORY existed, before the round trip finished and with no vouch near it. Correction the campaign owed its own brief: escrow_stale was described as closed; it is R-247 and READY. The live repo is the source. Sampled rather than swept, exactly: C7 60 of 2652 production invariant comments and NONE of the 1440 test comments (that half is owed); C2 19 of 221 refusals; C3/C4 controller only. No finding was reproduced live. STATUS.md is 100 lines against its 93-line one screen.
Golden 0.208.0 — baked, published, round-trip verified, NOT VOUCHED (2026-08-08)
Closes the delivery gap opened by controller v0.208.0 (R-254 — the last two secrets leaving the
page source, plus the gate against a fourth). Before this bake golden_currency_gate.py was correctly
red and a machine installed tonight would have received 0.207.0. Evidence: bake.log (324 lines,
beside this file).
⚠ THE VOUCH IS DELIBERATELY NOT DONE. Campaign 12 §3 halts here and asks the operator for it. The hub still serves 0.207.0 to fresh installs until someone presses Save. See "The vouch, awaiting the operator" below.
Where it ran
The drill VM on DooPlex (/mnt/5_hdd/felhom.eu/drill/drill.qcow2, internal snapshot virgin) —
the accepted Tier-2 exception for bakes, per runbooks/target-selection.md. Launched with the
canonical §4.0 line (if=virtio is load-bearing; the guest expects /dev/vda), cold-booted because
the snapshot is disk-only (0 B VM_SIZE). Restored to virgin afterwards, snapshot list re-read.
Liveness was checked with ps -eo comm | grep -c qemu-system-x86, never pgrep -f, which
self-matches its own command line and reports a false "still running".
The inputs, listed rather than assumed
| host | drill-pve, pve-manager/9.2.2 (kernel 7.0.2-6-pve), 40 G free on / |
| template | debian-13-standard_13.6-1_amd64.tar.zst — listed with pveam available on the day, because the exact point release rots; checksum verified on download |
| build script | felhom-agent/configs/build-golden.sh v3.0.0, from a clean tree at 703db166e762 (git status --porcelain empty, HEAD == origin/main, both checked before the copy) |
| controller baked | gitea.dooplex.hu/admin/felhom-controller:0.208.0 — a required argument; GOLDEN_VERSION is derived from it. Registry manifest confirmed HTTP 200 before the bake started |
The token never crossed a shell
Copied file → file (scp ~/.gitea-token → /root/.gitea-token, 0600), and the bake launched
through a runner script inside the VM that reads the file itself. The older --setenv= form put
the value where systemctl show prints it.
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)"
→ 0
The 404 pre-gate, with a control so a 404 cannot mean "wrong URL"
felhom-golden/0.207.0/golden.tar.zst → 200 ← the control: the URL SHAPE is right
felhom-golden/0.208.0/golden.tar.zst → 404 ← the pre-gate: nothing to overwrite
The filename is golden.tar.zst, not felhom-golden-<VER>.tar.zst — a wrong URL 404s for the
wrong reason and passes even when the version already exists (R-233).
Acceptance markers — each grepped verbatim against this run's real log
| marker | count | verbatim |
|---|---|---|
| storage driver | 1 | docker OK (overlay2; data-root /var/lib/docker) |
| mount points — rootfs and mp0, and there is 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 | — (it stopped existing in build-golden.sh v3.0.0, R-165) |
Result=success, ExecMainStatus=0. Archive 625 MB; volid
local:backup/vzdump-lxc-9100-2026_08_07-22_38_43.tar.zst (rootfs 32 G + ONE data volume 24 G at
/var/lib/felhom, all in the archive).
The publish, and the round trip — the published BYTES, not the local file
GOLDEN_VERSION=0.208.0
GOLDEN_SHA256=ba668f59f063511dda122a5b05900f1350573cdc9619980872f87a58755ffb82
Downloaded back from https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.208.0/golden.tar.zst:
| size | 656 150 362 B — identical to what the bake reported |
| sha256 | ba668f59…5ffb82 — hashed independently on DooPlex; identical |
./etc/felhom-controller-image read OUT of the downloaded archive |
gitea.dooplex.hu/admin/felhom-controller:0.208.0 |
That last line is the one that matters: it is not a claim about what was built, it is the delivered artifact saying which controller it will start.
A fourth, independent confirmation: the sha the hub's own dropdown offers for 0.208.0
(data-sha="ba668f59…", read from /configuration) matches the bake and the round trip. The package
the hub would serve is the one baked here.
The vouch, awaiting the operator — a THREE-field change, all three checked
MinAgent was read from the golden's controller CHANGELOG.md header, not assumed:
## v0.208.0 — … — MinAgent 0.127.0.
| field | now (live hub_settings) |
after the vouch | why |
|---|---|---|---|
golden_version |
0.207.0 | 0.208.0 | the new bake — this is the only field that moves |
agent_version |
0.127.0 | 0.127.0 (unchanged) | already ≥ MinAgent 0.127.0 — checked, not skipped |
min_agent |
0.127.0 | 0.127.0 (unchanged) | equals the controller's declared MinAgent |
min_agent is not above agent_version — that is the R-216 shape, which hub v0.97.0 HOLDS rather
than serving past. In the event this is a one-field move, and it is recorded as three because
checking all three is the point: golden_version alone ships a controller onto an older agent than
it declares it needs.
How: hub → Configuration → Day-0 artifacts → Golden 0.208.0 → Save. The R-120 gate sits on that
save and REFUSES a golden older than the newest controller the fleet reports; a refusal redirects to
?flash=golden_behind_fleet and writes nothing.
Vouching is reversible — re-select 0.207.0 and Save. The 0.207.0 package is not deleted by
this bake (the publish step's pre-delete targets only its own version), so rolling back is a form
submission, not a rebuild.
Teardown
pct destroy 9100 --purge (pct list empty after) · token, runner script, build script and in-VM log
shred -u'd, /root residue listing clean (.bashrc .forward .profile .ssh only) · poweroff ·
qemu confirmed exited via ps -eo comm | grep -c qemu-system-x86 → 0 ·
qemu-img snapshot -a virgin restored, snapshot list re-read.
Token-leak grep on the log that is COMMITTED here — and a 0 is only evidence once the grep is
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: the golden exists, is published, and is byte-verified. golden_currency_gate.py is green
again.
Does NOT: a fresh Day-0 install still lands on controller 0.207.0. The gate checks the BAKE, not the vouch — its own docstring says so, and this bake demonstrated the gap concretely:
The gate flipped from red to green the moment this evidence DIRECTORY existed — before the round-trip download had finished, and with no vouch anywhere near it. Its positive signal is "a directory named after the version is present in the repo". That is R-242's remaining half, measured rather than argued: nothing anywhere catches a skipped vouch. Recorded, not built — see the Campaign 12 report §8.