felhom.eu/documentation/tests/walk5-r201-2026-08-07/journal.md

# THE FIFTH WALK (R-201) — journal

**Venue:** `demo-hp` VM **325 `walk5-appliance`**, hub customer **`walk5`**. All four earlier venues
(`c11`, `rewalk`, `part4`, `finalwalk`) were torn down on 2026-08-06/07; **nothing was reused** except
the `c11-scratch` dir storage (a plain `dir` at `/mnt/nvme-1tb`, which is what the agent's
`exactMount` check requires) and the **freed** Storage Box sub-account *number* `sub4` — the account
itself is newly provisioned, id **285351**, not finalwalk's 285071 which the cascade destroyed.

**Written as the walk proceeds, per §9.9.** Clocks: DooPlex and demo-hp and the appliance = **CEST**;
the guest and the hub = **UTC**.

---

## §0–2 — orientation, on arrival

### §1 baselines — re-read, all four match the runbook exactly

| Component | Runbook | Measured on arrival | |
|---|---|---|---|
| `felhom-controller` | `3d3b4496f377` | `3d3b4496f377` | ✅ clean tree, == `origin/main` |
| `felhom-agent` | `703db166e762` | `703db166e762` | ✅ clean tree, == `origin/main` |
| `felhom.eu` | `10af63d0b04e` | `10af63d0b04e` | ✅ clean tree, == `origin/main` |
| `app-catalog-felhom.eu` | — | `459766cb1639` | clean, untouched |

**No drift.** (The two previous walks both found one-commit drift on arrival and had to check it was
benign; this one did not.)

### §1 the vouched set — read from the hub, not from a document

`GET /configuration` on the hub (Basic auth, ClusterIP):

```
agent_version   (selected)  0.127.0
golden_version  (selected)  0.206.0
min_agent                   0.127.0
min_controller_version      0.156.0
hub image (deployed)        gitea.dooplex.hu/admin/felhom-hub:0.98.0
installer SCRIPT_VERSION    1.25.0   (served live from felhom.eu/scripts/)
```

**All five match §1.** The vouched golden `0.206.0` carries controller `0.206.0`, so **this is the
first walk whose fresh install lands on the fixes it exists to exercise** — R-239's delivery gap,
which was the headline finding of the last two walks, is closed for this run.

### §1 the build gate — GREEN before starting

```
$ python3 scripts/golden_currency_gate.py
  newest released controller : 0.206.0
  newest golden baked        : 0.206.0
golden currency gate OK
rc=0
```

**Stated precisely, because the gate says so itself:** it checks the **bake**, not the **vouch**. The
vouch was therefore checked separately, from the hub, above — and it is `0.206.0`. Both halves green.

### §1 highest register ID

**R-248**, confirmed by grep over `OPEN-ITEMS.md` (`R-241 … R-248`). The runbook's figure is current.

### ISO — verified by round trip, not by name

| | |
|---|---|
| published | `https://iso.felhom.eu/felhom-installer-1.26.1-pve9.2-1.iso` · 1 705 322 496 B · `last-modified Fri 31 Jul 2026 18:37:18 GMT` |
| published `.sha256` | `f3cc86d5f0ec68bba4155c994b4fa84e208d50209bb6e815636c99e5441059a6` |
| local on `demo-hp` | `/var/lib/vz/template/iso/felhom-installer-1.26.1-pve9.2-1.iso` · **same sha256** |

**Byte-identical.** (`https://iso.felhom.eu/` **itself** 404s — there is no index object; only named
objects are served. Recorded so the next session does not read that 404 as an outage.)

### §2.6 — the open items that could touch this walk

- **R-247 / R-248** — the staleness flag. The runbook says no running code can set it; **confirmed at
  source**: R-246's census found `MarkEscrowStale` has **no production caller anywhere in the tree**,
  and its one historical setter was removed in hub v0.95.0. A fresh box cannot reach the state.
  **R-246 also records the demo-hp instance as CLEARED on 2026-08-07.** So shape (c) is live and
  un-inhibited for this venue.
- **R-243** — the alarm gap for a box held in `awaiting_recovery_key`. **Directly in this walk's
  path**: if §5 goes as designed, the rebuilt box enters exactly that state. The gap is that *the hub
  raises nothing for it*. Not a defect of the walk; watch for it and report it as still-open.
- **R-240** — „Sikeres" over a run that covered nothing. Only reachable if an off-site run is made
  with nothing selected; not part of this walk's route.
- **R-244** — teardown residue in `app_log_issues`. Teardown is §10, owed, not this session.

### §2.7 — the two functions this walk exercises, read before running

Both fixes are present in the tree at `3d3b4496f377` and both are new since the last walk:

- **the mint guard** — `WriteOffboxSecrets` (`controller/internal/backup/offbox.go:438`) now returns
  `ErrOffboxSealedPackageHeld` instead of generating, when `sealedPackageHeld()` is true **and** no
  password exists. It is a **conjunction**, so a first-time box mints exactly as before. The transport
  is still written. New declared state `offsite.state=awaiting_recovery_key`
  (`OffboxAwaitingRecoveryKey`, `:502` — derived, not stored, and gated on `t.Enabled`).
