admin
55274d5ef3
The gate failed only on `released > baked`, so it could catch a forgotten bake and nothing else. A golden AHEAD of the record passed silently - and that is how controller 0.221.1 was built, baked AND vouched while the newest CHANGELOG heading still read v0.221.0, with every gate green. Reproduced on the real history: newest released 0.221.0 / newest golden baked 0.221.1 -> exit 0. The gate now asks whether the version being shipped is WRITTEN DOWN: the baked version must have its own `## vX.Y.Z` heading anywhere in the CHANGELOG. Membership rather than `baked > released` deliberately - a comparison against the newest heading alone goes green the moment any later entry is written, leaving the unrecorded version permanently unrecorded. INCONCLUSIVE (exit 2) preserved; every refusal names a reason and a route. Red-proofed both directions: old gate/old record exit 0, new gate/old record exit 1, new gate/fixed record exit 0, absent clone exit 2, post-bake exit 0. 08-alarm-ladder.md is new, and its absence was itself the finding: no document owned "when does a broken app raise an alarm?". The rules lived as comments in four packages, each locally correct, with the ordering between them legible only by reading one function top to bottom - which is how R-384 survived review. R-383 and R-384 closed into CLOSED-ITEMS with their rules kept. R-385 filed closed. R-386 filed OPEN: a single-container app stopped out of band raises no alarm, and a comment claims the opposite - measured live, 9 scans, 0 events, against a positive control from the same box 17 minutes earlier. Not fixed here. Golden 0.222.0 baked and published; vouching is the operator's act.
2.0 KiB
Golden bake — controller 0.222.0 (2026-08-23)
Baked and PUBLISHED by Claude Code. NOT vouched — vouching is the operator's act.
| Field | Value |
|---|---|
GOLDEN_VERSION |
0.222.0 |
GOLDEN_SHA256 |
19f5904f53792684f046ec0bc25426645cb87ad73d5cfc6c03639d9f82706037 |
| Controller image | gitea.dooplex.hu/admin/felhom-controller:0.222.0 |
| MinAgent | 0.129.0 (unchanged) |
| Package URL | https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.222.0/golden.tar.zst |
| Archive size | 655,194,776 B (624 MB) |
| LXC template | debian-13-standard_13.6-1_amd64.tar.zst |
Acceptance markers (RUNBOOK-manual-build.md §4.1), each counted from bake.log
| Marker | Required | Observed |
|---|---|---|
docker OK (overlay2 |
≥1 | 1 — docker OK (overlay2; data-root /var/lib/docker) |
including mount point (rootfs + mp0) |
2 | 2 |
upload OK (HTTP 201) |
1 | 1 |
excluding |
0 | 0 |
FATAL |
0 | 0 |
Round-trip check on the published package: HTTP 206 on a ranged GET, so the bytes are fetchable at
the URL Day-0 will use.
One deviation from the runbook, recorded
§4.1 step 2 says to list the current Debian template because "the exact point release rots". On the
virgin snapshot the pveam index is itself stale: pveam available offered
debian-13-standard_13.1-2_amd64.tar.zst, and downloading it failed with
400 Parameter verification failed. template: no such template. pveam update first, then the
list reads 13.6-1 and the download succeeds. The runbook does not say to run pveam update; that
is the step that was missing, and it presents as a confusing 400 rather than as a stale index.
Vouching — the OPERATOR's step, not done here
Hub → Configuration → Day-0 artifacts:
golden_version→0.222.0golden_sha256→19f5904f53792684f046ec0bc25426645cb87ad73d5cfc6c03639d9f82706037min_agent→0.129.0(unchanged)- then, last and in its own save, the global controller floor →
0.222.0.