felhom.eu/documentation/audits/DRILL-retained-key-2026-08-12.md

DRILL — the retained key, and the two fixes nobody had watched work

Date: 2026-08-12 · Class: drill (unattended, destructive on Tier 0; spike for Phase C's first step) Venues: drill-r50 (nested PVE on DooPlex) · demo-felhom (guest 9201 on felhom-pve) — both Tier 0 Baselines re-confirmed live on arrival, not assumed: controller 0.213.0 on both demo boxes (pct exec 9201 -- docker ps), agent 0.128.0 (hub hosts), hub 0.102.0 (deployment image), register ceiling R-303 (grep), felhom.eu clean at fbe1155f and level with origin/main.

---

1. The three verdicts, first, in plain language

(a) Is the material retained? — YES. Proven for the first time in the fleet's history.

(b) Does the retained material, once unsealed, yield a password that actually opens the old store? — YES. Three planted files came back byte-identical from a store the box itself could no longer open, including the Hungarian accented filename.

(c) Does the customer have a route to (b) through the product? — NO. And the failure is worse than absence: the customer's old recovery code — the one that demonstrably opens their old backups — is rejected by the product with "the recovery code did not open the sealed bundle". They are told their correct code is wrong, and given no next step.

The headline the operator asked for. The brief said to be ready for the answer to be no, and our own records predicted the retention would be "a box we fill and cannot open". That prediction was half right, and the wrong half was the one nobody checked. The box can be opened — the crypto, the retention and the copy are all sound. What does not exist is the door: no code path reads a retained row, so the only way in is an operator with SQLite, age and a shell. Everything I did in §4 a customer cannot do.

That distinction matters for the three pieces of work resting on this:

Rests on	Verdict
The census answer ("nobody else is exposed")	Stands. It was a statement about retention, and retention works.
The countdown banner's promise (old backups stay recoverable)	True in substance, false in practice. The bytes are recoverable; the customer cannot recover them. The promise is made to someone who has no way to act on it.
The capability map's recovery claims	Must move. Any claim of the form "the customer can recover the old history with their recovery code" is false today.

---

2. §7.0 — the probe, run first and read-only

Run before anything was installed or planted, exactly as the order required.

Q1 — does any host today hold a superseded record with key material present? NO. Zero, fleet-wide.

host_id             kfp16             blob_len  identity_blob  superseded_at
demo-hp-bb76ea      3f:4f:65:c0:d8:f  383       NULL           2026-08-04 07:15:36
demo-felhom-8363b5  7e:a6:af:f7:ea:6  383       NULL           2026-08-04 07:20:08

Both are the pre-R-198 rows written hours before the fix. SELECT COUNT(*) … WHERE identity_blob IS NOT NULL returned 0. The retention as fixed had never once been exercised.

Instrument: hub SQLite copied WITH hub.db-wal + -shm (the standing gotcha). Freshness proved by a positive observable — newest host_reports row 61 s old — not by "the query returned no error". PRAGMA integrity_check = ok.

Q2 — what act produces a retaining supersession? Two, both read from source:

• hub/internal/store/store.go:2807 — SaveHostEscrow demotes when the newly sealed restic_pw_sha256 differs from the stored one.
• hub/internal/store/store.go:2636 — DeleteHost demotes the current row unconditionally.

Q3 — is there any code path that USES a retained record to recover a password? NO.

The product's recovery route is real and wired (R-199) but reaches the current row only:

controller  →  agent POST /escrow/recover-offsite-password
            →  escrow.OffsiteKeyRecoverer.Fetch      felhom-agent/cmd/felhom-agent/main.go:1757
            →  hubClient.FetchIdentityEscrow
            →  hub GET identity-escrow handler       hub/internal/api/handler.go:1325
            →  store.GetHostDRBundle                 hub/internal/store/store.go:3152
               SELECT blob, identity_blob, directive_json FROM host_escrow WHERE host_id = ?

ListSupersededEscrow (store.go:2841) is the sole reader of a retained identity_blob. It has zero production callers — five call sites, all in _test.go. CountSupersededEscrow is used twice and only to render a count (api/handler.go:1209, web/hosts.go:572).

Feasibility verdict: producible. Phase C proceeded.

---

3. Phase C — producing the state

3.1 The planted dataset

Planted in /mnt/sys_drive/felhom-data/userdata/drill-20260812 on demo-felhom.

file	sha256	bytes
payload.bin	6863824a67bf6cb636defca3cbddc1d58092bcdda3af939224dfef4663c15359	65536
plain-ascii.txt	e294e0ee5b8fd131dc0fa71f5cf1253dc39473241aa090be36404a568285c83a	56
árvíztűrő-tükörfúrógép.txt	a1957a87104c63be22b34e4f937e700edcdc925da5984bfcca407df4989f7190	37

The accented filename never crossed a shell as text (rule 6). It was built from explicit bytes and verified as hex, both as intended and as listed on disk — identical:

c3 a1 72 76 c3 ad 7a 74 c5 b1 72 c5 91 2d 74 c3 bc 6b c3 b6 72 66 c3 ba 72 c3 b3 67 c3 a9 70 2e 74 78 74

3.2 Positive control on the comparator — done BEFORE it was relied on

One byte of a copy of payload.bin flipped at offset 40000:

unaltered  f5de179b5ca941645819a879187db953db5c973d4c1a07b2a3ba96d3d79bfb6c
altered    515a65d96326bd847a87ea35c9fb5e6afebc9499ec0c1cd80ca3531b22cb2324
payload.bin: FAILED · sha256sum: WARNING: 1 computed checksum did NOT match

The comparator convicts. The copy was discarded and the original re-hashed unchanged.

3.3 The store, written under P1

restic backup into demo-felhom's own repository path (sftp:u629488-sub1@…your-storagebox.de:/home/felhom-repo) → snapshot 6ea85413, confirmed by identity and by listing its contents, not by the success line:

6ea85413  2026-08-12 15:15:33  demo-felhom  felhom-offbox,drill-retained-key-20260812
  …/drill-20260812/payload.bin
  …/drill-20260812/plain-ascii.txt
  …/drill-20260812/M-CM-!rvM-CM--ztM-EM-1rM-EM-^Q-tM-CM-<kM-CM-6rfM-CM-:rM-CM-3gM-CM-)p.txt