- **shape (c)** — `OffsiteRecoveryOffer` (`:1580`) now offers when
  `hubHash != "" && hubHash != localHash`. `""` falls back to (a)/(b) deliberately.

**Neither has ever run on a real rebuild.** That is §5, and it is deliverable 2 whatever the verdict.

---

## Venue construction

### Hub customer `walk5`

`POST /configs/new` — id `walk5`, name "Walk 5 R-201", domain `walk5.felhom.eu`, email = the
operator's registered address, **off-site ON** (shared, 50 GB), **DR tier ON**, `pbsdr_storage_id`
`felhom-pbs`. → **303** `/customers/walk5?flash=created`.

Provisioned descriptor, read from the hub DB rather than from the page:

```json
{"enabled":true,"type":"shared","host":"u629488-sub4.your-storagebox.de","user":"u629488-sub4",
 "port":23,"repo_path":"/home/felhom-repo","quota_gb":50,
 "host_fingerprint":"SHA256:oDHZqKXnoMtgvPBjjC57pcuFez28roaEuFcfwyg8O5c"}
```

`one_time_secrets` 1 · `customer_configs` 1 · `hosts` 0. Sub-account **285351**, user `u629488-sub4`.

> **⚠ THE FIRST CREATE FAILED, AND IT IS A FINDING — not a fluke of my own making.**
>
> The first `POST /configs/new` returned no response to the client and the hub logged
> `[ERROR] offsite provision for walk5: offsite: host-key scan u629488-sub4.your-storagebox.de:
> dial: dial tcp [2a01:4f8:bacc:2:200::d30]:23: connect: network is unreachable` at **13:46:46**.
>
> The scan is **fail-closed by design** (`offsite.go:111-121`: *"don't serve a descriptor the
> controller can't verify"*) and its retry ladder is **~60 s** (`defaultScanBackoff`, 2+4+8+16+30),
> sized by its own comment to *"the observed DNS propagation lag"* of a fresh sub-account. Here the
> lag was **longer than the budget**: the first five attempts failed `no such host`, and by the time
> DNS answered it answered **AAAA-first**, into a pod with no IPv6 route.
>
> **The retry (a second identical POST) succeeded** — idempotent on the label
> (`[offsite] shared already provisioned for walk5 (subaccount 285351)`), scan green on its own final
> rung at ~13:47:28, config created. **Total settle time ≈ 100 s against a 60 s budget.**
>
> **Measured afterwards, so the cause is not guessed:** the hub pod reaches
> `u629488-sub4.your-storagebox.de:23` **now**, by name, and gets `SSH-2.0-OpenSSH_9.6p1` — as does
> the node. So the endpoint is fine and the window was transient. **What is not fine is the operator
> experience**: a customer create can fail with a fail-closed error whose only remedy is "press it
> again", and nothing says so. Filed below.

### VM


| | |
|---|---|
| Host | `demo-hp` (HP t740), Tier 0 — the designated drill host |
| VM | **325 `walk5-appliance`** — q35/OVMF (`pre-enrolled-keys=0`), 4 cores, 8 GB, `cpu=host` |
| Disks | `scsi0` 200 G · `scsi1` 50 G · `scsi2` 50 G, qcow2 on `c11-scratch` (a `dir` at the **mount root** `/mnt/nvme-1tb`, which is what the agent's `exactMount` check requires) |
| Appliance | `walk5.felhom.eu` @ **192.168.0.100/24**, gw/DNS 192.168.0.1, MAC `bc:24:11:37:7c:f3` |
| Guest | LXC **9201** @ **192.168.0.149** (LAN) + `169.254.253.2` (R-50 island) |
| Hub customer | **`walk5`** "Walk 5 R-201", DR tier ON, off-site ON (shared, 50 GB) |
| Host id | **`walk5-4bada5`** · appliance uuid `596d8104-2af9-4525-baa7-e479314cbb44` |
| Off-site | Storage Box sub-account **285351**, user `u629488-sub4` · WG peer **10.77.0.5** |
| **Untouched** | `drill-r50` (VM 300, the protected fixture), guest 9201 on both demo boxes, DooPlex, `ep0`, the tester's box |

**Reachability, stated because it shapes every later step:** DooPlex has **no L2 path to the
192.168.0.0/24 LAN** — `ip neigh` is `INCOMPLETE` even for `demo-hp`, which it reaches over the
tailnet. So the appliance is one SSH hop behind `demo-hp`, and every request to the guest is made
**from the appliance**, which is exactly what a browser on the customer's LAN would do.

---

## Phase A — the fixture (§4)

### A1 — installed from the published ISO, through the Terminal UI

Driven with `qm sendkey` + `qm monitor screendump` → PNG. **All three known traps reproduced:**

1. **GRUB defaults to the graphical entry — and it bit, first attempt.** The countdown was **14 s**
   with my screendump→convert→read round trip at **~18 s**, so the menu auto-booted the default and
   the GUI installer came up. **Recorded rather than quietly retried:** the VM was stopped and
   restarted, and the keys sent **inside one remote command** (`sleep 6; sendkey down; screendump;
   sendkey ret`) — the screendump taken *between* the arrow and the Enter is the positive control,
   and it shows the highlight on **„Felhom telepítés (szöveges mód)"** at the moment of the press.
2. **The keymap defaults to Hungarian** while `sendkey` emits US scancodes. Changed to **U.S.
   English** before any typing. **Positive control:** the administrator email typed through the
   identical path rendered **`walk5@felhom.eu`** — `@` is `shift-2` on US and `AltGr+V` on HU, and it
   is the only available evidence for the 24 masked password characters.
3. **Auto-reboot was checked.** Unchecked, and **confirmed `[ ]` with the focus moved away**; then
   `--boot` set in its own `qm set` with the ISO detached, both verified from `qm config`
   **before the first boot**: `boot: order=scsi0`, `ide2` lines = **0**.

Summary screen, verbatim: `ext4` · `/dev/sda` · `Europe/Budapest` · **`U.S. English`** ·
`walk5@felhom.eu` · `nic0` · `walk5.felhom.eu` · `192.168.0.100/24` · `192.168.0.1` · `192.168.0.1`.

**One reading corrected by a second instrument, as in the last walk:** `192.168.0.100` was the
installer's prefill and answered on the LAN. The **MAC** was `bc:24:11:37:7c:f3` — VM 325's own DHCP
lease. Not a collision; a ping alone could not have told the difference.

**Day-0 fired on first boot, unaided.** Console showed the Hungarian pairing banner:

> `Felhom — a doboz készen áll, és a párosításra vár.` · `Párosító kód:  E28-WJH`

The hub's `appliance_registrations` row **24** carried the same code (`E28WJH`), the same MAC, the
same SMBIOS uuid and **three SSH host keys**, `first_seen 12:18:59Z` — **32 seconds after boot**.
Bound through the real endpoint (`POST /appliances/24/bind`, **303**).

### A1b — THE HEADLINE: a fresh install DOES get the fixes

| | vouched | the box landed on |
|---|---|---|
| agent | 0.127.0 | **0.127.0** ✅ |
| golden | 0.206.0 | — |
| controller | (baked into the golden) | **0.206.0** ✅ |

```
14:22:48 [INFO] Artifact manifest served for customer walk5 (agent=0.127.0 golden=0.206.0)
14:25:33 [INFO] Event from walk5: controller_started (info) — Controller elindult (0.206.0)
   docker ps → Up 10 minutes (healthy) gitea.dooplex.hu/admin/felhom-controller:0.206.0
   felhom-agent --version → felhom-agent 0.127.0
```

**No hand upgrade was needed and none was applied.** This is the first walk of the five where that
sentence is true of the *fixes under test*: R-239's delivery gap — the headline finding of both
previous walks — **is closed for this run**, and the box under test is the box a customer receives.

**The whole day-0 cascade ran hands-free**, bind → provision in **3 m 55 s**:

```
14:21:38 appliance 24 BOUND to customer walk5 (mode=appliance)
14:22:00 appliance credentials DELIVERED once
14:22:08 [claim] claim code (gen 1) emailed to the registered address
14:22:38 host enrolled: walk5-4bada5
14:22:46 offsite credentials re-issued on re-enroll; break-glass root@pam vaulted (32 chars)
14:23:19 wg registered 10.77.0.5 · DR-recipe host-half · tenantsync provision ok (ns=walk5)
         pbsdr auto-provisioned (hands-free cascade)
14:25:33 controller 0.206.0 reporting
```

### A2 — claimed

Claimed through the real `POST /claim` form (302 → `/`), then `POST /login` → 302. **The claim code
came from the documented `--print-reset-code` escape hatch** (R-204 item 1) — **a guest command line,
used deliberately as FIXTURE CONSTRUCTION, permitted by §3 in Phase A, and counted as such.** Phase B
must not use it.

The dashboard password is a 24-character alphanumeric, `0600` in `~/.config/walk5/` on **DooPlex
only**. The appliance's root credential is the hub-vaulted break-glass (`root@pam`, revealed through
`POST /hosts/walk5-4bada5/reveal-recovery-credential`) — **the password typed at the installer no
longer authenticates, because day-0 step 4b rotates and vaults it.** Stated because it cost a dead
end.

### A3 — drives, the app, and the three sentinels

Both raw disks enrolled through the **customer** endpoints (`GET /api/disks/candidates` →
`POST /api/storage/init`), ext4:

```
/dev/sdb → /mnt/felhom-drives/adatok     (app data)
/dev/sdc → /mnt/felhom-drives/mentes     (backup target)
```

Backup target assigned to `mentes` — and, exactly as the last walk recorded, it reported
`restart_required: true` and flipped only after the agent restart it asked for:

```
before: {"degraded":true, …"A rendszermentés jelenleg ugyanazon a lemezen van…"}
after:  {"degraded":false,"known":true,"label":"Mentes","target":"felhom-backup"}
```

`calibre-web` deployed through the real API with `HDD_PATH=/mnt/felhom-drives/adatok` —
`state: running` **and `health_probe.healthy: true`**.

**THE THREE SENTINELS**

| # | file | bytes | sha256 |
|---|---|---|---|
| A | `WALK5-SENTINEL-A.txt` | 61 | `11eb7fb2d1891f62a685e3d9a9fda44e0a342d437d4aebaa15fcb4c0fd79d539` |
| B | `WALK5-őrszem-ékezetes-árvíztűrő.txt` | 66 | `6b504d1e83bf4c673334d0b9e701f3e5f07311d954fdc4463a6b0a55b261ae32` |
| C | `WALK5-SENTINEL-C-12MB.bin` | 12 582 912 | `0baaf402733e6a85f3d9ce8c4c3a57b05692f5f6733da6a23da76d2cd7635210` |

Sentinel B's filename **as hex**, and this is the reading that cannot lie:

```
57414c4b352d c591 72737a656d2d c3a9 6b657a657465732d c3a1 7276 c3ad 7a74 c5b1 72 c591 2e747874
             ő                 é                    á         í       ű     r  ő
```

**No `efbfbd` anywhere.** Written by a Python placer pushed in with `pct push`, which builds the name
from a **hex string decoded to bytes** and passes a **bytes path** to `os.open` — no shell layer ever
sees the name, and the readback is from `os.listdir` on a bytes path, not from a shell `ls`. This is
the trap that bit three times; it did not bite here.

**Placed under `…/adatok/userdata/media/books` — the level the last walk got wrong.** The tree was
listed first and the namespace root confirmed to be `/mnt/felhom-drives/adatok` **directly**.

### A4 — the escrow ceremony

Preflight **6 of 6 green** (`pbs_storage_id` · `dr_tier` · `age_binary` · `hub_upload` ·
`staged_secret` · `sudo_grant`), `agent_supported: true`, **`stale: false`**.

> **That `stale: false` is a deliberate check, not a formality.** R-246/R-247/R-248 concern a
> staleness flag that would silently disable the very discriminator this walk exists to exercise.
> The spike's ruling was that a fresh box cannot reach the state (`MarkEscrowStale` has no production
> caller). **Measured here on a fresh box: it has not.**

