felhom.eu/REPORT.md

REPORT — F10 diagnostic: demo-hp offsite "enabled at the hub, absent on the box" (2026-07-23)

Task: F10 diagnostic spec (project Claude, 2026-07-23) — diagnose first, repair only via the designed path, prove the tier. No code changed in any repo. Full evidence record: documentation/audits/DIAG-f10-demo-hp-offsite-2026-07-23.md.

Phase-0 verdict

Neither of the spec's two candidate shapes. The evidence (hub DB + box state + live logs, every claim cited in the DIAG) proves a third: the day-0 managed floor-update (0.153.0→0.156.0, 07-21 16:28:17Z) killed the offsite apply-bridge ~35 s after it consumed the one-time password (16:27:42Z), before key-install/persist. Consume-then-persist + retry-only-on-restart (offsiteapply.go:106–187) ⇒ the credential was burned, no key was ever installed (so the key-auth-first recovery path could never engage), and every later start logged the consume-404 WARN and gave up. 153 reports over 2 days never carried an offbox object; the hub's "Provisioned…" line is static copy that reads neither consumed_at nor the reports.

• Shape B ruled out from source: managed offsite is fully automatic; the box's „Távoli mentési cél beállítása" button is the BYO NAS/SFTP form only (offbox_handlers.go:44–126).
• Strictly this was the spec's "consumed but persist failed → STOP" class; since the mechanism provably held its fail-safe and the source itself designates the recovery ("the password is spent; reset it on the hub to retry" = the offsite Re-issue), the operator ruled in-session: proceed on the Re-issue path.

Repair (designed path only)

• Operator clicked Re-issue offsite credentials ONCE (R-31 click-once discipline; pre-verified side-effect-free: no escrow blob existed, the box never held the old password, sub3 was empty). Click 09:53:37Z → box consumed 09:53:41 → offsite configured … (pending key escrow) 09:53:45. 8 seconds click-to-converged.
• Escrow ceremony run by the operator through the real /backup/escrow wizard (one-shot R on the operator's screen only): blob stored 10:01:17 (zero_knowledge, pw-hash recorded), hub-verified auto-confirm 10:01:24 → escrowed; offsite runs enabled.

Tier proof (F10 closure bar)

paperless-ngx toggled into offsite scope via the real endpoint (per-app default is OFF). Then, all via real endpoints from inside guest 9201 (endpoint-level method; no browser on DooPlex): probe (md5 9120e65d6a9f071072d827fc404dc840) in the mandatory appdata/paperless/media → first offsite run: repo initialized fresh on sub3, 79.8 MB / 49 files, 1m19s, ok → probe deleted → mode=full restore (size gate 79.8 MB → confirm): snapshot 2bf7f2e1 to staging, staging md5-identical → place: 1 file(s) merged (missing-only), live md5-identical. Cleanup: probe removed, second run (2m17s ok) leaves the latest snapshot probe-free (retention pruned the probe-bearing one); zero residue on box/repo; break-glass + DB copies shredded. Hub now reports demo-hp offsite: enabled/escrowed/quota 50; nightly run scheduled (04:15 UTC).

Product findings + docs

• R-70 (P2-HIGH) minted: the offsite last mile is invisible on both surfaces (hub can't tell staged/consumed/applied; box shows the generic empty state). Coupled to R-31's status-card idiom and the R-39 consumed_at honesty-gauge precedent.
• R-71 (P1) minted: the race itself — recurs structurally on every fresh onboarding whose ISO floor lags the managed floor. Spec-first directions listed in the row (ordering / two-phase consume / hub-side auto-restage with the R-39(a) mint-race guard).
• Audit F10 row annotated: offsite leg resolved; PBS-DR half explicitly stays open (F13 + DR ceremony R-moment). CONTEXT.md updated.

Observed, not acted on

• demo-felhom's 07-21 staged offsite secret is still unconsumed (residue of the mistaken R-39-day offsite Re-issue; box recovered via key-auth-first, which never consumes). Harmless; supports R-70.
• The 3 dead unclaimed-appliance records from the ISO train remain for operator discard.
• Hub pod log only reaches back to 07-22 20:58Z (restart); the 07-21 correlation came from the DB.