Key fingerprint of the store's password (P1): sha256 c60c8bc737a6b7c6… — value never recorded.

3.4 The supersession, by the product's own ceremony

The repository password was replaced (P1 → P2, d4aac4f1c0ef9ac0…), making /home/felhom-repo the old store, then the ceremony was driven through the same local-API calls the dashboard wizard makes: POST /escrow/stage-secret → POST /escrow/ceremony → …/status → …/claim.

phase=done  restic_pw_sealed=true  uploaded=true

3.5 (a) — the material IS retained

The hub grew its first ever retained row carrying key material:

id  host_id             identity_blob  restic_pw_sha256    superseded_at
11  demo-felhom-8363b5  572            c60c8bc737a6b7c6…   2026-08-12 15:18:55

Confirmed by identity and byte length, not by presence:

a10032341c8584edfd87ad941a50d9fd6f34c23a4802f55885cb1d4cab086bd3  current-identity.age   (pre-supersession)
a10032341c8584edfd87ad941a50d9fd6f34c23a4802f55885cb1d4cab086bd3  retained-identity.age  (retained row 11)
572 bytes both — IDENTICAL

3.6 (b) — the retained key DOES open the old store

Negative control first — the box's current password against the old store:

restic exit code: 1
Fatal: wrong password or no key found

Then the retained key. Retained blob → age -d with the old recovery code → bundle → restic_repo_password, sha256 c60c8bc737a6b7c6…, byte-identical to the P1 recorded before the supersession:

restic snapshots  → exit 0, snapshot 6ea85413 listed
restic restore    → exit 0
restored accented filename bytes: c3 a1 72 76 c3 ad 7a 74 c5 b1 72 c5 91 2d … (identical)
payload.bin: OK · plain-ascii.txt: OK · árvíztűrő-tükörfúrógép.txt: OK   (compare exit code 0)

All three files byte-identical, from a store the box itself could not open.

3.7 (c) — the customer has no route, and is actively misinformed

The product's own recovery endpoint was asked for the old password, using the same old recovery code that had just worked by hand:

OLD code (opens the retained row by hand → P1)   REFUSED: "the recovery code did not open the
                                                  sealed bundle — nothing was written"