Ceremony through the customer wizard's own endpoints (`/api/escrow/start` with password re-auth —
it is a **form** POST, not JSON, which cost one rate-limited attempt):

```
phase: done · restic_pw_sealed: TRUE · uploaded: true · entropy_bits: 129.24 · claimable: true
key_fingerprint: a6:86:f7:fb:74:e7:16:3c:…:31:2a:4c:f9
```

**`restic_pw_sealed: true` is the field the whole exercise rests on.**

**R was claimed ONE-SHOT and streamed file→file** into `~/.config/walk5/R_walk5.txt` (`0600`,
**DooPlex only**). It was never rendered, never an argument, never a log line. The appliance's copy
was `shred -u`'d and **its absence verified**. Shape only: **82 characters, 10 hyphen-separated
tokens, lowercase+digits**.

> **§9.4 slip, recorded rather than buried.** The Phase-A *claim code* (not R) reached this session's
> transcript, because the hatch prints it and my shape-only filter was written for an uppercase
> pattern and did not match a lowercase one. It was consumed by the claim seconds later and is now
> void. **R itself was never printed and never left the file→file path.**

### A5 — the off-site backup, and the sentinels BY NAME

> **THE §4.5 GATE EARNED ITS PLACE AGAIN — and this time it caught MY fault, not the product's.**
> The first run reported **`ok` in 28 s** with **`snapshots = 0`** and an empty repository size. The
> log said why: `[offbox] backup run started (0 app(s) toggled)`. **My toggle POST sent
> `enabled=1`**, and the handler accepts only `on`/`true` — so it recorded *off*, redirected with
> „A távoli mentés beállítása frissítve." and the run then correctly backed up nothing.
> **A harness fault, not a product defect** — but the shape is precisely R-240's, and had I read the
> green `ok` and moved on, the destruction would have proven nothing.

