R-1060 closed: demo-hp's Plex claimed through the dashboard on controller 0.314.0 (200, gate opened by the box, stranger meets Plex's sign-in)

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

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-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

@@ -124,7 +124,7 @@ stopping line that lies.
 | **R-494** | Install & onboarding | P4 | **NARROWED 2026-09-14 by operator ruling → [P3-LOW] the hub COULD create the tunnel at customer creation, for a domain already on Cloudflare. Not blocking: every customer has their own domain and the operator creates the tunnel per day-0 A.1 (`architecture/01-topology-and-trust.md`).** *Original finding, kept:* **[P1-HIGH] A new customer's dashboard has NO reachable address unless the operator hand-makes a Cloudflare tunnel — the link in the setup-code mail is dead.** MEASURED 2026-09-14 on a fresh install from the public ISO (drill intervention **I1**): the claim mail points at `https://felhom.drill0242.felhom.eu`; that name has **no A and no AAAA** record (`dig @1.1.1.1`, control `felhom.enkisfelhom.hu` resolves); the hub has **no tunnel- or DNS-creation code** (`hub/internal/cloudflare/` holds only geo-rule removal; `cf_tunnel_token` is a pasted, optional form field, `configs.go:1478`) — day-0 runbook A.1 makes it a manual Cloudflare-dashboard step that nothing on the customer-create page asks for; the box's own split-horizon resolver on the appliance LAN IP answered `google.com` but not the dashboard name at 13:27:39Z; the agent applied the record at **13:27:44Z** (`lanresolver: applied split-horizon record … ip=192.168.0.158`, 3 m 46 s after the controller started), so the box CAN answer the name — **but only to a device that uses the box as its DNS server, and no document, screen or mail tells a household to do that**; the router and the installer-offered DNS answer nothing. The page was reachable only at the guest's LAN address with the name forced (`curl --resolve …:443:192.168.0.158`). **A volunteer could not have done that.** **What it needs:** an operator ruling — the hub creates the tunnel and DNS at customer creation, or the product gives a household a LAN address that works with no DNS change. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: operator-side automation; the operator creates the tunnel by hand per the day-0 runbook.** | — | — | CC |
 | **R-504** | Install & onboarding | P4 | **[P3-LOW] `iso.felhom.eu` cannot show an index page on its own — its root returns 404, and the download page lives on the website instead.** MEASURED 2026-09-14: `https://iso.felhom.eu/` and `/index.html` → 404; only named objects answer. The host is an R2 bucket behind a custom domain; whether R2 would serve an uploaded `index.html` at `/` was **not measured** (uploading anything to the public bucket is a publication). The ISO v1.27.0 task puts the Hungarian download page at `felhom.eu/letoltes` (published with the ISO, after the operator's yes). **Remaining:** a redirect from `iso.felhom.eu/` to that page needs a Cloudflare rule the session has no credential for. | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator (Cloudflare rule)** **Re-ranked 2026-10-03: P3→P4: households are sent to the website's download page; the bare address is cosmetic.** | — | — | operator |
 
-## Apps & catalog — 14 rows (P2 2, P3 7, P4 5)
+## Apps & catalog — 13 rows (P2 1, P3 7, P4 5)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -134,7 +134,6 @@ stopping line that lies.
 | **R-994** | Apps & catalog | P3 | **Seven apps peak above 80 % of a memory limit, and 23 apps' typical use is above their catalog `mem_request`.** MEASURED 2026-10-13 (`documentation/audits/sizing-2026-10-13/SIZING.md` §3, `evidence/catalog-check.json`). Near a limit — risk: the container is stopped for using too much memory: docmost (container 475 of 512 MB), romm (703 of 768), termix (117 of 128), uptime-kuma (227 of 256, tester-1 telemetry), grafana (435 of 512), immich (`immich-server` 1,665 of 2,048 during a 200-photo import), tandoor (827 of 1,024). No container was killed during the bench. Under-stated request (typical ÷ request): calcom ×4.0, adventurelog ×3.6, termix ×3.4, claper ×2.5, grafana ×2.2, komga ×2.2, docmost ×2.1, recipe-importer ×2.1, uptime-kuma ×2.1, zipline ×2.0, and 13 more ≤ ×1.8. Templates NOT changed (read-only run). | **READY** — filed 2026-10-13 | — | Raise the seven limits and the 23 requests in their templates, each through the catalog's harness; re-measure Immich with a larger library first | CC |
 | **R-1018** | Apps & catalog | P3 | **The OnlyOffice links (FileBrowser, Nextcloud) have no recorded live proof since the move to Proxmox.** `controller/internal/integrations/` holds two handlers; no audit after the Proxmox move shows a document opened from FileBrowser or Nextcloud in OnlyOffice (searched 2026-10-14). The media-app links of `15` §6 will copy this code, including its revoke-on-stop rule (`lifecycle.go:10-13`). | **OPEN** — filed 2026-10-14 | — | One live walk on a Tier-0 box: install OnlyOffice + FileBrowser, open a document, save, read it back; then stop one app and record what the link does | CC |
 | **R-1028** | Apps & catalog | P3 | **Plex's claim code can run out during the install, and the box cannot recover it.** plex.tv's code lives 4 minutes from the moment the household copies it; the clock covers the wizard, the image pull (`plexinc/pms-docker` is 351 MB, measured) and the first start. Plex reads `PLEX_CLAIM` only on its first run, and the field is `locked_after_deploy` — so a late code leaves an unclaimed server and the only way back is remove + install again. Reported by the operator during the 2026-10-14 test; on Tester 1's line the pull+start took 8.5 s and the claim worked (`audits/media-all-drives-2026-10-14/``G-auth/G3-plex-claim.txt`), so it bites on a slow line or a slow hand. **K6, 2026-10-14 night (`audits/media-drive-events-2026-10-14/``K6-1-unclaimed-plex.txt`):** an unclaimed Plex starts with no code at all, and `POST /myplex/claim?token=` on the RUNNING server reaches plex.tv (a wrong code → 500 after plex.tv's 401). So the box can pull + start first and ask for the code after: no race. A real claim needs the household's code — the morning step on the throwaway `plex-k6` on Tester 1. Narrowed 2026-10-14 night. **PROVEN 2026-10-15 morning (`K6-2-claim-after-start.txt`):** the operator's real code, given to the RUNNING unclaimed `plex-k6` → 200, `claimed` 0→1, `PlexOnlineToken` written, and the open door closed (no token → 401). `ADVERTISE_IP` was unset and the claim did not need it; whether clients find the server without it was not measurable (the throwaway had no published port). **BUILT 2026-10-15 (v0.313.0):** `after_start` field — not asked at install; the Plex page asks for the code once Plex runs and claims the running server; the gate opens only when Plex says claimed. Proven up to the code on 9201 (G5). | **NARROWED** — the dashboard claim with a real code is the last step | a household Plex code | Claim through the Plex page with a real code (G5c); then close | CC |
