docs: R-223 CLOSED by a golden rebake — and it was never a dropdown

The first vouch of agent 0.125.0 was REFUSED by R-120's gate: the artifacts form saves as a unit, and golden 0.192.0 was older than the newest controller the fleet reports. The golden had been stale since before controller 0.193.0, so the Day-0 manifest had been effectively unvouchable for days and nobody had cause to notice. Correcting STATUS.md and OPEN-ITEMS, which said "one dropdown". Golden 0.201.0 baked in the drill VM, round-trip verified from Gitea (e730d7cab343eb35...f007654, 658165766 B), teardown clean, 0 token hits in the saved log. Manifest now agent=0.125.0 golden=0.201.0 min_agent=0.125.0, read back after the save. The held floor: the HOLD is established positively (hub log + the box's own "floor still unknown"). Its RELEASE is not — no HELD line and no dashboard reason are both absences, the served path logs nothing by design, and the box-side positive needs a restart the venue cannot take before Phase 2. Recorded as deduction plus a pinned test, not a live positive.
2026-08-05 22:29:30 +02:00
parent 1a0f7db92f
commit 3a539ea530
3 changed files with 83 additions and 8 deletions
@@ -1127,3 +1127,78 @@ This is also the live proof of **R-202**'s open concern: the orphan card promise
 hozzá tartozó helyreállítási kóddal később visszaállítható lehet"*. Here is a customer **with** that
 code, and the answer is "wrong code". → **R-222.** Per the brief: the gap is recorded, **nothing was
 built.**
+
+
+---
+
+## The fix pass (2026-08-05, evening) — and the golden rebake it turned into
+
+Six findings fixed in controller **v0.201.0** + hub **v0.97.0/0.97.1**, each red-proofed. Full account:
+`felhom-controller/REPORT.md`.
+
+### R-223 — vouching agent 0.125.0 was NOT a dropdown, and the manifest had been frozen
+
+The first vouch attempt was **REFUSED**, correctly, by R-120's gate (`hub/internal/web/configs.go:1162`):
+
+```
+[WARN] artifact vouch REFUSED: golden 0.192.0 is older than the newest controller
+       the fleet reports (0.201.0) — a fresh install would land on stale application code (R-120)
+```
+
+The manifest was **verified unchanged afterwards** rather than inferred from the HTTP 303 (which is a
+redirect carrying the refusal, not a success).
+
+**The artifacts form saves as a unit**, so the agent could not be vouched while the golden was stale —
+and the golden had been 0.192.0 since before controller 0.193.0 shipped. **The Day-0 manifest had
+therefore been effectively unvouchable for days, and nobody had cause to notice because nobody tried.**
+That is the finding; the "one dropdown" I first reported was wrong.
+
+### The rebake — golden 0.201.0
+
+Baked in the drill VM on DooPlex (the sanctioned exception for bakes, `target-selection.md`).
+Preconditions checked first: 6.6 T free, **no qemu held the qcow2 — proved by the revert succeeding**,
+`virgin` intact, Debian template `13.6-1` listed rather than assumed (the point release rots) and
+checksum-verified on download.
+
+| | |
+|---|---|
+| artifact | **658 165 766 B**, sha256 `e730d7cab343eb35bcef627829b40c160f83945e0a9bd57da546efc21f007654` |
+| markers | `Result=success` · `ExecMainStatus=0` · **no** `FATAL`/`excluding`/`ERROR` · `docker OK (overlay2; data-root /var/lib/docker)` · `including mount point rootfs ('/')` **and** `mp0 ('/var/lib/felhom')` · `upload OK (HTTP 201)` |
+| round trip | **the bytes downloaded from Gitea hash identically.** A local checksum proves only that the local file is what it is |
+| token hygiene | token read from a 0600 file **inside** the VM, never on a command line; literal-value grep on the saved log → **0 hits** |
+| teardown | guest 9100 `--purge`d · token/script/log shredded **after** the log was copied out for evidence · qemu exited (checked by `ps -eo comm`, not `pgrep -f`, which self-matches) · disk reverted to `virgin` |
+
+*Doc drift noticed, not acted on: the runbook's pass markers say `including mount point` for rootfs
+**and mp0 and mp1**. `build-golden.sh` v3.0.0 bakes ONE data volume, so two mount points is correct
+and the runbook describes an older layout.*
+
+### The manifest, read back after the save
+
+```
+agent_version  = 0.125.0   agent_sha256  = f7d8339b53d92a6c…7016b3
+golden_version = 0.201.0   golden_sha256 = e730d7cab343eb35…f007654
+min_agent      = 0.125.0
+```
+
+**A machine installed from now on lands on current agent AND current controller**, and can open a
+recovery package on day one. R-223 closed.
+
+### The held floor — what is and is not established
+
+**Established, positively, that the hold WAS in force**: the hub logged it with the corrected reason
+(*"floor 0.200.0 is ABOVE the vouched golden 0.192.0…"*, 22:12:06), and the box observed it from its own
+side — `[offsite-apply] settle-gate: GO — floor still unknown after 1m30s`, which is what a withheld
+directive looks like to a controller.
+
+**NOT established by a positive observable: that the hold is now released.** After the vouch, c11's
+next report (22:27:06) produced **no** HELD line and the Hosts dashboard renders **no** held reason —
+but both of those are absences, and this project's own rule is that an absent log line is not evidence.
+The hub logs nothing on the served path by design, and `SetFloor` is DEBUG-only and fires only on a
+change, so the box-side positive would need a controller restart — **which is not taken, because Phase 2
+needs the venue as it is.**
+
+What can be said with certainty is the arithmetic the code performs: floor `0.200.0` ≤ golden `0.201.0`
+(so the beyond-golden branch cannot fire) and agent `0.125.0` ≥ min_agent `0.125.0` (so the
+below-MinAgent branch cannot fire) — the exact combination
+`TestResolveManagedFloor_R216_FloorAboveGolden/floor_at_the_golden_→_unchanged_behaviour` pins as
+served. **Deduction plus a pinned test, not a live positive. Recorded as such.**