R-1052 closed: a new box from the public ISO (golden 0.313.0) reached the floor 0.314.0 by itself, 2 min 52 s after the bind (throwaway customer Tester3, VM removed)

Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/audits/gate-restore-2026-10-15/newbox/01-vm-create.txt

@@ -0,0 +1,10 @@
+iso=/var/lib/vz/template/iso/felhom-installer-1.29.0-pve9.2-1.iso sha256=dceacae5da247d76
+Formatting '/mnt/hdd_1/images/9301/vm-9301-disk-0.raw', fmt=raw size=128849018880 preallocation=off
+scsi0: successfully created disk 'nvme-scratch:9301/vm-9301-disk-0.raw,size=120G'
+update VM 9301: -boot order=scsi0;ide2
+boot: order=scsi0;ide2
+ide2: local:iso/felhom-installer-1.29.0-pve9.2-1.iso,media=cdrom,size=1665356K
+memory: 8192
+net0: virtio=BC:24:11:06:60:6E,bridge=vmbr0
+scsi0: nvme-scratch:9301/vm-9301-disk-0.raw,size=120G
+13:47:13

documentation/audits/gate-restore-2026-10-15/newbox/02-timeline.txt

@@ -0,0 +1,18 @@
+install pressed 13:51:20
+bind posted 13:59:17
+claim posted 14:04:09
+claim posted (2) 14:04:35
+poweroff posted 14:05:18
+poweroff posted 14:05:32
+--- read from the hub DB (copied with its WAL) and from the box's own /api/selfupdate/status ---
+13:45:52 hub: customer Tester3 created by the operator; the bind mail sent at once
+13:51:20 Install pressed (ISO 1.29.0, sha256 dceacae5… = published), VM 9301 on demo-hp, 8 GB / 4 cores / 120 GB
+~13:57    console: pairing code shown (screens/n9301-15-console.png)
+13:59:17 bind through the mailed link: „Sikeres összekötés"
+13:59:40 setup-code mail
+14:02:01 first report: controller 0.313.0 (the vouched golden)
+14:02:09 the box's own record: update 0.313.0 -> 0.314.0 status success, initiated_by „auto-floor"
+14:02:14 report: controller 0.314.0
+14:04:35 dashboard claimed (302 /), the household's password set
+14:05:32 the household's „turn off" (hub deliberate_off_at 14:05:32Z); 14:06:03 VM stopped; VM 9301 destroyed
+=> from bind to the floor: 2 min 52 s; from Install to the floor: 10 min 49 s. Nobody pressed an update.

documentation/audits/gate-restore-2026-10-15/newbox/03-bind.txt

@@ -0,0 +1 @@
+ Felhom — Doboz összekötése Felhom doboz összekötése Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést. Ezt az oldalt bezárhatod — a beállítás a háttérben befejeződik, és a vezérlőpultod hamarosan elérhető lesz. Felhom.eu 

documentation/audits/gate-restore-2026-10-15/newbox/04-box-health.json

@@ -0,0 +1 @@
+{"ok":true,"message":"felhom-controller is healthy"}

documentation/audits/gate-restore-2026-10-15/newbox/04-on-the-box.txt

@@ -0,0 +1 @@
+Permission denied, please try again.

documentation/audits/gate-restore-2026-10-15/newbox/05-claim.txt

@@ -0,0 +1,4 @@
+HTTP/2 200 
+0.314.0
+HTTP/2 302 
+location: /

documentation/audits/gate-restore-2026-10-15/newbox/06-version-on-the-box.txt

