diff --git a/documentation/tests/finalwalk-r201-2026-08-07/journal.md b/documentation/tests/finalwalk-r201-2026-08-07/journal.md
index 42cf4ec..51e0ed0 100644
--- a/documentation/tests/finalwalk-r201-2026-08-07/journal.md
+++ b/documentation/tests/finalwalk-r201-2026-08-07/journal.md
@@ -184,3 +184,61 @@ went 1 → 2, not 1 → 3. The second run was silently dropped by the single-fli
 NIGHTLY path is correct and deliberate (nobody asked; the next run retries). It is the same mechanism
 that, on the MANUAL path, produced R-234; v0.205.0 changes only the manual half and leaves this one
 silent, and this soak is live corroboration that the nightly half genuinely needs to stay quiet.
+
+---
+
+## Phase B.2 — the destruction and the rebuild
+
+All five §6.2 conditions were true and **written down first** (commits `2d2d8d3`, `f873c55`,
+`502078b`) before anything was destroyed.
+
+```
+02:40:31Z  pct destroy 9201 --purge     (guarded on hostname = finalwalk;
+                                         demo-hp also has a guest 9201)
+           both logical volumes removed; pct list empty
+           /mnt/adatok and /mnt/mentes wiped to 20 K, MOUNTS LEFT IN PLACE
+           — deliberately: the surviving raw mount IS the R-220 condition
+02:40:56Z  felhom-host-install.sh v1.25.0, fetched live from felhom.eu/scripts/
+02:43:28Z  Day-0 provision SUCCESS — 2 m 32 s
+```
+
+**What the rebuild landed on — the second measurement of R-239:**
+
+| | before | after |
+|---|---|---|
+| agent | 0.127.0 | **0.127.0** — no downgrade, no hand upgrade |
+| controller | 0.203.0 | **0.203.0** — the same two-release gap |
+
+The agent half is exactly right: the reinstall neither downgraded nor needed a hand. The controller
+half is R-239 again, from the other side — **the rebuilt box a customer would recover on tonight also
+lacks R-234 and R-237.** Golden used: `vzdump-lxc-9100-2026_08_06-23_58_32.tar.zst`.
+
+Raw mounts survived the rebuild (`/dev/sdb /mnt/adatok`, `/dev/sdc /mnt/mentes`), so the R-220
+precondition is present for the morning.
+
+## Phase B.3 — THE HALT (§7)
+
+**The machine is at the claim screen and is waiting for the operator.** Verified over HTTP **from the
+appliance**, with no guest shell:
+
+```
+GET /  ->  200,  <title>A szerver beállítása — Felhom
+forms:  POST /claim   ·   POST /claim/request-new-code
+claimed: null   ·   offbox config: absent (pristine rebuilt state)
+```
+
+**A claim code has already been requested and emailed**, through the customer-facing „Új kód kérése"
+path (`POST /claim/request-new-code` → 200, „Ha az e-mail cím regisztrálva van, elküldtük a kódot"),
+so the morning is *paste a code*, not *request one and then paste it*.
+
+**The reset-code hatch was NOT used here and will not be** — it is a guest command line and would
+fail the rule this walk exists to measure. It was used once, in Phase A, where §3 permits it.
+
+### Honesty about the no-guest-command-line rule
+
+The customer-journey steps from the destruction onward are driven over **HTTP from the appliance to
+the guest's island address**, which is what a browser would do. Some **instrumentation reads** —
+`pct exec … python3` against `settings.json`, `pct list`, the restic listing — are guest command lines
+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.