diff --git a/CONTEXT.md b/CONTEXT.md
index ed6653f..040a9f5 100644
--- a/CONTEXT.md
+++ b/CONTEXT.md
@@ -17,6 +17,38 @@
 
 ## Standing rulings
 
+**S-28 — the escrow retention now covers the OFF-SITE data key, and customer-present recovery is the
+accepted design, which makes that retention load-bearing (2026-08-04, R-198/R-197; hub v0.93.0).**
+
+**The contract changed, and this is the sentence to carry:** when an escrow blob supersedes another,
+`demoteCurrentEscrowTx` retains **both** sealed keys — the K-escrow `blob` (PBS datastore key) **and**
+`identity_blob` (the age-wrapped bundle carrying the restic **repository** password). Until v0.93.0 it
+retained only the first, so the retention preserved the whole-guest key and destroyed the off-site data
+key, and **the destroying act was the escrow ceremony a rebuilt box asks its customer to run.**
+
+*Why this is load-bearing rather than tidy:* the operator ruled on 2026-08-04 that **candidate (c) is
+refused — no repository password is retained on the Proxmox host.** With no host-retained copy, the
+**customer-present recovery path is the only way back from a rebuild**, and it runs entirely through
+the retained identity blob. A session that touches escrow custody is touching the single copy.
+
+*Facts a future session needs before touching this area:*
+- **The ordering is load-bearing and invisible from the routine.** `SaveHostDRBundle` writes
+  `identity_blob` **after** `SaveHostEscrow` returns (the escrow PUT, `api/handler.go`), so at demote
+  time `host_escrow` still holds the OLD identity blob. Invert that and the retained bytes become the
+  NEW blob filed under the OLD hash — recoverable-looking and wrong. Pinned by
+  `TestSaveHostEscrow_RetainsIdentityBlob`.
+- **`demoteCurrentEscrowTx` is shared by re-escrow and host-delete.** Both have a test; fixing one
+  caller instead of the routine is a demonstrated red-proof, not a hypothetical.
+- **Nothing was backfilled and nothing could be** — pre-v0.93.0 retained rows have no identity blob and
+  their source rows are already overwritten. Both demo boxes' pre-2026-08-04 repository passwords are
+  gone permanently, recovery code or not.
+- **A retained key is not a recovery.** The hub's blob-serving endpoints have no client (R-199), the
+  injection seam has no form (R-200), and the path has never been exercised (R-201). v0.93.0 makes the
+  key survive; it does not hand it back.
+- **`offsite_repo_key_changed`** (R-197, warning, operator-only, edge-triggered on a supersession where
+  both hashes are known and differ) is the evidential signal that a box's off-site data key moved. It
+  carries **no hash value**. `MarkEscrowStale` is **precautionary**, not evidential — see S-26(a).
+
 **S-27 — a customer with NO machine ever bound is UNKNOWN, silently; one that was bound and went quiet
 still alarms (2026-08-04, R-195; hub v0.92.0).** Operator ruling, implemented as
 `store.HasEverBoundHost` (live `hosts` row OR `host_deletions` tombstone) consulted once at the top of
diff --git a/REUSE.md b/REUSE.md
index d37ae96..da5f4e9 100644
--- a/REUSE.md
+++ b/REUSE.md
@@ -78,6 +78,7 @@
 | `(*Store).HasEverBoundHost` (v0.92.0, R-195) | hub/internal/store/store.go | `(customerID) (bool, error)` | Any verdict that must not fire for a customer with **no machine ever bound** — "was anything ever expected of this customer" | `hosts` row **OR** `host_deletions` tombstone. **NOT a liveness check and never a substitute for one:** a box that was bound and went silent returns `true` and must keep alarming — that is the case any change here breaks first (pinned by `TestCheckBackupDeadlines_BoundButNeverReported_StillAlarms`). Callers **fail OPEN** on its error: an unreadable binding must never SUPPRESS an alarm. Do **not** re-derive this from report presence — `store.GetCustomers()` (and therefore the staleness checker's `down` state) is a query over `reports`, so a never-reported customer has no state at all, which is exactly how the daily false alarm reached `david`. |
 | `(*Server).configFormData` (v0.49.0) | hub/internal/web/configs.go (~L430) | `(r, isNew, cfg, overrides, errMsg) configFormView` | The ONE view-model builder for the customer config form (standalone chrome + the customer page Edit tab) | `overrides=nil` → parses the STORED cfg.ConfigJSON; pass the SUBMITTED map on the update validation-error re-render or typed values reset (red-proofed). |
 | `config_form_body` sub-template (v0.49.0) | hub/internal/web/templates/config_form_body.html | `{{template "config_form_body" <configFormView>}}` | Rendering the config form on ANY surface (config_form.html chrome + customer Edit tab) | The floor/geo/danger cards on the Edit tab are SIBLINGS after `</form>` — never nest a form inside it (breaks the offsite/PBS formaction sub-buttons). Includes the F5 in-flight `<script>`. |
+| `demoteCurrentEscrowTx` (+ `(*Store).SaveHostEscrow`) | hub/internal/store/store.go (~L2597/~L2612) | `(tx, hostID) (int64, error)` / `(hostID, blob, fp, posture, createdAt, resticPwSHA) (superseded bool, prevResticPwSHA string, err error)` | **THE ONE escrow row-copy routine** — used by the re-escrow retention AND by `DeleteHost`'s custody demotion; never write a second one | **It must copy BOTH sealed artifacts** — `blob` (K-escrow / PBS key) and `identity_blob` (the age bundle carrying the offsite restic repo password). Omitting the second is R-198: two months of retaining the wrong key, with the ceremony as the destroying act. **Ordering it depends on:** `SaveHostDRBundle` writes `identity_blob` AFTER `SaveHostEscrow` returns, so the demote sees the PREVIOUS generation — invert that and the retained bytes are the new blob under the old hash. Pinned by `TestSaveHostEscrow_RetainsIdentityBlob` + `TestDeleteHost_DemotesIdentityBlob` (both callers). `prevResticPwSHA` feeds R-197's changed-key signal; it is a hash and never leaves the store. |
 | `(*Store).CountHostArtifacts` / `DeleteHost` | hub/internal/store/store.go (~L1640/~L1690) | `(hostID) (HostArtifacts, error)` / `(hostID, deleteEscrow bool) error` | Host-delete impact preview + the ONE-transaction cascade | ONLINE gate lives in the handler, escrow gate in the store (`ErrHostEscrowPresent`, tx never starts). log_bundles die by `scope_id == host_id` ONLY (customer-scoped bundles survive). The wg_peers delete is INSIDE the tx — never split it out. |
 | `(*Server).commitCustomerReset` (v0.69.0) | hub/internal/web/customer_reset.go (~L165) | `(ctx, cfg, resetID int64, purgeEscrow bool) *resetLegError` | THE committed RESET sequence — external teardown FIRST (Hetzner, PBS), then claim → descriptor → DB purge, each leg stamped into the `customer_resets` journal | Owns NO gate, NO audit event, NO journal open/close, NO redirect — those are the caller's (the two callers differ there). `purgeEscrow` governs ONLY whether `PurgeCustomerResetDBState` destroys retained custody: standalone RESET passes the operator's `escrow_ack`; the DELETE cascade passes **false** so custody dies exactly once, in its leg 3. Returns a `resetLegError` carrying the leg name + the exact status/message the standalone handler has always returned — do not re-word them. |
 | `(*Store).CustomerResidue` / `PurgeCustomerResidue` (v0.70.0) | hub/internal/store/customer_delete.go | `(customerID) (*CustomerResidue, error)` / `(customerID) error` | Counting + purging the report-derived state and the credential-bearing bindings a deleted customer leaves behind | **`GetCustomers()` is REPORT-derived** — until the reports are gone the customer stays on the Customers list AND stays in the staleness/offsite checkers’ work list, so a deleted customer keeps emailing the operator. Both funcs walk ONE shared `residueQueries` list so a table can never be counted-but-not-purged. Includes `appliance_registrations` + `selfbind_tokens` (credential-bearing, not telemetry). NEVER touches `events`, `notification_log`, `host_deletions`, `customer_resets`. |
diff --git a/STATUS.md b/STATUS.md
index 697c58e..6d2ab6c 100644
--- a/STATUS.md
+++ b/STATUS.md
@@ -20,40 +20,33 @@ Proven end to end on real hardware.
 
 ## What's broken
 
-- **Rebuilding a machine throws away its off-site backup HISTORY — and that is worse than we thought
-  yesterday.** We spent today establishing what a rebuild actually destroys, and the answer changes the
-  picture. There are three secrets involved. The one we have been talking about — the password to the
-  storage provider — is the one you can re-issue any time, and we did. **The one that matters is the
-  key that encrypts the backups themselves. The machine invents that key, and a rebuilt machine
-  invents a brand-new one**, so the old backups can no longer be opened by the machine that wrote
-  them.
-  **Both demo machines did exactly this, and one of them did it silently.** demo-hp lost access to
-  15 backups (41 MB). demo-felhom — the one we called lucky, because its off-site copy came back on
-  its own in 76 seconds — **lost access to 36 backups (1.14 GB), and nothing said a word for
-  thirteen hours.** The luck restored the delivery, not the history.
-  Nothing has been deleted, and this was measured without touching either machine or any password.
-  **The next scheduled off-site run is tomorrow at 04:15, and it will refuse rather than quietly start
-  a new history** — the machine already knows how to recognise this and asks before resetting.
-  **There is a decision here for you — see "Waiting on you".** *(R-193, R-192, and two new items)*
-- **And the safety net we believed was under all of this is not there.** We traced the whole path today —
-  from a dead machine to reopened backups — and it does not join up. The important part is not that
-  several steps are manual; it is this: **the central hub keeps the old sealed key when a machine
-  re-seals, and we found it keeps the wrong one.** It keeps the key for the whole-machine backups and
-  **not** the key for the off-site file backups — the one this entire problem is about. So the moment
-  a rebuilt machine is asked to make a new recovery code, which is exactly what it asks the customer to
-  do, **the last copy of the old key is gone.** Both demo machines crossed that line yesterday morning.
-  **This means the 51 orphaned backups were beyond reach even if you had kept the recovery codes** —
-  which is a relief in one narrow sense and much worse in every other. It also means the customer is
-  currently told, in Hungarian on their own screen, that their old backups "may later be restorable
-  with the matching recovery code". That sentence is not true today. It is a small fix — one missing
-  column — and it must land before anything else here. *(R-198)*
-- **Nothing in the recovery path has ever been performed.** Making a recovery code is proven, live,
-  with a real customer. **Using one is not.** No sealed package has ever been handed back to a machine
-  (the hub has the buttons for it; nothing anywhere presses them), no recovered key has ever been put
-  back, no old backup store has ever been reopened, and no file has ever been restored from a recovered
-  key. There is a form missing, a step missing, and a connection missing between two parts of the
-  system. We designed the exercise that would prove it end to end — see "Waiting on you".
-  *(R-199, R-200, R-201)*
+- **Rebuilding a machine still throws away its off-site backup HISTORY.** The machine invents the key
+  that encrypts its own off-site backups, and a rebuilt machine invents a brand-new one, so the old
+  backups can no longer be opened by the machine that wrote them. Both demo machines did this on 3–4
+  August — demo-hp lost access to 15 backups (41 MB), demo-felhom to 36 (1.14 GB), and **the second one
+  happened in silence for thirteen hours**. From today that silence is fixed (below) and the old key
+  survives the ceremony (below), but **the rebuild itself still starts a fresh history**, and getting
+  the old one back is a path nobody has walked. *(R-193)*
+- *(fixed 4 Aug)* ~~The safety net we believed was under all of this is not there.~~ **The central hub
+  was keeping the wrong key, and the fix shipped the same day.** When a machine re-seals its backups
+  under a new recovery code, the hub keeps the old sealed package — but it was keeping the one for the
+  whole-machine backups and **not** the one for the off-site file backups, which is the whole point. And
+  because the swap happens in one motion, **the act that destroyed the old key was the recovery-code
+  ceremony itself** — the exact thing a rebuilt machine asks its customer to do, on a screen promising
+  the old backups stay recoverable. Both keys are now kept. **What this cannot undo:** anything
+  superseded before today is gone for good, which includes both demo machines' pre-4-August keys — so
+  those 51 orphaned backups were beyond reach even if the recovery codes had been kept. *(R-198)*
+- **Nothing in the recovery path has ever been performed, and that has not changed today.** Making a
+  recovery code is proven, live, with a real customer. **Using one is not.** No sealed package has ever
+  been handed back to a machine, no recovered key has ever been put back, no old backup store has ever
+  been reopened. Today's work makes the key **survive**; it does not build the path that hands it back.
+  That is what the proof exercise is for. *(R-199, R-200, R-201)*
+- **One screen still tells the customer something we cannot yet promise.** The „elárvult tároló" card
+  says the old backups may later be restorable with the matching recovery code. From today that is true
+  for machines that re-seal from now on and **false for anything already orphaned** — and the machine
+  cannot tell which case it is in without the recovery path above. We deliberately did **not** patch the
+  sentence: a conditional promise that can still be wrong is worse on that screen than a vague one.
+  *(R-202)*
 - *(fixed 4 Aug)* ~~The weekly off-site backup reports FAILED although it worked.~~ It uploaded fine
   and then tripped on a tidy-up step it is deliberately not allowed to perform. The machine no longer
   asks — tidying up is the endpoint's job, and **that was checked first**: the endpoint has been doing
@@ -96,9 +89,10 @@ Proven end to end on real hardware.
 
 ## What we're working on
 
-- **Now:** waiting on your answer about the backup key (above). Two small honesty fixes are ready to
-  go the moment you say so — making a changed backup key raise an alarm, and correcting an email that
-  currently states the opposite of what it measured. Neither needs a decision.
+- **Now:** the proof exercise — wipe a demo machine and recover it with a saved recovery code. It is
+  designed and waiting on your go-ahead. Both honesty fixes shipped today: a changed backup key now
+  raises an alarm on the day, and the email that stated the opposite of what it measured now describes
+  what it actually saw.
 - **Also tomorrow:** confirming what the 04:15 off-site run does on both machines. We expect it to
   refuse and ask, rather than start fresh — but that is a prediction from the code, not something
   anyone has watched happen.
@@ -109,24 +103,11 @@ Proven end to end on real hardware.
 
 ## Waiting on you
 
-- **A real decision, and it is the important one on this page.** Every machine is going to be
-  reinstalled at some point, and each reinstall throws away the key that opens its off-site backups.
-  There are only two honest answers, and picking either is fine — picking neither is what leaves it
-  where it is.
-  **(a) Keep a copy of that key on the Proxmox host**, which survives a rebuild. The machinery for
-  this already exists and is barely any work. The price: the key would then sit on a machine you have
-  root on, so "only the customer's recovery code can open these backups" stops being true in the
-  strict sense. It was never quite true anyway — you hold root everywhere — but this makes a real
-  second copy, and copies are exactly what we are already uneasy about elsewhere.
-  **(b) Leave the key sealed under the customer's recovery code**, accept that every rebuild starts a
-  fresh off-site history, and make sure the system says so loudly on the day it happens instead of
-  never. Old backups are kept, not deleted, but they keep consuming the customer's off-site space.
-  **We recommend doing the "says so loudly" part immediately regardless** — it is cheap, it costs
-  nothing else, and it is the piece whose absence let a gigabyte of history go quiet for thirteen
-  hours. What we are asking you to choose is (a). *(R-193; the full reasoning is in the findings
-  document)*
-  **Correction to (b), from today:** "old backups are kept" is true, but "openable later with the
-  recovery code" is **not** — see R-198 above. Option (b) is only honest once that is fixed.
+- *(decided 4 Aug — recorded here until the work it unblocks is done)* You chose **not** to keep a
+  copy of the backup key on the Proxmox host. That is a coherent choice and it has a consequence worth
+  restating: **the customer's own recovery code is now the only route back from a rebuild**, so the
+  sealed package the hub keeps is the single copy. Today's fix is what makes that true rather than
+  wishful — until this morning the ceremony destroyed it. *(R-193)*
 - **Your ruling about the recovery screen has been priced, and it can be built.** You said: a freshly
   installed machine that finds a sealed package waiting should say so loudly, offer the customer a box
   to type their recovery code into, and show what would come back before doing anything. **All of it is
@@ -146,11 +127,12 @@ Proven end to end on real hardware.
   marked file comes back byte for byte. About half a day, of which under an hour needs you. The failure
   we are watching for is precise: **if the recovered machine reports one backup instead of the ones we
   put there, it started a fresh history and the proof failed** — "the store opened" is not good enough.
-  It costs that machine's contents if it goes wrong, which is acceptable there. **Do R-198 first**, or
-  the exercise walks a path that is missing a piece. *(R-201)*
-- **The orphaned backups still on the storage box.** About 1.2 GB across the two demo machines, sitting
-  in set-aside stores nobody can open and nothing prunes, using the 50 GB allowance. We did not touch
-  them. **Delete, or leave?** *(R-193)*
+  It costs that machine's contents if it goes wrong, which is acceptable there. **You said yes, after
+  R-198 — and R-198 shipped this morning, so this is ready to run on your word.** *(R-201)*
+- **The orphaned backups on the storage box — you said delete, and it is still owed.** About 1.2 GB
+  across the two demo machines, in set-aside stores nobody can open and nothing prunes. Deliberately not
+  done today: erasing data on the storage endpoint is not something that should ride along with a
+  database change, so it wants its own session. *(R-193)*
 - **A job, not a decision: the hub password needs changing.** A diagnostic command printed it into a
   session log; nothing suggests anyone else saw it. *(R-132)*
 - **One small question, not urgent.** The automatic check cannot see which version you have told
@@ -160,11 +142,11 @@ Proven end to end on real hardware.
 
 ## Changed since last update
 
-- **2026-08-04 (latest)** — Traced the whole recovery path end to end and it does not join up. The hub
-  keeps the wrong sealed key when a machine re-seals, so a rebuilt machine's old off-site key is lost the
-  moment the customer is asked for a new recovery code. Nothing in the recovery path has ever been
-  performed. Your ruling about the recovery screen is priced and buildable. The proof exercise is
-  designed and awaiting your go-ahead. *(R-198, R-199, R-200, R-201, R-193)*
+- **2026-08-04 (latest)** — **Fixed the worst of it.** The hub now keeps the off-site backup key when a
+  machine re-seals, instead of only the whole-machine one — four lines of database change that stop the
+  recovery ceremony from destroying the thing it exists to protect. A changed backup key now raises an
+  alarm the same day. The daily email that described the opposite of what it measured now states what it
+  saw, and a refusal to auto-repair leaves a record instead of silence. *(R-198, R-197, R-192, R-196)*
 - **2026-08-04 (later)** — Established what a machine rebuild actually destroys: not the storage
   password we had been re-issuing, but the key that encrypts the backups. Both demo machines lost
   access to their off-site history, one of them silently. A decision is now waiting on you. The daily
diff --git a/documentation/architecture/00-capability-map.md b/documentation/architecture/00-capability-map.md
index 5093a8d..c833875 100644
--- a/documentation/architecture/00-capability-map.md
+++ b/documentation/architecture/00-capability-map.md
@@ -36,7 +36,7 @@
 | Box survives a wrong-NIC install: hub-unreachable first boot → legible Hungarian console screen (NIC table + remedy) + NIC sweep self-heal (bounded DHCP + hub probe per NIC, success-only persist), and the baked root password is operator-knowable (`<iso>.rootpw.txt`) | scripts v1.24.0 (`scripts/iso/felhom-bootstrap.sh` `network_gate`/`sweep_nics`, `build-felhom-iso.sh` rootpw emission) | **PROVEN-LIVE (nested drill — nested ≠ metal: metal proof rides the next real multi-NIC install)** | `audits/SPIKE-firstboot-nic-sweep-2026-07-22.md` — dead-NIC install from the virgin v1.24.0 ISO baked the 192.168.100.2 fallback (WITH a dead default gateway), the R-59 screen painted on the console (screendump captured), and after the cable move the box swept to the working NIC, re-leased and **self-registered at the hub unaided in under a minute**; the drill also caught + fixed the stale-fallback-route trap (flush before the bounded dhclient) and verified the emitted rootpw against the installed box's shadow hash | R-59 ships as a first-boot gate, not an install-time abort (recorded deviation — the fallback is the auto-installer's own, initrd hook out of scope); sweep is structurally first-boot-only (`state.json` gate + unit done-flag condition); a box past install-start gets the screen but its interfaces are never touched |
 | Customer claim: one-time emailed code → customer sets own password (bcrypt, operator never sees it) | controller v0.122, hub v0.50 | **PROVEN-LIVE** (drill VM) | `DRILL-day0-vm-2026-07-12` §10/F-4 (gate ON via real edge; claimed, code consumed) | Never executed by a non-Viktor human → R-3. **Deliverability (R-4), gmail half DONE 2026-07-18:** the rehearsal's claim email was the first sent under the tightened DMARC `p=quarantine` and **landed in the gmail Inbox, not spam** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`). **freemail.hu remains Viktor's open half.** (Dropped mis-cited `CAMPAIGN-4` F-C — that is the escrow-claim 502, not password claim) |
 | Customer binds their own appliance (self-service): operator-sent 7-day tokenized capability link → public two-factor `/bind/<token>` (console pairing code + retrieval passphrase) → hub stages the bind, no operator | hub v0.66.0 + ISO scripts v1.20.0 | **PROVEN-LIVE** (real customer-zero bind on metal, 2026-07-18) | **`tests/VALIDATION-n100-rehearsal-2026-07-18.md`:** operator minted + emailed the link 16:28:55 (7-day TTL, expiry 2026-07-25 recorded); **the customer bound their own box at 16:29:55 with `attempts=0`, `locked=0`** — `appliance_bound` carries source **`customer_selfbind`**, and the credential was delivered **26 s later** with no operator action. Hub-side lifecycle in `hub-state.txt` (`selfbind_tokens` mint→email→consume). Prior unit evidence: hub v0.66.0 (`web/selfbind.go`, `store/selfbind.go`; Scenarios A–F + F1/F2; 4 red-proofs verified red — THE TRAP `/bind/` exemption, no-oracle, lockout, single-active); GC verdict §3 (no appliance GC → TTL stands alone) | R-27 **slice 1**. No appliance list ever rendered; wrong code == wrong passphrase (one generic failure); 5-attempt lockout → call support; expiry falls back to operator-bind. **Live first-run DONE 2026-07-18** (rehearsal; the console banner rendered on the real ISO). **R-27b** (controller second-box dismissable prompt) deferred; **multi-box-per-link** = repeated operator sends |
