# REPORT — tester gate: golden re-baked to 0.188.0, fresh-install proof PASSED (2026-07-31) Written as `REPORT-.md` per `CLAUDE.md:82-87` so the shared `REPORT.md` (E-2 increment 1) is not clobbered. Full record with every observable: `documentation/audits/tester-gate-golden-0.188.0-2026-07-31.md`. ## Outcome **§7.2 — YES: a fresh install is safe to hand to an external tester.** ISO boot → claimable, app-serving box in ~10 minutes unattended, and an app's data restored **from the drive with the guest's `app.yaml` gone**, proven readable by the application over its own TCP path. **Golden 0.186.0 → 0.188.0** baked, published, vouched. **No ISO rebuilt** — Part 0 proved none was needed. No existing box changed; floor still v0.156.0, MinAgent still 0.113.0. ## Part 0 — the ISO does not need rebuilding Verified against the ISO **on disk**, not from source. It bakes exactly three Felhom payloads (`felhom-bootstrap.sh`, its unit, the secret-free pairing env) — full-base64 match, 1 hit each — and **0** hits for `SCRIPT_VERSION="1.2`, `felhom-controller`, `vzdump-lxc-9100`. The installer is fetched at run time (`felhom-bootstrap.sh:96`) and the live URL is byte-identical to repo HEAD (sha `ab8b283e…`, v1.22.0, committed six days *after* the ISO). The golden arrives via the hub-vouched artifact manifest (`felhom-host-install.sh:423-433`). The one genuinely baked, drift-capable thing is `felhom-bootstrap.sh` itself — currently at repo HEAD. **Proven live**, not just argued: the fresh box ran `felhom-host-install v1.22.0` and fetched golden **v0.188.0**, sha-verified. ## Part 1 — bake / publish / vouch Baked **0.188.0**, not the brief's 0.187.0: 0.187.0 lacks D5, and Part 2 step 6 *is* the D5 claim, so that golden could not have passed the proof this task exists for. 0.188.0 satisfies R-120 anyway. Stated rather than absorbed, per standing rule 4. GOLDEN_VERSION=0.188.0 GOLDEN_SHA256=7353d8beb63641f87a848e45f8aa12e465647e1190ad164a65b32ad01fc3d299 Three observables: 404 pre-gate (with a 200 control on 0.186.0 so it is not vacuous), then an **anonymous** download returning `http=200 bytes=649310288` and a matching sha; the manifest read back showing `0.188.0` selected; and the consumer call `GET https://hub.felhom.eu/api/v1/artifacts/sess-g` returning the pair. Plus a fourth: a real fresh box fetched and sha-verified it. **R-120's gate evaluated and allowed.** Exercised both ways rather than inferred from silence — vouching 0.185.1 first produced `flash=golden_behind_fleet`, the logged `artifact vouch REFUSED`, and **no write** (the manifest still read 0.186.0); then 0.188.0 produced `Artifact manifest set: agent=0.118.1 golden=0.188.0`. ## Part 2 — the clean-install proof, on demo-hp All seven steps PASS. Venue was demo-hp (Tier 0, the designated drill host) using the scratch dir storage at `/mnt/nvme-1tb` that `target-selection.md:38-40` names; `local-lvm`, `drill-r50` and both 9201s untouched. Highlights: real day-0 pairing → bind → install; a **real** claim (the code is emailed-only, R-119 — the operator relayed it), with the gate flipping `dashboard not yet claimed` → `authentication required`; controller **0.188.0** confirmed *from the box*; **rallly** (postgres) + **homebox** deployed through the real endpoints. The D5 leg: recovery unit `portable-carried=2/2, withheld=0`; the carried `DB_PASSWORD` matched the live one **by fingerprint** (`14c8f515…`, never printed); guest `app.yaml` moved aside; restore returned `secrets recovered=2/2`. Step 7 read the data from **rallly's own network namespace** over TCP to `rallly-postgres` — not the localhost trust socket that produced D5's false pass — and the same path with a wrong password returned `FATAL: password authentication failed`, proving the credential does real work. **The discriminator held: PRE-BACKUP row = 1, POST-BACKUP row = 0.** ## Part 3 — runbook integrity `RUNBOOK-manual-build.md` told the reader to use a "RECORDED" qemu line that is itself labelled *reconstructed*, and whose source says it *"was never saved"*. The real invocation is now captured from this bake and recorded as canonical in **§4.0**, alongside the bake/publish/teardown steps, the template-rot warning and where the R-120 gate actually lives. The old runbook's deviation entry is marked SUPERSEDED with a forward pointer. ## Teardown — three layers 1. VM 310 destroyed with `--purge --destroy-unreferenced-disks 1`; `/mnt/nvme-1tb/images/` empty. 2. `cc-scratch` removed, `storage.cfg` back to its original four entries; `felhom-backup` available **926 492 284 KiB before and after** — space returned exactly. 3. Hub: **`sess-g` and its host record DELETED, full cascade** — `customer DELETE cascade COMPLETE for sess-g (journal #8) — full teardown`, residue purged including `appliance_registrations=1`. Verified positively: `/configs` and `/hosts` both loaded (10160 / 9880 bytes) with **0** hits for `sess-g` and 0 for the appliance UUID. The gate refused twice first (409 host ONLINE, then 400 missing acknowledgements) — the record cannot be deleted until the destroyed box ages out of ONLINE, ~30 min. **`sess-f` deliberately NOT deleted** (R-131); its command is in the audit §7.1. Secrets shredded in the guest and on the box. ## Findings — filed, none fixed `R-128` ISO_VERSION/SCRIPT_VERSION comment is false · `R-129` demo-hp's "no baked SSH key" is stale (key auth works) · `R-130` `HARD_MIN_LVM_GIB` warns and proceeds — a hard min that is not hard · `R-131` `sess-f` is a fourth orphaned scratch customer · **`R-132` — `curl -w '%{redirect_url}'` printed the hub operator password into a session transcript; `HUB_PW` needs rotating.** ## Not done, deliberately No ISO built; no defect fixed; no golden deployed to an existing box; no floor or MinAgent change; offsite/PBS-DR legs not exercised (the task forbids pointing anything at production PBS or the real restic offsite, so `sess-g` ran DR-tier off); Campaign 10, the demo-hp repartition and subdomain onboarding untouched.