## Claims in the prompt that turned out wrong — settled so far (measured, not argued) 1. **"A custom PBS role can carry just `Datastore.Modify`" — FALSE, and the prompt itself flagged it as unverified.** Proxmox Backup Server has **no role-create command** and no custom roles: the CLI describes `` as "Enum representing roles via their [PRIVILEGES] combination", and `proxmox-backup-manager` offers no `role` subcommand at all. I then measured the narrowest BUILT-IN role by applying it and reading the effective permissions back: `DatastorePowerUser` grants **Datastore.Backup + Datastore.Prune only** — it does not help. `DatastoreAdmin` grants Audit, Backup, Modify, Prune, Read, Verify, and is therefore the narrowest role that works. It is applied for the hub's `felhom@pbs` on `/datastore/felhom-offsite` only; the per-customer `DatastoreBackup` entries are untouched. 2. **"The banner unit can learn the claimed state" — NOT REACHABLE, as the prompt suspected.** Two measurements: the one-shot bind delivery emits `FELHOM_CUSTOMER_ID`, `FELHOM_RETRIEVAL_PASSPHRASE`, `FELHOM_MODE` and `FELHOM_EXTRA_ARGS` — **no domain** — so the console cannot name the dashboard URL without inventing it; and the unit hands over to the host install and exits, so the later CLAIM happens when nothing is watching. What IS reachable, and is what shipped: the pairing code stops being the last thing on the screen the moment the bind lands. The rest of R-535 is recorded as a residue rather than implied away. 3. **The baseline "ISO 1.27.1 published → target 1.28.0" needed care, and the care found a trap.** `installer-v1.28.0` **already existed as a git tag** — from 2026-08-13 — because the install SCRIPT and the ISO IMAGE are two separately numbered artifacts (`SCRIPT_VERSION` vs `ISO_VERSION`, and `build-felhom-iso.sh` says so in a comment). The published ISO really was 1.27.1 (confirmed live: the bucket serves 1.27.1 and 404s 1.28.0), so the target is right — but a session that read the tag list as the ISO history would have concluded 1.28.0 was already published. 4. **Still open at the time of writing:** "the off-site wizard's full restore brings back deleted files for nextcloud" — proven for immich in July and read from the design for nextcloud; Part E walks it. 5. **„The off-site wizard's full restore brings back deleted files for nextcloud" — TRUE, now measured.** It was proven for immich in July and read from the design for nextcloud. Tonight it was walked: five photos, deleted, returned byte-identical (sha256 5/5, negative control). 6. **My own wrong reading, recorded because I nearly filed it as a product fault.** I reported the data drive as „formatted but not mounted, 42 minutes on" from `/api/disks/candidates`. The storage page said the opposite and was right — the drive was mounted, registered and default. The endpoint reports raw disks from the agent, not what the controller has registered (now **R-542**). ## What shipped **controller v0.244.0** — the backup label is PER TIER and no longer claims files a Tier-1 unit cannot hold (R-537); a unit restore REFUSES before touching anything when it cannot return the app's drive-side files, and names the route that can (R-538); `app_deployed` moved from the deploy's acceptance to its completion, with `app_deploy_started` / `app_deploy_failed` as the honest pair (R-536). Plus the pending „0 B" tile fix. **hub v0.116.0** — off-site backup is ON by default for a new customer (shared, 100 GB prefilled), and the two new deploy event types are registered in both `allowedEventTypes` and `customerMessages`. **ep0** — one narrow grant: `DatastoreAdmin` for the hub's `felhom@pbs` on `/datastore/felhom-offsite` only. The narrowest role was MEASURED: `DatastorePowerUser` carries Backup+Prune only, and PBS has no custom roles. Per-customer `DatastoreBackup` entries untouched. **ISO 1.28.0** — built, gate-checked, installed and walked. **NOT published** — that is the operator's call and the one STOP of this task. **golden 0.244.0** — baked, published, vouched as a three-field change (agent and min_agent unchanged at 0.131.0), fleet floor raised 0.242.0 → 0.244.0 and already delivering (demo-felhom moved itself). ## Red-proofs Each fix seen failing with its own sentence, then passing: the app-shaped label restored → the Tier-1 assertion fails; the guard disabled → „a restore that cannot return the files must refuse" fails; the accept-time call put back → „the deploy handler announces an INSTALLED app at accept time" fails; the success hook removed → „the deploy ended and nothing was told about it" fails; the hub default dropped → „the new-customer form does not default the off-site copy ON" fails. ## The walk, end to end (evidence: `audits/evidence-backup-promise-2026-09-16/`) Fresh VM from the BUILT image → Felhom's own first screen, no admin URL → registered itself → **bound with zero operator presses** (the mail the hub sent itself after the morning's host delete) → claimed → landed on agent 0.131.0 + controller 0.244.0 → data drive registered → Nextcloud deployed → five photos in → tier-1 leg → **the PBS cascade stopped at R-511's refusal and needed ONE operator press**, which then succeeded because of this morning's grant → escrow ceremony (re-auth required; code shown once, captured out-of-band) → tier-3 „Sikeres" → photos deleted → **the old route REFUSED and touched nothing** → off-site restore (verification copy, then reconstitution: „5 fájl és 3 adatkötet és az adatbázis") → **the photos open, byte-identical** → teardown in three layers → the automatic connect e-mail again, one second after the host delete. ## Rows Opened: R-539, R-540, R-541, R-542, **R-543** (P1 — off-site on by default is not off-site working on day one), R-544. Closed: R-511, R-534, R-536, R-537, R-538. Register 236 → 244 open. ## Checks `repo_gates.py --fast` green at every push; controller `go build/vet/test` green; controller gates 15/15; `unproven.py --summary` unchanged at 35 of 55 not walked. Secret-leak check on the evidence: six real secret values as needles, planted control matched 6/6, committed evidence 0.