-| Escrow ceremony: customer-facing wizard, one-shot R claim, operator zero-knowledge | controller v0.127, agent v0.88/0.89 | **PROVEN-LIVE** (drill VM, endpoint-exact) | agent v0.88.0 REPORT (ceremony ~4s, one-shot claim 200→410, R absent from every payload); `SPIKE-controller-escrow-2026-07-13` | **Customer-facing browser wizard FIRST LIVE FIRING 2026-07-18** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`, S6): customer zero drove the wizard on the reborn box — ceremony started 16:56:29, recovery code claimed one-shot 16:56:39 (absent from logs by design), hub-verified and `EscrowState` auto-confirmed 16:56:41, **offsite runs enabled 12 s after the ceremony began**; the v0.138.0 „megerősítésre vár, legfeljebb 15 perc" awaiting card rendered and flipped on the ACK (operator screenshots: Viktor's set). Honest caveat: at a 12-second confirm the awaiting window is so short that catching *both* states on screen is luck, not procedure. Prior: endpoints driven on the drill VM. **agent v0.89.0:** `/escrow/preflight` `pbs_storage_id` row now live-reloads (reads current agent.json) — a pbsdr convergence that seeds the id flips it green with NO service restart. **hub v0.60.0 (data-first retention) — ⚠ CORRECTED 2026-08-04, the claim as written is FALSE for the offsite tier:** a re-escrow with a DIFFERENT sealed passphrase no longer destroys the old blob — the hub RETAINS it (`host_escrow_superseded`). ~~so a previous passphrase stays recoverable with its recovery code (turns the reinstall-orphan incident from "history destroyed" into "history recoverable")~~ **It retains the K-ESCROW BLOB ONLY. `host_escrow_superseded` has no `identity_blob` column and `demoteCurrentEscrowTx` (`hub/internal/store/store.go:2547-2556`) does not copy one, so what stays recoverable with the old recovery code is the PBS datastore key — NOT the restic repository password, which lives in `identity_blob` and is OVERWRITTEN by the next ceremony.** Measured live 2026-08-04: both current rows hold `blob`=383 B **and** `identity_blob`=572 B; both superseded rows hold `blob`=383 B only. The reinstall-orphan incident this sentence names is therefore still "history destroyed" for Tier-3 — and the same false promise is made to the customer in Hungarian on the orphan card. → **R-198**, evidence `audits/RECON-offsite-dr-chain-2026-08-04.md` §7. **There is also no read path:** `ListSupersededEscrow` has zero production callers; retrieval is `sqlite3` on the hub pod, by hand. Guided-recovery flow = R-26. Red-proof `TestSaveHostEscrow_RetainsSuperseded`. **hub v0.60.1 — custody survives the host lifecycle:** host deletion (with the escrow ack) DEMOTES the current blob to retained custody (moved into `host_escrow_superseded`, never destroyed; existing superseded rows spared); the customer Danger-zone Delete is the one true purge point (cascades both escrow tables incl. already-deleted hosts). No operator path through host lifecycle can lose a blob. Red-proofs `TestDeleteHost_DemotesEscrowNeverDestroys` + `TestDeleteCustomer_PurgesEscrowCustody`. **agent v0.93.0 (2026-07-21) — recovery codes can no longer contain a hyphenated word.** The EFF large list holds exactly four entries containing the hyphen the words are joined with (`drop-down`, `felt-tip`, `t-shirt`, `yo-yo`); drawing one produced a code that reads as 11 words instead of 10 — ambiguous to transcribe in exactly the situation R exists for. They are now excluded **from GENERATION only**: the draw space goes 7776 → 7772 and a 10-word code 129.248 → 129.241 bits, still well clear of the 128-bit floor. **Every code already issued remains valid** — R is verified as a whole passphrase by the PBS scrypt KDF and is never re-split, so no customer needs to re-run a ceremony. This also retired the long-standing ~1/5 `TestGenerateRecoveryCode_EntropyAndFormat` flake, which was this defect and not a flaky test |
+| Escrow ceremony: customer-facing wizard, one-shot R claim, operator zero-knowledge | controller v0.127, agent v0.88/0.89 | **PROVEN-LIVE** (drill VM, endpoint-exact) | agent v0.88.0 REPORT (ceremony ~4s, one-shot claim 200→410, R absent from every payload); `SPIKE-controller-escrow-2026-07-13` | **Customer-facing browser wizard FIRST LIVE FIRING 2026-07-18** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`, S6): customer zero drove the wizard on the reborn box — ceremony started 16:56:29, recovery code claimed one-shot 16:56:39 (absent from logs by design), hub-verified and `EscrowState` auto-confirmed 16:56:41, **offsite runs enabled 12 s after the ceremony began**; the v0.138.0 „megerősítésre vár, legfeljebb 15 perc" awaiting card rendered and flipped on the ACK (operator screenshots: Viktor's set). Honest caveat: at a 12-second confirm the awaiting window is so short that catching *both* states on screen is luck, not procedure. Prior: endpoints driven on the drill VM. **agent v0.89.0:** `/escrow/preflight` `pbs_storage_id` row now live-reloads (reads current agent.json) — a pbsdr convergence that seeds the id flips it green with NO service restart. **hub v0.60.0 (data-first retention) — ⚠ the claim as written was FALSE for the offsite tier for two months; **FIXED in hub v0.93.0 (2026-08-04), and the row below states what ships TODAY:** a re-escrow with a DIFFERENT sealed passphrase no longer destroys the old blob — the hub RETAINS it (`host_escrow_superseded`) — and **since v0.93.0 the retained row carries `identity_blob` as well as the K-escrow blob**, so a previous passphrase does now stay recoverable with the recovery code that sealed it. **What was wrong until v0.93.0, recorded because it is the ninth entry in `CLAUDE.md`'s comment-vs-code table and the first that was also customer-facing copy:** `host_escrow_superseded` had no `identity_blob` column and `demoteCurrentEscrowTx` did not copy one, so what survived a supersession was the **PBS datastore key only** — never the restic repository password, which lives in `identity_blob`. The destroying act was the **escrow ceremony** a rebuilt box asks its customer to run. Measured live 2026-08-04, before the fix: both current rows held `blob`=383 B **and** `identity_blob`=572 B; both retained rows held `blob`=383 B only. → **R-198** (SHIPPED), evidence `audits/RECON-offsite-dr-chain-2026-08-04.md` §7. **THREE SCOPE LIMITS THIS ROW MUST NOT BE READ PAST.** (1) **Nothing was backfilled and nothing could be** — rows superseded before v0.93.0 were written without the blob and their source rows are already overwritten; both demo boxes' pre-2026-08-04 repository passwords are gone permanently. (2) **A retained key is not a recovery.** `ListSupersededEscrow` reads the blob back into Go as of v0.93.0, but the hub's blob-serving endpoints still have **no client anywhere** (R-199), the controller's password-injection seam still has **no form** (R-200), and **no part of the recovery path has ever been exercised** — the one live round-trip proof (2026-06-10) predates the `ResticRepoPassword` field by a month (R-201). **No row in this map may claim a recovery capability while those three are open.** (3) The customer-facing orphan card still promises recoverability unconditionally (R-202, gate hit, card untouched). Guided-recovery flow = R-26. Red-proof `TestSaveHostEscrow_RetainsSuperseded`. **hub v0.60.1 — custody survives the host lifecycle:** host deletion (with the escrow ack) DEMOTES the current blob to retained custody (moved into `host_escrow_superseded`, never destroyed; existing superseded rows spared); the customer Danger-zone Delete is the one true purge point (cascades both escrow tables incl. already-deleted hosts). No operator path through host lifecycle can lose a blob. Red-proofs `TestDeleteHost_DemotesEscrowNeverDestroys` + `TestDeleteCustomer_PurgesEscrowCustody`. **agent v0.93.0 (2026-07-21) — recovery codes can no longer contain a hyphenated word.** The EFF large list holds exactly four entries containing the hyphen the words are joined with (`drop-down`, `felt-tip`, `t-shirt`, `yo-yo`); drawing one produced a code that reads as 11 words instead of 10 — ambiguous to transcribe in exactly the situation R exists for. They are now excluded **from GENERATION only**: the draw space goes 7776 → 7772 and a 10-word code 129.248 → 129.241 bits, still well clear of the 128-bit floor. **Every code already issued remains valid** — R is verified as a whole passphrase by the PBS scrypt KDF and is never re-split, so no customer needs to re-run a ceremony. This also retired the long-standing ~1/5 `TestGenerateRecoveryCode_EntropyAndFormat` flake, which was this defect and not a flaky test |
 | DR tier by default: PBS + WireGuard base infra on every install, hub-controlled activation | installer v1.15, agent v0.86, hub v0.51 | **PROVEN-LIVE** (2026-07-21) | `DRILL-day0-take2-2026-07-12` §2 (WG enabled both modes, PBS-DR descriptor auto-provisioned ~1s after WG registration, zero operator steps); ships installer v1.15/agent v0.86/hub v0.51 | Live only on demo/drill fleet. (Cited spike was slice-0 mechanics — shipped nothing; corrected.) **⚠ The candidate upgrade to PROVEN-LIVE is WITHDRAWN — the 2026-07-18 rehearsal produced a live counter-example (R-39).** On the reborn N100 the descriptor auto-provisioned and the agent reported `converged state=applied` (16:45:53), yet **the storage is dead**: `pvesm status` → `felhom-pbs: error fetching datastores - 401 Unauthorized` / `inactive`, and a direct probe with the stored credential returns **401 on every endpoint including `/version`** while the WG transport is healthy (handshake 9 s, 27.9 ms RTT) — i.e. authentication failure, not ACL scope. Root cause in the evidence: **the hub minted a SECOND token secret at 16:47:52, two minutes after the agent had applied the first, and `consumed_at` is still NULL**; the converged state machine will not re-apply, and the agent's 15-minute verify loop **cannot even read the credential to notice** (`open /etc/pve/priv/storage/felhom-pbs.pw: permission denied` — non-root agent reading a file it writes through a root wrapper). A tier that reports `applied` while silently unable to authenticate is exactly the shape that must not carry a PROVEN-LIVE badge. See `tests/VALIDATION-n100-rehearsal-2026-07-18.md` F2 and `pbs-dr-state.txt`. **agent v0.89.0 closes the F4 non-default-storage-id gap (R-22) — PROVEN-LIVE 2026-07-17:** the reconcile self-grants the ACL through the root wrapper on a pre-check 403 instead of dead-locking. Reproduced F4 on the demo (marker moved aside = reinstall fresh-state + felhom-offsite ACLs revoked) → next reconcile tick `pbsdr: pre-check 403 … self-granting … (R-22)` → `converged state=adopted` in ~3 s, ACLs self-restored, `pvesm status felhom-offsite`=active, zero operator action. No more one-shot `pveum` grant  **2026-07-21 — the R-39 fleet fix SHIPPED (hub v0.68.0 + agent v0.91.2), closing the self-heal chain end to end.** The three defects that let a box be `applied` and dead simultaneously are each addressed: the hub stamps a monotonic `secret_generation` into the descriptor so a credential re-key finally MOVES the content hash the agent re-applies on; the wrapper gains a narrow `read` verb so the non-root agent can read the credential it writes (it never could — `/etc/pve/priv` is 0700 root:www-data, which made the verify loop blind by construction); and `pbs.ProbeAuth` turns a 401 into a loud `auth_failed` that the existing `pbsdrheal` damper escalates to a fresh mint. Plus a consumed_at honesty gauge for the disagreement no single tier can see (box says `applied`, hub's staged secret never consumed). Proven live on felhom-pve: the agent read its credential through the wrapper (`rc=0`) and probed successfully (`credential probe OK storage=felhom-pbs`). **STOP-2 RAN 2026-07-21 AND THE CHAIN CLOSED — 13 SECONDS, operator click to converged.** The operator pressed **Re-issue PBS credentials**; the identical click on 2026-07-18 did nothing at all. Full chain (hub UTC / host CEST = UTC+2): `08:39:31Z` hub mints a fresh secret, **generation 0 → 1**, and the descriptor gains `"secret_generation": 1` — with `token_id` and `fingerprint` **byte-identical**, i.e. exactly the re-key shape that used to be invisible → `10:39:34` the agent READS its credential through the wrapper (leg b — the read that was impossible until v0.91.0) → `10:39:38` **`ERROR pbsdr: the DR endpoint REJECTED this box's credential — the tier is applied and DEAD` `previous_state=applied`** (leg c: the exact R-39 failure state, detected out loud for the first time ever) → `10:39:45` **`one-time token secret consumed`** `secret_len=36` (leg a: **NO short-circuit** — this is the line that never appeared on 2026-07-18) → `10:39:45` `felhom-pbs-apply reconcile` (the set-only wrapper, no `--server`) → `10:39:47` **`pbsdr: converged state=applied`**. Corroboration: the agent marker hash moved to `afbb3b41…` (it was byte-identical to the pre-reissue marker in the failure); `consumed_at` stamped `08:39:45Z`; the on-disk secret's mtime moved `2026-07-18 20:28:52` → `2026-07-21 10:39:45`; a live probe with the NEW credential returns **200**; three consecutive hub reports trace the whole state machine `applied → auth_failed → applied`; and **zero** `pbsdr_selfheal` escalations fired — the box healed through the descriptor path before the damper was ever needed, with exactly ONE mint and ONE consume and no `consumed-failed.json`. **Row upgraded to PROVEN-LIVE (2026-07-21).** Evidence: `felhom-agent/REPORT.md` (2026-07-21). |
 | **Recurring offsite (PBS) whole-guest backups actually LAND, and RESTORE** — local daily + offsite weekly as scheduled work | agent v0.97–0.103, controller v0.174/0.175, hub v0.76.0, host-install 1.20.0 | **PROVEN-LIVE (2026-07-26)** | `audits/SPIKE-r82-phase0-2026-07-26.md`; per-repo CHANGELOGs/REPORTs. **Restore round-trip on demo-hp:** `--selftest=restore-test` against `felhom-pbs:backup/ct/9201/2026-07-26T15:42:42Z` → `pass:true`, `verified:"boot+running"`, **`mount_parity:"ok"`** (`mp0=/var/lib/docker 50G`, `mp1=/mnt/sys_drive 20G`, mp8/mp9 throwaway stand-ins for the archived binds), `source_tier:"pbs"`, 4m5s restore+boot+verify+teardown, scratch band clean afterwards and the live guest untouched. | **This row is distinct from the DR-tier row above, which proves ACTIVATION, not ARRIVAL.** That tier was PROVEN-LIVE as `applied` since 2026-07-21 while demo-felhom held ONE snapshot (a healing artifact) and demo-hp held **zero, ever** — "applied and empty", the R-39 shape one level quieter. **What earns PROVEN-LIVE here:** (a) demo-hp's FIRST EVER offsite backup landed (4.25 GB into a verifiably empty namespace); (b) it **restores into a bootable, mount-complete guest** — `mount_parity` is the non-hollow half, since a boot-only verify cannot see a missing data volume; (c) **the multi-tier quiesce ran through the real UI endpoint** (`POST /api/guest-backup/trigger`, authed+CSRF) and produced **exactly ONE stop/start pair with BOTH backups inside it** — `quiescing 1 stack(s)` 17:01:39 → local done 17:02:56 *"next tier may start (app still quiesced)"* → felhom-pbs snapshotted 17:03:06 → `unquiescing` 17:03:06. **App downtime 1m27s for both tiers**, and the app came back healthy. **Known gaps, recorded not hidden:** the SCHEDULED restore-test still only selects the PRIMARY tier, so the offsite tier is never AUTOMATICALLY restore-tested (the manual/selftest path is proven, the unattended one is not); the hub infers "PBS ⇒ weekly" from storage TYPE rather than a reported cadence; the installer-default fleet flip awaits a full weekly cycle. → **R-82** |
 | **Restore-proof is UNATTENDED — the scheduler covers EVERY tier, follows the BACKUP rather than the clock, and a failure is heard** | agent v0.104.0 → **v0.121.0**, hub v0.77.0 → **v0.91.0** | **PROVEN-LIVE (2026-08-03)** | per-repo CHANGELOGs; `backlog/SPEC-r85-phase4-5-2026-07-26.md`. Unit red-proofs for tier rotation, restart-survival, the one-heavy-op gate, failure-emits-an-event, and newborn silence. | **The row above is earned by a MANUAL `--selftest=restore-test`; this one is about the SCHEDULED path, and the distinction is the whole point.** Before R-85 the scheduler could only ever see `cfg.Backup.BackupTarget()`, so the offsite tier was never a candidate — and a failed restore-test was a `[WARN]` line with no event at all, which was true for the LOCAL tier that WAS being tested. Now: oldest-first rotation across every configured tier (operator ruling 2026-07-26), persisted so it survives a restart; a restore-test joins the host-wide one-heavy-operation gate so it never contends with a backup over the same tunnel; and the hub raises two DISTINCT operator-tier signals — `restore_test_failed` (broken now) and `restore_test_stale` (unverified, not known-broken), anchored on R-81 so a newborn box never alarms. **Why this was NOT PROVEN-LIVE until now:** rotation had not been observed selecting both tiers across consecutive UNATTENDED cadences — at a 24h cadence a multi-day window — and a single passing run proves the code path, not the schedule. → **R-85**. **R-86 (agent v0.121.0 + hub v0.91.0, 2026-08-03) replaced the schedule and the observation became possible in one afternoon**, because what has to be observed is no longer a multi-day rotation but a RULE: a tier is due when its newest archive that has settled ~24 h has not been proven. **UPGRADE EVIDENCE — a real unattended run on demo-felhom (2026-08-03), triggered by DUE-NESS, not by a timer.** The scheduler's own log: `15:14:38 restore-test tier is DUE … target=felhom-pbs archive=felhom-pbs:backup/ct/9201/2026-07-28T04:49:43Z … reason="newest settled archive … has not been proven"` → `proxmox-backup-client restore --crypt-mode=encrypt` under the agent's own token → `15:25:08 gate decision class=guest_destroy guest=990000 allowed=true` → `15:25:14 scratch guest torn down` → **`15:25:14 backup: scheduled restore-test passed archive=felhom-pbs:… duration_s=635.1`**. A **14.5 GB encrypted offsite archive pulled from ep0 over the WAN**, restored, booted, verified and destroyed in 635 s, unattended. **The three things a timer could not show**, all verified after it: the state names THAT archive (`{"felhom-pbs":{"archive":"…2026-07-28T04:49:43Z","proven_at":"2026-08-03T13:25:14Z"}}`); a second evaluation reports `due=false … is already proven` and runs nothing; and **an agent restart runs nothing**, which is the defect a person actually noticed — every deploy used to restart the timer. Teardown verified at all three layers: guest absent from `pct list`, **zero** `990000` volumes in `lvs`, and the hub-side `restore_tests[]` entry deliberately RETAINED (it IS the proof the staleness check reads). **R-189 (agent v0.122.0, 2026-08-03) closed the reporting half of this row, and it was a REAL gap in the evidence path:** the proof above reached the hub only because no restart intervened — `restore_tests[]` came solely from an in-memory store, so the 15:25:14 PASS was in fact LOST when the agent restarted 2 m 43 s later for a deploy (`0 restore-tests` on the next two host-reports). Under per-archive due-ness the box would not have repeated the work for a week. The persisted per-tier proof (with the archive, and now the tier) is merged into the report, so a proof survives a restart — one entry per tier, newest wins, and a record that cannot be described honestly is not emitted. **THE HOST TIER'S HALF OF THIS ROW WAS OPTIMISTIC UNTIL 2026-08-03, and it is worth saying plainly.** Every live restore-test cited here is on the OFFSITE tier. The HOST tier was not merely unproven on demo-felhom — it was **unprovable**, and on demo-hp equally: the agent's token had no ACL on `/storage/felhom-backup`, the storage both boxes configure as `local_backup_target`, so the content API answered `{"data":[]}` through the token while root listed three archives. The scheduler skipped it as *"no settled archive yet"* — which is exactly what a brand-new tier reports — so nothing ever said so (**R-185**). **CLOSED 2026-08-03 — agent v0.123.0 + installer 1.24.0.** The grant is applied on both demo boxes (the token now lists 3 and 4 archives), the installer's reuse arm grants on a pre-existing target, and the agent now **asks whether it may read each tier it depends on** instead of inferring it from an empty list: a critical degraded capability naming the storage and the missing role, which the hub alerted and emailed on **while the box was still blind**. **THE HOST TIER IS NOW PROVEN-LIVE, UNATTENDED, ON BOTH DEMO BOXES (2026-08-04) — this row's optimistic half is cashed.** Four SCHEDULED runs, nothing triggered by hand: **demo-felhom** host tier `…2026_08_02-04_42_14.tar.zst` **passed in 83.8 s** at 00:55, offsite `…2026-07-28T04:49:43Z` **passed in 540.4 s** at 06:55; **demo-hp** host tier `…2026_08_02-04_49_29.tar.zst` **passed in 109.3 s** at 02:05, offsite `…2026-07-28T19:19:45Z` **passed in 300.1 s** at 08:05. Each restored into a scratch guest, booted, verified and destroyed itself; `pct list` and `lvs` show zero `990000` afterwards on both, and both boxes' `local-lvm` returned to their pre-run figures (1.95 % and 30.83 %). **Both boxes had BOTH tiers due at once and the ordering was observed live for the first time under R-86's rule:** never-proven sorted first, so each box took its HOST tier, deferred the offsite one, and picked it up on the following evaluation six hours later — one heavy operation at a time, per box, without anyone sequencing it. **The proofs reached the hub**, which is R-189 carrying a host-tier entry for the first time: demo-felhom's report holds **two** entries, one per tier, and the `local` one can only have come from the persisted state because the in-memory store held only that morning's offsite run. **SCOPE, stated because one box proving something does not make it a fleet property:** this covers `demo-felhom` and `demo-hp`. The tester's box is untested and untouched. Evidence: `felhom-agent/REPORT.md`, `felhom.eu/REPORT.md` |
diff --git a/documentation/architecture/03-host-agent.md b/documentation/architecture/03-host-agent.md
index 4d5db77..1a88fd7 100644
--- a/documentation/architecture/03-host-agent.md
+++ b/documentation/architecture/03-host-agent.md
@@ -378,6 +378,42 @@ nicety.
   **loses Felhom's backup guarantees** — no PBS verify / monitoring on storage we can't reach. An
   honest signup-time tradeoff, not a hidden one.
 
+#### Custody across generations — what the hub retains when a blob is superseded (hub v0.60.0; **contract corrected hub v0.93.0, R-198**)
+
+A ceremony that seals a *different* passphrase does not destroy the blob it replaces: the hub copies
+the current `host_escrow` row into `host_escrow_superseded` **before** overwriting it, so a previous
+generation stays openable with the recovery code that sealed it. The same routine
+(`demoteCurrentEscrowTx`) is used when a host is deleted, which **demotes** custody rather than
+destroying it. The hub never decrypts either table.
+
+**The contract as originally shipped was incomplete, and the gap is worth recording because it was
+invisible for two months.** An escrow generation is **two** sealed artifacts — the K-escrow `blob`
+(the PBS datastore key `K`) and `identity_blob` (the age-wrapped `IdentityBundle`, which carries the
+offsite **restic repository password** as well as the tunnel/PBS tokens and the WG key). Retention
+covered only the first. So a supersession preserved the whole-guest key and destroyed the off-site
+data key — and because the copy happens as the new blob lands, **the destroying act was the ceremony
+itself**, i.e. the step a rebuilt box asks its customer to perform. Corrected in hub v0.93.0: the
+retained row carries both.
+
+**Two consequences that belong in this doc rather than a changelog:**
+
+- **Generational custody is now the recovery precondition for the offsite tier.** The operator ruled
+  on 2026-08-04 that no repository password is retained on the Proxmox host (R-193 candidate (c),
+  refused). With no host-side copy, a rebuilt box's only route back to its previous off-site history
+  is *the customer's older recovery code opening the retained identity blob* — which exists only if
+  the supersession that replaced it happened on hub v0.93.0 or later.
+- **Retention is custody, not recovery, and this doc must not be read as claiming otherwise.** The
+  hub's restore-mode serving of these blobs (§ slice 10D) has **no client** in the agent, the
+  controller's recovered-password injection seam has **no user interface**, and no part of the chain
+  has ever been exercised outside a unit test — the one live identity round-trip (2026-06-10)
+  predates the `ResticRepoPassword` field. Tracked as R-199/R-200/R-201; evidence
+  `documentation/audits/RECON-offsite-dr-chain-2026-08-04.md`.
+
+**The honesty property above is unchanged and now has a second edge:** losing `R` and the box makes
+the offsite backups unrecoverable by anyone — *and* an older generation's data is recoverable only
+with **that generation's** recovery code, which the customer must still hold. A current recovery code
+does not open a previous generation's blob.
+
 ## 9. Provisioning & DR flows
 
 **Provisioning (reconcile-driven, by restore).** Fresh creation of a Docker-capable LXC needs
diff --git a/documentation/backlog/OPEN-ITEMS.md b/documentation/backlog/OPEN-ITEMS.md
index 4257221..25ed749 100644
--- a/documentation/backlog/OPEN-ITEMS.md
+++ b/documentation/backlog/OPEN-ITEMS.md
@@ -7,6 +7,28 @@ a non-overwritten `REPORT-<topic>.md` sibling instead (`CLAUDE.md:82-87`), of wh
 
 State: `BLOCKED` · `READY` · `WAITING-ON-OPERATOR` · `WATCHING`. Every row has an owner.
 
+## Operator rulings — 2026-08-04
+
+Recorded here because a ruling that lives only in a conversation binds nobody (the R-96 standing rule).
+
+1. **Run the recovery drill, after R-198.** R-198 shipped in hub v0.93.0; **the drill is the next
+   session.** Design: `audits/RECON-offsite-dr-chain-2026-08-04.md` §10 — demo-hp, ~3–4 h, a recovery
+   code created and KEPT, a sentinel file, wipe, reinstall, recover, and **pass = a byte-identical
+   sha256, not "the repository opened"**. → R-201
+2. **Delete the orphaned ciphertext** (~1.2 GB across the two demo boxes, in set-aside restic stores
+   nothing prunes). **STILL OWED — not done in v0.93.0.** It is a destructive act on a protected
+   endpoint and belongs to a session that is scoped for it, not to a release that ships a schema
+   change. → R-193
+3. **Accept the risk on R-193 candidate (c)** — no repository password retained on the Proxmox host.
+   **This is what makes R-198 load-bearing rather than tidy:** with no host-retained copy, the
+   customer-present recovery path is the ONLY way back from a rebuild, and that path runs entirely
+   through the retained identity blob. → R-193, R-199, R-200, R-201
+
+**Still open and untouched by v0.93.0:** **R-199** (the hub's blob-serving endpoints have no client
+anywhere), **R-200** (the password-injection seam has a handler and no form), **R-201** (nothing in the
+recovery path has ever been exercised). v0.93.0 makes the key survive; it does not assemble the chain
+that would hand it back.
+
 | ID | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|
 | **R-88a** | ~~Failing backup re-quiesces every 5 min, no backoff~~ | **SHIPPED** (controller v0.176.0, 2026-07-27) | — | Live on both boxes; breaker 15m→4h, per-tier, never permanent | — |