@@ -0,0 +1,3 @@
+/api/selfupdate/status -> {"ok":true,"data":{"running":false,"last_check":{"current_version":"0.314.0","latest_version":"0.314.0","update_available":false,"checked_at":"2026-10-15T14:02:39Z"},"last_state":{"status":"success","previous_version":"0.313.0","previous_image":"gitea.dooplex.hu/admin/felhom-controller:0.313.0","target_version":"0.314.0","target_image":"gitea.dooplex.hu/admin/felhom-controller:0.314.0","initiated_
+/api/system/info -> {"ok":true,"data":{"sync_status":{"last_sync":"2026-10-15T14:02:09.644603083Z","last_status":"ok","syncing":false},"system":{"total_mem_mb":4096,"used_mem_mb":0,"avail_mem_mb":4096,"mem_percent":0,"disk_total_gb":68.72599792480469,"disk_used_gb":0.989349365234375,"disk_avail_gb":64.22103500366211,"disk_percent":1.5171653637825615,"disk_known":true,"hdd_configured":false,"hdd_known":false,"cpu_perc
+/api/version -> {"ok":false,"error":"endpoint not found"}

documentation/audits/gate-restore-2026-10-15/newbox/07-poweroff.txt

@@ -0,0 +1,6 @@
+{"ok":false,"error":"CSRF token missing or invalid"}
+HTTP 403
+{"data":{"powering_off":true},"ok":true}
+
+HTTP 202
+Tester3-ac1287|2026-10-15 14:05:34|2026-10-15T14:05:32Z

documentation/audits/gate-restore-2026-10-15/newbox/99-teardown.txt

@@ -0,0 +1,5 @@
+name: newbox-r1052
+scsi0: nvme-scratch:9301/vm-9301-disk-0.raw,size=120G
+purging VM 9301 from related configurations..
+Configuration file 'nodes/demo-hp/qemu-server/9301.conf' does not exist
+ls: cannot access '/mnt/hdd_1/images/9301': No such file or directory

documentation/audits/gate-restore-2026-10-15/newbox/README.md

@@ -0,0 +1,17 @@
+# R-1052 — a brand-new box installed from the public ISO reaches the floor by itself (2026-10-15)
+
+Throwaway customer **Tester3** (domain `tester3.test`, a reserved name that never resolves; no off-site, no PBS-DR —
+nothing on ep0). VM 9301 on demo-hp from ISO 1.29.0 (checksum = the published one), the graphical installer driven by
+`qm sendkey`; the household's path: the mailed bind link + pairing code + owner phrase, then the setup code.
+
+- `02-timeline.txt` — every step with its time. **The golden 0.313.0 box moved to the floor 0.314.0 by itself 2 min 52 s
+  after the bind (initiated_by „auto-floor"), before the household claimed the dashboard.**
+- `screens/` — the installer and the console (pairing banner, then „the box is linked").
+- `03-bind.txt`, `05-claim.txt` — the bind page's answer; the claim's 302 (the first try was a 200 refusal: the claim form
+  has its own CSRF field).
+- `06-version-on-the-box.txt` — the box's own `/api/selfupdate/status`: a second channel beside the hub's reports.
+- `07-poweroff.txt` — the household's „turn off", recorded by the hub as deliberate (no alarm mails).
+- `99-teardown.txt` — VM 9301 destroyed. **Left for the operator (session only):** delete customer Tester3.
+
+Not walked: SSH or a console login on the new host — Felhom replaces the root password at first boot (G1, vaulted in the
+hub), so the installer's password stops working; the vault was not opened for this.

documentation/backlog/CLOSED-ITEMS.md

@@ -32,6 +32,7 @@
 |---|---|---|---|
 | **R-1057** | **A restore of a REMOVED gated app came back without its setup gate, even from a backup made before the setup.** (P2 — raised from P3 by the reviewer 2026-10-15) | CLOSED 2026-10-15 — **controller v0.314.0** (`09` §3 decision 253): the per-app backup records the gate; a restore puts it back as it was (closed then → closed now, file first; open then → open; no record → closed until the probe or „Kész"). Unit tests red-proved by ten mutations. **Live on 9202** (rc.1): Prowlarr installed, no account, the Update's per-app backup, remove keeping backups, restore → a stranger got `/ping` 401, `/` 302 to the gate, `/initialize.json` 401; the household 200; the box's log: „restored with its setup gate CLOSED — it was closed when the backup was taken (R-1057)"; „Kész" then opened it. Before the fix the same walk gave the stranger 200. Plex: the same rule, proven by a unit test with Plex's gate shape (no live Plex restore). | `audits/gate-restore-2026-10-15/9202/restore.txt`, `02-controller-log.txt` |
 | **R-1053** | **A box on an `-rc` tag was never moved by the floor.** (P3) | CLOSED 2026-10-15 — **controller v0.314.0**: `util.ParseVersionPre` puts `X.Y.Z-rc.N` below `X.Y.Z` for the floor only; the button never offers a test build; an unreadable version WARNs once per change. **Live:** Tester 1 put on 0.314.0-rc.1 by hand (rc.4 runs the old check and could never leave by itself), then the floor 0.314.0 moved it: „Post-update startup: update successful (0.314.0-rc.1 → 0.314.0)" at 13:09:38 UTC. | `audits/gate-restore-2026-10-15/release/01-tester1-rc1.txt`, `03-boxes-move.txt` |
+| **R-1052** | **A fresh box installed from a golden older than the floor reaching the floor at first boot was not proven.** (P3) | CLOSED 2026-10-15 — proven: a VM on demo-hp from the public ISO 1.29.0 (golden 0.313.0), bound to the throwaway customer Tester3 through the mailed link, moved to the floor 0.314.0 by itself — initiated_by „auto-floor", 2 min 52 s after the bind, 10 min 49 s after Install, before the household claimed the dashboard; read from the hub's reports AND the box's own self-update record. The domain was a reserved placeholder (`tester3.test`); the floor path does not need a working domain. The operator deletes customer Tester3 (session only). | `audits/gate-restore-2026-10-15/newbox/` |
 | **R-1060** | **On controller 0.313.0 the Plex claim button could never work: Plex refused the code with 401 because the box called it as `http://plex:32400`.** (P2) | CLOSED 2026-10-15 — **controller v0.314.0**: every Plex call by the container's address (`mediawire.PlexURL`). **Live on demo-hp 9201** with the operator's fresh code, through the dashboard's own claim call: 200 `claimed: true` in 11.8 s; the box: „claimed — the setup gate is open"; `/identity` „claimed":true; the gate file gone; a stranger meets Plex's own sign-in (`/web/index.html` 200, `/library/sections` 401 without a token); one library wiring run: `plex=done(2)` (`FSEventLibraryUpdatesEnabled=1`, `FSEventLibraryPartialScanEnabled=1`). A fifth call by name — the health probe's `/identity` — is harmless (Plex answers it to anyone). | `audits/gate-restore-2026-10-15/plex9201/01-fake-code.txt`, `02-claim.txt` |
 | **R-1023** | **Build: media apps see every drive, and the box says when they must restart.** (P2) | CLOSED 2026-10-15 — delivered by controller v0.313.0 and the floor; its last step was Tester 1 off the test build (R-1053): Tester 1 runs the release 0.314.0 since 13:09:38 UTC, moved by the floor by itself. | `audits/gate-restore-2026-10-15/release/03-boxes-move.txt`, `audits/media-build-2026-10-15/` |
 | **R-1058** | **Prowlarr installed AFTER Sonarr/Radarr was not linked until „Bekötés most".** (P3) | CLOSED 2026-10-15 — **controller v0.314.0**: Prowlarr's own start runs the media wiring (`linkOnlyApps`). **Live on 9202** (rc.1): Sonarr first, then Prowlarr → „a media app came up: prowlarr", Sonarr in Prowlarr's Apps ~40 s later, no button; a second run „unchanged"; Prowlarr's connection test 200. Catalog `e67aad4` and the website card drop the button sentence. | `audits/gate-restore-2026-10-15/9202/link.txt` |

documentation/backlog/OPEN-ITEMS.md

@@ -221,7 +221,7 @@ stopping line that lies.
 | **R-1050** | Security & access | P4 | **Raise HSTS to one year on or after 2026-11-15, if no https trouble was reported.** `09` §3 decision 249 (D2 = A, operator 2026-10-15): HSTS stays `max-age=86400` now; after a month with no https trouble it becomes one year (`31536000`); never preload, never `includeSubDomains`. The value is `HSTSMaxAgeSeconds` in `felhom-controller/controller/internal/infra/infra.go`, pinned by `TestRenderForwardedHeaders_HTTPSOnly`. „Trouble” = any report of a name that will not open, or a box answering http after the floor. | **WATCHING** — filed 2026-10-15 | the date | On or after 2026-11-15: read the register and the operator's mail for https trouble since 2026-10-15; none → a controller release with one year (test updated), bake → vouch → floor | CC |
 | **R-1054** | Security & access | P3 | **The hub's operator/global API key is still one bearer that can do everything on `/api/v1`, including reading every box's break-glass root password (`GET /admin/hosts/{id}/recovery-credential`).** Hub v0.152.0 gave the web surface scoped tokens (`05` §17) but tokens are refused on `/api/v1` by design. Who uses the global key today is not listed in one place. Fix: list its consumers; move each operator use to a scoped token on the web side (or a token class on the API), and keep the global key only where a box path needs it — or retire it. | OPEN — filed 2026-10-15 by the token build | — | List the global key's consumers (pod env, scripts, runbooks) | CC |
 
-## Box system & updates — 13 rows (P2 1, P3 8, P4 4)
+## Box system & updates — 12 rows (P2 1, P3 7, P4 4)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -236,7 +236,6 @@ stopping line that lies.
 | **R-1004** | Box system & updates | P4 | **After an unclean stop every guest ext4 volume waits ~43 s in multi-mount protection before it mounts, so each restart after a power cut takes ~1.5 min longer.** Kernel: „EXT4-fs warning (device dm-6): ext4_multi_mount_protect: MMP interval 42 higher than expected, please wait" on dm-6/dm-7 and loop0/loop1, demo-hp and Tester 1, every round of `audits/night-power-2026-10-13/` (R1 `repairs.txt`). | **READY** — filed 2026-10-14 | — | CC: find where MMP is switched on for the guest volumes (Proxmox `pct` create, or our own mkfs), whether it protects anything on a one-host disk, and measure the restart without it on a scratch guest | CC |
 | **R-1013** | Box system & updates | P4 | **After a power cut the agent's start-up stale-lock pass logs an ERROR „pct unlock failed … no lock found" when Proxmox's own start-all removed the lock in the same second.** The outcome is the goal (no lock), so the line is a false alarm in the log. Seen on demo-hp 2026-10-14 12:07:44–45 UTC (`audits/power-cut-fixes-2026-10-14/E/after-boot.txt`; Proxmox: „removed left over backup lock from '9201'!"). Small, but the agent's release for this session is spent (v0.156.1). | **OPEN** — filed 2026-10-14 | — | CC: treat „no lock found" from `pct unlock` as already clear (INFO), with a test; ride the next agent release | CC |
 | **R-1010** | Box system & updates | P3 | **The agent's stale-lock janitor cannot remove a half-removed `vzdump` snapshot: Proxmox's delete fails on the first missing volume („Failed to find logical volume pve/snap_vm-9201-disk-0_vzdump") and the janitor retries the same call every 10 min forever, leaving the other volume's snapshot and the snapshot entry.** Seen 2026-10-14 after a backup ran out of space on a full host root (LVM could not write its metadata; `audits/power-cut-fixes-2026-10-14/README.md` C4). Fixed by hand with `pct delsnapshot 9201 vzdump --force`. | **READY** — filed 2026-10-14 | — | CC: on that error, retry once with `--force` (a sudoers line or the API's `force=1`), with a test that replays the error text; next agent release | CC |
-| **R-1052** | Box system & updates | P3 | **The new-box path is not proven: a fresh install from a golden older than the floor reaching the floor by itself at first boot.** `09` §3 decision 250 relies on it (the golden is weekly, releases ride the floor). Proof owed at the next controller release: a throwaway VM on demo-hp installed from the ISO (the vouched golden one release behind the floor); time from claim to the floor; the controller's self-update log lines; then the VM and its hub records removed. | **BLOCKED** — filed 2026-10-15; not run with the 0.314.0 release: the proof needs a throwaway customer, and creating a customer is session only since hub 0.153.0 (`09` §3 decision 252) — CC's token is refused by design | the operator: create a throwaway customer (or name one to reuse) in the browser | Then: a VM on demo-hp from the current ISO, claimed as that customer; time from claim to the floor; remove the VM; the operator deletes the customer (session only) | CC |
 | **R-1061** | Box system & updates | P4 | **A per-customer floor reached Tester 1 only at its next 15-minute report, not in seconds.** Set 2026-10-15 12:55:51 UTC for tester-1, demo-hp and demo-felhom together (hub 0.153.0, CC's token): demo-hp and demo-felhom ran 0.314.0 within 13 s (the hub's wake); Tester 1 moved at 13:09:35, its regular report (`audits/gate-restore-2026-10-15/release/03-boxes-move.txt`). It had restarted at 12:54:29 onto rc.1 and logged „hub wait channel active". Why the wake did not reach it is not read (the wake line is DEBUG). No harm: the floor arrived. | **OPEN** — filed 2026-10-15 | — | Read Tester 1's DEBUG ring at the next floor change; compare with the hub's bump log | CC |