admin
1eb64bec51
07-backup-architecture.md gains a dated [FACT] on R-361 - a comment asserting an invariant the code did not have, for four months - and a [DESIGN] on the db_dumps decision INCLUDING the trap it created: a stable list lets the already-current early return fire, so per-capture housekeeping must sit above it. 00-capability-map.md records the NEGATIVE from Part 3 so it is not re-derived: a held app does NOT raise the dead-app alarm. It aggregates to unhealthy, which IsDownState excludes. Measured on the shipped build with the scans demonstrably running over it. No suppression was built and no row opened. R-383: the double-failure message names an undo copy that is not there - R-361's own class, one surface over, observed on both 0.220.2 and 0.221.1. R-384: an app whose database has died reads unhealthy and raises no alarm. R-361 closed and compressed. OPEN-ITEMS 325236 -> 327266 bytes. Golden 0.221.1 baked, published and round-trip verified. The golden-currency gate blocked this push and that block is not circular, so it was satisfied rather than bypassed - no --no-verify anywhere in this session.
3.0 KiB
Golden bake — 0.221.1 (2026-08-23)
Baked in the drill VM on DooPlex per documentation/runbooks/RUNBOOK-manual-build.md §4.0/§4.1,
carrying controller v0.221.1 (R-361 — the safety dump no longer destroys the app's own database
backup, plus the follow-on that keeps the undo-copy cap reachable).
GOLDEN_VERSION |
0.221.1 |
GOLDEN_SHA256 |
1c8bf6cf08cadabeca6331f38360d905e867c235067cd10c2716915b6e6df089 |
| package | https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.221.1/golden.tar.zst |
| size | 656 966 079 B |
| controller image | gitea.dooplex.hu/admin/felhom-controller:0.221.1 |
| template | debian-13-standard_13.6-1_amd64.tar.zst (listed fresh, checksum verified on download) |
build-golden.sh |
v3.0.0, from felhom-agent @ 40d857b52711 |
MinAgent |
0.129.0 (from the controller CHANGELOG header — unchanged) |
Why this bake happened in this session
The golden-currency gate refused the docs push: 0.221.1 was released with no golden carrying it.
That block is not circular — a golden needs the controller image, which was already built and
pushed, not the docs commit — so the gate was satisfied by doing the work it asked for rather than
bypassed. No push in this session used --no-verify.
Pass markers — each checked, with the negative controls
docker OK (overlay2 : 1 -> " docker OK (overlay2; data-root /var/lib/docker)"
including mount point : 2 -> rootfs ('/') and mp0 ('/var/lib/felhom') [there is no mp1]
upload OK (HTTP 201) : 1 -> pre-delete returned HTTP 404 (404/204 expected)
excluding : 0 <- negative control
FATAL : 0 <- negative control
The 404 pre-gate was controlled before it was believed: the same URL shape for 0.220.2 returned HTTP 200 in the same minute, so the 404 on 0.221.1 means absent, not a wrong URL.
Verified by ROUND TRIP
Downloaded again — HTTP 200, 656 966 079 bytes — and the sha256 recomputed: 1c8bf6cf08ca… on
both sides. What a machine receives is byte-identical to what was baked.
Token hygiene
Copied file → 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,
and that grep was proved able to convict first (planted copy → 1, copy shredded). The same
control was run on the committed bake.log: 0, positive control 1.
Teardown
pct destroy 9100 --purge; token, runner, build script and in-VM log shred -u'd after
bake.log was copied out — all four confirmed absent; poweroff; waited for qemu to exit;
qemu-img snapshot -a virgin.
NOT vouched
The hub's Day-0 artifact manifest was not changed and the floor was not raised. Both are the operator's, and it is a three-field save:
| field | value |
|---|---|
golden_version |
0.221.1 |
agent_version |
0.130.0 |
min_agent |
0.129.0 |