REPORT.md — golden 0.228.0 baked, vouched, floor raised; demo-felhom self-updated
gates / gates (push) Successful in 12s

This commit is contained in:
2026-08-31 10:54:19 +02:00
parent 04abeb20c0
commit 430fb4448d
+71 -16
View File
@@ -144,8 +144,11 @@ Image digest `sha256:ed28f160fac742dc6d6b22ccee3b7774b49b4f31d67d18099c342f5ce10
Deploy path: `docker pull` → `/etc/felhom-controller-image` → restart Deploy path: `docker pull` → `/etc/felhom-controller-image` → restart
`felhom-controller-bootstrap.service`. Before: 0.227.1 (up 13 h, healthy). `felhom-controller-bootstrap.service`. Before: 0.227.1 (up 13 h, healthy).
**The fleet is on 0.227.1. A golden carrying 0.228.0 is OWED, and it is Viktor's (R-242).** The **DELIVERED the same session, on the operator's instruction.** Golden **0.228.0** baked, published,
`golden-currency` gate says so out loud — see §13. round-trip verified and vouched; the fleet floor raised 0.227.1 → 0.228.0. `demo-felhom` then
self-updated in under a minute and re-registered `offsite-integrity` by itself — so both demo boxes
now re-read their whole off-site store weekly, and only `demo-hp` was ever touched by hand. Full
evidence: `felhom.eu/documentation/tests/golden-0.228.0-2026-08-31/`. See §15.
--- ---
@@ -373,24 +376,76 @@ Ran 4 tests in 0.106s — OK
--- ---
## 13. The push bypassed one gate, deliberately ## 13. One push bypassed a gate, deliberately — and the gate is now green
`felhom.eu`'s `golden-currency` gate is **RED and correctly so**: controller v0.228.0 is released and The **first** `felhom.eu` docs push (`77a5a115`) used `git push --no-verify`. At that moment
the newest golden bake is 0.227.1, so a machine installed right now would receive 0.227.1. That is `golden-currency` was **RED and correctly so**: v0.228.0 was released and the newest golden bake was
not a defect in this work — **it is the state the gate exists to make visible, and baking the golden 0.227.1, so a machine installed right then would have received 0.227.1. That was not a defect in the
is Viktor's (R-242).** It is not a waiver either: a golden is genuinely owed, so recording one would work — it is the state the gate exists to make visible. It was not a waiver case either: a golden was
be false. genuinely owed, so recording one would have been false. The hook sanctions `--no-verify` on condition
that the session report says so; this is that sentence.
The `felhom.eu` docs push therefore used `git push --no-verify`, which the hook explicitly sanctions **It is no longer red.** The golden was baked and vouched later in the same session (§15), the gate
on condition that the session report says so. This is that sentence. Every other gate in that repo is went red → green, and the follow-up push (`1623a4d5`) passed the hook normally with **all 12 gates
green, including `wire-contract`, `one-register`, `due-checks` and `observations`. OK**. Both `felhom-controller` pushes used the hook normally, 13/13.
The `felhom-controller` push used the hook normally and all 13 gates passed.
--- ---
## 14. What Viktor is owed ## 14. What Viktor is owed
1. **Bake and vouch a golden carrying controller 0.228.0, and raise the fleet floor** (currently **Nothing.** No customer action, no data migration, no credential change. The debug page is
0.227.1). Until then the release is written, tested, pushed — and not delivered. operator-only and no customer sees any part of it. The delivery that §13 recorded as owed was carried
2. Nothing else. No customer action, no data migration, no credential change. The debug page is out on the operator's instruction and is verified in §15.
operator-only and no customer sees any part of it.
---
## 15. Delivery — golden 0.228.0 baked, vouched, and the floor raised
| | |
|---|---|
| `GOLDEN_VERSION` | **0.228.0** |
| `GOLDEN_SHA256` | `76a3a98b9e7cc23bf8ae51b38a6272f576df285cb34cd22235ac3f06a31e53ec` |
| size | 658 079 744 B |
| script | `build-golden.sh v3.0.0`, drill VM reverted to `virgin` and cold-booted |
| template | `debian-13-standard_13.6-1_amd64.tar.zst`, after `pveam update` |
**Acceptance markers, counted:** `docker OK (overlay2` 1 · `including mount point rootfs` 1 ·
`including mount point mp0` 1 · `upload OK (HTTP 201)` 1 · `excluding` 0 · `FATAL` 0 ·
`mount point mp1` 0. `felhom-controller:0.228.0` appears 4× in the bake log.
**The 404 pre-gate was proven before its 404 was believed:** the target URL returned 404 while the
existing 0.227.1 package returned 200 on the same command. A 404 from a check that cannot see
anything is not a measurement.
**The evidence is the round trip.** Downloaded size and sha match the bake exactly, and
`./etc/felhom-controller-image` read **out of the downloaded archive** says
`gitea.dooplex.hu/admin/felhom-controller:0.228.0` — the golden naming its controller from the bytes a
customer's box would actually fetch.
**The vouch — three fields together:** `golden_version` 0.228.0, `agent_version` 0.130.0,
`min_agent` 0.129.0 (read from this release's CHANGELOG header, not assumed), `wrapper_sha256`
carried through explicitly because the handler clears it when omitted. `agent ≥ min_agent`, so **not
the R-216 shape**. **Verified by RE-READING the manifest, never by the flash.** The R-120 gate passed
rather than being bypassed.
**The floor is ACTING, not merely set.** Impact preview `{"below":3,"valid":true,"version":"0.228.0"}`;
re-read after the POST confirms `DB override: v0.228.0`. Then, with nobody touching it:
```
[INFO] [selfupdate] Post-update startup: update successful (0.227.1 → 0.228.0)
[INFO] [scheduler] Daily job offsite-integrity scheduled for 2026-09-01 06:00 CEST
[INFO] [offsite-apply] settle-gate: GO — at/above floor 0.228.0 (we are 0.228.0)
```
That is `demo-felhom`. **The second line is the one worth keeping:** a box nobody deployed to now runs
the deeper off-site check on its own schedule — R-399 reaching the fleet, observed rather than assumed.
**Token hygiene and teardown** are recorded in full at
`felhom.eu/documentation/tests/golden-0.228.0-2026-08-31/README.md`. In short: file → file `scp`, a
runner script inside the VM so the token never reached a command line (`systemctl show … | grep -c`
→ 0), the committed log's leak grep **proven with a planted copy (1) before its 0 was believed**,
build guest `9100` purged, secrets shredded after the log was copied out (standing rule 5), VM
powered off and the disk reverted to `virgin`.
**Still NOT live-validated,** unchanged from §7: a real weekly firing at the new depth (next is
2026-09-01 06:00 CEST, now on both boxes), and everything about a large store (R-401).