From 1ff6f8f8e06b728cc80b7b4ad908cf90cca4cf29 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Fri, 7 Aug 2026 05:23:03 +0200 Subject: [PATCH] =?UTF-8?q?final=20walk=20=C2=A77:=20the=20credential=20ch?= =?UTF-8?q?ain=20runs=20end=20to=20end,=20unaided,=20on=20an=20UNCLAIMED?= =?UTF-8?q?=20box?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three questions answered from the hub's own log, not inferred: 1. the rebuilt, still-unclaimed box DOES report (host-report + Received report) 2. it DOES declare offsite.state=needs_credential, and offsite-delivery correctly declines once a minute, naming internal/offsiteheal as the owner 3. offsiteheal re-staged UNAIDED at 03:15Z, after two reports carried the declaration, with no provider credential minted — about 32 minutes after the rebuild, matching the documented 2x15-minute debounce And then the box COLLECTED it on its own 5-minute tick: [offsite-apply] credential retry: the staged credential was collected and the tier applied That success line shipped in v0.203.0 and this is the FIRST time it has been seen live: yesterday's walk only produced its sibling before I intervened at 102s and mistook my own button press for the cause — the error that produced R-236 and forced its withdrawal. Here nobody touched anything and the box was not even claimed. R-218's consume half, R-236's withdrawal and the previous walk's dead end 1 are all settled by one unattended observation. --- .../finalwalk-r201-2026-08-07/journal.md | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/documentation/tests/finalwalk-r201-2026-08-07/journal.md b/documentation/tests/finalwalk-r201-2026-08-07/journal.md index 51e0ed0..ddcbf4b 100644 --- a/documentation/tests/finalwalk-r201-2026-08-07/journal.md +++ b/documentation/tests/finalwalk-r201-2026-08-07/journal.md @@ -242,3 +242,56 @@ the guest's island address**, which is what a browser would do. Some **instrumen and are counted as such. They are not steps of the journey: none of them changed state, and none was needed to progress it. The distinction matters because conflating the two is how a walk claims a property it does not have. + +### §7's observation — the rebuilt, still-UNCLAIMED box + +Three questions, all answered from the hub's own log rather than inferred: + +**1. Does it report while unclaimed? YES.** +`host-report from finalwalk-ed05d6 (1 guests, 4 storage targets, 1 backups, 0 restore-tests, +1 pbs-snapshots, 12907 bytes)` at 05:12:04 local, and `Received report from finalwalk` at 05:13:03. + +**2. Does it declare the credential need? YES**, and the hub's other mechanism correctly declines to +act on it — logged once a minute, from 02:59Z onward: + +> `offsite-delivery: finalwalk: self-heal REFUSED — the box DECLARES offsite.state=needs_credential; +> internal/offsiteheal owns this remediation (it re-stages the stored credential before minting). +> A second mechanism minting here would double-issue.` + +**3. Did the hub stage one unaided? YES, at 05:14:57 local (03:15Z):** + +> `offsiteheal: re-staged the stored one-time offsite secret for customer finalwalk (declared +> needs_credential across 2 reports) — the box re-consumes on its next cycle; no provider credential +> was minted` + +That is **~32 minutes after the rebuild**, consistent with the documented 2 × 15-minute report +debounce, and **nobody touched anything**. + +**This is a stronger case than yesterday's.** On 2026-08-06 I pressed Re-issue 102 seconds after the +self-heal had already fired and mistook my own button for the cause — the error that produced R-236 +and forced its withdrawal. Here the box was **pristine, rebuilt and not even claimed**, no operator +action of any kind was taken, and the chain ran end to end on its own. R-236's withdrawal is now +confirmed on the exact shape it was filed against. + +**4. And then the box COLLECTED it, on its own tick — the full loop, unaided:** + +``` +[offsite-apply] settle-gate: GO — at/above floor 0.156.0 (we are 0.203.0), no managed update running +[offsite-apply] offsite configured for u629488-sub4@…:/home/felhom-repo (pending key escrow) +[offsite-apply] credential retry: the staged credential was collected and the tier applied +``` + +The box's own settings went from **no `offbox` object at all** to `enabled: true`, host, user and +`repo_path` populated, `escrow_state: pending`. + +**This is the first time that success line has ever been observed live.** It shipped in controller +v0.203.0; the 2026-08-06 walk only ever produced its sibling — *"no unconsumed offsite password … +(the box still declares a need; retrying)"* — before an operator intervened. Here the whole chain ran +with **zero human action, on a box that has not even been claimed yet**: + +> declare → `offsite-delivery` declines and names the owner → `offsiteheal` re-stages after two +> reports → the box's 5-minute retry collects it → the tier is applied. + +**That is R-218's consume half, R-236's withdrawal, and the previous walk's dead end 1, all settled by +one unattended observation.** By the time the operator claims this machine in the morning, its +off-site tier is already up — which is exactly the property the recovery journey needed and never had.