Re-toggled (`enabled=on`), selection verified in the rendered page (`name="app" value="calibre-web"`
+ `checked`) **before** the re-run, which then logged `backup run started (1 app(s) toggled)`.

**`ok`, 1 m 20 s, 1 snapshot, 12.0 MB (12 611 563 B).** **The gate is not the green tick** —
`restic snapshots` + `restic ls latest --long`, run against the repository with its own credentials:

```
5b0f20f7  2026-08-07 12:57:41  walk5  [felhom-offbox, calibre-web]
    /mnt/felhom-drives/adatok/backups/primary/calibre-web
    /mnt/felhom-drives/adatok/userdata/media/books

-rw-r--r-- 1000 1000       61  …/userdata/media/books/WALK5-SENTINEL-A.txt
-rw-r--r-- 1000 1000 12582912  …/userdata/media/books/WALK5-SENTINEL-C-12MB.bin
-rw-r--r-- 1000 1000       66  …/userdata/media/books/WALK5-őrszem-ékezetes-árvíztűrő.txt
-rw-r--r-- 1000 1000   413696  …/userdata/media/books/metadata.db        ← calibre-web's real DB
restic stats latest: 22 files, 12.784 MiB
```

**All three sentinels are in the snapshot, by name, at the right sizes — and the accented filename
survived into restic intact.**