@@ -37,14 +59,15 @@ State: `BLOCKED` · `READY` · `WAITING-ON-OPERATOR` · `WATCHING`. Every row ha
 | **R-191** | **Every weekly offsite backup UPLOADS successfully and then FAILS the job on a prune the box is deliberately not allowed to do — on both demo boxes.** Measured on demo-felhom 2026-08-04 06:49–06:53: the upload completed (223 s, 629 MiB of 1.874 GiB, **67.2 % reused incrementally**), then `ERROR: prune 'ct/9201': proxmox-backup-client failed: Error: permission check failed - missing Datastore.Modify\|Datastore.Prune on /datastore/felhom-offsite/demo-felhom` → `ERROR: Backup of VM 9201 failed - error pruning backups` → `TASK ERROR: job errors`. The hub raised `whole_guest_backup_failed` | **CLOSED — SHIPPED 2026-08-04** (installer **1.25.0**; both live boxes corrected) | — | **This is R-89's rule not reaching the config.** R-89 moved PBS pruning SERVER-SIDE — *"boxes set `keep_last: 0`, ep0 runs prune jobs; box tokens stay write-only, never widen the grant"*. The token behaves exactly as designed: it refuses. But **both** demo boxes still arm the offsite tier with `keep_last=2 prune_pbs_allowed=true` (`backup_targets: [{target_id: felhom-pbs, cadence_seconds: 604800, keep_last: 2}]`), so every run asks for a prune that must fail. **The data is SAFE and that is why this is not a P1:** the snapshot lands before the prune is attempted; what is wrong is the job's VERDICT and the weekly operator e-mail it produces. **But it is corrosive in the specific way this project keeps finding:** a backup that reports FAILED while succeeding trains the operator to discount `whole_guest_backup_failed`, which is the same alert that would carry a real one — and it is exactly the failure the R-100 corollary warns about, an alarm whose text is true and whose trigger is not the thing you would act on. **Fix is one config line per box** (`keep_last: 0` on the PBS tier) plus whatever writes it on a fresh install; **deliberately NOT applied in this session** — the session was a runbook with an explicit "change nothing, and if a change appears necessary, stop and report" rule, and a retention field on a live backup tier is not a change to slip into an observation run. **Check before fixing:** whether ep0's prune jobs actually cover these two namespaces, or the snapshots simply accumulate once the box stops asking **THE GATE WAS RUN FIRST, AND IT MATTERED.** Before disabling anything, ep0 was read (read-only, Tier 2): prune jobs `prune-demo-felhom` and `prune-demo-hp` exist on datastore `felhom-offsite`, one per namespace, `schedule 03:30`, `keep-last 2`, comment *"R-82 retention keep-last=2, server-side (box tokens are write-only)"* — and they have run **every day since 2026-07-27: 18 tasks, all `status=OK`**. The newest task log reads `retention options: --ns demo-felhom --max-depth 0 --keep-last 2` / `keep ct/9201/2026-07-27…` / `keep ct/9201/2026-07-28…` / `TASK OK`. Retention happens, and it happens there. **A METHODOLOGICAL WARNING WORTH MORE THAN THE FIX.** Three separate queries said the OPPOSITE — *no prune jobs have ever run* — and **all three were broken instruments**: `worker-type` where the field is `worker_type`; the value `prune` where the worker type is `prunejob`; and `journalctl -u proxmox-backup` where the unit is `proxmox-backup-proxy`. A fourth reading (3 snapshots under keep-last 2) was mis-framed by CC and self-corrected — the third snapshot had landed AFTER that day's 03:30 window. Acting on any of them would have disabled the only pruning ATTEMPT while reporting that nothing prunes: a weekly false alarm traded for unbounded growth on the protected endpoint, invisible for months. **The gate is what caught it, and only because it demanded evidence rather than a verdict.** **Shipped:** installer **1.25.0** writes `keep_last: 0` on the offsite tier (the agent's existing guard `allowPBSPrune = !primary && keep_last > 0` already reads that as *never prune from the box* — no agent change), the justifying paragraph is rewritten to say where retention lives and cite R-89, and `hostinstall_gates.py` asserts it (red-proved: pinning `keep_last: 2` back fails the gate). **Both live boxes corrected in their own config** — `backup tier armed target=felhom-pbs … keep_last=0 … prune_pbs_allowed=false` on demo-felhom and demo-hp, with the local tier untouched at `keep_last=3`. Served over HTTPS at `1.25.0` with `"keep_last":0` in the served bytes. **STILL TO OBSERVE:** the next weekly offsite run completing OK end-to-end. The change removes the failing step; the *schedule* proving it is next week's event, and this row should carry that line when it happens. | CC |
 | **R-194** | **PVE's permission cache delays every grant-state verdict by an unknown amount, so "the agent can read it" and "the ACL exists" are not the same measurement.** Observed twice while validating R-190's self-repair on demo-felhom 2026-08-04: both ACL rows for `/storage/felhom-backup` were deleted, and `GET /access/permissions` continued to report `Datastore.AllocateSpace` present — for **~40 s** in one run and **~16 minutes** in another. During that window the capability probe reads healthy and the self-repair does not fire | **OPEN** | — | **Why it matters beyond the delay:** it puts a floor under how fast a lost grant can be noticed, it makes any single permission read a lagging indicator, and — the interesting part — **it is a candidate contributor to R-190's own timeline**: a grant removed at an unknown moment could keep working until a cache expiry, which is exactly the shape of *worked at 04:44, refused at 09:24*. That does not explain what removed it, but it may explain when the refusal SURFACED, and the two have been treated as the same instant. **Not a defect in our code** — it is PVE behaviour, and the mitigation already tolerates it (the repair fires on the next probe after the cache clears). **What is worth deciding:** whether the store-grant probe should ALSO consult the storage content listing as a second signal, since that appeared to reflect the loss immediately (`{"data":[]}` while the permission read still said present) — two signals disagreeing is itself information, and today only one of them is read | CC |
 | **R-195** | ~~**A customer with no machine ever bound e-mailed an `expected_dbdump_missed` ERROR every morning.** `david` — a real prospective customer whose record was created 2026-08-01 16:51:49 with **hosts=0, host_deletions=0, host_reports=0, reports=0** — raised the alarm at 03:00 UTC on 08-02, 08-03 and 08-04~~ | **SHIPPED** (hub **v0.92.0**, 2026-08-04) | — | **The mechanism, and it is the interesting half: the skip that protects every other silent customer is keyed off having reported at least once.** `CheckBackupDeadlines`' down-skip reads `StalenessChecker.GetState()`, whose map is seeded from `store.GetCustomers()` — a query **over the `reports` table**. A customer with zero reports appears in no row, gets no state, and `GetState()` returns `""` rather than `"down"`. The skip therefore misses exactly the customer it would most obviously cover. (Corroborated live: `peti-felhom` is active with a host deleted 2026-07-15 and **does not** alarm — it has 482 old reports, so it is `down` and skipped.) The backup half was already safe (`reportJSON == ""` → skip); the DB-dump half had no guard at all. **Fix:** `store.HasEverBoundHost(customerID)` = a live `hosts` row **OR** a `host_deletions` tombstone, consulted once per customer at the top of the deadline loop. **The discriminator is deliberately "was a host EVER bound", NOT "has a report arrived"** — a box that was installed and went silent is a real fault and must keep alarming; that is the case the change could break and it has its own test. Fail-**open** on a read error (an unreadable binding must never SUPPRESS a real alarm), and the deferral is LOGGED with its own counter (the v0.73.0 Part-7 precedent: a quiet check must not look like a check that did not run). The anchored-verdict structure is untouched. **Red-proof observed:** deleting the guard fails `TestCheckBackupDeadlines_NeverBoundHost_Silent` with `got [expected_dbdump_missed]` — verbatim the event `david` sent three mornings running. `david`'s record was NOT modified; the record was correct and the alarm was what was wrong | — |
-| **R-196** | **`escrow_stale` is wired to the ONE path that does not change the repo password, and absent from the path that does.** `ReissueCredentials` (`hub/internal/offsite/offsite.go:150-228`) resets **only** the Hetzner sub-account/box password and stages a fresh one-time secret — it contains no reference to a restic password and *cannot*, since that password is generated on the box and never leaves it except into the R-wrapped escrow. Yet it calls `MarkEscrowStale` on the stated grounds that *"the restic repo password just changed"* (`offsite.go:198-201`), and the same false premise is repeated at `api/handler.go:1067-1069` and in R-39's record | **OPEN** | — | **This is the EIGHTH entry in `CLAUDE.md`'s table of comments asserting a guarantee the code does not provide** — and the first where the comment factually describes a *different function*. It survived because its EFFECT (a stale escrow) is real, so nobody checked its CAUSE. **The live defect, not a documentation nit:** on the ordinary Re-issue shape (a consumed-but-failed install on a box that still holds its `repo_password` file) the box re-applies, `WriteOffboxSecrets` finds the file present and **keeps it**, the repo password is unchanged — and the hub has told the customer in Hungarian that their recovery escrow is stale and asked them to re-run the ceremony. **A false staleness alarm and an unnecessary ceremony.** **The inverse is the worse half and is R-193's:** demo-felhom's repo password *did* change on 2026-08-03 with **no Re-issue anywhere in its history** (its only `escrow_stale`/`offsite_reissued` pair is dated 2026-07-21 08:29:29) and therefore **nothing marked its escrow stale for 13 h**. **Fix shape:** mark the escrow stale on the evidence that it IS stale — a changed `restic_pw_sha256` (→ R-197) — not on a Re-issue; and correct all three comments in the same commit. **Not established, so not asserted:** whether the 2026-07-21 Re-issue on demo-felhom re-sealed an unchanged password (the predicted false-staleness shape) — `host_escrow_superseded` holds only two rows in the whole DB, both from 2026-08-04, so the prior generation is not retained. Source: `audits/SPIKE-offsite-credential-recovery-2026-08-04.md` Q4 | CC |
-| **R-197** | **The hub holds both halves of the evidence that a box's offsite DATA key changed, and reads neither.** `restic_pw_sha256` is stored on `host_escrow` and carried to `host_escrow_superseded` on every re-escrow. Comparing the two is what let this spike answer its hardest question in one query — and **nothing in the hub does it** | **OPEN** | — | **Why this is the cheapest real fix on the table.** A changed repo password means the previous offsite repository is now unopenable by the box, i.e. the customer's off-site history is orphaned. That is the single most consequential state change in the backup system, it is **already fully observable from data the hub owns**, and today it produces **no event, no e-mail, no card and no log line** — demo-felhom's went unremarked for 13 hours and would have gone unremarked indefinitely had this spike not run. **Two-line verdict:** on `SaveHostEscrow`, if the incoming `restic_pw_sha256` differs from the row being superseded, emit a distinct operator event naming the orphaned generation. **Deliberately an EVENT, not a heal** — nothing should act on this automatically until R-193's (c)-vs-accept decision is taken; the point is that the operator learns on the day. **Pair with R-196**, which is the same signal aimed at the right trigger. **Generalises past this row:** *a comparison the system could be making from data it already stores, and is not, is a silence with no cost of entry* — cf. R-190's store-grant probe, where the state was read and the TRANSITION was not. Source: `audits/SPIKE-offsite-credential-recovery-2026-08-04.md` Q8 option (d) | CC |
-| **R-198** | **The hub's superseded-escrow retention does NOT retain the offsite repository password — and the ceremony the system tells the customer to run is what destroys the last copy.** `host_escrow_superseded` has **no `identity_blob` column**, and `demoteCurrentEscrowTx` (`hub/internal/store/store.go:2547-2556`) copies only `host_id, blob, key_fingerprint, posture, created_at, restic_pw_sha256`. `blob` is the **K-escrow** (the PBS datastore key, PBS-native scrypt); the **restic repo password lives in `identity_blob`** (`felhom-agent/internal/escrow/identity.go:34-39`, age-wrapped `IdentityBundle`). Measured live: both hosts' current rows hold `blob`=383 B **and** `identity_blob`=572 B; both superseded rows hold `blob`=383 B and nothing else | **OPEN** | — | **This is the NINTH entry in `CLAUDE.md`'s table of comments asserting an invariant the code does not provide, and the first that is ALSO customer-facing copy.** The claim appears three times: the schema comment (`store.go:370-375`, *"so the old passphrase stays customer-R-recoverable … turns the reinstall-orphan incident from 'history destroyed' into 'history recoverable'"*), the capability map's escrow row, and — in Hungarian, to the customer, on the orphan card — `controller/internal/web/templates/backups_remote.html:66,69` (*„a hozzájuk tartozó helyreállítási kóddal később visszaállíthatók lehetnek"*). **For the offsite restic repository, the incident it names, all three are false.** **Why it is worse than a missing column:** a rebuilt box lands in `EscrowState: pending`, offsite runs are blocked (`OffboxRunnable`, `offbox.go:570`), the card says „Helyreállítási kód szükséges", and the controller's own detector logs *"run the escrow ceremony"* (`report/escrow_confirm.go:100`) — so **the prescribed remedy is the act that overwrites `host_escrow.identity_blob` and loses the old password forever**. Both demo boxes crossed that line on **2026-08-04 at 07:15:36 (demo-hp) and 07:20:08 (demo-felhom)**. **This is an independent, stronger reason the 51 orphaned demo snapshots are unrecoverable than "nobody kept the recovery codes" — keeping R would not have helped.** **Fix shape (small):** add `identity_blob` to the superseded table and to `demoteCurrentEscrowTx`'s SELECT list; pin it with a test that asserts the CONSEQUENCE (a superseded row can still yield a repo password) rather than the mechanism. **Then correct all three claims in the same commit** — including the Hungarian card, which must not promise what the system cannot do. **Prerequisite for R-193's (d)-alone branch** and for the drill. Source: `audits/RECON-offsite-dr-chain-2026-08-04.md` §7 | CC |
+| **R-196** | **`escrow_stale` is wired to the ONE path that does not change the repo password, and absent from the path that does.** `ReissueCredentials` (`hub/internal/offsite/offsite.go:150-228`) resets **only** the Hetzner sub-account/box password and stages a fresh one-time secret — it contains no reference to a restic password and *cannot*, since that password is generated on the box and never leaves it except into the R-wrapped escrow. Yet it calls `MarkEscrowStale` on the stated grounds that *"the restic repo password just changed"* (`offsite.go:198-201`), and the same false premise is repeated at `api/handler.go:1067-1069` and in R-39's record | **COMMENTS CORRECTED** (hub **v0.93.0**); **the BEHAVIOUR stays OPEN** | — | **This is the EIGHTH entry in `CLAUDE.md`'s table of comments asserting a guarantee the code does not provide** — and the first where the comment factually describes a *different function*. It survived because its EFFECT (a stale escrow) is real, so nobody checked its CAUSE. **The live defect, not a documentation nit:** on the ordinary Re-issue shape (a consumed-but-failed install on a box that still holds its `repo_password` file) the box re-applies, `WriteOffboxSecrets` finds the file present and **keeps it**, the repo password is unchanged — and the hub has told the customer in Hungarian that their recovery escrow is stale and asked them to re-run the ceremony. **A false staleness alarm and an unnecessary ceremony.** **The inverse is the worse half and is R-193's:** demo-felhom's repo password *did* change on 2026-08-03 with **no Re-issue anywhere in its history** (its only `escrow_stale`/`offsite_reissued` pair is dated 2026-07-21 08:29:29) and therefore **nothing marked its escrow stale for 13 h**. **Fix shape:** mark the escrow stale on the evidence that it IS stale — a changed `restic_pw_sha256` (→ R-197) — not on a Re-issue; and correct all three comments in the same commit. **Not established, so not asserted:** whether the 2026-07-21 Re-issue on demo-felhom re-sealed an unchanged password (the predicted false-staleness shape) — `host_escrow_superseded` holds only two rows in the whole DB, both from 2026-08-04, so the prior generation is not retained. Source: `audits/SPIKE-offsite-credential-recovery-2026-08-04.md` Q4 **FIVE instances, not three** — the spec expected three and named two; a census found five: `offsite/offsite.go` (the `MarkEscrowStale` justification), `api/handler.go` (the F3 re-enroll comment) and **three in `store/store.go`** (the `stale_at` ALTER comment, the `MarkEscrowStale` doc comment, and `EscrowStatus.Stale`). All five now state what the code does, name the correction, and cite the recon; the staleness mark is documented as **precautionary** (the box's re-apply may mint a fresh repository password — the guest-rebuild shape) rather than evidential, with R-197's measured signal named as the evidential one. **THE BEHAVIOUR IS UNCHANGED AND THIS ROW STAYS OPEN:** on the ordinary re-issue shape — a box that still holds its `repo_password` file — the password does not change and the hub still marks a healthy escrow stale and asks the customer for an unnecessary ceremony. That is a behaviour change and must not ride a comment-correction release; it is also now **more** consequential than when filed, because under R-198 an unnecessary ceremony is no longer harmless bookkeeping — it supersedes a blob. Fix shape unchanged: mark stale on the evidence that it IS stale (R-197's hash comparison), not on a re-issue. | CC |
+| **R-197** | **The hub holds both halves of the evidence that a box's offsite DATA key changed, and reads neither.** `restic_pw_sha256` is stored on `host_escrow` and carried to `host_escrow_superseded` on every re-escrow. Comparing the two is what let this spike answer its hardest question in one query — and **nothing in the hub does it** | **SHIPPED** (hub **v0.93.0**, 2026-08-04) | — | **Why this is the cheapest real fix on the table.** A changed repo password means the previous offsite repository is now unopenable by the box, i.e. the customer's off-site history is orphaned. That is the single most consequential state change in the backup system, it is **already fully observable from data the hub owns**, and today it produces **no event, no e-mail, no card and no log line** — demo-felhom's went unremarked for 13 hours and would have gone unremarked indefinitely had this spike not run. **Two-line verdict:** on `SaveHostEscrow`, if the incoming `restic_pw_sha256` differs from the row being superseded, emit a distinct operator event naming the orphaned generation. **Deliberately an EVENT, not a heal** — nothing should act on this automatically until R-193's (c)-vs-accept decision is taken; the point is that the operator learns on the day. **Pair with R-196**, which is the same signal aimed at the right trigger. **Generalises past this row:** *a comparison the system could be making from data it already stores, and is not, is a silence with no cost of entry* — cf. R-190's store-grant probe, where the state was read and the TRANSITION was not. Source: `audits/SPIKE-offsite-credential-recovery-2026-08-04.md` Q8 option (d) **SHIPPED.** `SaveHostEscrow` returns the hash it replaced; `handleHostEscrowPut` raises **`offsite_repo_key_changed`** when both hashes are known and differ. **Edge-triggered** (once per supersession, never per report — the dispatcher owns cooldown), **operator-only** (registered in `notify.operatorOnlyEvents` in the same commit that mints the type, because a missing `customerMessages` entry is NOT a block — the v0.78.0 defect), and **no hash value travels** in the message or the details. The in-between shapes (a first-ever hash, a hash-less supersession) are LOGGED rather than dropped, so *"we chose not to alarm"* and *"the check did not run"* never look identical. **Severity = warning, chosen for the world v0.93.0 creates:** before R-198 a changed key meant the previous history was unopenable by anyone ever, which would have argued for `error`; from v0.93.0 the superseding ceremony retains the old identity blob, so the fact is *"this customer's off-site history now depends on an older recovery code"* — operator-actionable, not a loss. `warning` also routes (the dispatcher treats `info` as an intentional non-notify). Driven through the real endpoint in test, not by calling the emitter. **Red-proof observed:** removing the comparison from the escrow PUT → the changed-key scenario fails with *"the repository key demonstrably changed and NO signal was raised"* while the unchanged-key scenario still passes. | CC |
+| **R-198** | **The hub's superseded-escrow retention does NOT retain the offsite repository password — and the ceremony the system tells the customer to run is what destroys the last copy.** `host_escrow_superseded` has **no `identity_blob` column**, and `demoteCurrentEscrowTx` (`hub/internal/store/store.go:2547-2556`) copies only `host_id, blob, key_fingerprint, posture, created_at, restic_pw_sha256`. `blob` is the **K-escrow** (the PBS datastore key, PBS-native scrypt); the **restic repo password lives in `identity_blob`** (`felhom-agent/internal/escrow/identity.go:34-39`, age-wrapped `IdentityBundle`). Measured live: both hosts' current rows hold `blob`=383 B **and** `identity_blob`=572 B; both superseded rows hold `blob`=383 B and nothing else | **SHIPPED** (hub **v0.93.0**, 2026-08-04) | — | **This is the NINTH entry in `CLAUDE.md`'s table of comments asserting an invariant the code does not provide, and the first that is ALSO customer-facing copy.** The claim appears three times: the schema comment (`store.go:370-375`, *"so the old passphrase stays customer-R-recoverable … turns the reinstall-orphan incident from 'history destroyed' into 'history recoverable'"*), the capability map's escrow row, and — in Hungarian, to the customer, on the orphan card — `controller/internal/web/templates/backups_remote.html:66,69` (*„a hozzájuk tartozó helyreállítási kóddal később visszaállíthatók lehetnek"*). **For the offsite restic repository, the incident it names, all three are false.** **Why it is worse than a missing column:** a rebuilt box lands in `EscrowState: pending`, offsite runs are blocked (`OffboxRunnable`, `offbox.go:570`), the card says „Helyreállítási kód szükséges", and the controller's own detector logs *"run the escrow ceremony"* (`report/escrow_confirm.go:100`) — so **the prescribed remedy is the act that overwrites `host_escrow.identity_blob` and loses the old password forever**. Both demo boxes crossed that line on **2026-08-04 at 07:15:36 (demo-hp) and 07:20:08 (demo-felhom)**. **This is an independent, stronger reason the 51 orphaned demo snapshots are unrecoverable than "nobody kept the recovery codes" — keeping R would not have helped.** **Fix shape (small):** add `identity_blob` to the superseded table and to `demoteCurrentEscrowTx`'s SELECT list; pin it with a test that asserts the CONSEQUENCE (a superseded row can still yield a repo password) rather than the mechanism. **Then correct all three claims in the same commit** — including the Hungarian card, which must not promise what the system cannot do. **Prerequisite for R-193's (d)-alone branch** and for the drill. Source: `audits/RECON-offsite-dr-chain-2026-08-04.md` §7 **SHIPPED.** `host_escrow_superseded` gains `identity_blob` (CREATE + additive `ALTER TABLE`) and `demoteCurrentEscrowTx` carries it, so **both** callers — re-escrow and host-delete demotion — are fixed by one change to the routine its own comment calls *"THE ONE escrow row-copy routine"*. `ListSupersededEscrow` reads it back and `store.HostEscrow` gains `IdentityBlob`, so a retained blob is reachable from Go at all. The table comment now records that the ruling stated above it was not met and what that cost. **Tests assert the CONSEQUENCE, which is why the existing one stayed green:** `TestSaveHostEscrow_RetainsSuperseded` asserted that a retained row exists carrying the old K-blob and passed throughout; `TestSaveHostEscrow_RetainsIdentityBlob` asserts the retained row can still yield a repository password, and pins the load-bearing ordering (the identity blob is written by `SaveHostDRBundle` AFTER `SaveHostEscrow`, so the demote sees the PREVIOUS generation — if that inverts, the retained bytes would be the new blob filed under the old hash, recoverable-looking and wrong). `TestDeleteHost_DemotesIdentityBlob` proves the shared routine through its other caller. **Red-proofs, both observed failing:** dropping `identity_blob` from the copy (production behaviour ≤ v0.92.0) fails BOTH scenarios; fixing only the re-escrow caller fails the delete scenario while the re-escrow one passes — the §8.2 mistake, demonstrated rather than asserted. **Nothing was backfillable and it was CHECKED, not deduced:** rows superseded before v0.93.0 were written without the blob and their source rows are already overwritten; the live database holds exactly 2 retained rows, both from 2026-08-04, both `identity_blob` NULL. **Who the fix protects, measured live:** 2 of 2 hosts with a current escrow carry an identity blob (`demo-felhom-8363b5`, `demo-hp-bb76ea`) — their NEXT ceremony now retains a recoverable off-site key instead of destroying one. | CC |
 | **R-199** | **The hub serves recovery blobs on two endpoints that have no client anywhere in the system.** `handleReEnroll` (`hub/internal/api/dr.go:101`) and `handleGetRestoreDirective` (`:155`) return `identity_escrow_b64` + `k_escrow_b64`, gated on operator-armed recovery mode. Census: **zero** callers in `felhom-agent` (no `ReEnroll` symbol at all; `internal/hub/client.go` reaches only `desired-state`, `wg`, `pbs/consume-token`, `jobs`), **zero** in the hub UI or any template, **zero** in `scripts/` or any runbook | **OPEN** | — | **The documented retrieval path is a human with `sqlite3`:** `SELECT writefile('/root/idblob', identity_blob) FROM host_escrow …` on a `kubectl cp`-ed `hub.db` — recorded in project memory as the 2026-07-04 S5 prep, where hub-side blob serving was explicitly deemed *"Part 3 NOT needed"*. **This is the built-but-never-wired class at the DR capstone**, and it is why the chain from a dead node to an open repository has no automatable middle. **What a recovery flow actually needs is smaller than what exists:** a narrow `GET /hosts/<id>/escrow` authed with the box's own per-host key, serving opaque bytes to the box that owns them — zero-knowledge untouched, and far lighter than `re-enroll`, which **rotates the host API key** and returns the new key in the response body (`dr.go:130,148`). **Decide before building:** whether `re-enroll`/`restore-directive` should get a client, be replaced by the narrow GET, or be retired. Source: `audits/RECON-offsite-dr-chain-2026-08-04.md` §3 link 6 | CC |
 | **R-200** | **The DR password-injection seam has a handler, a route and tests — and no form.** `POST /backup/offbox/inject-password` is routed (`controller/internal/web/server.go:510`) to `offboxInjectPasswordHandler` (`offbox_handlers.go:174-196`) → `InjectOffboxPassword` (`backup/offbox.go:541`). **No template in the repository contains that path or any form posting to it** (grep over `internal/web/templates/`: one unrelated hit, an XSS comment) | **OPEN** | — | **The tenth instance of this project's built-but-never-wired class, and the exact shape `CLAUDE.md` and `felhom.eu/CLAUDE.md`'s seam-wiring rule were written for:** handler tests that POST directly (`offbox_escrow_test.go:167,180`) prove nothing about reachability. To use the only implemented recovery seam today, a person must hand-craft an authenticated POST with a session cookie and CSRF token. **Note the layering while fixing it:** this form takes a **64-hex repo password**, not a recovery code (`offboxRepoPwPattern`, `offbox.go:543`) — they are different secrets at different layers, and the operator's 2026-08-04 ruling asks for a form that takes **R**. Build the R form and treat this one as the operator/DR fallback it was written as, but **ship it with a render test per branch of whatever gate it sits behind**. Source: `audits/RECON-offsite-dr-chain-2026-08-04.md` §3 link 9 | CC |
 | **R-201** | **Nothing in the offsite DR chain has ever been exercised past the ceremony — and the one live proof that exists predates the field it is cited for.** `slice10d-identity-restore-spike-findings.md` §1 (2026-06-10) proved a real wrap→unwrap of an identity bundle with a real R on a secret-less box, byte-identical, wrong-R failing closed. **That bundle was `{tunnel_token, pbs_token}`.** `ResticRepoPassword` was added in agent **v0.77.0 on 2026-07-09** — a month later — and is **unit-proven only** | **OPEN** | — | **Never exercised, in these words:** a blob has never been served to a box; a fork-4 bundle has never been unsealed with a real R outside a unit test (the only production caller is `--selftest=identity-consume`, `cmd/felhom-agent/main.go:2845`, reading R from `FELHOM_RECOVERY_CODE`); a recovered repo password has never been injected; an existing offsite repository has never been reopened with one; **no restore of any kind has ever been performed from a recovered secret.** The one live consume ever prepared (S5 Part 4-B, 2026-07-04) is still marked *"DEFERRED, not run"*. **`_recovery-inventory-2026-07-28.md` already recorded this accurately** (A.2.7, C.1 row 1, C-2) — this row exists so the gap has an owner and a closing condition, not only a description. **Closing condition = the drill** designed in `audits/RECON-offsite-dr-chain-2026-08-04.md` §10, whose pass condition is a **byte-identical sha256 of a sentinel file restored after a wipe** — explicitly NOT "the repository opened". **Do not run it before R-198 is fixed**: the drill would walk a chain that is missing a link everyone believed was there | CC + operator |
-| **R-192** | **`offsite_delivery_stuck` tells the operator the opposite of what the detector measured, and the self-heal silently refuses for exactly the reason the message denies.** demo-hp has been e-mailing this daily since 2026-08-03 06:12 UTC: *"one-time password consumed 284h ago and **500 report(s) since carry no offbox target** — the credential is likely burned (apply died between consume and persist). Re-issue delivers a fresh one."* **Measured against the hub's own data: all 500 of those reports DO carry an offbox target** | **OPEN** | — | **What actually happened on that box:** the credential was consumed 2026-07-23 09:53:41 and **applied successfully** — the controller reported an `offsite` object continuously until **2026-08-03 05:59:21 UTC**, then it **vanished at 06:12:19** and has been absent for **108 consecutive reports** since. So this is a **regressed apply**, not a burned credential. **Two distinct defects, and the second explains the first's invisibility.** **(a)** `maybeEmitStuck` builds its message from `status.ReportsSinceConsume` (the TOTAL) while hardcoding the phrase *"carry no offbox target"*, and never consults `status.OffsiteReportsSinceConsume` — which is the field that says the opposite. The recommended action (*Re-issue*) is aimed at a failure mode that did not occur. This is R-100's corollary again: an alarm whose text stopped matching what its verdict counts. **(b)** `maybeHeal` refuses **silently** (`OffsiteReportsSinceConsume != 0` → *"regressed-apply shape → operator's call"*, a bare `return` with no log line), so the operator gets a daily e-mail with the wrong story, no heal, and nothing anywhere saying why the heal declined. `offsite_credential_restaged` has **never** fired, on any customer. **The underlying condition is REAL and is the part that matters:** demo-hp currently reports no offsite target at all, i.e. that box's customer app-data has **no off-site copy right now** — and it has been that way since 08:12 CEST on 2026-08-03. A spot check inside the controller container found no restic environment, consistent with the report. **What removed it is not established** and is the first thing to find out. **Fix shape:** the message must state which shape was detected (burned vs regressed) and say what to do for each; the heal's refusal must log its reason; and the regressed shape probably deserves its own event type rather than borrowing the burned one. **Do NOT 'fix' it by widening the heal to restage over a regression** — the guard is right, only mute **CAUSE ESTABLISHED 2026-08-04 (operator confirms no hub-side offsite config change).** The regression is a **guest REBUILD**: at 06:09:40 `host_leaf_changed` (agent re-keyed), at 06:12:18 `controller_started (0.192.0)` — the controller went **0.187.0 → 0.192.0** with a **new config hash** (`1f725a2e843c` → `744e83d72c80`) — and the report at 06:12:19 is the first without `offsite`. The pre-rebuild object was fully healthy: `escrow_state: escrowed, last_status: ok, last_success 2026-08-03T02:16:39Z, snapshot_count 15, repo_size 40.9 MB`. → **R-193** owns the rebuild half. **AND THE HEAL'S GUARD IS WRONG FOR EXACTLY THIS CASE, which is why the automation that exists to fix it declined.** `maybeHeal` refuses when `OffsiteReportsSinceConsume != 0`, reading that as *"the apply regressed, so it is the operator's call"*. But `CountReportsOffsiteSince` counts the **OLDEST 500 reports since the consume** (`ORDER BY id LIMIT 500`) — for demo-hp all 500 predate the rebuild. **Offbox evidence from before a rebuild is not evidence that the credential still works**, so the guard reads healthy history as a reason not to heal a box that demonstrably cannot apply. The fix is to judge on RECENT evidence (e.g. the latest N reports, or evidence after the newest `controller_started`), not on everything since the consume. **SPIKE 2026-08-04 — BOTH HALVES CONFIRMED WITH NUMBERS, still OPEN, still not fixed here** (`audits/SPIKE-offsite-credential-recovery-2026-08-04.md` Q7). The query is quoted at source (`store.go:987`): `... ORDER BY id LIMIT 500` = **the oldest 500**. Reproduced against the live hub DB with demo-hp's real consume anchor `2026-07-23 09:53:41`: the guard sees `total=500, withOffsite=500`, spanning `2026-07-23 09:53:47` → **`2026-07-28 11:17:40`** — the entire evidence set ends **six days before** the 2026-08-03 rebuild. The true window totals are `1174 / 1063` (⇒ 111 without, matching the 111 offsite-less reports). So the e-mail's *"500 report(s) since carry no offbox target"* interpolates `ReportsSinceConsume` while `OffsiteReportsSinceConsume` was **500** — the message states the precise negation of its own measurement. `offsite_credential_restaged` has **never fired for any customer** (zero rows of that type in the DB — checked, not assumed). **A NEW REASON NOT TO FIX THIS IN ISOLATION, from the same spike:** under R-193's Q2 finding a successful auto-restage would have restored demo-hp's TRANSPORT while the box minted a new repo password anyway — the heal can protect the plumbing and **cannot** protect the data, and had it fired on 2026-08-04 both boxes would have looked healthy while their snapshots were orphaned. **That is strictly worse than the current loud failure.** Whatever shape the fix takes must say so in its message. **RECON 2026-08-04 adds two inputs and changes no verdict** (`audits/RECON-offsite-dr-chain-2026-08-04.md`). **(1) The guard's own conclusion — that a fix here protects the plumbing and not the data — is now stronger, not weaker:** even a perfect restage leaves the rebuilt box minting a fresh repo password, and per **R-198** the old one is destroyed by the re-ceremony the box is pushed into. Whatever shape the message takes must say that in the same breath, or it will read as an all-clear. **(2) The recency-bounded discriminator this row asks for has a ready anchor the hub already receives:** the report ACK's `escrow{identity_blob_present, restic_pw_sha256}` moves when a box re-keys, so "evidence since the newest re-key" is computable from data already stored — the same observation R-197 makes, aimed at this guard's time window. | CC |
-| **R-193** | **A guest rebuild silently drops the off-site app-data tier, and nothing restages the credential.** demo-hp was rebuilt on 2026-08-03 (controller 0.187.0 → 0.192.0, new config hash, agent leaf re-keyed at 06:09:40). Before it, the offsite tier was healthy and working — `escrow_state: escrowed`, `last_status: ok`, last success **02:16:39Z that morning**, **15 snapshots, 40.9 MB**. After it: no `offsite` object in any of **108** reports, and **no off-site copy of that customer's app data since 08:12 CEST on 2026-08-03** | **OPEN** | — | **Mechanism, fully evidenced.** The restic credential reaches a box exactly once, as a one-time secret. demo-hp's was consumed **2026-07-23 09:53:41**; the rebuilt controller came up with a fresh data volume, no copy of it, and **no way to ask for another** — the hub is the only side that can stage one, and it will not re-stage a consumed secret on its own (the R-71c self-heal would, but it refuses — see R-192). **demo-felhom survived the SAME rebuild by luck, and the contrast is the proof:** its secret was created 2026-07-21 and still **UNCONSUMED**, so when its config hash changed at 07:17:54 and `offsite` dropped for exactly one report, it consumed the staged secret at **07:17:58** and was reporting `offsite` again by 07:19:10. One box had a spare credential staged and recovered in 76 seconds; the other did not and has been unprotected for a day. **That difference was not a design decision — it was an accident of which box happened to have an unconsumed secret lying around.** **Why this is not just "re-issue it":** the remedy (Re-issue) resets the sub-account password via the Hetzner API and, per R-39's record, **rotates the restic password and makes the escrow STALE** — so it needs the recovery-code ceremony re-run, and the continuity of the 15 existing snapshots under the new credential must be VERIFIED, not assumed (`hub v0.60.0` retains superseded escrow, and the orphan guard is move-aside-never-delete). That is an operator act with a customer-facing consequence, so it is not something to fire automatically without deciding the escrow question first. **What to design:** a rebuild is a normal, expected event on these boxes — the offsite tier must survive one, either by the hub restaging automatically when a re-enrolled box reports no offsite (the R-192 guard fix makes this safe), or by the credential being recoverable from escrow at re-bootstrap rather than delivered once and unrecoverable **RESOLVED ON THE BOX 2026-08-04 (operator-authorised).** Re-issue fired through the designed endpoint (`POST /configs/demo-hp/offsite-reissue`, HTTP 303): hub staged a fresh one-time password at **07:11:51**, the box's config hash moved `744e83d7` → `5eee0e42`, R-71a's settle-gate reported **GO** (*at/above floor 0.156.0, we are 0.194.0*), the password was **consumed 15 s later at 07:12:06**, and the controller logged *offsite configured for u629488-sub3@…:/home/felhom-repo* at 07:12:09 — the **same sub-account (275124) and the same repo path**, since Re-issue resets the sub-account password and the one-time password is only the transport credential used once to install the box's own SSH key. **THE ESCROW DID NOT RECOVER BY ITSELF — a correction to this session's own first reading.** `escrow_state` went `pending` → `escrowed` 15 s after the apply and CC inferred an automatic re-escrow; **the operator had run the ceremony**. It needed a human, on BOTH boxes: demo-hp escrowed 07:16:02, demo-felhom (whose offsite re-applied on its own the previous day but whose escrow had been `pending` ever since) escrowed 07:20:28. **A 15-second state change is not evidence of automation** — that is the same class as reading an absent log line as success. **Snapshot continuity is NOT yet established and must not be assumed from the counters:** both boxes report `snapshot_count: 0, repo_size_bytes: 0`, but the run-history keys (`last_run`, `last_status`, `last_success`) are **absent entirely** rather than zeroed — the shape of a controller that has never run an offbox backup in this lifetime, not of an empty repo. demo-hp's pre-rebuild object carried all three plus 15 snapshots / 40.9 MB. ~~**The next scheduled `offbox-backup` (04:15) decides it:** 15+ snapshots ⇒ the repo reattached; 1 ⇒ it started fresh and the old snapshots are orphaned-but-retained.~~ **SPIKE 2026-08-04 SETTLED IT WITHOUT WAITING, AND THE ITEM IS BIGGER THAN FILED** (`audits/SPIKE-offsite-credential-recovery-2026-08-04.md`). **(1) THE ONE-SHOT SECRET IS NOT WHERE THE HARM IS.** Three secrets exist; the one-time password is the *recoverable* one (the operator can reset it at the provider any time) and the box's SFTP key is regenerable by design. The **restic repository password** — the DATA key, which the agent's own source calls *"irreplaceable (unlike the SFTP access key…)"* (`felhom-agent/internal/escrow/identity.go:35-39`) — is the one a rebuild destroys, and **nothing automatic ever restages it**: `WriteOffboxSecrets` mints a fresh 256-bit password whenever `<DataDir>/offbox/repo_password` is absent (`offbox.go:392`), and the only recovery path, `InjectOffboxPassword`, has **exactly one caller in the whole repo** — a web form a human pastes into (`web/offbox_handlers.go:189`). **(2) MEASURED, WITHOUT TOUCHING A BOX:** the hub already stores `restic_pw_sha256` on both the live and the superseded escrow, so the question is a hash comparison. demo-hp `8e03eddf…` → `8a9e33aa…`; demo-felhom `48741892…` → `c60c8bc7…`. **Both boxes minted a new repository password.** **(3) THE CONTRAST IN THIS ROW IS FALSE FOR THE DATA.** demo-felhom's 76-second "lucky" recovery restored **delivery only** — its pre-rebuild object carried **36 snapshots / 1.14 GB** (`repo_size_bytes 1136685919`) and it has reported `snapshot_count: 0` in all 109 reports since, with a changed repo password and **nothing marking its escrow stale for 13 h**. Both boxes lost repository continuity; one loudly, one silently, and **the silent one is worse**. **(4) Q3 IS UNMEASURED AND THE BINARY WAS WRONG.** Neither box could run on 2026-08-04 02:15 UTC (demo-hp had no target at all until 07:15; demo-felhom's target was `escrow_state: pending`, which `OffboxRunnable` blocks) — **the decisive run is 2026-08-05 ~02:15 UTC**. Source predicts a **third** outcome, neither 15 nor 1: same account + same repo path (`u629488-sub3:/home/felhom-repo`, and `repoPath` is a compile-time constant) + new password + `claimed: 1` ⇒ `ensureOffboxRepo` classifies **orphaned** and returns `ErrOffboxOrphaned` — **the run refuses and shows the orphan card**, it does not start a silent fresh history. **Record which of the three actually occurs; a prediction from source is not a measurement.** **(5) CANDIDATE (b) IS NOT IMPLEMENTABLE AS STATED** — the escrow is R-wrapped/zero-knowledge and the hub has no recovery code, so "recoverable from escrow at re-bootstrap" describes a customer-present ceremony, i.e. the manual form that already exists. **(6) CANDIDATE (a) ALREADY EXISTS AND IS WIRED TO THE WRONG EVENT:** `reissueOnReenroll`'s **F3 leg** does exactly this (`api/handler.go:1051-1084`) but sits behind `handleHostEnroll`'s mint-once-reuse short-circuit (`if existing != nil { return }`), and a **guest** rebuild leaves the `hosts` row intact — so F3 is never reached. **(7) A NEW CANDIDATE (c), not previously named and recommended second:** the **agent survives a guest rebuild**, already receives the repo password over the pinned local API (`POST /escrow/stage-secret`) and already writes it to a fixed 0600 path — it merely **wipes** it after the ceremony. Retaining it and serving it back is the only candidate that addresses the irreplaceable secret, and every seam it needs exists. Its cost is one deliberate trade the operator must make (a copy of the data key at rest on the Proxmox host — see D6). **SPIKE RECOMMENDATION: ship the honesty pass (R-196 + R-197) now; then decide (c). Do NOT ship (a) first — it would have hidden this.** **NOT CLOSED — WAITING-ON-OPERATOR for the (c)-vs-accept-it decision, stated at the end of the spike.** **RECON 2026-08-04 — the chain was traced link by link, and the picture is worse than the spike's** (`audits/RECON-offsite-dr-chain-2026-08-04.md`). **(A) THE SPIKE'S CANDIDATE (b) IS OVERTURNED IN PART.** "Recoverable from escrow" is not blocked by zero-knowledge — the *hub* cannot open the blob, the *customer* can, with R. What is genuinely impossible is an **unattended** recovery. A **customer-present** one is a real design, and the operator has now ruled on its shape (below). **(B) THE CHAIN IS NOT ASSEMBLED — eleven links, and the automation stops at four.** Mint → stage → seal → store on the hub are PROVEN-LIVE. Then: the hub's blob-serving endpoints have **no client anywhere** (**R-199**); unsealing's only production caller is a `--selftest` mode reading R from an env var; nothing extracts `restic_repo_password` from the recovered bundle; the injection seam **has no form** (**R-200**); and reopening an existing repo with a recovered password has **never happened** (**R-201**). **(C) THE LOAD-BEARING NEW FACT, and it retires this row's own "hub v0.60.0 retains superseded escrow" premise: the retention does NOT retain the restic repo password** — `host_escrow_superseded` has no `identity_blob` column (**R-198**). Both demo boxes' old passwords were destroyed by the 2026-08-04 re-ceremonies, so the orphaned snapshots are unrecoverable for a **second, independent** reason; keeping R would not have helped. **(D) A FAIL-CLOSED REFUSAL IS IMPLEMENTABLE — this is the most useful thing settled.** The hub already tells every box, on every report ACK, `escrow{identity_blob_present, restic_pw_sha256, created_at}` (`hub/internal/api/handler.go:504-510`) — and the controller **discards it** whenever no offbox target exists (`report/escrow_confirm.go:75-84`). Persisting it (the `ClaimSync` set-only pattern, `report/claim_sync.go:39-53`) and refusing to mint when a blob covers a password we do not have needs **no new hub API and no new secret**. **(E) OPERATOR RULING, 2026-08-04, recorded verbatim:** *"If a node is a fresh install AND the hub has a recovery blob, then the controller should yell that recovery is available, and provide a form for the customer to enter the recovery key. After unlocking the blob, the controller should show what will be recovered before proceeding."* Priced row by row in the recon §9: fresh-install signal **exists** (the mint branch's own `os.Stat`); hub-has-a-blob **exists on the wire, S to persist**; the yell **S**; an **R** form **does not exist** (the UI has only ever *emitted* R) **S**; unsealing must cross agent→controller because the controller image ships no `age` — **M**, one new agent local-API endpoint mirroring `/escrow/ceremony/claim`, plus a narrow hub `GET /hosts/<id>/escrow`; the **preview is cheap and read-only** — `restic snapshots --json` + `stats --mode raw-data --json` are already how the box counts snapshots (`offbox.go:1234-1265`), so count, dates, sizes, app tags and paths are all knowable before committing **S**. **Security question put to the operator, not answered:** the form sits behind the dashboard password (bcrypt + CSRF + 5/min lockout); the preview exposes backup cadence and app names; the form is an **oracle** for a stolen R and must fail as generically as `UnwrapIdentity` already does; and R transits the agent, which is the same trade as option (c) in a smaller, time-bounded form. **(F) THE DRILL IS DESIGNED AND NOT RUN** (recon §10): demo-hp, ~3–4 h, R kept deliberately, sentinel file sha256 before and after, **pass = byte-identical sha256, NOT "the repository opened"**, fail = a snapshot count of 1. **Run R-198's fix first.** **(G) Q3 STILL UNMEASURED:** neither box has run since (`last_run` absent on both, 2026-08-04 09:49/09:56 reports) — the decisive run remains **2026-08-05 ~02:15 UTC**. | CC + operator |
+| **R-202** | **The orphan card promises the customer their old backups "may later be restorable with the matching recovery code" — and after v0.93.0 that is true for supersessions from now on and FALSE for anything already orphaned.** `controller/internal/web/templates/backups_remote.html:66,69` states it unconditionally, in Hungarian, on the one surface where being wrong costs most | **OPEN — Part 5 hit its gate 2026-08-04; the card is UNTOUCHED and the sentence is still live** | R-199/R-201 (which generation an orphaned repo belongs to is not knowable to the box today) | — | **THE GATE, and why it was hit rather than squeezed past.** The condition was: ship it iff the hub can tell a box what it needs with **one** additional boolean on the escrow ACK it already sends. The hub *can* cheaply compute *"≥1 retained blob for this host carries an identity blob"* — one correlated predicate in `GetEscrowStatusForCustomer`, and the controller even has the right seam already (`SetEscrowStale`/`StaleBlob` is exactly this shape). **But that boolean does not answer the card's question.** The card renders on `RepoState == "orphaned"`, and the promise is about *the key THIS orphaned repository was written under*. A box does not know which escrow generation the orphaned remote belongs to; a box with a pre-v0.93.0 orphan and a post-v0.93.0 supersession would read the boolean TRUE and the promise would still be false — a **conditional** falsehood that looks verified, which is strictly worse on a customer-facing card than today's hedged one. **What would actually make it truthful** is knowing the orphaned repo's generation, which is the same knowledge R-199/R-201's unassembled chain needs. **Interim exposure, stated rather than buried:** the sentence remains live and remains false for both demo boxes. **Cheapest honest interim** (not taken here — it is a customer-copy change and the gate said leave it alone): drop the recoverability clause and say only that the old history is set aside and not deleted, which is true unconditionally | CC + operator |
+| **R-192** | **`offsite_delivery_stuck` tells the operator the opposite of what the detector measured, and the self-heal silently refuses for exactly the reason the message denies.** demo-hp has been e-mailing this daily since 2026-08-03 06:12 UTC: *"one-time password consumed 284h ago and **500 report(s) since carry no offbox target** — the credential is likely burned (apply died between consume and persist). Re-issue delivers a fresh one."* **Measured against the hub's own data: all 500 of those reports DO carry an offbox target** | **HALF SHIPPED** (hub **v0.93.0**) — **the guard's SCOPING stays OPEN** | — | **What actually happened on that box:** the credential was consumed 2026-07-23 09:53:41 and **applied successfully** — the controller reported an `offsite` object continuously until **2026-08-03 05:59:21 UTC**, then it **vanished at 06:12:19** and has been absent for **108 consecutive reports** since. So this is a **regressed apply**, not a burned credential. **Two distinct defects, and the second explains the first's invisibility.** **(a)** `maybeEmitStuck` builds its message from `status.ReportsSinceConsume` (the TOTAL) while hardcoding the phrase *"carry no offbox target"*, and never consults `status.OffsiteReportsSinceConsume` — which is the field that says the opposite. The recommended action (*Re-issue*) is aimed at a failure mode that did not occur. This is R-100's corollary again: an alarm whose text stopped matching what its verdict counts. **(b)** `maybeHeal` refuses **silently** (`OffsiteReportsSinceConsume != 0` → *"regressed-apply shape → operator's call"*, a bare `return` with no log line), so the operator gets a daily e-mail with the wrong story, no heal, and nothing anywhere saying why the heal declined. `offsite_credential_restaged` has **never** fired, on any customer. **The underlying condition is REAL and is the part that matters:** demo-hp currently reports no offsite target at all, i.e. that box's customer app-data has **no off-site copy right now** — and it has been that way since 08:12 CEST on 2026-08-03. A spot check inside the controller container found no restic environment, consistent with the report. **What removed it is not established** and is the first thing to find out. **Fix shape:** the message must state which shape was detected (burned vs regressed) and say what to do for each; the heal's refusal must log its reason; and the regressed shape probably deserves its own event type rather than borrowing the burned one. **Do NOT 'fix' it by widening the heal to restage over a regression** — the guard is right, only mute **CAUSE ESTABLISHED 2026-08-04 (operator confirms no hub-side offsite config change).** The regression is a **guest REBUILD**: at 06:09:40 `host_leaf_changed` (agent re-keyed), at 06:12:18 `controller_started (0.192.0)` — the controller went **0.187.0 → 0.192.0** with a **new config hash** (`1f725a2e843c` → `744e83d72c80`) — and the report at 06:12:19 is the first without `offsite`. The pre-rebuild object was fully healthy: `escrow_state: escrowed, last_status: ok, last_success 2026-08-03T02:16:39Z, snapshot_count 15, repo_size 40.9 MB`. → **R-193** owns the rebuild half. **AND THE HEAL'S GUARD IS WRONG FOR EXACTLY THIS CASE, which is why the automation that exists to fix it declined.** `maybeHeal` refuses when `OffsiteReportsSinceConsume != 0`, reading that as *"the apply regressed, so it is the operator's call"*. But `CountReportsOffsiteSince` counts the **OLDEST 500 reports since the consume** (`ORDER BY id LIMIT 500`) — for demo-hp all 500 predate the rebuild. **Offbox evidence from before a rebuild is not evidence that the credential still works**, so the guard reads healthy history as a reason not to heal a box that demonstrably cannot apply. The fix is to judge on RECENT evidence (e.g. the latest N reports, or evidence after the newest `controller_started`), not on everything since the consume. **SPIKE 2026-08-04 — BOTH HALVES CONFIRMED WITH NUMBERS, still OPEN, still not fixed here** (`audits/SPIKE-offsite-credential-recovery-2026-08-04.md` Q7). The query is quoted at source (`store.go:987`): `... ORDER BY id LIMIT 500` = **the oldest 500**. Reproduced against the live hub DB with demo-hp's real consume anchor `2026-07-23 09:53:41`: the guard sees `total=500, withOffsite=500`, spanning `2026-07-23 09:53:47` → **`2026-07-28 11:17:40`** — the entire evidence set ends **six days before** the 2026-08-03 rebuild. The true window totals are `1174 / 1063` (⇒ 111 without, matching the 111 offsite-less reports). So the e-mail's *"500 report(s) since carry no offbox target"* interpolates `ReportsSinceConsume` while `OffsiteReportsSinceConsume` was **500** — the message states the precise negation of its own measurement. `offsite_credential_restaged` has **never fired for any customer** (zero rows of that type in the DB — checked, not assumed). **A NEW REASON NOT TO FIX THIS IN ISOLATION, from the same spike:** under R-193's Q2 finding a successful auto-restage would have restored demo-hp's TRANSPORT while the box minted a new repo password anyway — the heal can protect the plumbing and **cannot** protect the data, and had it fired on 2026-08-04 both boxes would have looked healthy while their snapshots were orphaned. **That is strictly worse than the current loud failure.** Whatever shape the fix takes must say so in its message. **RECON 2026-08-04 adds two inputs and changes no verdict** (`audits/RECON-offsite-dr-chain-2026-08-04.md`). **(1) The guard's own conclusion — that a fix here protects the plumbing and not the data — is now stronger, not weaker:** even a perfect restage leaves the rebuilt box minting a fresh repo password, and per **R-198** the old one is destroyed by the re-ceremony the box is pushed into. Whatever shape the message takes must say that in the same breath, or it will read as an all-clear. **(2) The recency-bounded discriminator this row asks for has a ready anchor the hub already receives:** the report ACK's `escrow{identity_blob_present, restic_pw_sha256}` moves when a box re-keys, so "evidence since the newest re-key" is computable from data already stored — the same observation R-197 makes, aimed at this guard's time window. **BOTH HONESTY HALVES SHIPPED 2026-08-04 (hub v0.93.0); THE GUARD'S LOGIC IS DELIBERATELY UNTOUCHED.** **(a) The message now describes what was measured.** The one stuck state is reported as the two situations it actually covers — **burned** (`OffsiteReportsSinceConsume == 0`) and **regressed** (> 0, the demo-hp shape) — each stating its own measurement and carrying its own recommendation; the regressed text explicitly WITHDRAWS Re-issue and points at what removes an offbox target (a guest rebuild, R-193). `offsite_reports_since_consume` rides the details for the first time. **(b) Every refusal to self-heal leaves a record** — a `notification_log` row on the operator channel, status `refused`, with its reason (the R-182 suppressed-e-mail precedent), riding the stuck event's 24 h cadence so it sits beside the e-mail it explains rather than accumulating per tick. The two conditions were split into separate branches solely so each can name its own reason; **the set of situations in which the heal fires is byte-for-byte what it was**. **(c) Not in the spec and done anyway, narrowing only:** `offsite_delivery_stuck` and `offsite_credential_restaged` are added to `operatorOnlyEvents`. Neither was ever registered and neither has a `customerMessages` entry — which is not a block — so a customer with a configured recipient was in line for an English e-mail about one-time passwords being *"likely burned"*. Measured live: `notification_log` holds operator rows for demo-hp and no customer rows, which is NOT evidence the leg was blocked (equally consistent with no configured recipient), so the register makes it structural. **WHAT STAYS OPEN, and it is this row now:** `CountReportsOffsiteSince` reads `ORDER BY id LIMIT 500` — the OLDEST 500 reports after the consume — so the counts describe the start of the window, not the present. Its correct shape (recency-bounded, rebuild-aware) depends on the recovery chain that is not yet assembled (R-199/R-200/R-201), so it was NOT fixed here. **The window is named inside the alert text** so the limitation travels with the number instead of being laundered into a confident sentence. **Red-proofs observed:** restoring the single hardcoded sentence fails both message scenarios (the first mutation attempt left the default branch in place and only the burned scenario failed — recorded because a mutation that does not remove every guard is not a red-proof); replacing the regressed branch with a bare `return` fails the refusal record and its cadence test. | CC |
+| **R-193** | **A guest rebuild silently drops the off-site app-data tier, and nothing restages the credential.** demo-hp was rebuilt on 2026-08-03 (controller 0.187.0 → 0.192.0, new config hash, agent leaf re-keyed at 06:09:40). Before it, the offsite tier was healthy and working — `escrow_state: escrowed`, `last_status: ok`, last success **02:16:39Z that morning**, **15 snapshots, 40.9 MB**. After it: no `offsite` object in any of **108** reports, and **no off-site copy of that customer's app data since 08:12 CEST on 2026-08-03** | **OPEN** — the (c) decision is TAKEN (accept the risk); the chain is still unassembled | — | **Mechanism, fully evidenced.** The restic credential reaches a box exactly once, as a one-time secret. demo-hp's was consumed **2026-07-23 09:53:41**; the rebuilt controller came up with a fresh data volume, no copy of it, and **no way to ask for another** — the hub is the only side that can stage one, and it will not re-stage a consumed secret on its own (the R-71c self-heal would, but it refuses — see R-192). **demo-felhom survived the SAME rebuild by luck, and the contrast is the proof:** its secret was created 2026-07-21 and still **UNCONSUMED**, so when its config hash changed at 07:17:54 and `offsite` dropped for exactly one report, it consumed the staged secret at **07:17:58** and was reporting `offsite` again by 07:19:10. One box had a spare credential staged and recovered in 76 seconds; the other did not and has been unprotected for a day. **That difference was not a design decision — it was an accident of which box happened to have an unconsumed secret lying around.** **Why this is not just "re-issue it":** the remedy (Re-issue) resets the sub-account password via the Hetzner API and, per R-39's record, **rotates the restic password and makes the escrow STALE** — so it needs the recovery-code ceremony re-run, and the continuity of the 15 existing snapshots under the new credential must be VERIFIED, not assumed (`hub v0.60.0` retains superseded escrow, and the orphan guard is move-aside-never-delete). That is an operator act with a customer-facing consequence, so it is not something to fire automatically without deciding the escrow question first. **What to design:** a rebuild is a normal, expected event on these boxes — the offsite tier must survive one, either by the hub restaging automatically when a re-enrolled box reports no offsite (the R-192 guard fix makes this safe), or by the credential being recoverable from escrow at re-bootstrap rather than delivered once and unrecoverable **RESOLVED ON THE BOX 2026-08-04 (operator-authorised).** Re-issue fired through the designed endpoint (`POST /configs/demo-hp/offsite-reissue`, HTTP 303): hub staged a fresh one-time password at **07:11:51**, the box's config hash moved `744e83d7` → `5eee0e42`, R-71a's settle-gate reported **GO** (*at/above floor 0.156.0, we are 0.194.0*), the password was **consumed 15 s later at 07:12:06**, and the controller logged *offsite configured for u629488-sub3@…:/home/felhom-repo* at 07:12:09 — the **same sub-account (275124) and the same repo path**, since Re-issue resets the sub-account password and the one-time password is only the transport credential used once to install the box's own SSH key. **THE ESCROW DID NOT RECOVER BY ITSELF — a correction to this session's own first reading.** `escrow_state` went `pending` → `escrowed` 15 s after the apply and CC inferred an automatic re-escrow; **the operator had run the ceremony**. It needed a human, on BOTH boxes: demo-hp escrowed 07:16:02, demo-felhom (whose offsite re-applied on its own the previous day but whose escrow had been `pending` ever since) escrowed 07:20:28. **A 15-second state change is not evidence of automation** — that is the same class as reading an absent log line as success. **Snapshot continuity is NOT yet established and must not be assumed from the counters:** both boxes report `snapshot_count: 0, repo_size_bytes: 0`, but the run-history keys (`last_run`, `last_status`, `last_success`) are **absent entirely** rather than zeroed — the shape of a controller that has never run an offbox backup in this lifetime, not of an empty repo. demo-hp's pre-rebuild object carried all three plus 15 snapshots / 40.9 MB. ~~**The next scheduled `offbox-backup` (04:15) decides it:** 15+ snapshots ⇒ the repo reattached; 1 ⇒ it started fresh and the old snapshots are orphaned-but-retained.~~ **SPIKE 2026-08-04 SETTLED IT WITHOUT WAITING, AND THE ITEM IS BIGGER THAN FILED** (`audits/SPIKE-offsite-credential-recovery-2026-08-04.md`). **(1) THE ONE-SHOT SECRET IS NOT WHERE THE HARM IS.** Three secrets exist; the one-time password is the *recoverable* one (the operator can reset it at the provider any time) and the box's SFTP key is regenerable by design. The **restic repository password** — the DATA key, which the agent's own source calls *"irreplaceable (unlike the SFTP access key…)"* (`felhom-agent/internal/escrow/identity.go:35-39`) — is the one a rebuild destroys, and **nothing automatic ever restages it**: `WriteOffboxSecrets` mints a fresh 256-bit password whenever `<DataDir>/offbox/repo_password` is absent (`offbox.go:392`), and the only recovery path, `InjectOffboxPassword`, has **exactly one caller in the whole repo** — a web form a human pastes into (`web/offbox_handlers.go:189`). **(2) MEASURED, WITHOUT TOUCHING A BOX:** the hub already stores `restic_pw_sha256` on both the live and the superseded escrow, so the question is a hash comparison. demo-hp `8e03eddf…` → `8a9e33aa…`; demo-felhom `48741892…` → `c60c8bc7…`. **Both boxes minted a new repository password.** **(3) THE CONTRAST IN THIS ROW IS FALSE FOR THE DATA.** demo-felhom's 76-second "lucky" recovery restored **delivery only** — its pre-rebuild object carried **36 snapshots / 1.14 GB** (`repo_size_bytes 1136685919`) and it has reported `snapshot_count: 0` in all 109 reports since, with a changed repo password and **nothing marking its escrow stale for 13 h**. Both boxes lost repository continuity; one loudly, one silently, and **the silent one is worse**. **(4) Q3 IS UNMEASURED AND THE BINARY WAS WRONG.** Neither box could run on 2026-08-04 02:15 UTC (demo-hp had no target at all until 07:15; demo-felhom's target was `escrow_state: pending`, which `OffboxRunnable` blocks) — **the decisive run is 2026-08-05 ~02:15 UTC**. Source predicts a **third** outcome, neither 15 nor 1: same account + same repo path (`u629488-sub3:/home/felhom-repo`, and `repoPath` is a compile-time constant) + new password + `claimed: 1` ⇒ `ensureOffboxRepo` classifies **orphaned** and returns `ErrOffboxOrphaned` — **the run refuses and shows the orphan card**, it does not start a silent fresh history. **Record which of the three actually occurs; a prediction from source is not a measurement.** **(5) CANDIDATE (b) IS NOT IMPLEMENTABLE AS STATED** — the escrow is R-wrapped/zero-knowledge and the hub has no recovery code, so "recoverable from escrow at re-bootstrap" describes a customer-present ceremony, i.e. the manual form that already exists. **(6) CANDIDATE (a) ALREADY EXISTS AND IS WIRED TO THE WRONG EVENT:** `reissueOnReenroll`'s **F3 leg** does exactly this (`api/handler.go:1051-1084`) but sits behind `handleHostEnroll`'s mint-once-reuse short-circuit (`if existing != nil { return }`), and a **guest** rebuild leaves the `hosts` row intact — so F3 is never reached. **(7) A NEW CANDIDATE (c), not previously named and recommended second:** the **agent survives a guest rebuild**, already receives the repo password over the pinned local API (`POST /escrow/stage-secret`) and already writes it to a fixed 0600 path — it merely **wipes** it after the ceremony. Retaining it and serving it back is the only candidate that addresses the irreplaceable secret, and every seam it needs exists. Its cost is one deliberate trade the operator must make (a copy of the data key at rest on the Proxmox host — see D6). **SPIKE RECOMMENDATION: ship the honesty pass (R-196 + R-197) now; then decide (c). Do NOT ship (a) first — it would have hidden this.** **NOT CLOSED — WAITING-ON-OPERATOR for the (c)-vs-accept-it decision, stated at the end of the spike.** **RECON 2026-08-04 — the chain was traced link by link, and the picture is worse than the spike's** (`audits/RECON-offsite-dr-chain-2026-08-04.md`). **(A) THE SPIKE'S CANDIDATE (b) IS OVERTURNED IN PART.** "Recoverable from escrow" is not blocked by zero-knowledge — the *hub* cannot open the blob, the *customer* can, with R. What is genuinely impossible is an **unattended** recovery. A **customer-present** one is a real design, and the operator has now ruled on its shape (below). **(B) THE CHAIN IS NOT ASSEMBLED — eleven links, and the automation stops at four.** Mint → stage → seal → store on the hub are PROVEN-LIVE. Then: the hub's blob-serving endpoints have **no client anywhere** (**R-199**); unsealing's only production caller is a `--selftest` mode reading R from an env var; nothing extracts `restic_repo_password` from the recovered bundle; the injection seam **has no form** (**R-200**); and reopening an existing repo with a recovered password has **never happened** (**R-201**). **(C) THE LOAD-BEARING NEW FACT, and it retires this row's own "hub v0.60.0 retains superseded escrow" premise: the retention does NOT retain the restic repo password** — `host_escrow_superseded` has no `identity_blob` column (**R-198**). Both demo boxes' old passwords were destroyed by the 2026-08-04 re-ceremonies, so the orphaned snapshots are unrecoverable for a **second, independent** reason; keeping R would not have helped. **(D) A FAIL-CLOSED REFUSAL IS IMPLEMENTABLE — this is the most useful thing settled.** The hub already tells every box, on every report ACK, `escrow{identity_blob_present, restic_pw_sha256, created_at}` (`hub/internal/api/handler.go:504-510`) — and the controller **discards it** whenever no offbox target exists (`report/escrow_confirm.go:75-84`). Persisting it (the `ClaimSync` set-only pattern, `report/claim_sync.go:39-53`) and refusing to mint when a blob covers a password we do not have needs **no new hub API and no new secret**. **(E) OPERATOR RULING, 2026-08-04, recorded verbatim:** *"If a node is a fresh install AND the hub has a recovery blob, then the controller should yell that recovery is available, and provide a form for the customer to enter the recovery key. After unlocking the blob, the controller should show what will be recovered before proceeding."* Priced row by row in the recon §9: fresh-install signal **exists** (the mint branch's own `os.Stat`); hub-has-a-blob **exists on the wire, S to persist**; the yell **S**; an **R** form **does not exist** (the UI has only ever *emitted* R) **S**; unsealing must cross agent→controller because the controller image ships no `age` — **M**, one new agent local-API endpoint mirroring `/escrow/ceremony/claim`, plus a narrow hub `GET /hosts/<id>/escrow`; the **preview is cheap and read-only** — `restic snapshots --json` + `stats --mode raw-data --json` are already how the box counts snapshots (`offbox.go:1234-1265`), so count, dates, sizes, app tags and paths are all knowable before committing **S**. **Security question put to the operator, not answered:** the form sits behind the dashboard password (bcrypt + CSRF + 5/min lockout); the preview exposes backup cadence and app names; the form is an **oracle** for a stolen R and must fail as generically as `UnwrapIdentity` already does; and R transits the agent, which is the same trade as option (c) in a smaller, time-bounded form. **(F) THE DRILL IS DESIGNED AND NOT RUN** (recon §10): demo-hp, ~3–4 h, R kept deliberately, sentinel file sha256 before and after, **pass = byte-identical sha256, NOT "the repository opened"**, fail = a snapshot count of 1. **Run R-198's fix first.** **(G) Q3 STILL UNMEASURED:** neither box has run since (`last_run` absent on both, 2026-08-04 09:49/09:56 reports) — the decisive run remains **2026-08-05 ~02:15 UTC**. **OPERATOR RULINGS 2026-08-04, and one of them changes what the other items are for.** (1) **Candidate (c) is REFUSED — the risk is accepted:** no repository password is retained on the Proxmox host. **That makes the customer-present recovery path the ONLY way back from a rebuild**, which is why R-198 was shipped the same day as a load-bearing fix rather than a tidy-up: with no host-retained copy, everything runs through the retained identity blob, and until hub v0.93.0 the ceremony destroyed it. (2) **Run the drill, after R-198** — R-198 has shipped, so the drill is the next session (design: `audits/RECON-offsite-dr-chain-2026-08-04.md` §10; tracked as R-201). (3) **Delete the orphaned ciphertext** — ~1.2 GB across the two demo boxes; **STILL OWED**, deliberately not done in v0.93.0 (a destructive act on a protected endpoint does not ride a schema-change release). **What v0.93.0 delivers against this row:** the key now SURVIVES a supersession (R-198) and a changed key is now REPORTED on the day (R-197). **What it does NOT:** the chain that hands the key back is still unassembled at three links — R-199 (no client for the hub's blob-serving endpoints), R-200 (no form for the injection seam), R-201 (never exercised end to end). This row stays open until the drill returns a byte-identical sentinel file. | CC + operator |
 | — | Storage Box **snapshots** on `storage-box-pool-1` — plan SET (daily 00:00, keep 7) but **0 taken yet** | WATCHING | first run tonight 00:00 | Confirm `size_snapshots > 0` tomorrow; until then the mitigation is armed, not proven | CC |
 | — | `PBS-storage-1` (u629193, box 611421) still `status=active`, 19.9 MB | WAITING-ON-OPERATOR | operator console | Delete the box | operator |
 | **R-90** | ~~ep0 RAM headroom — 4 GiB swap survived its first reboot 2026-07-27; 3.8 GB RAM unchanged~~ | **CLOSED — the operator rescaled ep0 to a CX33 on 2026-08-03** | — | **MEASURED ON THE BOX, not read from an invoice:** `felhom-hetzner` reports `Mem: 7757` MB total (**8 GB**, was 3.8) and `nproc` **4**. **The interim lever survived and was checked rather than assumed** — a resize is a stop/start, so "the swapfile is still there" was an assumption until measured: `/swapfile`, 4 GiB, dated `Jul 27 14:40`, **active** (`swapon --show` → `/swapfile file 4G 0B -2`), 0 B in use on an idle box. **THE 40 GB LOCAL DISK DID NOT CHANGE** and must not be "corrected" alongside the RAM: `/` is 38 G, 58% used. This was a CPU/RAM resize only, so every disk figure in the runbooks still stands — the separate 98 G volume at `/mnt/pbs-datastore` (R-82 P0.3) is unaffected. **Why this was BLOCKED and no longer is:** the row recorded CX33 as *"confirmed unavailable even powered OFF"* — the Cost-Optimized line's limited availability, not a power-state problem. It became available and the operator took it. **Documentation corrected** (`RUNBOOK-ep0-datastore-volume`, `RUNBOOK-pbs-prune-serverside` ×2, `runbooks/offsite-endpoint.md` ×2, `runbooks/target-selection.md`) and **audit/evidence documents ANNOTATED, not revised** (`SPIKE-connectivity-wireguard-2026-07-03`, campaign-10 `phaseA-journal`) — they record what was true when written and that is their value. **Still open and still the operator's, deliberately untouched:** `target-selection.md`'s *"D-d did not name ep0 either way. Confirm it explicitly."* | — |
diff --git a/documentation/backlog/ROADMAP.md b/documentation/backlog/ROADMAP.md
index 0311672..5dc3345 100644
--- a/documentation/backlog/ROADMAP.md
+++ b/documentation/backlog/ROADMAP.md
@@ -57,6 +57,10 @@
 | R-16 | Operator hygiene: campaign6 autofs orphan (clears on host reboot) + tied-CreatedAt flash duplicates (audiobookshelf/komga/romm) | XS | open (doc-drift bit CLOSED) | Viktor's own action items from 6D/6E. **Doc-drift leftover CLOSED (host-install v1.17.0, 2026-07-17):** the R-20-noted stale "EMPTY by default" operator-key comment corrected (keys are PINNED). Remaining = the two operator items above |
 | R-22 | **PBS-DR pre-check self-grant (F4).** On a non-default storage id the token-auth `GET /storage/<id>` pre-check 403s (no ACL yet) and used to abort before the root-run `grant` that creates it. | S | **SHIPPED + PROVEN-LIVE agent v0.89.0** (2026-07-17) | On a 403 the reconcile self-grants via the root wrapper + re-reads, then converges. Red-proof `TestSelfGrant_PreCheck403DoesNotAbortBeforeGrant`; live-reproduced on the demo (marker aside + ACLs revoked → self-grant → `converged state=adopted` in ~3 s, ACLs restored, offsite active). Origin `tests/VALIDATION-n100-baremetal-2026-07-16.md` F4. |
 | R-17 | Old-box archive (u629193-sub1) retirement — 9/9 byte-identical restores verified | XS | **CLOSED 2026-07-22 — archive deleted (operator console)** | **operator ruling 2026-07-21**: delete the archive now; the 9/9 byte-identical restores are the evidence it is no longer needed. **CC spike-lite (2026-07-21) — it CANNOT be deleted through existing tooling, and CC did not improvise credentialed API calls:** (a) `felhom-tenantsync.sh` does not touch Hetzner at all — it manages PBS namespaces/tokens only; (b) the hub CAN delete sub-accounts (`hetznerapi.DeleteSubaccount`), but its ONLY caller is `offsite.Deprovision`, which selects by the `felhom-customer=<id>` label and runs as part of a customer RESET — a legacy archive sub-account from the 2026-07-09/10 spikes carries no such label, so no tooling verb targets it; (c) the only in-repo references are TEST FIXTURES (`hub/internal/hetznerapi/fake.go` generates the `u629193-sub%d` pattern; `felhom-controller/.../dr_recipe_test.go` uses it as a literal) — nothing live points at it. **Operator console steps:** Hetzner Storage Box console → box `u629193` → Sub-accounts → `u629193-sub1` → confirm the directory holds only the old-box archive → Delete. Deleting the sub-account destroys its data; the 9/9 verification is the sign-off. **CLOSED 2026-07-22: the operator executed the console action — `u629193-sub1` deleted, confirmed no sub-accounts remain on PBS-storage-1** |
+| R-198 | **The superseded-escrow retention kept the K-escrow and dropped the identity blob** — so it preserved the PBS key and destroyed the offsite restic repository password, with the escrow CEREMONY as the destroying act | S | **SHIPPED (hub v0.93.0, 2026-08-04)** | Corrects the escrow-ceremony capability-map row's v0.60.0 retention claim (was struck through 2026-08-04, now restated as what ships). One column + one SELECT list, in the shared `demoteCurrentEscrowTx`, so both callers are fixed at once. Nothing backfillable. **Load-bearing, not tidy:** with R-193(c) refused, customer-present recovery is the only route back from a rebuild and it runs entirely through the retained identity blob |
+| R-197 | **The hub stored both halves of "did this box's offsite data key change" and compared them nowhere** | S | **SHIPPED (hub v0.93.0, 2026-08-04)** | New `offsite_repo_key_changed` (warning, operator-only, edge-triggered, no hash values). Flips nothing in the capability map — it adds a signal, not a capability |
+| R-196 | **Five comments claimed `ReissueCredentials` rotates the restic repo password** — it resets the PROVIDER password and cannot touch the repo password | S | **comments corrected (hub v0.93.0); the BEHAVIOUR stays open** | The false-staleness alarm is a behaviour change and must not ride a comment-correction release — and it matters MORE now, because under R-198 an unnecessary ceremony supersedes a blob rather than being harmless bookkeeping |
+| R-202 | **The orphan card promises recoverability unconditionally**, which after R-198 is true going forward and false for anything already orphaned | S | **gate hit 2026-08-04 — card untouched, sentence still live** | Blocked on knowing which escrow generation an orphaned repo belongs to (R-199/R-201). A single ACK boolean can say a retained recoverable blob EXISTS but not that one COVERS this repo; a conditional promise that can still be false is worse on that surface than a hedged one |
 | R-19 | Internet-outage customer-experience drill: pull WAN on demo, verify lan_resolver path, document what the customer actually sees/does | S | idea | Flips map row E "LAN access" IMPLEMENTED→PROVEN-LIVE |
 | R-20 | ~~Verify operator-key pinning is fully in the day-0 install flow~~ | XS | **closed** (2026-07-16) | Confirmed against `scripts/felhom-host-install.sh` source (not changelog): keys resolve at L1181–1219 (script constants `OPERATOR_KEY_*`, populated, `--operator-pubkey-file` override), pinned automatically by `step_agent_config()` "STEP 6/8" (L2044; python builds `authz.signers` L2146–2156, reinstall preserves existing), verified at L2332–2337 ("authz signers: N … operator-signed self-update armed"). No interactive prompt or post-install hand-edit — fully automatic. Doc-drift note: the L193–197 "EMPTY by default" comment is stale vs the now-populated constants (→ R-16 hygiene) |
 | R-23 | **Immediate-sync Direction-2 follow-ups** (hub v0.58 / controller v0.140, 2026-07-16): **(a) — BANKED 2026-07-21 (both legs).** The operator-UI save->apply round trip is PROVEN: the STOP-2 global-floor save (hub `18:56:27 CEST`) released the controller's held wait in the **same second** (`16:56:27Z wait woke: generation=1 - firing out-of-cycle report`), with the report built 2 s later; the ring also shows `wait baseline generation=0` at startup (baseline recorded WITHOUT firing, as designed) then `generation=1`, so the generation advanced past 0. **RESTART LEG BANKED 2026-07-21 — the floor was moved to a version the box did NOT run, and the swap fired EXACTLY ONCE.** Operator saved global floor 0.153.0 → **v0.154.0** (a real version boundary, unlike the 2026-07-20 attempt which targeted an already-running version and therefore proved nothing). Timeline (guest UTC): `06:57:13` UpdateState `pending` written `initiated_by=auto-floor` → `06:57:17` agent `controller swap requested 0.153.0 -> 0.154.0` → `06:57:19` `image file written, restarting bootstrap` → `06:57:21` container StartedAt + UpdateState `completed_at` → `06:57:29` agent `new controller healthy`. **16 s end to end.** Assertions over the whole window (06:50 → 07:29, 39 min): `controller swap requested` = **1**, agent-driven bootstrap restarts = **1**, `new controller healthy` = **1**, rollback/swap-failed/unhealthy = **0**, container `RestartCount` = **0**. `VerifyStartup` banked it on the next boot (`Post-update startup: update successful (0.153.0 → 0.154.0)`) and the `06:57:52` periodic check logged `Current version 0.154.0 is up to date` — the at/above-floor branch correctly doing nothing. **No storm, no rollback, no second attempt.** *Caveat, disclosed: a hand-deploy of v0.155.0 at `07:17:10` sits inside the observation window and is what StartedAt shows after that point; it never touches `SwapController`, so the swap-count assertions above are uncontaminated across the full window. A second, unplanned confirmation of the at/above-floor branch came with it — after the hand-deploy the box ran 0.155.0 against a 0.154.0 floor and the updater logged `Current version 0.155.0 is up to date` and did nothing.* Evidence: `felhom-controller/REPORT.md` §6 (2026-07-21). *(Superseded note:)* **the self-restart single-fire leg was** - the floor was set to a version the box ALREADY ran, so there was no work and no restart. Finish by bumping the floor to a version the box does NOT run, debug ring open, asserting EXACTLY ONE restart. **Trap found while banking this: the wake is `logx.Debugf`, so it is INVISIBLE in `docker logs` at INFO** and lives only in the debug ring (`GET /api/debug/logs?level=DEBUG`) - a hunter looking at stdout wrongly concludes the box never woke; arguably (b) generalised. (b) cosmetic: the Waiter's "recovered" INFO logs on the next hold completion (`pollOnce` blocks ~240 s), not at reconnect | S | **(a) BANKED in full; only (b) cosmetic remains** | Map row "config/state change round-trips in seconds" flipped PARTIAL->PROVEN-LIVE 2026-07-21 on this evidence. Evidence: `felhom-controller/REPORT.md` 4f |
diff --git a/hub/CHANGELOG.md b/hub/CHANGELOG.md
index 5136feb..1866aa5 100644
--- a/hub/CHANGELOG.md
+++ b/hub/CHANGELOG.md
@@ -1,3 +1,107 @@
+## v0.93.0 — the retention keeps the key it was built to keep, and three things stop lying (2026-08-04, R-198/R-197/R-196/R-192)
+
+### R-198 — the superseded-escrow retention was preserving the wrong key, and the ceremony was destroying the right one
+
+`host_escrow_superseded` shipped in v0.60.0 with a `blob` column — the **K-escrow**, i.e. the PBS
+datastore encryption key. `identity_blob` was added to `host_escrow` **later**, by the slice-10D
+`ALTER TABLE`, and **never to the retained table**. The offsite **restic repository password** — the
+data key for every off-site app-data snapshot — lives inside `identity_blob`. So
+`demoteCurrentEscrowTx`, whose own comment calls it *"THE ONE escrow row-copy routine"*, retained the
+whole-guest key and silently dropped the off-site data key: **precisely the secret the reinstall-orphan
+incident the feature was built for was about.**
+
+**What makes it the most serious defect this project has recorded is not the missing column — it is
+which act destroys the key.** The copy happens as the new blob overwrites the old, so the destroying
+act is the **escrow ceremony**: the exact thing a rebuilt box tells its customer to run, on a card
+that promises in Hungarian that the old backups stay recoverable with their recovery code. Both demo
+boxes crossed that line on 2026-08-04 (07:15:36 and 07:20:08), and their previous repository passwords
+are now unrecoverable whether or not anyone kept the recovery codes.
+
+- `host_escrow_superseded` gains `identity_blob BLOB` (in the CREATE for fresh databases **and** as an
+  additive `ALTER TABLE`, following the existing idiom; tolerated on re-run, changes no existing row).
+- `demoteCurrentEscrowTx` carries it — so **both** callers are fixed by one change: the re-escrow path
+  (`SaveHostEscrow`) and the host-delete demotion (`DeleteHost`).
+- `ListSupersededEscrow` reads it back and `store.HostEscrow` gains `IdentityBlob`, so a retained blob
+  is reachable from Go at all. `CountCurrentEscrowWithIdentity` is the census of who the fix protects.
+- The comment above the table now records that the ruling stated there was not met, and what it cost.
+- **Nothing is backfillable and the code says so:** rows superseded before this were written without
+  the identity blob and their source rows are already overwritten.
+
+**Tests assert the CONSEQUENCE, not the mechanism** — the pre-existing
+`TestSaveHostEscrow_RetainsSuperseded` was green throughout, because it asserted that a retained row
+exists with the old K-blob. `TestSaveHostEscrow_RetainsIdentityBlob` asserts the retained row can still
+yield a repository password, and pins the load-bearing ordering (the identity blob is written **after**
+`SaveHostEscrow`, so the demote sees the previous generation). `TestDeleteHost_DemotesIdentityBlob`
+proves the shared routine through its **other** caller — a shared routine tested through one caller is
+how a fix gets believed on a path nobody exercised. Red-proofs: dropping the column from the copy fails
+both; fixing only the re-escrow caller fails the delete one while the re-escrow one passes.
+
+### R-197 — the hub held both halves of the evidence and compared them nowhere
+
+`restic_pw_sha256` is stored on the current escrow and carried to the retained row on every
+supersession. Comparing the two is what answered the 2026-08-04 recon's hardest question in one query —
+and nothing in the hub did it. demo-felhom's repository password changed on 2026-08-03, orphaning 36
+snapshots / 1.14 GB, and **no event, e-mail, card or log line said so for thirteen hours.**
+
+`SaveHostEscrow` now returns the hash it replaced, and `handleHostEscrowPut` raises
+**`offsite_repo_key_changed`** (warning, operator-only, edge-triggered once per supersession) when both
+hashes are known and differ. The in-between shapes are logged rather than dropped, so *"we chose not to
+alarm"* and *"the check did not run"* never look identical. **No hash value travels** — not in the
+message, not in the details; the event names the host, the customer and the retained count.
+
+**Severity chosen for the world this release creates, not the one it inherits:** before R-198 a changed
+key meant the previous history was unopenable by anyone, ever, which would have argued for `error`.
+From v0.93.0 the superseding ceremony retains the old identity blob, so the situation is *"this
+customer's off-site history now depends on an older recovery code"* — operator-actionable, not a loss.
+`warning` also routes: the dispatcher treats `info` as an intentional non-notify.
+
+### R-192 (partially) — the alert describes what was measured, and a refusal leaves a trace
+
+demo-hp e-mailed this daily from 2026-08-03: *"one-time password consumed 284h19m0s ago and 500
+report(s) since carry no offbox target — the credential is likely burned … Re-issue delivers a fresh
+one."* `OffsiteReportsSinceConsume` for that same call was **500**: every one of those reports carried a
+target. The message stated the precise negation of its own measurement and prescribed a remedy for a
+failure mode that had not occurred — while the self-heal correctly declined, **in complete silence**.
+
+- The one stuck state is now reported as the two situations it actually covers, **burned** and
+  **regressed**, each stating its own measurement and carrying its own recommendation (the regressed
+  text explicitly withdraws Re-issue and points at what removes an offbox target — a guest rebuild,
+  R-193). `offsite_reports_since_consume` is in the details for the first time.
+- **The counting window is named in the text.** `CountReportsOffsiteSince` reads `ORDER BY id LIMIT
+  500` — the **oldest** 500 reports after the consume — so on a long-lived box the counts describe the
+  start of the window, not the present. **That guard defect stays OPEN (R-192)** because its correct
+  shape depends on the recovery chain that is not yet assembled (R-199/R-200/R-201); naming the window
+  is how it stays visible instead of being laundered into a confident sentence.
+- **Every self-heal refusal now leaves a record** — a `notification_log` row on the operator channel
+  with status `refused` and its reason, the R-182 suppressed-e-mail precedent. It rides the stuck
+  event's 24 h cadence, so it sits beside the e-mail it explains rather than accumulating per tick.
+  **The guard's logic is unchanged**: the set of situations in which the heal fires is what it was.
+- `offsite_delivery_stuck` and `offsite_credential_restaged` are added to `operatorOnlyEvents`. Neither
+  was ever registered, and neither has a `customerMessages` entry — which is **not** a block, so a
+  customer with a configured recipient was in line for an English e-mail about one-time passwords being
+  *"likely burned"*. Narrowing only; the operator channel is untouched.
+
+### R-196 — five comments corrected (the spec expected three)
+
+`ReissueCredentials` resets the **provider account** password. It does not and cannot touch the restic
+repository password, which is generated on the box and never leaves it except sealed under R. Five
+places in the hub said otherwise: `offsite/offsite.go` (the `MarkEscrowStale` justification),
+`api/handler.go` (the F3 re-enroll comment), and three in `store/store.go` (the `stale_at` ALTER, the
+`MarkEscrowStale` doc comment, and `EscrowStatus.Stale`). **That false belief sent two separate
+investigations the wrong way in one day.** All five now say what the code does, name the correction and
+cite the recon; the staleness mark is documented as **precautionary**, not evidential. **The behaviour
+is unchanged and R-196 stays OPEN** — the false-staleness alarm it causes is a behaviour change and
+must not ride a comment-correction release.
+
+### Not in this release
+
+**R-199, R-200 and R-201 remain open** — the hub's blob-serving endpoints still have no client, the
+password-injection seam still has no form, and nothing in the recovery path has ever been exercised.
+**Part 5 hit its gate and the orphan card is untouched** — see R-202: a single ACK boolean can say
+whether a retained recoverable blob exists, but not whether one covers *the key this orphaned
+repository was written under*, and a conditional promise that is still capable of being false is worse
+on that surface than a hedged sentence.
+
 ## v0.92.0 — a customer with no machine ever bound does not alarm (2026-08-04, R-195)
 
 `david` is a real prospective customer whose record was created 2026-08-01 with **no host ever bound**
diff --git a/hub/internal/api/escrow_repo_key_changed_test.go b/hub/internal/api/escrow_repo_key_changed_test.go
new file mode 100644
index 0000000..1070b1c
--- /dev/null
+++ b/hub/internal/api/escrow_repo_key_changed_test.go
@@ -0,0 +1,146 @@
+package api
+
+import (
+	"encoding/base64"
+	"encoding/json"
+	"net/http"
+	"strings"
+	"testing"
+
+	"gitea.dooplex.hu/admin/felhom-hub/internal/notify"
+	"gitea.dooplex.hu/admin/felhom-hub/internal/store"
+)
+
+// R-197 (v0.93.0) — a changed offsite repository key must be REPORTED. Both halves of the comparison
+// (host_escrow.restic_pw_sha256 and the row it replaces) have been in the database since SLICE 3 and
+// nothing read them: demo-felhom's repository password changed on 2026-08-03, orphaning 36 snapshots /
+// 1.14 GB, and no event, e-mail, card or log line said so for thirteen hours.
+//
+// Driven through the real endpoint (PUT /hosts/<id>/escrow), not by calling the emitter, so the wiring
+// is part of what is proven.
+
+// escrowBodyWithHash is escrowBody plus the sealed-password hash and an identity blob — the fork-4
+// upload shape. Hash VALUES here are test fixtures, never real secrets.
+func escrowBodyWithHash(blob []byte, resticPwSHA, identity string) string {
+	m := map[string]string{
+		"blob_b64":         base64.StdEncoding.EncodeToString(blob),
+		"key_fingerprint":  "ab:cd:ef",
+		"posture":          "zero_knowledge",
+		"created_at":       "2026-08-04T05:00:00Z",
+		"restic_pw_sha256": resticPwSHA,
+	}
+	if identity != "" {
+		m["identity_blob_b64"] = base64.StdEncoding.EncodeToString([]byte(identity))
+	}
+	b, _ := json.Marshal(m)
+	return string(b)
+}
+
+// Scenario D — a new escrow sealing a DIFFERENT repo password raises exactly one operator signal,
+// naming the host, carrying NO hash value.
+// RED-PROOF: remove the maybeEmitRepoKeyChanged call from handleHostEscrowPut (or make its predicate
+// always fall through) → no event → this FAILS.
+func TestEscrowPut_ChangedRepoKey_RaisesSignal(t *testing.T) {
+	h, st, _ := newTestHandler(t)
+	st.UpsertHost(&store.Host{HostID: "h1", CustomerID: "c1", APIKey: "HKEY"})
+
+	if rr := do(h, http.MethodPut, "/hosts/h1/escrow", "HKEY", escrowBodyWithHash([]byte("k1"), "SHA_GEN1", "age-gen1")); rr.Code != http.StatusOK {
+		t.Fatalf("first PUT = %d (%s)", rr.Code, rr.Body.String())
+	}
+	// Generation 1 is onboarding, not a change — nothing may fire yet.
+	if ev, _ := st.GetLatestEventByType("c1", eventRepoKeyChanged); ev != nil {
+		t.Fatalf("a FIRST escrow must not raise %s: %+v", eventRepoKeyChanged, ev)
+	}
+
+	if rr := do(h, http.MethodPut, "/hosts/h1/escrow", "HKEY", escrowBodyWithHash([]byte("k2"), "SHA_GEN2", "age-gen2")); rr.Code != http.StatusOK {
+		t.Fatalf("second PUT = %d (%s)", rr.Code, rr.Body.String())
+	}
+
+	ev, err := st.GetLatestEventByType("c1", eventRepoKeyChanged)
+	if err != nil {
+		t.Fatal(err)
+	}
+	if ev == nil {
+		t.Fatal("R-197: the repository key demonstrably changed and NO signal was raised — this is the " +
+			"thirteen-hour silence that let demo-felhom lose 1.14 GB unremarked")
+	}
+	if ev.Severity != "warning" {
+		t.Errorf("severity = %q, want warning (info is an intentional non-notify — the operator would not be told)", ev.Severity)
+	}
+	if !strings.Contains(ev.Message, "h1") {
+		t.Errorf("message must name the host, got %q", ev.Message)
+	}
+	// NO HASH VALUE may travel — not in the message, not in the details.
+	for _, forbidden := range []string{"SHA_GEN1", "SHA_GEN2"} {
+		if strings.Contains(ev.Message, forbidden) || strings.Contains(ev.DetailsJSON, forbidden) {
+			t.Errorf("a repo-password hash value leaked into the event (%s): msg=%q details=%q", forbidden, ev.Message, ev.DetailsJSON)
+		}
+	}
+	// Exactly one, not one per anything.
+	evs, _ := st.GetRecentEvents("c1", 50)
+	n := 0
+	for _, e := range evs {
+		if e.EventType == eventRepoKeyChanged {
+			n++
+		}
+	}
+	if n != 1 {
+		t.Fatalf("%s fired %d times for one supersession, want 1 (edge-triggered)", eventRepoKeyChanged, n)
+	}
+}
+
+// Scenario E — an UNCHANGED key says nothing. A customer re-running a ceremony for good reasons must
+// not be punished for it with an alarm.
+func TestEscrowPut_UnchangedRepoKey_Silent(t *testing.T) {
+	h, st, _ := newTestHandler(t)
+	st.UpsertHost(&store.Host{HostID: "h1", CustomerID: "c1", APIKey: "HKEY"})
+
+	do(h, http.MethodPut, "/hosts/h1/escrow", "HKEY", escrowBodyWithHash([]byte("k1"), "SHA_SAME", "age-1"))
+	do(h, http.MethodPut, "/hosts/h1/escrow", "HKEY", escrowBodyWithHash([]byte("k2"), "SHA_SAME", "age-2"))
+
+	if ev, _ := st.GetLatestEventByType("c1", eventRepoKeyChanged); ev != nil {
+		t.Fatalf("a same-hash re-ceremony must be SILENT, got: %+v", ev)
+	}
+	// And it must not have created a superseded row either (pre-existing contract, re-asserted here
+	// because Scenario E's silence would also be produced by the supersede branch never running).
+	if n, _ := st.CountSupersededEscrow("h1"); n != 0 {
+		t.Fatalf("same-hash re-upload created %d superseded row(s), want 0", n)
+	}
+}
+
+// The in-between shapes must not be silent-and-indistinguishable either: a hash-less NEW blob cannot
+// show whether the key changed, and saying nothing at all would look identical to "unchanged".
+// Asserted at the level the code offers — no event (correct: nothing was measured) and no crash.
+func TestEscrowPut_HashlessSupersession_NoSignal(t *testing.T) {
+	h, st, _ := newTestHandler(t)
+	st.UpsertHost(&store.Host{HostID: "h1", CustomerID: "c1", APIKey: "HKEY"})
+
+	do(h, http.MethodPut, "/hosts/h1/escrow", "HKEY", escrowBodyWithHash([]byte("k1"), "SHA_GEN1", "age-1"))
+	if rr := do(h, http.MethodPut, "/hosts/h1/escrow", "HKEY", escrowBodyWithHash([]byte("k2"), "", "age-2")); rr.Code != http.StatusOK {
+		t.Fatalf("hash-less supersession PUT = %d", rr.Code)
+	}
+	if ev, _ := st.GetLatestEventByType("c1", eventRepoKeyChanged); ev != nil {
+		t.Fatalf("a hash-less new blob cannot EVIDENCE a change; it must not claim one: %+v", ev)
+	}
+	// The retention still ran (the hashes differ, so this IS a supersession) — the key is kept even
+	// though the change cannot be evidenced.
+	if n, _ := st.CountSupersededEscrow("h1"); n != 1 {
+		t.Fatalf("superseded rows = %d, want 1", n)
+	}
+}
+
+// R-97a's lesson, pinned in the SAME commit that mints the type: an operator-tier event that is not in
+// operatorOnlyEvents reaches customers as raw English, because a missing customerMessages entry is NOT
+// a block. Checked here rather than in notify so the type's two registers are asserted together.
+func TestRepoKeyChanged_IsOperatorOnly(t *testing.T) {
+	if !notify.IsOperatorOnly(eventRepoKeyChanged) {
+		t.Fatalf("%s is not registered operator-only — a customer would receive operator-grade English "+
+			"about escrow custody", eventRepoKeyChanged)
+	}
+	// The two R-192 types have the same property and the same reason (see the register's comment).
+	for _, et := range []string{"offsite_delivery_stuck", "offsite_credential_restaged"} {
+		if !notify.IsOperatorOnly(et) {
+			t.Errorf("%s is not registered operator-only", et)
+		}
+	}
+}
diff --git a/hub/internal/api/escrow_test.go b/hub/internal/api/escrow_test.go
index 6884fca..9e5b6be 100644
--- a/hub/internal/api/escrow_test.go
+++ b/hub/internal/api/escrow_test.go
@@ -155,7 +155,7 @@ func TestReportACK_EscrowStatus(t *testing.T) {
 	}
 
 	// escrow row with identity blob + hash → the ACK carries all three fields
-	if _, err := st.SaveHostEscrow("hv1", []byte("k-blob"), "fp", "zero_knowledge", "2026-07-09T20:00:00Z", "abc123"); err != nil {
+	if _, _, err := st.SaveHostEscrow("hv1", []byte("k-blob"), "fp", "zero_knowledge", "2026-07-09T20:00:00Z", "abc123"); err != nil {
 		t.Fatal(err)
 	}
 	if err := st.SaveHostDRBundle("hv1", []byte("identity-blob"), "{}"); err != nil {
diff --git a/hub/internal/api/handler.go b/hub/internal/api/handler.go
index 4f92a94..92ae56c 100644
--- a/hub/internal/api/handler.go
+++ b/hub/internal/api/handler.go
@@ -1065,9 +1065,13 @@ func (h *Handler) reissueOnReenroll(cc *store.CustomerConfig) {
 		}
 	}
 	// F3 — offsite continuity: re-stage the one-time offsite password to the fresh controller (the
-	// one-time password only ever reached the OLD controller). The re-issuer resets the restic repo
-	// password, which makes the OLD escrow blob stale — the offsite provisioner invalidates the
-	// escrow (2.3) and emits both events. Skips silently when offsite isn't provisioned/enabled.
+	// one-time password only ever reached the OLD controller). ⚠ CORRECTED 2026-08-04 (R-196): this
+	// used to claim "the re-issuer resets the restic repo password, which makes the OLD escrow blob
+	// stale". It does not and cannot — the re-issuer resets the PROVIDER account password; the
+	// repository password is generated on the box and never leaves it except sealed under R. The
+	// provisioner does mark the escrow stale, but PRECAUTIONARILY (see the reasoning at
+	// offsite.ReissueCredentials), not because this call rotated anything.
+	// Skips silently when offsite isn't provisioned/enabled.
 	if h.offsiteReissuer != nil {
 		if err := h.offsiteReissuer(context.Background(), cc.CustomerID); err != nil {
 			h.logger.Printf("[WARN] offsite re-issue on re-enroll for %s failed: %v", cc.CustomerID, err)
@@ -1141,7 +1145,7 @@ func (h *Handler) handleHostEscrowPut(w http.ResponseWriter, r *http.Request, pa
 	// Store the OPAQUE bytes. No decrypt path exists — the hub cannot open this. Part B (v0.60.0):
 	// when this upload supersedes a DIFFERENT-passphrase old blob, the old one is RETAINED (not
 	// overwritten) so its recovery-code-recoverable history survives (Viktor's data-first ruling).
-	superseded, serr := h.store.SaveHostEscrow(pathHostID, blob, req.KeyFingerprint, req.Posture, createdAt, req.ResticPwSHA256)
+	superseded, prevPwSHA, serr := h.store.SaveHostEscrow(pathHostID, blob, req.KeyFingerprint, req.Posture, createdAt, req.ResticPwSHA256)
 	if serr != nil {
 		h.logger.Printf("[ERROR] Failed to store escrow for host %s: %v", pathHostID, serr)
 		http.Error(w, "Internal error", http.StatusInternalServerError)
@@ -1157,6 +1161,10 @@ func (h *Handler) handleHostEscrowPut(w http.ResponseWriter, r *http.Request, pa
 				"A korábbi helyreállítási csomag megőrizve (új kulcs érkezett).", string(details), "hub"); eerr != nil {
 				h.logger.Printf("[WARN] escrow_superseded event save failed for %s: %v", pathHostID, eerr)
 			}
+			// R-197: the box's offsite DATA key demonstrably changed. Both halves of that comparison
+			// have been stored since SLICE 3 and nothing read them — demo-felhom's key changed on
+			// 2026-08-03 and nothing said so for thirteen hours.
+			h.maybeEmitRepoKeyChanged(host.CustomerID, pathHostID, prevPwSHA, req.ResticPwSHA256, n)
 		}
 	}
 	// Slice 10D.1: optionally store the IDENTITY escrow blob + the non-secret DR directive alongside
@@ -1185,6 +1193,69 @@ func (h *Handler) handleHostEscrowPut(w http.ResponseWriter, r *http.Request, pa
 	w.Write([]byte(`{"status":"ok"}`))
 }
 
+// eventRepoKeyChanged (R-197) — the box's offsite restic REPOSITORY password changed, proven by the
+// hub's own stored hashes. Hub-internal (not in allowedEventTypes, like escrow_superseded) and
+// registered operator-only in notify.operatorOnlyEvents.
+const eventRepoKeyChanged = "offsite_repo_key_changed"
+
+// maybeEmitRepoKeyChanged raises ONE operator signal per supersession when the sealed offsite repo
+// password demonstrably changed. Both hashes have been stored since SLICE 3 (host_escrow and, since
+// v0.60.0, host_escrow_superseded) and NOTHING compared them: demo-felhom's repository password
+// changed on 2026-08-03, orphaning 36 snapshots / 1.14 GB, and no event, e-mail, card or log line
+// said so for thirteen hours — the comparison that eventually found it is this one
+// (audits/RECON-offsite-dr-chain-2026-08-04.md, R-197).
+//
+// THE PREDICATE IS DELIBERATELY NARROW: both hashes known AND different. A first-ever hash (prev "")
+// is onboarding, not a change; a hash-less supersession (now "") cannot show a change happened; an
+// identical hash is a re-ceremony of the SAME password, which is a normal healthy act and must stay
+// silent or a customer is punished for re-running a ceremony. The in-between shapes are LOGGED rather
+// than dropped, so "we chose not to alarm" and "the check did not run" never look identical.
+//
+// SEVERITY = warning, chosen for the world v0.93.0 creates rather than the one it inherits. Before
+// R-198 a changed key meant the previous history was unopenable by anyone, ever — that would have
+// argued for error. From v0.93.0 the superseding ceremony RETAINS the old identity blob, so the
+// previous history stays recoverable with the recovery code that sealed it: the situation is "this
+// customer's off-site history now depends on an older recovery code", which is operator-actionable
+// (check the orphan card, expect a fresh repository) and is not a loss. warning also routes: the
+// dispatcher notifies on warning/error/critical and treats info as an intentional non-notify, and
+// the whole point of this row is that the operator learns on the day.
+//
+// EDGE-TRIGGERED: called only from the superseded branch of the escrow PUT, i.e. once per
+// supersession, never per report. No timer lives here — the dispatcher owns cooldown.
+//
+// NO HASH VALUE TRAVELS. The message and the details name the host, the customer and the retained
+// count only. The hashes are non-reversible, but a hash is still a fingerprint of a live secret and
+// this project's rule is that values do not leave the store.
+func (h *Handler) maybeEmitRepoKeyChanged(customerID, hostID, prevSHA, newSHA string, retained int) {
+	switch {
+	case prevSHA == "":
+		h.logger.Printf("[INFO] escrow for host %s: no previous repo-password hash recorded (first hash, or a legacy hash-less blob) — repo-key-change check not applicable", hostID)
+		return
+	case newSHA == "":
+		h.logger.Printf("[WARN] escrow for host %s: the NEW blob carries no repo-password hash (hash-less supersession) — whether the repository key changed CANNOT be determined from the hub's data", hostID)
+		return
+	case prevSHA == newSHA:
+		return // same password re-sealed: a healthy re-ceremony (Scenario E — silence is correct)
+	}
+	msg := fmt.Sprintf("Offsite repository key CHANGED for host %s: the new escrow seals a different repository password than the one it replaced. "+
+		"The previous off-site history is no longer opened by this box's current key. The superseding blob was retained (%d held), so that history stays recoverable with the recovery code that sealed it — verify the box's off-site tier reports a repository rather than an orphan card, and expect the next backup to start a fresh history.",
+		hostID, retained)
+	details, _ := json.Marshal(map[string]any{
+		"host_id":        hostID,
+		"retained_count": retained,
+		"repo_key":       "changed", // never the hash values
+	})
+	if _, err := h.store.SaveEvent(customerID, eventRepoKeyChanged, "warning", msg, string(details), "hub"); err != nil {
+		h.logger.Printf("[WARN] %s event save failed for %s: %v", eventRepoKeyChanged, hostID, err)
+		return // audit row first: an e-mail without its event row lies (the OffsiteChecker convention)
+	}
+	h.logger.Printf("[WARN] offsite repository key CHANGED for host %s (customer %s) — previous history now depends on the superseded recovery code; %d retained blob(s)",
+		hostID, customerID, retained)
+	if h.dispatcher != nil {
+		go h.dispatcher.ProcessEvent(customerID, eventRepoKeyChanged, "warning", msg, string(details), "hub")
+	}
+}
+
 // handleHostRecoveryCredentialPut vaults a host's break-glass root@pam console credential (TASK G1).
 // SELF-SCOPED (a host key writes only its own; global may write any) — day-0 posts it with the
 // host api_key. The secret is stored at rest and NEVER logged (only the username + a length are
diff --git a/hub/internal/monitor/offsite_delivery.go b/hub/internal/monitor/offsite_delivery.go
index 13ec5b2..50e4984 100644
--- a/hub/internal/monitor/offsite_delivery.go
+++ b/hub/internal/monitor/offsite_delivery.go
@@ -94,40 +94,112 @@ func (c *OffsiteDeliveryChecker) Check() {
 		if age < stuckAfter {
 			continue // normal convergence window
 		}
-		c.maybeEmitStuck(cfg.CustomerID, status, age)
-		c.maybeHeal(cfg.CustomerID, status)
+		emitted := c.maybeEmitStuck(cfg.CustomerID, status, age)
+		c.maybeHeal(cfg.CustomerID, status, emitted)
 	}
 }
 
-// maybeEmitStuck emits offsite_delivery_stuck (warning) once per stuckCooldown per customer.
-func (c *OffsiteDeliveryChecker) maybeEmitStuck(customerID string, status offsite.DeliveryStatus, age time.Duration) {
+// deliveryShape names the two situations the ONE stuck state actually covers. They need different
+// text and different advice, and conflating them is R-192's defect (a).
+type deliveryShape string
+
+const (
+	// shapeBurned — NO report since the consume carried an offbox target: the apply never persisted.
+	// Re-issue is the indicated action.
+	shapeBurned deliveryShape = "burned"
+	// shapeRegressed — reports since the consume DID carry an offbox target and the latest does not:
+	// the credential worked and the target was later lost (a guest rebuild does exactly this, R-193).
+	// Re-issue is NOT indicated; it treats a symptom whose cause is elsewhere.
+	shapeRegressed deliveryShape = "regressed"
+)
+
+func shapeOf(status offsite.DeliveryStatus) deliveryShape {
+	if status.OffsiteReportsSinceConsume == 0 {
+		return shapeBurned
+	}
+	return shapeRegressed
+}
+
+// maybeEmitStuck emits offsite_delivery_stuck (warning) once per stuckCooldown per customer. Returns
+// whether it emitted, so the heal's refusal record rides the same cadence rather than inventing one.
+//
+// R-192 defect (a), fixed here: the message used to interpolate ReportsSinceConsume (the TOTAL) into
+// a hardcoded phrase "report(s) since carry no offbox target", and never consulted
+// OffsiteReportsSinceConsume — the field that says the opposite. On demo-hp it stated, daily, that
+// 500 reports carried no offbox target when all 500 of them did, and prescribed Re-issue for a
+// failure mode that had not occurred. The message now STATES WHAT WAS MEASURED and lets the operator
+// read it; the recommendation follows the shape rather than being hardcoded.
+//
+// THE WINDOW IS NAMED ON PURPOSE. CountReportsOffsiteSince reads `ORDER BY id LIMIT 500` — the OLDEST
+// 500 reports after the consume, not the newest — so on a long-lived customer these counts describe
+// the beginning of the window and not the present. That is a real scoping defect (R-192's other half)
+// and it stays OPEN because its correct shape depends on the recovery chain that is not yet
+// assembled (R-199/R-200/R-201). Naming the window in the text is how it stays visible instead of
+// being laundered into a confident sentence — an instrument that can silently mis-scope its results
+// must say so where it reports them.
+func (c *OffsiteDeliveryChecker) maybeEmitStuck(customerID string, status offsite.DeliveryStatus, age time.Duration) bool {
 	last, err := c.store.LastEventAt(customerID, eventDeliveryStuck)
 	if err != nil {
 		c.logger.Printf("[WARN] offsite-delivery: %s: cooldown read: %v", customerID, err)
-		return
+		return false
 	}
 	if !last.IsZero() && c.now().Sub(last) < stuckCooldown {
-		return
+		return false
+	}
+	shape := shapeOf(status)
+	var msg string
+	switch shape {
+	case shapeBurned:
+		msg = fmt.Sprintf("Offsite delivery stuck (BURNED-credential shape): the one-time password was consumed %s ago; of the first %d report(s) after that consume, NONE carried an offbox target, and the latest report carries none either. The credential never reached a persisted apply. Re-issue delivers a fresh one.",
+			age.Round(time.Minute), status.ReportsSinceConsume)
+	default:
+		msg = fmt.Sprintf("Offsite delivery stuck (REGRESSED-apply shape): the one-time password was consumed %s ago; of the first %d report(s) after that consume, %d DID carry an offbox target — and the latest report carries none. The credential was applied and worked; the target was lost afterwards. Re-issue is NOT the indicated action: find what removed the offbox target (a guest rebuild does, R-193). Automatic restage is deliberately withheld for this shape. NOTE: the counts cover at most the first 500 reports after the consume, so on a long-lived box they describe the start of the window, not now (R-192, open).",
+			age.Round(time.Minute), status.ReportsSinceConsume, status.OffsiteReportsSinceConsume)
 	}
-	msg := fmt.Sprintf("Offsite delivery stuck: one-time password consumed %s ago and %d report(s) since carry no offbox target — the credential is likely burned (apply died between consume and persist). Re-issue delivers a fresh one.",
-		age.Round(time.Minute), status.ReportsSinceConsume)
 	details, _ := json.Marshal(map[string]any{
-		"state":                 string(status.State),
-		"consumed_at":           status.Since.UTC().Format(time.RFC3339),
-		"reports_since_consume": status.ReportsSinceConsume,
+		"state":                         string(status.State),
+		"shape":                         string(shape),
+		"consumed_at":                   status.Since.UTC().Format(time.RFC3339),
+		"reports_since_consume":         status.ReportsSinceConsume,
+		"offsite_reports_since_consume": status.OffsiteReportsSinceConsume,
+		"count_window":                  "oldest 500 reports after consumed_at (R-192, open)",
 	})
 	c.emit(customerID, eventDeliveryStuck, "warning", msg, string(details))
+	return true
 }
 
 // maybeHeal fires the R-71c self-heal when the burned-credential shape is unambiguous:
 // consumed ≥ stuckAfter ago, ≥ healMinReports consecutive reports since with ZERO offbox evidence,
 // one heal per healCooldown — and the R-39(a) guard holds at act time.
-func (c *OffsiteDeliveryChecker) maybeHeal(customerID string, status offsite.DeliveryStatus) {
+//
+// R-192 defect (b), fixed here: every refusal above the "not configured" line now leaves a RECORD.
+// The regressed-shape branch used to be a bare `return`, so the operator received a daily e-mail with
+// the wrong story, no heal, and nothing anywhere saying why the heal declined — "we chose not to act"
+// and "the heal never ran" looked identical. `offsite_credential_restaged` has never fired for any
+// customer, and until now that fact was indistinguishable from the checker being dead.
+//
+// The record is a notification_log row (the dispatcher's suppressed-operator-e-mail precedent, R-182:
+// a decision not to act is written down on the channel it would have used). It rides `recordRefusal`
+// — true only when the stuck event was emitted this pass — so it appears once per stuckCooldown
+// beside the e-mail it explains, rather than once per monitor tick. The GUARD ITSELF IS UNCHANGED:
+// the set of situations in which the heal fires is byte-for-byte what it was; only the silence is
+// gone. The two conditions are split into separate branches solely so each refusal can name its own
+// reason.
+func (c *OffsiteDeliveryChecker) maybeHeal(customerID string, status offsite.DeliveryStatus, recordRefusal bool) {
 	if c.reissuer == nil {
+		return // no provisioner configured: the heal does not exist on this hub, so there is nothing to explain
+	}
+	if status.OffsiteReportsSinceConsume != 0 {
+		c.recordHealRefusal(customerID, recordRefusal, fmt.Sprintf(
+			"regressed-apply shape: %d of the first %d report(s) after the consume DID carry an offbox target, so a burned credential is ruled out — a restage would treat a symptom whose cause is elsewhere. Operator's call (R-193).",
+			status.OffsiteReportsSinceConsume, status.ReportsSinceConsume))
 		return
 	}
-	if status.ReportsSinceConsume < healMinReports || status.OffsiteReportsSinceConsume != 0 {
-		return // box not reporting enough, or offbox evidence exists (regressed-apply shape) → operator's call
+	if status.ReportsSinceConsume < healMinReports {
+		c.recordHealRefusal(customerID, recordRefusal, fmt.Sprintf(
+			"only %d report(s) since the consume (need %d): the box has not reported enough for the burned shape to be unambiguous.",
+			status.ReportsSinceConsume, healMinReports))
+		return
 	}
 	last, err := c.store.LastEventAt(customerID, eventCredentialRestaged)
 	if err != nil {
@@ -146,8 +218,8 @@ func (c *OffsiteDeliveryChecker) maybeHeal(customerID string, status offsite.Del
 		return
 	}
 	if info == nil || info.ConsumedAt.IsZero() {
-		c.logger.Printf("[INFO] offsite-delivery: %s: heal refused — secret row is now %s (R-39(a) guard: never restage over an unconsumed secret)",
-			customerID, secretShape(info))
+		c.recordHealRefusal(customerID, recordRefusal, fmt.Sprintf(
+			"R-39(a) guard: the secret row is now %s — restaging over an unconsumed secret would clobber a password the box may be about to consume.", secretShape(info)))
 		return
 	}
 	ctx, cancel := context.WithTimeout(context.Background(), 3*time.Minute)
@@ -167,6 +239,22 @@ func (c *OffsiteDeliveryChecker) maybeHeal(customerID string, status offsite.Del
 		string(details))
 }
 
+// recordHealRefusal makes a decision NOT to self-heal visible. Always logs; additionally writes a
+// notification_log row on the "operator" channel with status "refused" when `record` is set (the
+// stuck event was emitted this pass), so the refusal sits next to the e-mail that prompted the
+// question. A LogNotification failure is logged, never swallowed, and never blocks the refusal — the
+// refusal is the primary effect.
+func (c *OffsiteDeliveryChecker) recordHealRefusal(customerID string, record bool, reason string) {
+	c.logger.Printf("[INFO] offsite-delivery: %s: self-heal REFUSED — %s", customerID, reason)
+	if !record {
+		return
+	}
+	if err := c.store.LogNotification(customerID, eventCredentialRestaged, "warning",
+		"Automatic offsite credential restage was NOT performed.", "refused", reason, "operator"); err != nil {
+		c.logger.Printf("[WARN] offsite-delivery: %s: could not record the heal refusal: %v", customerID, err)
+	}
+}
+
 func secretShape(info *store.OneTimeSecretInfo) string {
 	if info == nil {
 		return "absent"
diff --git a/hub/internal/monitor/offsite_delivery_honesty_test.go b/hub/internal/monitor/offsite_delivery_honesty_test.go
new file mode 100644
index 0000000..5471cc3
--- /dev/null
+++ b/hub/internal/monitor/offsite_delivery_honesty_test.go
@@ -0,0 +1,223 @@
+package monitor
+
+import (
+	"encoding/json"
+	"strings"
+	"testing"
+	"time"
+
+	"gitea.dooplex.hu/admin/felhom-hub/internal/store"
+)
+
+// R-192 (v0.93.0) — the alert must describe what was MEASURED, and a refusal to self-heal must leave a
+// trace.
+//
+// What was wrong, quoted from the live e-mail demo-hp sent daily from 2026-08-03: "one-time password
+// consumed 284h19m0s ago and 500 report(s) since carry no offbox target — the credential is likely
+// burned … Re-issue delivers a fresh one." OffsiteReportsSinceConsume for that same call was 500:
+// every one of those reports carried a target. The message stated the precise negation of its own
+// measurement and prescribed a remedy for a failure mode that had not occurred — while the self-heal
+// correctly declined, in complete silence.
+
+// regressedFixture puts c1 into demo-hp's real shape: consumed >1h ago, reports WITH an offbox target
+// after the consume, then reports WITHOUT — the latest carrying none.
+//
+// The report timestamps get jitter deliberately: a perfectly regular series lands exactly on
+// boundaries and survives mutations that a realistic one catches.
+func (h dtHarness) regressedFixture(t *testing.T, withOffsite, without int) {
+	t.Helper()
+	if err := h.st.SaveOneTimeSecret("c1", "x"); err != nil {
+		t.Fatal(err)
+	}
+	consumed := time.Now().UTC().Add(-30 * time.Hour).Format("2006-01-02 15:04:05")
+	staged := time.Now().UTC().Add(-31 * time.Hour).Format("2006-01-02 15:04:05")
+	if err := h.st.SetOneTimeSecretTimesForTest("c1", staged, consumed); err != nil {
+		t.Fatal(err)
+	}
+	jitter := []int{0, 3, 1, 7, 2, 5, 11, 4}
+	for i := 0; i < withOffsite; i++ {
+		if err := h.st.SaveReport("c1", []byte(dtReportWithOffsite)); err != nil {
+			t.Fatal(err)
+		}
+		time.Sleep(time.Duration(jitter[i%len(jitter)]) * time.Millisecond)
+	}
+	for i := 0; i < without; i++ {
+		if err := h.st.SaveReport("c1", []byte(dtReportNoOffsite)); err != nil {
+			t.Fatal(err)
+		}
+		time.Sleep(time.Duration(jitter[(i+3)%len(jitter)]) * time.Millisecond)
+	}
+}
+
+func (h dtHarness) refusalRows(t *testing.T) []store.NotificationLogEntry {
+	t.Helper()
+	all, err := h.st.GetRecentNotifications("c1", 50)
+	if err != nil {
+		t.Fatal(err)
+	}
+	var out []store.NotificationLogEntry
+	for _, n := range all {
+		if n.Status == "refused" {
+			out = append(out, n)
+		}
+	}
+	return out
+}
+
+// Scenario F — the message states the measured state, not a denied cause.
+// RED-PROOF: restore the old single hardcoded sentence (interpolate ReportsSinceConsume into
+// "report(s) since carry no offbox target") → the regressed assertions FAIL.
+func TestDeliveryChecker_RegressedShape_MessageMatchesMeasurement(t *testing.T) {
+	h := newDTHarness(t, true)
+	h.regressedFixture(t, 6, 2)
+
+	h.checker.Check()
+
+	saved := h.savedEvents(t, "offsite_delivery_stuck")
+	if len(saved) != 1 {
+		t.Fatalf("stuck events = %d, want 1", len(saved))
+	}
+	msg := saved[0].Message
+
+	// It must NOT assert the thing the data contradicts.
+	if strings.Contains(msg, "carry no offbox target") || strings.Contains(msg, "likely burned") {
+		t.Fatalf("R-192(a): the message still asserts a burned credential on a REGRESSED shape — this is "+
+			"the sentence that stated the negation of its own measurement:\n%s", msg)
+	}
+	// It must name the shape it detected and the measurement behind it.
+	if !strings.Contains(msg, "REGRESSED") {
+		t.Errorf("the message must name the detected shape, got:\n%s", msg)
+	}
+	if !strings.Contains(msg, "6 DID carry an offbox target") {
+		t.Errorf("the message must state the measured offbox-bearing count (6), got:\n%s", msg)
+	}
+	// It must not prescribe the action for a failure mode that did not occur.
+	if !strings.Contains(msg, "Re-issue is NOT the indicated action") {
+		t.Errorf("the message must withdraw the Re-issue recommendation for this shape, got:\n%s", msg)
+	}
+	// The counting window is named, because CountReportsOffsiteSince reads the OLDEST 500 — an
+	// instrument that can silently mis-scope must say so where it reports (R-192's other half, open).
+	if !strings.Contains(msg, "500") {
+		t.Errorf("the message must name its counting window, got:\n%s", msg)
+	}
+
+	var details map[string]any
+	if err := json.Unmarshal([]byte(saved[0].DetailsJSON), &details); err != nil {
+		t.Fatal(err)
+	}
+	if details["shape"] != "regressed" {
+		t.Errorf("details.shape = %v, want regressed", details["shape"])
+	}
+	// The field whose absence was defect (a) is now carried.
+	if got, ok := details["offsite_reports_since_consume"].(float64); !ok || int(got) != 6 {
+		t.Errorf("details must carry offsite_reports_since_consume=6, got %v", details["offsite_reports_since_consume"])
+	}
+}
+
+// The burned shape keeps its own (correct) text and its recommendation — the fix must not blunt the
+// case that was always right.
+func TestDeliveryChecker_BurnedShape_KeepsItsRecommendation(t *testing.T) {
+	h := newDTHarness(t, false)
+	h.burnedFixture(t, 5)
+
+	h.checker.Check()
+
+	saved := h.savedEvents(t, "offsite_delivery_stuck")
+	if len(saved) != 1 {
+		t.Fatalf("stuck events = %d, want 1", len(saved))
+	}
+	msg := saved[0].Message
+	if !strings.Contains(msg, "BURNED") || !strings.Contains(msg, "NONE carried an offbox target") {
+		t.Errorf("the burned shape must state its own measurement, got:\n%s", msg)
+	}
+	if !strings.Contains(msg, "Re-issue delivers a fresh one") {
+		t.Errorf("the burned shape must keep its recommendation, got:\n%s", msg)
+	}
+	var details map[string]any
+	_ = json.Unmarshal([]byte(saved[0].DetailsJSON), &details)
+	if details["shape"] != "burned" {
+		t.Errorf("details.shape = %v, want burned", details["shape"])
+	}
+}
+
+// Scenario G — a refusal to self-heal leaves a durable record naming its reason.
+// RED-PROOF: replace the recordHealRefusal call in the regressed branch with a bare `return`
+// (production behaviour up to v0.92.0) → no row → this FAILS.
+func TestDeliveryChecker_HealRefusal_LeavesARecord(t *testing.T) {
+	h := newDTHarness(t, true)
+	h.regressedFixture(t, 6, 2)
+
+	h.checker.Check()
+
+	if h.reissuer.count() != 0 {
+		t.Fatal("the heal must NOT fire on a regressed shape — the guard is unchanged by this fix")
+	}
+	rows := h.refusalRows(t)
+	if len(rows) != 1 {
+		t.Fatalf("R-192(b): the heal declined and left %d record(s), want 1 — 'we chose not to act' and "+
+			"'the heal never ran' must not look identical", len(rows))
+	}
+	r := rows[0]
+	if r.Channel != "operator" {
+		t.Errorf("refusal channel = %q, want operator (the channel the heal's own event would use)", r.Channel)
+	}
+	if !strings.Contains(r.ErrorMessage, "regressed-apply shape") {
+		t.Errorf("the record must name WHY, got %q", r.ErrorMessage)
+	}
+	if !strings.Contains(r.ErrorMessage, "6 of the first 8") {
+		t.Errorf("the record must carry the measurement it refused on, got %q", r.ErrorMessage)
+	}
+}
+
+// The R-39(a) guard's refusal is recorded too — it was the one refusal that already logged, and it
+// still must not be the only one that does.
+//
+// Reaching it needs the real TOCTOU, not a pre-staged row: staging BEFORE Check() makes the derive
+// itself return staged_awaiting_consume and the pass never reaches the heal at all. Same technique as
+// TestDeliveryChecker_R39aGuard_NeverRestagesOverUnconsumed — the operator stages mid-tick, on the
+// stuck event's dispatch, which runs after the derive and before maybeHeal.
+func TestDeliveryChecker_R39aRefusal_LeavesARecord(t *testing.T) {
+	h := newDTHarness(t, true)
+	h.burnedFixture(t, 5)
+
+	base := h.checker.onEvent
+	h.checker.onEvent = func(cid, et, sev, msg, det, src string) {
+		if et == "offsite_delivery_stuck" {
+			if err := h.st.SaveOneTimeSecret("c1", "operator-fresh"); err != nil {
+				t.Errorf("mid-tick stage: %v", err)
+			}
+			if err := h.st.SetOneTimeSecretTimesForTest("c1", "2026-07-23 12:00:00", ""); err != nil {
+				t.Errorf("mid-tick stamp: %v", err)
+			}
+		}
+		base(cid, et, sev, msg, det, src)
+	}
+
+	h.checker.Check()
+
+	if h.reissuer.count() != 0 {
+		t.Fatal("R-39(a): the heal must never restage over an unconsumed secret")
+	}
+	rows := h.refusalRows(t)
+	if len(rows) != 1 {
+		t.Fatalf("the R-39(a) refusal left %d record(s), want 1", len(rows))
+	}
+	if !strings.Contains(rows[0].ErrorMessage, "R-39(a)") {
+		t.Errorf("the record must name the guard, got %q", rows[0].ErrorMessage)
+	}
+}
+
+// The refusal record rides the stuck event's 24h cadence: it explains the e-mail the operator just
+// received, and must not accumulate one row per monitor tick.
+func TestDeliveryChecker_HealRefusal_RidesTheStuckCadence(t *testing.T) {
+	h := newDTHarness(t, true)
+	h.regressedFixture(t, 6, 2)
+
+	h.checker.Check()
+	h.checker.Check() // the stuck event is swallowed by its cooldown; so is the refusal record
+	h.checker.Check()
+
+	if n := len(h.refusalRows(t)); n != 1 {
+		t.Fatalf("refusal records = %d after three passes, want 1 (one per stuck e-mail, not per tick)", n)
+	}
+}
diff --git a/hub/internal/monitor/offsite_neverran_test.go b/hub/internal/monitor/offsite_neverran_test.go
index 05720c3..0471a71 100644
--- a/hub/internal/monitor/offsite_neverran_test.go
+++ b/hub/internal/monitor/offsite_neverran_test.go
@@ -102,7 +102,7 @@ func TestOffsiteStale_NeverRanEscrowAnchorWins(t *testing.T) {
 		t.Fatal(err)
 	}
 	// escrow blob stored now (SaveHostEscrow stamps updated_at with datetime('now'))
-	if _, err := st.SaveHostEscrow("h1", []byte("blob"), "fp", "zero_knowledge", time.Now().UTC().Format(time.RFC3339), "sha"); err != nil {
+	if _, _, err := st.SaveHostEscrow("h1", []byte("blob"), "fp", "zero_knowledge", time.Now().UTC().Format(time.RFC3339), "sha"); err != nil {
 		t.Fatal(err)
 	}
 	saveOffsiteReport(t, st, "c1", offsiteJSON(true, "escrowed", "", "", 0, 50))
diff --git a/hub/internal/notify/dispatcher.go b/hub/internal/notify/dispatcher.go
index e26f41e..859c0f1 100644
--- a/hub/internal/notify/dispatcher.go
+++ b/hub/internal/notify/dispatcher.go
@@ -421,6 +421,23 @@ var operatorOnlyEvents = map[string]bool{
 	// block — `FormatCustomerEmail` falls back to the raw English message. That mistake shipped
 	// once (v0.78.0) and the comment above records it.
 	"backup_run_failures": true,
+	// R-197 (v0.93.0). "The sealed offsite repository key changed" is a custody fact about escrow
+	// blobs. A customer can take no action on it — the remedy is the operator's inspection of the
+	// off-site tier — and the text is operator-grade English naming host ids and retained-blob
+	// counts. Listed here in the SAME commit that mints the type: an operator-tier type that is not
+	// registered here reaches customers as raw English, because a missing customerMessages entry is
+	// NOT a block (the v0.78.0 defect recorded above).
+	"offsite_repo_key_changed": true,
+	// R-192 (v0.93.0). These two predate the register and were never added to it — a real gap, not a
+	// tidy-up. `offsite_delivery_stuck` is severity warning, has no customerMessages entry, and
+	// therefore fell through to FormatCustomerEmail's raw-English fallback: a customer whose box hit
+	// the stuck shape was in line for an English e-mail about one-time passwords being "likely
+	// burned". Measured on the live hub: notification_log holds operator rows for demo-hp and no
+	// customer rows — which is NOT evidence the leg is blocked (it is equally consistent with no
+	// configured recipient), so the register makes it structural instead of incidental. Narrowing
+	// only: the operator channel is untouched.
+	"offsite_delivery_stuck":      true,
+	"offsite_credential_restaged": true,
 }
 
 // IsOperatorOnly reports whether an event type is barred from customer dispatch. Exported so the
diff --git a/hub/internal/offsite/offsite.go b/hub/internal/offsite/offsite.go
index 30ef4d0..bd830a7 100644
--- a/hub/internal/offsite/offsite.go
+++ b/hub/internal/offsite/offsite.go
@@ -195,13 +195,30 @@ func (p *Provisioner) ReissueCredentials(ctx context.Context, customerID, typ st
 		return fmt.Errorf("offsite: store re-issued one-time password: %w", err)
 	}
 
-	// v0.57.0 (2.3, the escrow-honesty fix): the restic repo password just changed, so any existing
-	// key-escrow blob — which sealed the OLD password — is now STALE. A recovery code minted against
-	// it would decrypt a password that no longer opens the repo. Mark the escrow stale so the hub
-	// stops advertising "ceremony done" and the customer's escrow wizard is offered again; a fresh
-	// ceremony seals the new password and clears the flag. Every credential change also emits a
-	// visible customer event (offsite_reissued always; escrow_stale only when a blob was invalidated).
-	// Best-effort: the password reset already succeeded — a bookkeeping failure here must not fail it.
+	// v0.57.0 (2.3, the escrow-honesty fix). ⚠ ITS STATED REASON WAS FALSE AND IS CORRECTED HERE
+	// (R-196, 2026-08-04). The comment used to read "the restic repo password just changed" — this
+	// function does NOT change it and CANNOT: the repository password is generated on the box
+	// (controller `WriteOffboxSecrets`) and never leaves it except sealed inside the R-wrapped escrow.
+	// What this function changes is the PROVIDER account password (①), which is a different secret at
+	// a different layer. The false premise survived because the EFFECT (a stale escrow) is real, so
+	// nobody checked the CAUSE — and it sent two separate investigations the wrong way in one day
+	// (audits/SPIKE-offsite-credential-recovery-2026-08-04.md Q4).
+	//
+	// WHY THE MARK IS STILL MADE, on honest grounds: a re-issue is the operator's response to a
+	// broken delivery, and the box's re-apply may mint a fresh repository password (it does exactly
+	// that whenever `<DataDir>/offbox/repo_password` is absent — the guest-rebuild shape). The mark is
+	// therefore PRECAUTIONARY, not evidential. The evidential signal is R-197's
+	// `offsite_repo_key_changed`, which fires on a measured hash difference at the next ceremony.
+	// KNOWN CONSEQUENCE, left in place deliberately: on the ordinary re-issue shape — a box that still
+	// holds its repo_password file — the password does NOT change, so this marks a healthy escrow
+	// stale and asks the customer for an unnecessary ceremony. R-196 stays OPEN for that; it is a
+	// behaviour change, not a comment fix, and it must not ride a comment-correction commit.
+	//
+	// Mark the escrow stale so the hub stops advertising "ceremony done" and the customer's escrow
+	// wizard is offered again; a fresh ceremony seals the current password and clears the flag. Every
+	// credential change also emits a visible customer event (offsite_reissued always; escrow_stale
+	// only when a blob was invalidated). Best-effort: the password reset already succeeded — a
+	// bookkeeping failure here must not fail it.
 	escrowStaled := false
 	if host, herr := p.Store.GetHostByCustomer(customerID); herr == nil && host != nil {
 		if esc, eerr := p.Store.GetHostEscrow(host.HostID); eerr == nil && esc != nil {
diff --git a/hub/internal/offsite/offsite_test.go b/hub/internal/offsite/offsite_test.go
index 155298f..1dbfcac 100644
--- a/hub/internal/offsite/offsite_test.go
+++ b/hub/internal/offsite/offsite_test.go
@@ -226,7 +226,7 @@ func TestReissue_InvalidatesEscrow(t *testing.T) {
 	if err := st.UpsertHost(&store.Host{HostID: cust + "-01", CustomerID: cust, APIKey: "k"}); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := st.SaveHostEscrow(cust+"-01", []byte("opaque-blob"), "SHA256:fp", "zero_knowledge", "2026-07-16T00:00:00Z", "OLDHASH"); err != nil {
+	if _, _, err := st.SaveHostEscrow(cust+"-01", []byte("opaque-blob"), "SHA256:fp", "zero_knowledge", "2026-07-16T00:00:00Z", "OLDHASH"); err != nil {
 		t.Fatal(err)
 	}
 	// Before re-issue: current escrow — the hub serves the sealed hash and is NOT stale.
@@ -256,7 +256,7 @@ func TestReissue_InvalidatesEscrow(t *testing.T) {
 	}
 
 	// A fresh ceremony (new blob sealing the new password) clears stale + serves the new hash.
-	if _, err := st.SaveHostEscrow(cust+"-01", []byte("opaque-blob-2"), "SHA256:fp", "zero_knowledge", "2026-07-16T01:00:00Z", "NEWHASH"); err != nil {
+	if _, _, err := st.SaveHostEscrow(cust+"-01", []byte("opaque-blob-2"), "SHA256:fp", "zero_knowledge", "2026-07-16T01:00:00Z", "NEWHASH"); err != nil {
 		t.Fatal(err)
 	}
 	es, _ = st.GetEscrowStatusForCustomer(cust)
diff --git a/hub/internal/store/customer_reset_test.go b/hub/internal/store/customer_reset_test.go
index 1dfffa4..1eb85bf 100644
--- a/hub/internal/store/customer_reset_test.go
+++ b/hub/internal/store/customer_reset_test.go
@@ -25,10 +25,10 @@ func seedRetainedBlob(t *testing.T, st *Store, customerID string) {
 	if err := st.UpsertHost(&Host{HostID: hostID, CustomerID: customerID, APIKey: "h"}); err != nil {
 		t.Fatalf("upsert host: %v", err)
 	}
-	if _, err := st.SaveHostEscrow(hostID, []byte("A"), "fpA", "p", "2026-01-01T00:00:00Z", "shaA"); err != nil {
+	if _, _, err := st.SaveHostEscrow(hostID, []byte("A"), "fpA", "p", "2026-01-01T00:00:00Z", "shaA"); err != nil {
 		t.Fatalf("escrow A: %v", err)
 	}
-	if _, err := st.SaveHostEscrow(hostID, []byte("B"), "fpB", "p", "2026-01-02T00:00:00Z", "shaB"); err != nil {
+	if _, _, err := st.SaveHostEscrow(hostID, []byte("B"), "fpB", "p", "2026-01-02T00:00:00Z", "shaB"); err != nil {
 		t.Fatalf("escrow B: %v", err)
 	}
 	if err := st.DeleteHost(hostID, true); err != nil {
diff --git a/hub/internal/store/escrow_identity_retention_test.go b/hub/internal/store/escrow_identity_retention_test.go
new file mode 100644
index 0000000..44e34b6
--- /dev/null
+++ b/hub/internal/store/escrow_identity_retention_test.go
@@ -0,0 +1,168 @@
+package store
+
+import (
+	"bytes"
+	"testing"
+)
+
+// R-198 (v0.93.0) — the retention must keep the OFF-SITE data key, not only the PBS key.
+//
+// WHAT WAS BROKEN, and why these tests are the ones that would have caught it: host_escrow_superseded
+// shipped with `blob` (the K-escrow / PBS datastore key) and `identity_blob` was added to host_escrow
+// by a later ALTER and never to the retained table. The restic REPOSITORY password lives inside
+// identity_blob. So every supersession retained the whole-guest key and destroyed the off-site data
+// key — the exact secret the retention exists to preserve — and the destroying act is the escrow
+// ceremony a rebuilt box asks its customer to run.
+//
+// The pre-existing TestSaveHostEscrow_RetainsSuperseded was GREEN throughout, because it asserts the
+// MECHANISM (a retained row exists, with the old K-blob) and not the CONSEQUENCE (the retained row can
+// still yield a repository password). These assert the consequence.
+
+// Scenario A — a re-escrow retains BOTH sealed keys.
+// RED-PROOF: drop `identity_blob` from demoteCurrentEscrowTx's INSERT/SELECT (production behaviour up
+// to v0.92.0) → the retained row's identity blob is nil → this FAILS.
+func TestSaveHostEscrow_RetainsIdentityBlob(t *testing.T) {
+	st := newTestStore(t)
+	const h = "hid-1"
+	oldIdentity := []byte("age-blob-sealing-REPO-PASSWORD-OLD")
+	newIdentity := []byte("age-blob-sealing-REPO-PASSWORD-NEW")
+
+	// Generation 1: the K-escrow, then the identity blob — the real order the escrow PUT uses
+	// (SaveHostEscrow, then SaveHostDRBundle).
+	if _, _, err := st.SaveHostEscrow(h, []byte("k-blob-old"), "fp-old", "zk", "2026-07-09T00:00:00Z", "SHA_OLD"); err != nil {
+		t.Fatal(err)
+	}
+	if err := st.SaveHostDRBundle(h, oldIdentity, `{"gen":1}`); err != nil {
+		t.Fatal(err)
+	}
+
+	// Generation 2 with a DIFFERENT sealed repo password → supersede.
+	sup, prev, err := st.SaveHostEscrow(h, []byte("k-blob-new"), "fp-new", "zk", "2026-07-16T00:00:00Z", "SHA_NEW")
+	if err != nil {
+		t.Fatal(err)
+	}
+	if !sup {
+		t.Fatal("a different-passphrase upload must supersede")
+	}
+	if prev != "SHA_OLD" {
+		t.Fatalf("prevResticPwSHA256 = %q, want SHA_OLD (R-197 needs the replaced hash)", prev)
+	}
+	if err := st.SaveHostDRBundle(h, newIdentity, `{"gen":2}`); err != nil {
+		t.Fatal(err)
+	}
+
+	retained, err := st.ListSupersededEscrow(h)
+	if err != nil {
+		t.Fatal(err)
+	}
+	if len(retained) != 1 {
+		t.Fatalf("retained rows = %d, want 1", len(retained))
+	}
+	// THE ASSERTION THIS WHOLE ITEM IS ABOUT: the off-site data key survived the supersession.
+	if retained[0].IdentityBlob == nil {
+		t.Fatal("R-198: the retained row carries NO identity blob — the off-site repository password " +
+			"was destroyed by the ceremony that was supposed to preserve it")
+	}
+	// And it is the PREVIOUS generation's blob, not the one that replaced it. This pins the ordering
+	// dependency named on demoteCurrentEscrowTx: the identity blob is written AFTER SaveHostEscrow, so
+	// the demote sees the old one. If that order ever inverts, the retained bytes would silently be
+	// the new blob filed under the old hash — recoverable-looking and wrong.
+	if !bytes.Equal(retained[0].IdentityBlob, oldIdentity) {
+		t.Fatalf("retained identity blob is not the PREVIOUS generation (got %q) — the demote ran after the overwrite",
+			retained[0].IdentityBlob)
+	}
+	if retained[0].ResticPwSHA256 != "SHA_OLD" || string(retained[0].Blob) != "k-blob-old" {
+		t.Fatalf("retained row is not the old generation: %+v", retained[0])
+	}
+	// Current row unchanged in behaviour: the NEW generation, both blobs.
+	if bundle, berr := st.GetHostDRBundle(h); berr != nil || bundle == nil || !bytes.Equal(bundle.IdentityBlob, newIdentity) {
+		t.Fatalf("current identity blob is not the new one: %+v (%v)", bundle, berr)
+	}
+}
+
+// Scenario B — deleting a host demotes BOTH blobs too. demoteCurrentEscrowTx is shared by the
+// re-escrow path and the host-delete path; a shared routine proven through one caller is how a fix
+// gets believed on a path nobody exercised.
+// RED-PROOF: fix only the re-escrow caller (e.g. carry the column in SaveHostEscrow's own SQL instead
+// of in the shared routine) → this FAILS while Scenario A passes.
+func TestDeleteHost_DemotesIdentityBlob(t *testing.T) {
+	s := newTestStore(t)
+	const hostID, cust = "hid-del", "cust-del"
+	identity := []byte("age-blob-sealing-REPO-PASSWORD")
+	if err := s.UpsertHost(&Host{HostID: hostID, CustomerID: cust, APIKey: "k"}); err != nil {
+		t.Fatal(err)
+	}
+	if _, _, err := s.SaveHostEscrow(hostID, []byte("k-blob"), "fp", "zk", "2026-07-16T00:00:00Z", "SHA_A"); err != nil {
+		t.Fatal(err)
+	}
+	if err := s.SaveHostDRBundle(hostID, identity, `{}`); err != nil {
+		t.Fatal(err)
+	}
+
+	if err := s.DeleteHost(hostID, true); err != nil {
+		t.Fatalf("DeleteHost: %v", err)
+	}
+	retained, err := s.ListSupersededEscrow(hostID)
+	if err != nil {
+		t.Fatal(err)
+	}
+	if len(retained) != 1 {
+		t.Fatalf("demoted rows = %d, want 1", len(retained))
+	}
+	if !bytes.Equal(retained[0].IdentityBlob, identity) {
+		t.Fatalf("R-198: host delete demoted custody WITHOUT the identity blob (got %q) — the off-site "+
+			"repository password was destroyed by a host delete", retained[0].IdentityBlob)
+	}
+}
+
+// Scenario C — a legacy host whose current escrow has NO identity blob supersedes cleanly. The column
+// is nullable on purpose: a NOT NULL constraint here would make the fix block a ceremony, which is a
+// worse failure than the one it repairs.
+func TestSaveHostEscrow_SupersedesWithoutIdentityBlob(t *testing.T) {
+	st := newTestStore(t)
+	const h = "hid-legacy"
+	if _, _, err := st.SaveHostEscrow(h, []byte("k-old"), "fp", "zk", "2026-07-09T00:00:00Z", "SHA_OLD"); err != nil {
+		t.Fatal(err)
+	}
+	// No SaveHostDRBundle — a slice-7-era upload.
+	sup, prev, err := st.SaveHostEscrow(h, []byte("k-new"), "fp", "zk", "2026-07-16T00:00:00Z", "SHA_NEW")
+	if err != nil {
+		t.Fatalf("a supersession of an identity-less escrow must not fail: %v", err)
+	}
+	if !sup || prev != "SHA_OLD" {
+		t.Fatalf("superseded=%v prev=%q, want true/SHA_OLD", sup, prev)
+	}
+	retained, err := st.ListSupersededEscrow(h)
+	if err != nil {
+		t.Fatal(err)
+	}
+	if len(retained) != 1 {
+		t.Fatalf("retained rows = %d, want 1", len(retained))
+	}
+	if retained[0].IdentityBlob != nil {
+		t.Fatalf("a legacy row must retain a NULL identity blob, got %q", retained[0].IdentityBlob)
+	}
+}
+
+// CountCurrentEscrowWithIdentity is the census §8.1 asks for: which hosts hold an identity blob today
+// and are therefore protected from the next ceremony by this fix. Asserted rather than eyeballed,
+// because the report quotes its numbers.
+func TestCountCurrentEscrowWithIdentity(t *testing.T) {
+	st := newTestStore(t)
+	if _, _, err := st.SaveHostEscrow("with-id", []byte("k"), "fp", "zk", "2026-07-16T00:00:00Z", "SHA1"); err != nil {
+		t.Fatal(err)
+	}
+	if err := st.SaveHostDRBundle("with-id", []byte("age-blob"), `{}`); err != nil {
+		t.Fatal(err)
+	}
+	if _, _, err := st.SaveHostEscrow("without-id", []byte("k"), "fp", "zk", "2026-07-16T00:00:00Z", "SHA2"); err != nil {
+		t.Fatal(err)
+	}
+	total, withIdentity, err := st.CountCurrentEscrowWithIdentity()
+	if err != nil {
+		t.Fatal(err)
+	}
+	if total != 2 || withIdentity != 1 {
+		t.Fatalf("census = %d/%d, want 2 total / 1 with identity", withIdentity, total)
+	}
+}
diff --git a/hub/internal/store/escrow_superseded_test.go b/hub/internal/store/escrow_superseded_test.go
index a4e6ab0..15b504b 100644
--- a/hub/internal/store/escrow_superseded_test.go
+++ b/hub/internal/store/escrow_superseded_test.go
@@ -11,7 +11,7 @@ func TestSaveHostEscrow_RetainsSuperseded(t *testing.T) {
 	const h = "h1"
 
 	// 1st upload (P_old) — nothing to supersede.
-	sup, err := st.SaveHostEscrow(h, []byte("blob-old"), "fp-old", "zk", "2026-07-09T00:00:00Z", "SHA_OLD")
+	sup, _, err := st.SaveHostEscrow(h, []byte("blob-old"), "fp-old", "zk", "2026-07-09T00:00:00Z", "SHA_OLD")
 	if err != nil {
 		t.Fatal(err)
 	}
@@ -20,7 +20,7 @@ func TestSaveHostEscrow_RetainsSuperseded(t *testing.T) {
 	}
 
 	// 2nd upload (P_new, DIFFERENT sha) — must supersede + retain the old.
-	sup, err = st.SaveHostEscrow(h, []byte("blob-new"), "fp-new", "zk", "2026-07-16T00:00:00Z", "SHA_NEW")
+	sup, _, err = st.SaveHostEscrow(h, []byte("blob-new"), "fp-new", "zk", "2026-07-16T00:00:00Z", "SHA_NEW")
 	if err != nil {
 		t.Fatal(err)
 	}
@@ -45,7 +45,7 @@ func TestSaveHostEscrow_RetainsSuperseded(t *testing.T) {
 	}
 
 	// 3rd upload, SAME sha as current — idempotent (re-ceremony of the same password): NO supersede row.
-	sup, err = st.SaveHostEscrow(h, []byte("blob-new-2"), "fp-new", "zk", "2026-07-16T01:00:00Z", "SHA_NEW")
+	sup, _, err = st.SaveHostEscrow(h, []byte("blob-new-2"), "fp-new", "zk", "2026-07-16T01:00:00Z", "SHA_NEW")
 	if err != nil {
 		t.Fatal(err)
 	}
diff --git a/hub/internal/store/host_delete_demote_test.go b/hub/internal/store/host_delete_demote_test.go
index a55a34c..6e43c0d 100644
--- a/hub/internal/store/host_delete_demote_test.go
+++ b/hub/internal/store/host_delete_demote_test.go
@@ -15,10 +15,10 @@ func TestDeleteHost_DemotesEscrowNeverDestroys(t *testing.T) {
 		t.Fatal(err)
 	}
 	// current escrow = SHA_A, one superseded = SHA_OLD (two uploads with different passphrases).
-	if _, err := s.SaveHostEscrow(hostID, []byte("blob-old"), "fp", "zk", "2026-07-09T00:00:00Z", "SHA_OLD"); err != nil {
+	if _, _, err := s.SaveHostEscrow(hostID, []byte("blob-old"), "fp", "zk", "2026-07-09T00:00:00Z", "SHA_OLD"); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := s.SaveHostEscrow(hostID, []byte("blob-A"), "fp", "zk", "2026-07-16T00:00:00Z", "SHA_A"); err != nil {
+	if _, _, err := s.SaveHostEscrow(hostID, []byte("blob-A"), "fp", "zk", "2026-07-16T00:00:00Z", "SHA_A"); err != nil {
 		t.Fatal(err)
 	}
 	if n, _ := s.CountSupersededEscrow(hostID); n != 1 {
diff --git a/hub/internal/store/host_delete_test.go b/hub/internal/store/host_delete_test.go
index 3df96ca..688f7a3 100644
--- a/hub/internal/store/host_delete_test.go
+++ b/hub/internal/store/host_delete_test.go
@@ -57,7 +57,7 @@ func seedHostWithArtifacts(t *testing.T, s *Store, hostID, customerID string) {
 		"PK-"+hostID, "ip-"+hostID, hostID); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := s.SaveHostEscrow(hostID, []byte("opaque-escrow"), "fp", "posture", "2026-07-01T00:00:00Z", ""); err != nil {
+	if _, _, err := s.SaveHostEscrow(hostID, []byte("opaque-escrow"), "fp", "posture", "2026-07-01T00:00:00Z", ""); err != nil {
 		t.Fatal(err)
 	}
 }
diff --git a/hub/internal/store/store.go b/hub/internal/store/store.go
index 91c4d63..af54aed 100644
--- a/hub/internal/store/store.go
+++ b/hub/internal/store/store.go
@@ -374,6 +374,22 @@ func (s *Store) migrate() error {
 		-- "history destroyed" into "history recoverable with the recovery code"). Append-only; the hub
 		-- never decrypts; NO pruning (the blobs are tiny + R-encrypted; custody unchanged). The ACK and
 		-- restore-serving read host_escrow (the CURRENT row) — never this table.
+		--
+		-- THE RULING ABOVE WAS NOT MET FOR TWO MONTHS, AND THIS IS THE RECORD OF IT (R-198, fixed
+		-- v0.93.0). This table shipped with the blob column — the K-escrow, i.e. the PBS datastore key
+		-- — and identity_blob was added to host_escrow LATER (the slice-10D ALTER below), never here.
+		-- The offsite restic REPOSITORY password lives in identity_blob, not in blob. So the retention
+		-- preserved the whole-guest key and silently dropped the off-site data key: precisely the
+		-- secret the reinstall-orphan incident was about. Worse, the copy happens as the new blob
+		-- overwrites the old, so the destroying act was the ESCROW CEREMONY — the exact thing a
+		-- rebuilt box asks its customer to run, on a card promising the old backups stay recoverable.
+		-- Both demo boxes crossed that line on 2026-08-04 (07:15:36 and 07:20:08) and their previous
+		-- repository passwords are unrecoverable, recovery code or not.
+		-- identity_blob is now carried (see demoteCurrentEscrowTx, which is still THE ONE row-copy
+		-- routine). Pinned by TestSaveHostEscrow_RetainsIdentityBlob and
+		-- TestDeleteHost_DemotesIdentityBlob — the routine is proven through BOTH of its callers,
+		-- because a shared routine tested through one caller is how a fix gets believed on a path
+		-- nobody exercised. Evidence: audits/RECON-offsite-dr-chain-2026-08-04.md §7.
 		CREATE TABLE IF NOT EXISTS host_escrow_superseded (
 			id               INTEGER PRIMARY KEY AUTOINCREMENT,
 			host_id          TEXT NOT NULL,
@@ -382,7 +398,8 @@ func (s *Store) migrate() error {
 			posture          TEXT NOT NULL DEFAULT '',
 			created_at       DATETIME NOT NULL,
 			restic_pw_sha256 TEXT NOT NULL DEFAULT '',
-			superseded_at    DATETIME NOT NULL DEFAULT (datetime('now'))
+			superseded_at    DATETIME NOT NULL DEFAULT (datetime('now')),
+			identity_blob    BLOB
 		);
 		CREATE INDEX IF NOT EXISTS idx_host_escrow_superseded_host ON host_escrow_superseded(host_id);
 
@@ -414,16 +431,28 @@ func (s *Store) migrate() error {
 	s.db.Exec(`ALTER TABLE host_escrow ADD COLUMN identity_blob BLOB`)
 	s.db.Exec(`ALTER TABLE host_escrow ADD COLUMN directive_json TEXT NOT NULL DEFAULT '{}'`)
 
+	// R-198 (v0.93.0) — the SAME column on the RETAINED table. It was added above and not here, and
+	// that omission is what made the retention keep the wrong key for two months (see the comment on
+	// host_escrow_superseded). Additive and tolerated on re-run, exactly like the lines above; it
+	// changes no existing row. Rows superseded BEFORE this ships were written without the identity
+	// blob and their source rows are already overwritten — there is nothing to backfill, and the
+	// v0.93.0 report records that as a looked-at fact rather than a deduction.
+	s.db.Exec(`ALTER TABLE host_escrow_superseded ADD COLUMN identity_blob BLOB`)
+
 	// SLICE 3 (escrow auto-confirm) — sha256 hex of the offsite restic repo password sealed in the
 	// identity blob. The hash of a 256-bit random secret is non-reversible/non-brute-forceable — safe to
 	// store and serve; it lets the controller VERIFY "the escrow covers the CURRENT repo password"
 	// instead of trusting blob-presence. NULL/'' = a legacy or password-less blob (never auto-confirms).
 	s.db.Exec(`ALTER TABLE host_escrow ADD COLUMN restic_pw_sha256 TEXT`)
 
-	// v0.57.0 (2.3, escrow honesty on offsite re-issue) — stale_at is set when the offsite repo
-	// password is re-issued: the blob then seals a password that no longer opens the repo, so the
-	// hub must stop advertising "ceremony done" and withhold the (now non-matching) restic_pw_sha256
-	// from the auto-confirm ACK. NULL = current; a fresh ceremony (SaveHostEscrow) clears it.
+	// v0.57.0 (2.3, escrow honesty on offsite re-issue) — stale_at is set when the offsite PROVIDER
+	// credentials are re-issued. ⚠ CORRECTED 2026-08-04 (R-196): it used to say "when the offsite repo
+	// password is re-issued", which nothing in the hub does — the repository password is generated on
+	// the box and never leaves it except sealed under R. The flag is PRECAUTIONARY (the box's re-apply
+	// MAY mint a fresh repository password), not evidence that it changed; the evidential signal is
+	// R-197's offsite_repo_key_changed. While set, the hub stops advertising "ceremony done" and
+	// withholds the possibly-non-matching restic_pw_sha256 from the auto-confirm ACK. NULL = current;
+	// a fresh ceremony (SaveHostEscrow) clears it.
 	s.db.Exec(`ALTER TABLE host_escrow ADD COLUMN stale_at DATETIME`)
 
 	// dr_recipe (SPIKE-dr-recipe-2026-06-16): the secret-free DR reconstruction recipe, stored
@@ -2529,6 +2558,11 @@ type HostEscrow struct {
 	// StaleAt (v0.57.0, 2.3) — non-empty when the offsite password was re-issued after this blob was
 	// sealed: the blob is stale (seals a password that no longer opens the repo). Cleared by a fresh ceremony.
 	StaleAt string
+	// IdentityBlob (R-198, v0.93.0) — the age-wrapped identity bundle, which is where the offsite
+	// restic REPOSITORY password lives. Populated by ListSupersededEscrow so a retained blob is
+	// reachable from Go at all; nil for pre-v0.93.0 retained rows and for hosts that never uploaded
+	// one. Opaque: useless without the customer's recovery code, which the hub never holds.
+	IdentityBlob []byte
 }
 
 // SaveHostEscrow stores (last-write-wins) the OPAQUE escrow blob for a host. The hub keeps the
@@ -2538,16 +2572,35 @@ type HostEscrow struct {
 // host_escrow_superseded before overwriting the current row (Part B, v0.60.0). A same-sha re-upload
 // (idempotent re-ceremony of the same password) refreshes the current row and does NOT create a
 // superseded row.
+//
+// R-197 (v0.93.0): it also returns prevResticPwSHA256 — the hash the row being replaced sealed ("" when
+// no row existed, or when it was a legacy hash-less blob). Both halves of "did the box's offsite DATA
+// key change?" have been in this database since SLICE 3 and NOTHING compared them; demo-felhom's key
+// changed on 2026-08-03 and no signal of any kind fired for thirteen hours. The comparison is the
+// caller's (api.handleHostEscrowPut) because the event needs the customer id; returning the value is
+// this function's part. The VALUE is a non-reversible hash of a 256-bit random secret and is never
+// logged, mailed or written to a report — see the caller.
 // demoteCurrentEscrowTx copies the host's CURRENT host_escrow row (if any) into
 // host_escrow_superseded as a retained blob, inside the given tx. This is THE ONE escrow row-copy
 // routine (v0.60.0): SaveHostEscrow uses it to retain a superseded different-passphrase blob before
 // overwriting, and DeleteHost (v0.60.1) uses it to DEMOTE the current blob to retained custody
 // instead of destroying it. Returns the number of rows copied (0 when the host has no current row).
 // The hub never decrypts; custody is unchanged.
+//
+// R-198 (v0.93.0): `identity_blob` is copied too. It was omitted from this SELECT for two months, so
+// every supersession retained the PBS datastore key and destroyed the offsite restic repository
+// password — the one secret the retention exists to preserve. Copying more opaque bytes gains the hub
+// NO knowledge: it still has no recovery code and no decrypt path.
+//
+// ORDERING THIS DEPENDS ON, stated because it is load-bearing and invisible from here: the identity
+// blob is written by SaveHostDRBundle AFTER SaveHostEscrow returns (api/handler.go, the escrow PUT),
+// so at demote time host_escrow still holds the OLD identity blob. If that order ever changes, this
+// routine silently retains the NEW blob under the OLD blob's hash — pinned by
+// TestSaveHostEscrow_RetainsIdentityBlob, which asserts the retained bytes are the previous ones.
 func demoteCurrentEscrowTx(tx *sql.Tx, hostID string) (int64, error) {
 	res, err := tx.Exec(`
-		INSERT INTO host_escrow_superseded (host_id, blob, key_fingerprint, posture, created_at, restic_pw_sha256, superseded_at)
-		SELECT host_id, blob, key_fingerprint, posture, created_at, COALESCE(restic_pw_sha256, ''), datetime('now')
+		INSERT INTO host_escrow_superseded (host_id, blob, key_fingerprint, posture, created_at, restic_pw_sha256, superseded_at, identity_blob)
+		SELECT host_id, blob, key_fingerprint, posture, created_at, COALESCE(restic_pw_sha256, ''), datetime('now'), identity_blob
 		FROM host_escrow WHERE host_id = ?`, hostID)
 	if err != nil {
 		return 0, err
@@ -2555,10 +2608,10 @@ func demoteCurrentEscrowTx(tx *sql.Tx, hostID string) (int64, error) {
 	return res.RowsAffected()
 }
 
-func (s *Store) SaveHostEscrow(hostID string, blob []byte, keyFingerprint, posture, createdAt, resticPwSHA256 string) (superseded bool, err error) {
+func (s *Store) SaveHostEscrow(hostID string, blob []byte, keyFingerprint, posture, createdAt, resticPwSHA256 string) (superseded bool, prevResticPwSHA256 string, err error) {
 	tx, err := s.db.Begin()
 	if err != nil {
-		return false, err
+		return false, "", err
 	}
 	defer func() {
 		if err != nil {
@@ -2577,11 +2630,14 @@ func (s *Store) SaveHostEscrow(hostID string, blob []byte, keyFingerprint, postu
 		exists = false
 	default:
 		err = scanErr
-		return false, err
+		return false, "", err
+	}
+	if exists {
+		prevResticPwSHA256 = curSHA // R-197: the caller compares; "" = no row or a legacy hash-less blob
 	}
 	if exists && curSHA != resticPwSHA256 {
 		if _, err = demoteCurrentEscrowTx(tx, hostID); err != nil {
-			return false, err
+			return false, prevResticPwSHA256, err
 		}
 		superseded = true
 	}
@@ -2598,10 +2654,10 @@ func (s *Store) SaveHostEscrow(hostID string, blob []byte, keyFingerprint, postu
 			stale_at = NULL,
 			updated_at = datetime('now')`,
 		hostID, blob, keyFingerprint, posture, createdAt, resticPwSHA256); err != nil {
-		return false, err
+		return false, prevResticPwSHA256, err
 	}
 	err = tx.Commit()
-	return superseded, err
+	return superseded, prevResticPwSHA256, err
 }
 
 // CountSupersededEscrow returns how many retained (superseded) escrow blobs the hub holds for a host
@@ -2616,7 +2672,7 @@ func (s *Store) CountSupersededEscrow(hostID string) (int, error) {
 // first. Opaque bytes — the hub never decrypts. Seeds the future guided-recovery flow (R-26).
 func (s *Store) ListSupersededEscrow(hostID string) ([]HostEscrow, error) {
 	rows, err := s.db.Query(`
-		SELECT host_id, blob, key_fingerprint, posture, created_at, restic_pw_sha256, superseded_at
+		SELECT host_id, blob, key_fingerprint, posture, created_at, restic_pw_sha256, superseded_at, identity_blob
 		FROM host_escrow_superseded WHERE host_id = ? ORDER BY id DESC`, hostID)
 	if err != nil {
 		return nil, err
@@ -2625,7 +2681,7 @@ func (s *Store) ListSupersededEscrow(hostID string) ([]HostEscrow, error) {
 	var out []HostEscrow
 	for rows.Next() {
 		var e HostEscrow
-		if err := rows.Scan(&e.HostID, &e.Blob, &e.KeyFingerprint, &e.Posture, &e.CreatedAt, &e.ResticPwSHA256, &e.UpdatedAt); err != nil {
+		if err := rows.Scan(&e.HostID, &e.Blob, &e.KeyFingerprint, &e.Posture, &e.CreatedAt, &e.ResticPwSHA256, &e.UpdatedAt, &e.IdentityBlob); err != nil {
 			return nil, err
 		}
 		out = append(out, e)
@@ -2633,10 +2689,22 @@ func (s *Store) ListSupersededEscrow(hostID string) ([]HostEscrow, error) {
 	return out, rows.Err()
 }
 
-// MarkEscrowStale flags a host's escrow blob as stale (v0.57.0, 2.3) — called when the offsite repo
-// password is re-issued, because the blob then seals a password that no longer opens the repo. No-op
-// when no escrow row exists; idempotent (only stamps the first re-issue since the last ceremony; a
-// fresh ceremony clears stale_at via SaveHostEscrow's ON CONFLICT).
+// CountCurrentEscrowWithIdentity returns how many hosts hold a CURRENT escrow row, and how many of
+// those carry an identity blob — i.e. the population whose offsite repository password R-198's fix
+// now protects from the next ceremony, and the remainder for whom there is nothing to protect
+// because no identity blob was ever uploaded. Read-only; no blob or hash leaves this call.
+func (s *Store) CountCurrentEscrowWithIdentity() (total, withIdentity int, err error) {
+	err = s.db.QueryRow(`
+		SELECT COUNT(*), COALESCE(SUM(identity_blob IS NOT NULL), 0) FROM host_escrow`).Scan(&total, &withIdentity)
+	return total, withIdentity, err
+}
+
+// MarkEscrowStale flags a host's escrow blob as stale (v0.57.0, 2.3) — called when the offsite
+// PROVIDER credentials are re-issued. ⚠ CORRECTED 2026-08-04 (R-196): it used to say "when the offsite
+// repo password is re-issued", which no hub path does; see the reasoning at offsite.ReissueCredentials.
+// The flag is precautionary — the box's re-apply may mint a fresh repository password — not a
+// measurement that one did. No-op when no escrow row exists; idempotent (only stamps the first
+// re-issue since the last ceremony; a fresh ceremony clears stale_at via SaveHostEscrow's ON CONFLICT).
 func (s *Store) MarkEscrowStale(hostID string) error {
 	_, err := s.db.Exec(`UPDATE host_escrow SET stale_at = datetime('now') WHERE host_id = ? AND stale_at IS NULL`, hostID)
 	return err
@@ -2665,9 +2733,11 @@ type EscrowStatus struct {
 	IdentityBlobPresent bool   `json:"identity_blob_present"`
 	ResticPwSHA256      string `json:"restic_pw_sha256,omitempty"`
 	CreatedAt           string `json:"created_at,omitempty"`
-	// Stale (v0.57.0, 2.3) — true when the offsite password was re-issued after the blob was sealed.
+	// Stale (v0.57.0, 2.3) — true when the offsite PROVIDER credentials were re-issued after the blob
+	// was sealed. ⚠ CORRECTED 2026-08-04 (R-196): it used to say "the offsite password was re-issued",
+	// which reads as the repository password and is not what happens; see MarkEscrowStale.
 	// When stale the ResticPwSHA256 is WITHHELD (emptied) so the controller cannot auto-confirm against
-	// a hash that no longer matches the live repo password — the ceremony must run again.
+	// a hash that may no longer match the live repo password — the ceremony must run again.
 	Stale bool `json:"escrow_stale,omitempty"`
 }
 
diff --git a/hub/internal/web/customer_delete_test.go b/hub/internal/web/customer_delete_test.go
index c6d6859..9a425e4 100644
--- a/hub/internal/web/customer_delete_test.go
+++ b/hub/internal/web/customer_delete_test.go
@@ -74,11 +74,11 @@ func seedDeletable(t *testing.T, st *store.Store, customerID string) string {
 	if err := st.UpsertHost(&store.Host{HostID: hostID, CustomerID: customerID, APIKey: "hapi-" + hostID, LastReportAt: &long}); err != nil {
 		t.Fatalf("seed host: %v", err)
 	}
-	if _, err := st.SaveHostEscrow(hostID, []byte("blobA"), "fpA", "posture", "2026-01-01T00:00:00Z", "shaA"); err != nil {
+	if _, _, err := st.SaveHostEscrow(hostID, []byte("blobA"), "fpA", "posture", "2026-01-01T00:00:00Z", "shaA"); err != nil {
 		t.Fatalf("seed escrow A: %v", err)
 	}
 	// A second save supersedes A → one RETAINED blob + one CURRENT blob before the cascade runs.
-	if _, err := st.SaveHostEscrow(hostID, []byte("blobB"), "fpB", "posture", "2026-01-02T00:00:00Z", "shaB"); err != nil {
+	if _, _, err := st.SaveHostEscrow(hostID, []byte("blobB"), "fpB", "posture", "2026-01-02T00:00:00Z", "shaB"); err != nil {
 		t.Fatalf("seed escrow B: %v", err)
 	}
 	if err := st.SaveOneTimeSecret(customerID, "one-time-pw"); err != nil {
diff --git a/hub/internal/web/customer_reset_test.go b/hub/internal/web/customer_reset_test.go
index 8564b9d..18760bd 100644
--- a/hub/internal/web/customer_reset_test.go
+++ b/hub/internal/web/customer_reset_test.go
@@ -37,10 +37,10 @@ func seedResettable(t *testing.T, st *store.Store, customerID string) {
 	if err := st.UpsertHost(&store.Host{HostID: hostID, CustomerID: customerID, APIKey: "hapi"}); err != nil {
 		t.Fatalf("seed host: %v", err)
 	}
-	if _, err := st.SaveHostEscrow(hostID, []byte("blobA"), "fpA", "posture", "2026-01-01T00:00:00Z", "shaA"); err != nil {
+	if _, _, err := st.SaveHostEscrow(hostID, []byte("blobA"), "fpA", "posture", "2026-01-01T00:00:00Z", "shaA"); err != nil {
 		t.Fatalf("seed escrow A: %v", err)
 	}
-	if _, err := st.SaveHostEscrow(hostID, []byte("blobB"), "fpB", "posture", "2026-01-02T00:00:00Z", "shaB"); err != nil {
+	if _, _, err := st.SaveHostEscrow(hostID, []byte("blobB"), "fpB", "posture", "2026-01-02T00:00:00Z", "shaB"); err != nil {
 		t.Fatalf("seed escrow B: %v", err)
 	}
 	if err := st.DeleteHost(hostID, true); err != nil { // demotes current → retained; records host_deletions
diff --git a/hub/internal/web/hosts_delete_test.go b/hub/internal/web/hosts_delete_test.go
index 91b7fe9..11cea86 100644
--- a/hub/internal/web/hosts_delete_test.go
+++ b/hub/internal/web/hosts_delete_test.go
@@ -64,7 +64,7 @@ func TestHostDelete_EscrowAckRequired(t *testing.T) {
 	if err := st.UpsertHost(&store.Host{HostID: "esc-host", CustomerID: "c2", APIKey: "k"}); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := st.SaveHostEscrow("esc-host", []byte("blob"), "fp", "p", "2026-07-01T00:00:00Z", ""); err != nil {
+	if _, _, err := st.SaveHostEscrow("esc-host", []byte("blob"), "fp", "p", "2026-07-01T00:00:00Z", ""); err != nil {
 		t.Fatal(err)
 	}
 
@@ -110,7 +110,7 @@ func TestHostDelete_ImpactJSON(t *testing.T) {
 	if err := st.UpsertHost(&store.Host{HostID: "imp-host", CustomerID: "c4", APIKey: "SECRET-KEY"}); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := st.SaveHostEscrow("imp-host", []byte("blob"), "fp", "p", "2026-07-01T00:00:00Z", ""); err != nil {
+	if _, _, err := st.SaveHostEscrow("imp-host", []byte("blob"), "fp", "p", "2026-07-01T00:00:00Z", ""); err != nil {
 		t.Fatal(err)
 	}
 	if err := st.UpsertGuestFromReport(&store.Guest{GuestID: store.GuestID("imp-host", 100),
@@ -159,7 +159,7 @@ func TestHostDelete_HappyPath(t *testing.T) {
 	if err := st.UpsertHost(&store.Host{HostID: "dr-drill", CustomerID: "c5", APIKey: "k"}); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := st.SaveHostEscrow("dr-drill", []byte("blob"), "fp", "p", "2026-07-01T00:00:00Z", ""); err != nil {
+	if _, _, err := st.SaveHostEscrow("dr-drill", []byte("blob"), "fp", "p", "2026-07-01T00:00:00Z", ""); err != nil {
 		t.Fatal(err)
 	}
 	rr := postHostDelete(t, s, "dr-drill", url.Values{
diff --git a/hub/internal/web/hosts_test.go b/hub/internal/web/hosts_test.go
index 29bd77c..009e32d 100644
--- a/hub/internal/web/hosts_test.go
+++ b/hub/internal/web/hosts_test.go
@@ -130,7 +130,7 @@ func TestHandleHostDetail(t *testing.T) {
 		t.Fatal(err)
 	}
 	// DR + escrow present (escrow row must exist before the DR bundle UPDATE).
-	if _, err := st.SaveHostEscrow("demo-felhom-01", []byte("opaque-escrow"), "fp", "posture", "2026-06-01T00:00:00Z", ""); err != nil {
+	if _, _, err := st.SaveHostEscrow("demo-felhom-01", []byte("opaque-escrow"), "fp", "posture", "2026-06-01T00:00:00Z", ""); err != nil {
 		t.Fatal(err)
 	}
 	if err := st.SaveHostDRBundle("demo-felhom-01", []byte("opaque-identity"), `{"v":1}`); err != nil {
diff --git a/hub/internal/web/pbsdr_test.go b/hub/internal/web/pbsdr_test.go
index 7bf9f23..6dfbe47 100644
--- a/hub/internal/web/pbsdr_test.go
+++ b/hub/internal/web/pbsdr_test.go
@@ -404,7 +404,7 @@ func TestPBSDR_F14AutoReissueOnAckedDeletion(t *testing.T) {
 	if err := st.UpsertHost(&store.Host{HostID: "peti-00-dead", CustomerID: "peti", APIKey: "oldkey"}); err != nil {
 		t.Fatal(err)
 	}
-	if _, err := st.SaveHostEscrow("peti-00-dead", []byte("opaque"), "fp", "posture", "2026-07-01T00:00:00Z", ""); err != nil {
+	if _, _, err := st.SaveHostEscrow("peti-00-dead", []byte("opaque"), "fp", "posture", "2026-07-01T00:00:00Z", ""); err != nil {
 		t.Fatal(err)
 	}
 	if err := st.DeleteHost("peti-00-dead", true); err != nil {