felhom.eu/REPORT.md

REPORT — DRILL: prove the P1 fixes on a fresh box (2026-09-16)

Claims in the prompt that turned out wrong — first, as asked

1. "The WG hook now adopts a stuck endpoint token." It does not, on a real box. The hook refused exactly as R-511 describes, the operator pressed the explicit Re-issue, hub v0.114.0's adopt path ran, and the ENDPOINT refused it: missing Datastore.Modify on /datastore/felhom-offsite → 502, nothing written. The fix is sound and inert until the ep0 grant is given (R-534, P1).
2. "The claim is one-shot — measure it, do not assume." Correct to doubt it: it is NOT one-shot. After a successful claim the same URL becomes the password-reset surface with a "request a new code" button. And the lock-out is not at five wrong codes, it is at two — the third try already says "Túl sok próbálkozás — próbáld újra 15 perc múlva."
3. "The fresh box lands on golden 0.243.0." This one was TRUE, and it is now measured rather than assumed: the golden archive left on the box has sha256 e2d1843c…c10a, byte-identical to this drill's own bake, and the guest runs controller 0.243.0 with no self-update.
4. "Restore one DB-backed app from the off-site tier onto 9202." Not walkable at all on this box — there is no off-site tier to restore from (consequence of item 1), proven by a read-only listing of the customer's namespace, empty before and after.
5. My own wrong reading, recorded: I first reported "no lock-out" for the claim code. That was false and I corrected it in the same evidence file — the lock-out is real and the alarm for it fired and was true.

What I exercised

A fresh box from the published ISO 1.27.1, walked as a volunteer: download by checksum, install, first console, connect e-mail and self-bind, claim, tunnel from outside, data drive, file manager, four apps, ten minutes of real use, the backup page and „Mentés most", version labels. Then five faults, then the morning-after checks and a three-layer teardown.

What broke — product, and mine

Product. Five new rows: R-534 (P1, the off-site tier cannot be provisioned — the endpoint token lacks a grant), R-535 (P2, the console keeps showing the pairing banner after bind and claim), R-536 (P2, „app installed" is sent when the install is merely accepted), R-537 (P1, the app-backup page claims it holds the app's data and it does not), R-538 (P1, a restore reports success and leaves the app listing files it cannot open, after making the app's own wastebasket unreachable).

Mine, recorded because they cost real time. A blunt sed rewrote Redis's memory cap while I was restoring caps after the memory test — the second time this exact mistake has happened, repaired per-service. A hand-run docker compose up -d inside the guest recreated Paperless without the controller-injected environment and crash-looped it; repaired through the controller's own API. I measured my own CSRF error twice before measuring the claim page. And I guessed the file manager's address twice before reading it off the dashboard.

Rows

Opened 5 (R-534 … R-538), updated 3 (R-511, R-528, R-531), closed 2 earlier in the day (R-529, R-533, plus R-510 from the walk). Counted, not asserted: the register held 236 open rows before this session's first commit today and holds 238 now. Three of the five new rows are P1: R-534, R-537, R-538.

The automatic connect e-mail (R-509) — PASSED

The host record tester-1-652049 was deleted at 12:22:59Z (the hub refuses to delete an ONLINE host, with no override by design, so the record had to fall stale first — it did at 12:22:28Z, 25m46s after the box's last report). In the same second the hub logged „self-bind link auto-minted for tester-1 on host delete", and the mailbox received „[Felhom] Kösd össze a Felhom dobozodat" at 12:23:00Z — one second later. The customer timeline carries selfbind_link_sent — Self-bind link e-mailed (host delete). The requirement was two minutes.

Verdict

Ready for a volunteer: no. Every P1 fix this drill set out to prove held on a fresh box — the supervisor restarts a dead controller, the file manager has its own password, the backup page tells the truth per tier and skips an absent tier without stopping apps, the tunnel opens from outside, and the connect e-mail now sends itself. Interventions: 0. What stops a volunteer is new: their own files are in no backup on a one-drive box, the page says otherwise, and the restore that should save them makes things worse.

Teardown

Three layers, stated. Evidence off the box first (R-320): agent journal, controller log and box state, token-leak control 0. Machine: VM 334 purged with its disks; qm list empty; demo-hp's own containers 9201 and 9202 untouched. Host: nothing to remove — the drill box WAS the nested VM. Hub: the host record deleted, the customer tester-1 kept with its e-mail, domain and tunnel; RESET was never used. Nothing on the off-site server was written, removed or pruned — its listing is empty before and after.

Checks

python3 scripts/repo_gates.py --fast — all 14 gates OK. scripts/unproven.py --summary — unchanged at 35 of 55 not walked. CI for the session's pushes: job 642, conclusion success, matched by head_sha.