### A6 — §4.6's two pre-destruction checks, neither ever exercised on a clean box

**Check 1 — the recovery offer is NOT shown. PASSES.**

```
GET /          → 302 → /launcher
GET /launcher  → 200,  recovery mentions: 0
GET /          → 200 (followed), recovery mentions: 0
GET /recovery  → 302 → /backups/remote
```

No banner, no entry point, nothing to seek. **And the reason is measurable rather than assumed:** the
hub's package covers the key in use, so v0.206.0's **shape (c) compares equal and correctly stays
silent** —

```
box   /data/offbox/repo_password  sha256 = eabf427c72749fdad355d8cbcadedd8430c8398999b6385cfb1960899167144f
box   settings.hub_escrow_key_sha256    = eabf427c72749fdad355d8cbcadedd8430c8398999b6385cfb1960899167144f
hub   host_escrow.restic_pw_sha256      = eabf427c72749fdad355d8cbcadedd8430c8398999b6385cfb1960899167144f
      hub_escrow_key_checked_at         = 2026-08-07T12:51:39Z
```

**This is the first live measurement of the persisted discriminator**, and it is the negative half:
the shape that must NOT fire, not firing, for the right reason.

**Check 2 — the restore page lists the app with the future-backup toggle OFF. PASSES.**

With `calibre-web` toggled **off** for future off-site backups, `/backups/restore` renders
**identically** — „Calibre-Web Automated" still listed under **„Visszaállítás a távoli tárolóból"**,
10 `calibre` occurrences in the HTML both before and after.

**That is R-237's fix, live.** The last walk's T3 measured **0 restore entries and a 302** on
controller 0.203.0 — the customer's existing backup hidden by a setting about the future. The toggle
was returned to **on** afterwards.

### A7 — the pre-destruction truth (§4.7's seven records)

**Box** (`settings.json`, secrets stripped):

```
offbox: enabled true · escrow_state "escrowed" · last_status "ok" · last_duration 1m20s
        last_run/last_success 2026-08-07T12:58:57Z · snapshot_count 1
        repo_size_bytes 12 611 563 ("12.0 MB") · stats_known true · quota_gb 50
        host u629488-sub4.your-storagebox.de:23 · repo_path /home/felhom-repo
repo_state: (absent — not orphaned) · hub_escrow_identity_present: true · claimed: true
agent 0.127.0 · controller 0.206.0 (healthy) · guests 1/1
```

**Hub:**

```
host_escrow(walk5-4bada5):  blob 383 B · identity_blob 572 B (R-198 material present)
                            key_fingerprint a6:86:f7:fb:…:4c:f9
                            restic_pw_sha256 eabf427c7274…144f
                            stale_at NULL · created 2026-08-07T12:51:02Z
host_escrow_superseded:     0 rows for walk5
hosts:                      walk5-4bada5 ONLINE · agent 0.127.0 · PBS wrapper MATCHES VOUCHED
                            (104db0a4401f…) · WG 10.77.0.5 confirmed
DR Recipe: present · Key Escrow: present
```

**Phase A gate: PASSED.** All seven records taken; the three sentinels listed **by name**.

---

## Phase B — the journey (§7)

**The rule: no command line inside the guest, at any point.** After the destruction the only things
that reach the guest are HTTP requests a browser could have made, issued **from the appliance** (the
only machine with an L2 path to it). **Instrumentation reads are counted separately and named**: the
`w5watch.log` sampler, `pct exec … docker logs`, the restic listing and the hub-DB queries are guest
or operator command lines. **None of them changed state and none was needed to progress the journey** —
that distinction is the whole point, and conflating the two is how a walk claims a property it does
not have.

### B1 — the destruction (14:19:26Z)

Guarded **four ways** before anything ran, because `demo-hp` also carries a guest 9201:

```
hostname == walk5                      ✓
pct config 9201 → hostname: walk5      ✓
mountpoint -q /mnt/adatok              ✓
mountpoint -q /mnt/mentes              ✓
```

```
14:19:18Z  pct stop 9201
14:19:26Z  pct destroy 9201 --purge
           → "Logical volume vm-9201-disk-0 successfully removed"
           → "Logical volume vm-9201-disk-1 successfully removed"
           → pct list EMPTY · lvs | grep 9201 → NONE
14:19:27Z  /mnt/adatok and /mnt/mentes wiped 13M/1.2G → 4.0K each,
           MOUNTS LEFT IN PLACE — deliberately: the surviving raw mount IS the R-220 condition
```

### B2 — the rebuild (14:24:09Z, 3 m 31 s)

`felhom-host-install.sh` fetched **live** from `felhom.eu/scripts/` — `v1.25.0`,
sha256 `cb4d02059f126f8bfdddfe98607e87a3cb45dd2592c6b40b43c9659e2b687534`. The retrieval passphrase
was passed as `--passphrase-file` (a `0600` file), never on the command line.