-| **R-1060** | Apps & catalog | P2 | **On controller 0.313.0 (the floor) the Plex claim button can never work: Plex refuses the code with 401 because the box calls it as `http://plex:32400`.** Plex's own log: „Request came in with unrecognized domain / IP 'plex' in header Host; treating as non-local" → `401 POST /myplex/claim` in 0 ms (plex.tv never asked). Measured 2026-10-15 on demo-hp 9201, two codes, the second used ~1 minute after it was made (`audits/media-build-2026-10-15/G7/G5c-claim.txt`, `G5d-claim.txt`). The K6 spike on Tester 1 called the container by its IP address and got 200 (`audits/media-drive-events-2026-10-14/K6-2-claim-after-start.txt`); the product's `plexClaim` (`felhom-controller` `internal/web/media_events.go`) uses the name, and its test replaces the call with a seam, so no test ever met a real Plex. Since 0.313.0 does not ask the code in the wizard (`after_start`), a new Plex on any box at the floor stays unclaimed and behind its setup gate — safe, but unusable. | **NARROWED** — filed 2026-10-15; the fix shipped in controller v0.314.0 (the floor since 13:11 UTC): all Plex calls by address (`mediawire.PlexURL`), red-proved against a fake Plex that refuses the name. Live on 9201 with a FAKE code through the dashboard's claim call: Plex took it as local and asked plex.tv (500 after 938 ms; before: 401 in 0 ms) — `audits/gate-restore-2026-10-15/plex9201/01-fake-code.txt`. A fifth call by name remains — the generic health probe's `GET :32400/identity` — and is harmless: `/identity` answers anyone (200 measured) | the operator's claim code | Claim 9201's waiting Plex through the dashboard with a fresh code (a watcher waits for `~/.felhom-demohp/plex-claim`); prove claimed, gate open, a stranger meets Plex's own login, one library wiring run; then close | CC |
 | **R-1029** | Apps & catalog | P3 | **Plex's folder picker shows the drives as identical „media” folders.** With one bind per drive at the same path (`/mnt/felhom-drives/<drive>/userdata/media`), the leaf of every library folder is `media`; the drive's name sits two levels up, so in Plex's picker the household sees several folders all called „media” (reported by the operator during the 2026-10-14 test on Tester 1). It conflicts with `15` §2 reason 2 (the same path everywhere). | **READY** — filed 2026-10-14 | the layout decision (STATUS D9) | Decide in `15` §2: the players (`:ro`, never linked) may get a readable path per drive (e.g. `/media/<drive label>`) without breaking the hardlink rule, which binds only the download/library apps | CC |
 | **R-1036** | Apps & catalog | P3 | **The apps page lags the catalog by two apps.** `app-catalog-felhom.eu/templates/` holds **64** apps; `/alkalmazasok` and `/en/apps` render **63** cards, one of which (`filebrowser`) is built in and not a catalog template — so **62 catalog apps are listed**. Missing: **`plant-it`** and **`wger`**, both in the catalog since 2026-10-06/08. Their website assets are ALREADY present (`plant-it-logo.svg` + 3 screenshots, `wger-logo.png` + 3 screenshots, renamed to the catalog slug by `a3507761`, 2026-10-08) — only the cards were never written, so this is not a new-asset job. Found 2026-10-14 while reconciling the app count for the „felhő tárhely” page, where four places said **60** and the rest said **62**. **Done in that session:** every stated count on the site set to **62** (`index.html`, `szolgaltatasok.html`, `en/services.html` were 60), which is what the apps page actually shows — so no visitor can count the cards and find the number wrong. **62 is still not the catalog's number.** **To close:** write the two cards on both apps pages (gate 15 keeps the two pages' app sets equal, so they move together), then raise every stated count 62 → 64 in the same commit. **The operator chose this split at the 2026-10-14 STOP** over doing it inside the SEO change. **2026-10-15 (R-1048):** Prowlarr's card added on both pages and every stated count 62 → 63 (the media group 19 → 20), so the site still states what it shows; the two owed cards would make it 65. **Note before writing them:** `wger` is `lifecycle: hidden` and `plant-it` `lifecycle: abandoned` — neither is offered for a new install, so a card would advertise an app the wizard refuses. | **OPEN** | — | write the `plant-it` + `wger` cards on both apps pages, then 62 → 64 everywhere, one commit | CC |
 | **R-76** | Apps & catalog | P4 | **FileBrowser-created folders break the setgid chain, and a drop-zone's mode is not stable** **MIGRATED FROM `ROADMAP.md` 2026-08-22 (R-369) — originally filed 2026-07-26, size S, roadmap state `idea (surfaced by the R-75 spike, 2026-07-26)`.** Moved verbatim; nothing added or reinterpreted. The roadmap keeps its copy as history, marked moved. | **OPEN — migrated from ROADMAP 2026-08-22, rank unchanged** **2026-10-06 night: not a catalog fix** — the setgid chain is set by the controller's FileBrowser setup; a controller row. | — | Two related findings from `audits/SPIKE-catalog-data-paths-2026-07-26.md` P3/P5, both **pre-existing** and deliberately left alone by that spike. **(a)** FileBrowser Quantum 1.3.3 creates files `0644` and folders `0755` and does **not** propagate the setgid bit — even though the entrypoint wrapper's `umask 002` really is in effect (`/proc/1/status` `Umask: 0002`). Group inheritance itself works (a file uploaded into a 2775 group-100 dir landed group 100, not the process gid 1000), so the convention's *group* half holds and only its *mode* half is lost. The consequence is proven with a control: inside a UI-created `0755` folder a gid-1000 process's file landed group **1000**, while the identical write into the 2775 parent landed group **100**. So **any folder a customer creates through FileBrowser breaks the shared-group chain one level down.** Latent today — every userdata-touching catalog app that declares an identity declares uid/gid **1000**, the same uid FileBrowser runs as, so owner permissions mask it; it bites the day a content app runs as a different non-root uid with gid 1000. The comment at `infra/infra.go:156` is right that the image ignores `-e UMASK` but does not say t | CC |