NEW code (today's ceremony)                      RETURNED a password, sha d4aac4f1c0ef9ac0 = P2

P2 does not open the old store. The one code that works is reported as the code that does not. This is the R-224 defect class in a new guise: there, an unreachable hub was reported as a bad recovery code; here, a valid code for retained history is reported as a bad code. The message is not merely unhelpful — it is wrong, and it terminates the customer's attempt.

---

4. Every step taken off the customer's path

Stated plainly, because (b)'s "yes" is worth exactly as much as this list is short.

Step	Off-path how	Cost to the walk's fidelity
Read identity_blob out of the hub's SQLite	No API serves a retained row — this is (c)	None to the finding; it is the finding
age -d via a hand-written pty wrapper on DooPlex	The product's unwrap is reachable only for the CURRENT blob	None — same age -p primitive the agent uses
restic invoked directly with the recovered password	The controller's recovery path compares, it never installs	None — same restic, same repo, same credentials
Recovery code taken from the operator's credentials file	A customer would read it from their card	None — a customer plausibly has it
Planted dataset pushed with restic backup directly	The dashboard button was unreachable (see F6)	The unit-snapshot chain was not exercised; the store is identical
--skip-provision + --force on Phase A installs	Saved a guest restore per cycle	None — dnsmasq handling is independent of provisioning

---

5. Phase A — our removal undoes what our installation did

Venue drill-r50, reverted to virgin before each clean run.

5.1 The chain re-established, not assumed

Virgin baseline: dnsmasq not-installed, unit not-found, :53 free. After an appliance install the agent installed dnsmasq (internal/lanresolver, not the script) and the Felhom snippet constrained it to 10.0.2.15:53 + 127.0.0.1:53.

5.2 The wrong outcome, demonstrated first

Pre-fix uninstall (v1.26.0) — snippet removed, README only left, and:

enabled: enabled · active: active
udp UNCONN 0.0.0.0:53 · udp UNCONN [::]:53 · tcp LISTEN 0.0.0.0:53 · tcp LISTEN [::]:53

Pre-fix byo install, exit 1 — the refusal the publication had been waiting for since Sunday:

[ERROR]   a resolver is already bound to :53 on this host:
      udp UNCONN 0 0 0.0.0.0:53 … users:(("dnsmasq",pid=4934,fd=4)) …
[ERROR] a resolver is already bound to :53 on this host — Felhom needs the guest reachable by name on your LAN.
  Stop or reconfigure that resolver, OR point your LAN DNS at the guest's address, then re-run.
  (Felhom does NOT touch DNS services on a host it does not own — this is a refusal, not a change.)
[ERROR] PRE-FLIGHT FAIL (exit 1) — fix the finding above and re-run

Nothing in it suggests the resolver is Felhom's own leftover.

5.3 The pass

Fixed path (v1.27.0) from virgin: preflight recorded dnsmasq: not present before Felhom; uninstall logged dnsmasq was installed by Felhom (recorded at install) — stopping + disabling it; result enabled: disabled · active: inactive · :53 FREE; and the second install:

[INFO]   host DNS (:53): free
[OK] pre-flight passed
[OK] PRE-FLIGHT PASS (mode=byo) — no state written, no install step executed

5.4 Both sides of the ownership record

• no (Felhom's): stop + disable. Quoted above.
• yes (the owner's): dnsmasq pre-dates Felhom (recorded at install) — leaving it running, restarting only → left enabled/active. Felhom does not disable a resolver it did not install. Correct.
• No record (the field case): every box installed before this change. Exercised by running the fixed byo preflight on a box whose state file the uninstall had already deleted — the improved refusal fired (§5.5).

5.5 The improved refusal, judged

  THIS LOOKS LIKE OURS. A previous Felhom install leaves the dnsmasq PACKAGE installed and its unit
  enabled (only our config snippet is removed), and unconstrained it binds 0.0.0.0:53 — which is what
  this gate is seeing. If this host had no dnsmasq before Felhom, clear it with:
      systemctl disable --now dnsmasq
  Then re-run this installer. If dnsmasq is YOURS, leave it and use one of the two routes above.

It names the leftover, gives the exact command, and does not overclaim — it says looks like, and leaves the owner's case intact. Good. One weakness: it asks the reader to answer "did this host have dnsmasq before Felhom?" — a question the installer itself now records the answer to, but in a state file the uninstall has already deleted. English throughout, consistent with the rest of the installer (this surface is operator/tester-facing, not the customer dashboard).

5.6 The finding this phase was not looking for — the fix works exactly once per machine

Proven, not deduced. Cycle 2 on the same box:

install : [INFO]   dnsmasq: already installed BEFORE Felhom — recorded; uninstall will not touch it
uninstall: [INFO]  dnsmasq pre-dates Felhom (recorded at install) — leaving it running, restarting only
after   : enabled: enabled · active: active · 0.0.0.0:53
cycle-3 byo preflight: PRE-FLIGHT FAIL (exit 1) — "a resolver is already bound to :53"

Why: the uninstall disables the unit but never purges the package (deliberately — purging on a host we may not own is the wrong blast radius). So on every later install dpkg-query says installed, preflight records yes, the agent re-enables it, and the uninstall then only restarts it. The wall returns on the second reinstall. → F2

---

6. Phase B — an install takes the image that was approved

Venue drill-r50, reverted to virgin. A genuinely stale golden (golden-0.98.3.tar.zst, controller 0.98.3, marker verified before use) was placed as local:backup/vzdump-lxc-9100-2026_08_12-23_59_59.tar.zst — newest by filename, which is exactly what discovery sorts on.

6.1 The fault, observed

Pre-fix (v1.25.0, the published tag) reported both facts and used the wrong one:

[INFO]   manifest: agent v0.128.0 (sha c6eba73bf9b9ad69…), golden v0.213.0
[STEP] 7/8 golden archive
[SKIP]   using local golden: local:backup/vzdump-lxc-9100-2026_08_12-23_59_59.tar.zst
[OK] Day-0 provision SUCCESS — vmid=120 … golden=local:backup/vzdump-lxc-9100-2026_08_12-23_59_59.tar.zst

No digest, no version compare, no warning. The box came up on controller 0.98.3 — confirmed twice, from the running container and from the in-guest marker:

gitea.dooplex.hu/admin/felhom-controller:0.98.3     (docker ps)
gitea.dooplex.hu/admin/felhom-controller:0.98.3     (/etc/felhom-controller-image)

The sharp end (§6 item 4). Vouched golden 0.213.0; floor 0.213.0; the box landed on 0.98.3 — below the floor, and below the version carrying the off-site recovery screen. A box born this way cannot run the ceremony its own data depends on, and is born below the update floor. The row was right.

6.2 Both fixed shapes

Explicitly named archive → refuses (exit 1):

[STEP] 7/8 golden archive
[ERROR] refusing the golden you named (local:backup/vzdump-lxc-9100-2026_08_12-23_59_59.tar.zst):
        it is controller 0.98.3, but the vouched golden is 0.213.0.
  The vouched golden is 0.213.0. Either pass the archive that matches it,
  or re-run with --force-gitea-golden to fetch the vouched one from Gitea.

Auto-discovered archive → warns and re-fetches: see §6.3.

No local goldens were deleted and teardown's keep-behaviour was not changed.

6.3 Auto-discovery result

[STEP] 7/8 golden archive
[WARN]   ignoring the local golden local:backup/vzdump-lxc-9100-2026_08_12-23_59_59.tar.zst
         — it is controller 0.98.3, but the vouched golden is 0.213.0
[WARN]   fetching the vouched golden instead (this is what the manifest is for)
[INFO]   fetching golden v0.213.0 from Gitea → …/vzdump-lxc-9100-2026_08_12-17_31_32.tar.zst
[OK]   verified sha256 77429bfc7e39ffc8… matches the hub manifest

Landed on 0.213.0, confirmed from both the running container and the in-guest marker.

Observation, not a fault: the re-fetched archive is named by its real timestamp (17_31_32), which sorts below the planted stale one (23_59_59). So the stale archive stays the newest-by-filename and is re-discovered — and correctly re-rejected — on every subsequent install. The fix is not defeated; it just never displaces the bad archive, so the warning recurs forever.

---

7. Findings, ranked by what they cost the person in front of you

#	Rank	Finding
F1	1 — stops the visit	The retained key has no product route, and the product tells a customer holding the correct old recovery code that it "did not open the sealed bundle". Recoverable data, valid code, and a dead end with no next step. (§3.7)
F2	2 — costs time	The R-300 cleanup fires only on a machine that never had Felhom. The package is never purged, so every later install records dnsmasq_preexisting=yes and the leftover returns on the second reinstall. (§5.6)
F3	3 — misleads	--preflight-only claims "no state written" (banner and the flag's own comment) but writes /var/lib/felhom-install/state.json — _state_put short-circuits on DRY_RUN only. Worse, on a box carrying a Felhom leftover it records dnsmasq_preexisting=yes before the real install, baking in the wrong ownership answer.
F4	3 — misleads	The pre-fix uninstall's closing note called dnsmasq a "system package". On these boxes Felhom installed it. (Already corrected in v1.27.0's wording; confirmed live.)
F5	4 — cosmetic	The shape-2 refusal states the vouched version twice in consecutive sentences.
F6	2 — costs time	The stored PASSWORD credential no longer opens demo-felhom's dashboard (Hibás jelszó). Not the known quoting trap — quotes were stripped and the value is unquoted. The dashboard was unreachable headlessly for this drill.
F7	— operator decision	demo-felhom has a live abandon countdown: abandon_started_at 2026-08-10T08:06:31Z, abandon_at 2026-08-24T08:06:31Z, abandon_repo_path /home/felhom-repo.orphaned-20260810. Not started by this drill. See §9.
F8	4 — cosmetic	--uninstall requires /dev/tty for the typed vmid confirmation when a guest exists, and --force does not bypass it (deliberate, and correct for an irreversible destroy) — but it means teardown cannot be scripted without a pty. Worth one line in the runbook.

A drill that finds nothing is a suspicious result. This one found eight, and the instrument was demonstrably working: the comparator was shown convicting a one-byte change before it was trusted (§3.2), the negative control on the old store failed closed before the positive one succeeded (§3.6), and both installer faults were reproduced from a virgin machine before either fix was watched.

---

8. Publication

Both Phase A's and Phase B's faults were observed live. The reward is earned.

• Phase A fault: observed (§5.2) and fixed path quoted (§5.3).
• Phase B fault: observed (§6.1) — the box came up on 0.98.3 against a vouched 0.213.0.

installer-v1.27.0 cut, covering both fixes (R-297 stale-golden comparison, R-300 removal leftover — the only two commits touching the installer since installer-v1.25.0).

And publishing is not what the day-0 runbook says it is. §C.1 states the URL "is always the current main script … pushing scripts/felhom-host-install.sh publishes it." That has been false since R-110: manifests/webpage.yaml runs two git-syncs, and /scripts/ follows the installer tag, not main. Measured before publishing — https://felhom.eu/scripts/felhom-host-install.sh served SCRIPT_VERSION="1.25.0" while main carried 1.27.0, three and a half hours after the push. So the fixes were genuinely unpublished, as the brief assumed — but for a reason the runbook denies. Publication here therefore meant: cut the tag and bump both --refs (sidecar at line 327 and init container at line 372). → R-309

---

9. The countdown — an operator decision, deliberately not taken

demo-felhom carries a running abandon countdown, started 2026-08-10, firing 2026-08-24, for /home/felhom-repo.orphaned-20260810. This drill did not start, shorten or trigger it, per the fence.

But §9 of the brief requires an end state of "no abandon countdown anywhere", and one exists. The two ways to satisfy that are not equivalent and the choice is not mine:

1. Cancel it — the orphaned repository is kept indefinitely (storage cost, no data risk).
2. Let it run — on 2026-08-24 the orphaned repository is deleted, irreversibly.

Doing nothing selects option 2 by default. Flagged, not resolved.

---

10. Teardown — four layers

Layer	State
The machine	demo-felhom: planted dataset and working directory removed; eight secret-bearing files shredded, not unlinked; repo_password restored to P1 (c60c8bc737a6b7c6…); escrow re-sealed and uploaded; offsite repo reachable (restic snapshots exit 0, 4 snapshots). The agent's escrow-stage/ directory is empty — the ceremony wiped the staged secret (positive observable). demo-hp: not touched at any point. drill-r50: see §11.
The host	felhom-pve: no drill artefacts left outside guest 9201. drill-r50 host: see §11.
The hub	Two new retained rows (id 11 = the P1 blob, id 12 = the P2 blob), both identity_blob 572 bytes — deliberately kept as the fixture that proves the retention works; they are append-only, tiny, and exactly what the design intends. drill-r50-0a4f9a host record: pre-existing since 2026-07-25, re-used rather than duplicated — no new hub-side sprawl. customer_configs gained nothing.
The off-site side	Only demo-felhom's own repository path was touched. No prune, no forget, no delete, no rename — anywhere, at any point. One snapshot was added: 6ea85413, 66 KiB, tagged drill-retained-key-20260812. Deliberate residue — removing it would have meant a forget on the endpoint, which the fence forbids in spirit; the operator can remove it by ID if desired. Nothing outside /home/felhom-repo was read or written; peti-felhom was never contacted.

How I know the off-site side is untouched outside this machine's path: every restic invocation in this drill went through one wrapper pinned to sftp:u629488-sub1@u629488-sub1.your-storagebox.de:/home/felhom-repo — a per-customer sub-account whose credentials reach nothing else — and the only mutating verb used was backup.

---

11. Close of run

11.1 Wall clocks (CEST)

Phase	Span	Elapsed
§7.0 probe (read-only, source + hub)	16:42 → 16:52	~9 min
Phase A — removal leftover	16:50 → 17:12	~22 min (4 installs, 4 uninstalls, 3 preflights)
Phase B — stale golden	17:13 → 17:34	~21 min (2 full provisions)
Phase C — retained key	17:14 → 17:23	~25 min (overlapped Phase B; different machine)
Record, register, publication, teardown	17:35 → 17:55	~20 min
Total	16:42 → 17:55	≈ 1 h 13 min

Phase C ran concurrently with Phase B deliberately — different machines, no shared state. The 4–5 hour envelope was not needed; nothing was hurried and nothing was dropped for time.

11.2 Register

Ceiling moved R-303 → R-310. Opened: R-304 (retained key has no product route — rank 1), R-305 (R-300 fix is single-shot per machine — rank 2), R-306 (--preflight-only writes state it says it does not — rank 3), R-307 (live abandon countdown, operator decision), R-308 (stored controller password stale for demo-felhom — rank 2), R-309 (day-0 runbook's publication claim false since R-110 — rank 3), R-310 (two installer edges — rank 4). Closed: R-297 and R-300, both observed live and published.

11.3 Teardown

drill-r50: reverted to snapshot virgin and left powered off — qemu-img snapshot -a virgin, qemu exited first, qemu.pid removed. Its three in-VM goldens went with the revert (the VM's normal lifecycle); the source archive on DooPlex, /mnt/5_hdd/felhom.eu/drill/golden-0.98.3.tar.zst, is untouched (mtime still 2026-07-03). Full four-layer detail in §10.

11.4 What was dropped, named plainly

Nothing was dropped. Phase A, Phase B and Phase C all ran in full, in the required order, and the publication was earned rather than assumed.

One thing was not done and it was not in scope: the planted dataset reached the off-site store via restic directly rather than via the dashboard's own button, because the stored controller password no longer opens demo-felhom (R-308). The store, the credentials and the restic binary were the product's own; what went unexercised is the app-backup → recovery-unit → offsite chain, which is not what this drill was measuring.

11.5 Evidence, including a gap

Logs at audits/evidence-drill-retained-key-2026-08-12/: B1-install-preB.log, B2-uninstall.log, B3-explicit-stale.log, B4-autodiscover-stale.log, Z-final-state.txt.

The Phase A logs did not survive. They lived on the drill VM's disk and were destroyed by the revert to virgin between Phase A and Phase B — I copied evidence out before the final teardown but not before the intermediate one. Every Phase A quotation in §5 is verbatim from the live run as read at the time, but the raw files are gone and cannot be re-read. This is the GL-1 discipline the golden-bake runbook already states ("scp the log OUT first"), applied to the last revert and not the middle one. Recorded rather than glossed; the fix is procedural, not a code change.

11.6 Observations — noticed, not acted on

• The stale archive is never displaced. A re-fetched golden carries its real timestamp, which sorts below a planted 23_59_59, so the bad archive stays newest-by-filename and is re-rejected on every future install. Correct, but the warning recurs forever and nothing removes the cause.
• The ceremony wipes its staged secret. After every run /var/lib/felhom-agent/escrow-stage/ was empty — checked as a positive observable, not inferred from an absent log line.
• restic_pw_sealed: true in the ceremony status is a genuinely useful positive observable — it distinguishes "a ceremony ran" from "a ceremony sealed the thing that matters".
• demo-felhom already had an orphaned store (/home/felhom-repo.orphaned-20260810) from the 10 August rebuild, and its password never changed — the current escrow's restic_pw_sha256 matched the box's live repo_password exactly on arrival. So that orphaning was a rename, not a key change.
• R-241's mint guard makes password-changing supersessions rare by design. A rebuilt guest no longer mints a fresh repository password while the hub holds a sealed package, which is why the state Phase C needed had to be produced deliberately rather than found.
• The Hungarian locale warning (perl: LC_CTYPE = "UTF-8") prefixes almost every pct exec on felhom-pve. Harmless, but it is noise on every operator transcript.