```
[OK] Day-0 provision SUCCESS — vmid=9201 host_id=walk5-4bada5 customer=walk5
     golden=local:backup/vzdump-lxc-9100-2026_08_07-16_21_39.tar.zst
[OK]   controller: Up 19 seconds (healthy)
[INFO] controller image: gitea.dooplex.hu/admin/felhom-controller:0.206.0
[OK]   authz signers: 2 (operator-signed self-update armed)
[INFO] root@pam was rotated + vaulted at step 4b
```

**What the rebuild landed on:**

| | before | after |
|---|---|---|
| agent | 0.127.0 | **0.127.0** — no downgrade, no hand upgrade |
| controller | 0.206.0 | **0.206.0** — same, and it is the vouched build |

**No hand upgrade, either time.** R-216 part 4's reinstall-downgrade did not recur.

Guest re-provisioned at **192.168.0.83** (it was .149 before — a fresh DHCP lease, not a fault).

### B3 — §5's observation window: THE MOMENT THAT MATTERS

**T0 — 14:24:31Z, 22 seconds after provision, nobody has logged in:**

```
offbox directory                  ABSENT  ("No such file or directory")
repository key                    NONE
settings.offbox                   null
settings.hub_escrow_identity_present   TRUE   ← the box already knows a package is held for it
settings.hub_escrow_key_sha256    eabf427c7274…144f  ← and already knows WHICH key it seals
settings.claimed                  null   (pristine, unclaimed)
```

**The scheduler is alive — the positive control, because an absent line is not evidence.** In the
first five minutes the controller logged `agent-channel-health` ×5 (1 m cadence), `stack-scan` ×2,
`system-health`, `backup-cache` and `offsite-credential-retry`. So "no key was written" is a
measurement, not a silence.

**The window, minute by minute — nobody logged in at any point during it:**

| time (UTC) | event | source |
|---|---|---|
| 14:24:09 | Day-0 provision SUCCESS; rebuilt guest, controller **0.206.0** | installer |
| 14:24:31 | **T0** — no offbox dir, no key, `offbox: null`, but `hub_escrow_identity_present` already **true** and the sealed key's hash already learned | box, **measured** |
| 14:24:53 | hub: `offsite_delivery_stuck` (warning) + operator `notification_log` row — **REFUSED**, "regressed-apply shape … a guest rebuild does, R-193" | hub, **measured** |
| 14:23:54 | first post-rebuild report carries **no** `offsite` object — it predates the ACK that set the flag | hub `reports`, **measured** |
| **14:38:49** | **first declaration**: `offsite={"enabled":false,"state":"needs_credential"}` | hub `reports`, **measured** |
| 14:38:53 | the checker **hands off**: *"the box DECLARES offsite.state=needs_credential; internal/offsiteheal owns this remediation"* | hub, **measured** |
| 14:53:49 | second declaration, same shape | hub `reports`, **measured** |
| **14:56:34** | `offsiteheal: re-staged the stored one-time offsite secret … (declared needs_credential across 2 reports) … no provider credential was minted` | hub, **measured** |
| **14:58:52** | **the box collects it and applies the tier — AND REFUSES TO MINT** | box log, **measured** |

### THE LINE THIS WALK EXISTED TO SEE

```
14:58:52 [WARN] [offbox] NOT minting a repository password: the hub holds a sealed recovery package
         for this box, and a fresh key would orphan the history that package protects (R-241).
         The transport is configured; the tier stays down until the customer's recovery code places
         the escrowed key.
14:58:52 [INFO] [offbox] apply-offsite: transport configured for u629488-sub4@…:/home/felhom-repo,
         tier HELD awaiting the escrowed key (the hub holds a sealed package; no key was minted — R-241)
14:58:52 [INFO] [offsite-apply] credential retry: the staged credential was collected and the tier applied
```

**At the equivalent moment the previous walk minted `9b4a9a9d…` over a package sealing `30ef574f…`,
and lost the journey silently at 03:18 in the morning. This build did not.**

### §5's four items, answered

**1. Does the box declare a need, and when is it staged and collected?** **Yes** — declared
`needs_credential` at **14:38:49Z** and **14:53:49Z**, staged by the hub unaided at **14:56:34Z**,
collected and applied at **14:58:52Z**. **Zero human actions**; the whole chain ran on a box that had
not even been claimed.

**2. Is any repository key written?** **NO.** Sampled every ~20 s from 14:24:52Z onward:
`repo_password_sha=NONE` at every single sample. At 15:00:24Z the directory holds exactly:

```
-rw------- applied_marker   64
-rw-r--r-- known_hosts     290
-rw------- ssh_key         400
            repo_password: ABSENT
```

**The transport is present and the key is not** — which is the guard's designed shape, not a partial
failure: `ApplyOffsiteTarget` deliberately keeps the transport so the recovery screen can bring the
tier up the instant the key arrives (R-219).

