# REPORT — tester gate: golden re-baked to 0.188.0, fresh-install proof PASSED (2026-07-31)

Written as `REPORT-<topic>.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.