**3. What state does it report instead?** `offbox.enabled = true`, `escrow_state = pending`,
`repo_state` absent — and `OffboxAwaitingRecoveryKey()` is therefore **true** (target exists, target
enabled, no password), so the box declares the new **`awaiting_recovery_key`** holding state rather
than coming up under a fresh key.

**4. The two fingerprints, before anyone logged in (15:00:24Z):**

```
the escrowed key (hub's package, ACK-cached)  eabf427c72749fdad355d8cbcadedd8430c8398999b6385cfb1960899167144f
whatever the box holds                        NONE — there is no repository key on this box
```

> **HONEST NOTE ON WHICH SHAPE FIRES, because it changes what has been proven.** With the mint guard
> holding, the box has **no local key at all**, so `OffsiteRecoveryOffer` returns true on **shape (a)**
> — the pristine-rebuild shape — not on shape (c). **Shape (c) was measured in Phase A, in its
> negative half**: equal hashes, correctly silent. So this walk proves the mint guard **positively**
> and the discriminator **negatively**; a positive shape-(c) firing needs a box holding a *different*
> key, which v0.206.0 now prevents from arising by itself. That is the intended end state (the fix
> removes the state its own second half was written to describe), but it should not be reported as
> "shape (c) proven".

### B4 — the journey, step by step (§7)

| # | step | result |
|---|---|---|
| 1 | **Destroy** — 14:19:26Z | guest 9201 purged (both LVs), both drives wiped 13M/1.2G → 4.0K. Host identity `walk5-4bada5` survived |
| 2 | **Reinstall** | `felhom-host-install.sh` **v1.25.0** fetched live; **Day-0 provision SUCCESS 14:24:09Z**, 3 m 31 s. **controller 0.206.0, agent 0.127.0 — no hand upgrade, no downgrade** |
| 3 | **§5's window** | **no key minted**; transport configured; `awaiting_recovery_key` — see B3 |
| 4 | **Claim back** | new code requested through the customer-facing „Új kód kérése" path (15:01:27Z), hub rotated to **generation 2** and emailed it; the operator relayed it; **worked FIRST TRY** — 302 in **0.151 s**, accents intact (`á`=`c3a1`, `í`=`c3ad`, sha256 identical source→appliance) |
| 5 | **Log in** | `/` → 302 `/launcher` → 302 **`/recovery`** — **the recovery screen appeared WITHOUT BEING SOUGHT** |
| 6 | **Read the screen** | all three questions answered — quoted below |
| 7 | **Enter R** | **HTTP 200 in 12.44 s** — a real unseal. `[web] recovery: the offsite repository key was recovered and placed (outcome=installed)` |
| 8 | **The listing** | **rendered** — `calibre-web · 2026-08-07 14:57 · 12.8 MB` |
| 9 | **Restore** | **all three sentinels byte-identical** — after two unsignposted obstacles, both cleared from the dashboard |

### The recovery screen, as a customer reads it (§7.6)

> **„Adatok visszaszerzése"**
>
> „Ezt a gépet újratelepítették. **A korábbi, házon kívüli mentéseid megvannak** — a Felhom központi
> rendszere őriz hozzájuk egy lezárt csomagot, amelyet **2026-08-07T12:51:02Z** zártunk le. A csomagot
> csak a **te helyreállítási kódoddal** lehet kinyitni.
>
> **A helyreállítási kódot senki nem tudja pótolni** — sem a Felhom, sem az ügyfélszolgálat, sem az
> üzemeltető. Ez szándékos: így a mentéseidet rajtad kívül senki nem tudja megnyitni. Ha a kód
> elveszett, a korábbi mentések nem nyithatók meg többé.
>
> Ha megadod a kódot, **feloldjuk a mentéseid zárolását és megmutatjuk, mi van bennük** — melyik
> alkalmazás, mikorról, mekkora. **Ebben a lépésben semmit nem állítunk vissza és semmi nem változik.**"

**All three questions answered.** The sealed-at timestamp **`2026-08-07T12:51:02Z` matches the hub's
`host_escrow.created_at` exactly**. The field label reads „Helyreállítási kód (tíz szó)" and R is
indeed ten tokens.

*(One copy wart, recorded not filed: the sealed-at is rendered as a raw ISO-8601 string on a
customer-facing Hungarian screen, where every other date on the box is formatted `2026-08-07 14:57`.)*

### The listing, against Phase A's record (§7.8)

| | Phase A recorded | the screen showed |
|---|---|---|
| app | `calibre-web` | **`calibre-web`** ✅ |
| when | snapshot `5b0f20f7` at 12:57:41Z | **`2026-08-07 14:57`** ✅ (12:57Z rendered in CEST) |
| size | `restic stats` 12.784 MiB | **`12.8 MB`** ✅ |

*(A second row `felhom-offbox · 12.8 MB` also appears — the snapshot carries both tags and the screen
renders one row per tag. A customer sees an "app" they have never installed, and the same 12.8 MB
counted twice. Cosmetic; filed as R-251.)*

### THE RTO (§7.7)

```
login                      15:04:25.417Z
unlock returns 200         15:05:37.156Z
------------------------------------------
wall clock, login → open store      71.7 s
```

**Of which 12.44 s was the unseal itself.** ~22 s of the remainder was **my own harness retry** — I
scraped the CSRF token from a `<meta>` tag the recovery page does not carry, got a 403, and re-read it
from the form (the controller logged `CSRF rejected … (token mismatch)` at 15:05:02). **A customer
clicking the button would have seen ≈50 s.** Both numbers are stated because the 71.7 s is what was
actually measured.

### The restore, and the two obstacles (§7.9)

`POST /backup/offbox/restore` (mode=full) → **refused**: „nincs elérhető adatmeghajtó a
visszaállításhoz". Then, after that was cleared, `POST /backup/offbox/reconstitute` → **refused**:
„a(z) calibre-web nincs telepítve — előbb állítsd helyre az alkalmazást, utána az adatokat".

Both were cleared **from the dashboard, with no guest shell**:

1. **Re-attach the drives** — `GET /api/disks/candidates` offered both surviving disks
   (`mountable: true`, `data_bearing: true`), and Tárhely → Meghajtók → „Meglévő meghajtó csatolása"
   (`POST /api/storage/attach`) registered them: `/mnt/felhom-drives/adatok` and `…/mentes`.
2. **Redeploy the app** — `POST /api/stacks/calibre-web/deploy`, running in 1 m 30 s.

Then prepare (12.8 MB) → confirm → reconstitute:

```
15:10:18  [offbox] restored calibre-web (5b0f20f7, full=true) → …/backups/offsite-restore/calibre-web
15:14:30  [offbox] reconstituted calibre-web from snapshot 5b0f20f7: 6 file(s) placed,
          0 DB dump(s) replayed, safety dump=., skewed=false
```

### THE THREE SENTINELS, read back as BYTES from the live path

```
MATCH [A] 11eb7fb2d1891f62a685e3d9a9fda44e0a342d437d4aebaa15fcb4c0fd79d539        61
          name_hex 57414c4b352d53454e54494e454c2d412e747874
MATCH [B] 6b504d1e83bf4c673334d0b9e701f3e5f07311d954fdc4463a6b0a55b261ae32        66
          name_hex 57414c4b352d c591 72737a656d2d c3a9 6b657a657465732d c3a1 7276 c3ad 7a74 c5b1 72 c591 2e747874
MATCH [C] 0baaf402733e6a85f3d9ce8c4c3a57b05692f5f6733da6a23da76d2cd7635210  12582912
          name_hex 57414c4b352d53454e54494e454c2d432d31324d422e62696e
all three present: True
```

**Identical to Phase A in every byte, including the accented filename.** Read with `os.listdir` on a
**bytes** path, so no decode/encode round trip could launder a `U+FFFD` into looking correct.

### The end state — the loop closed

```
escrow_state              escrowed        (auto-confirmed: hub hash == local hash)
repo_password sha256      eabf427c7274…144f   == the escrowed key, == Phase A's key
GET /launcher             200             (the recovery screen no longer interrupts)
GET /recovery             302             (correctly retired — shape (c) compares equal again)
```

---

# THE VERDICT — both halves, separately

## THE DATA: **PASS**

All three sentinels came back **byte-identical**, out of snapshot `5b0f20f7`, under the key recovered
from the sealed package with R — including the accented filename's **bytes**. Disk → restic → SFTP →
Storage Box → a destroyed machine → a rebuilt machine → disk, intact.

## THE JOURNEY: **PASS — the first time in five walks**

**No step needed a command line inside the guest.** Every step that *progressed* the journey — request
a code, claim, log in, read the screen, enter R, read the listing, re-attach the drives, redeploy the
app, prepare, confirm, restore — was an HTTP request a browser makes, issued from the appliance
because DooPlex has no L2 path to that LAN.

**Guest command lines used, named per §3 so the claim is not read wider than it is:** the `w5watch.log`
sampler, `docker logs`, the settings reads, the restic listing and the final sentinel verification.
**Every one is instrumentation** — none changed state, none was needed to progress, and removing them
all would have changed nothing except my ability to describe what happened. The previous walk needed
**three** guest command lines to progress; this one needed **zero**.

**The reset-code hatch was used ONCE, in Phase A**, where §3 permits it. It was **not** used in Phase B.

### But the journey is not smooth, and two obstacles are new

Neither is a dead end by §3's definition (neither needed a guest shell), and both were cleared from
the dashboard — **but a customer would not know to do either**, because the product does not say so
and, in the second case, says the opposite:

1. **The restore refuses with „nincs elérhető adatmeghajtó" and nothing on the recovery path mentions
   that the drives must be re-attached first.** → **R-252**
2. **„a(z) calibre-web nincs telepítve — előbb állítsd helyre az alkalmazást" — on a page that says,
   three lines above, „Nincs telepítve — a visszaállítás előbb újratelepíti."** The product
   contradicts itself in the customer's own language, at the last step of a recovery. → **R-253**

**So: the machinery works end to end and the data is provably safe. The unaided journey now succeeds,
and it succeeds through two obstacles the customer must guess their way past.**