Evening 2026-10-18: fresh install proven (R-1148), OnlyOffice walk (R-1018), one-sign-in spike (R-1100 READY), Redis volumes (R-1117), CI rows, golden 0.331.0 baked; register 168 -> 168 (closed 6, opened R-1149..R-1154)

documentation/backlog/CLOSED-ITEMS.md

@@ -26,6 +26,17 @@
 
 ---
 
+## 2026-10-18 (evening) — a fresh install from scratch, OnlyOffice saves, Redis without a volume, CI mail link (controller v0.331.0, catalog `30eea97`)
+
+| Row | What | Closed | Evidence |
+|---|---|---|---|
+| **R-1148** | **Installer 1.34.0 is published (operator yes, 2026-10-18) but its default path has not run on a fresh install.** Step 4b now vaults FIRST, then sets the password, then checks a PVE login (R-1145); the SC2066 loop became an `if`. Proven: the harness (52/0, the R1145 cases run the real step with fake commands), `test_hostinstall.py` 40/0, a real `--rotate-recovery-only` on demo-hp (vault time moved, new value 200, old 401). Not proven: a whole fresh install on a machine, where step 4b runs inside the full sequence and `https://127.0.0.1:8006` must answer during it. (P3) | CLOSED 2026-10-18 — **proven on a fresh install:** VM 9302 on demo-hp from the public ISO 1.29.0, which fetched installer **1.34.0** at run time; throwaway customer Tester4 (the operator's). Step 4b in the full sequence: „vaulted at the hub (stored) — now setting it” → chpasswd → „[OK] … the PVE login takes it”, 18:03:43 UTC, the hub's `host_recovery.set_at` the same second; CC's own PVE login from DooPlex: vaulted value 200, the installer's value 401. The manifest named the vouched agent 0.159.2 and golden 0.329.0 (sha-verified); the box came up on 0.329.0 and moved to the floor 0.330.0 by itself (`initiated_by: auto-floor`) 2 min 47 s after the bind; claimed, BentoPDF installed and healthy; turned off by the household's button (deliberate). VM destroyed by name. **The operator keeps Tester4 as the standing fresh-install customer** (2026-10-18); before its next install the old host `Tester4-31fa0e` must be deleted on the Hosts page, or the enroll reuses it and skips the re-issues (memory „reinstall without deleting the host”). | `audits/newbox-2026-10-18/` |
+| **R-1018** | **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`). (P3) | CLOSED 2026-10-18 — **walked live and fixed, controller v0.331.0 (floor):** on 0.330.0 FileBrowser → OnlyOffice never loaded a document (OnlyOffice fetched the public `files.<domain>` URL: 403) and Nextcloud → OnlyOffice lost every save (`http://onlyoffice:80cache/…` — no slash); switching the link on or off left files.<domain> 502 for 3.5–4 min. Fixed: FileBrowser `server.internalUrl: http://filebrowser:80`, Nextcloud `DocumentServerInternalUrl` with its slash, the R-1126 gate after any FileBrowser restart. On rc.1 both paths open, edit, save and read back; the revoke-on-stop rule holds (no editor in FileBrowser, Nextcloud 404); the stop's outage ≈ 2 s. Each fix red-proofed. | `audits/onlyoffice-2026-10-18/` |
+| **R-1117** | **Immich's and Nextcloud's Redis keep a volume they do not need** (upstream runs both without one; queues and caches only). Deferred from R-1096 on purpose: removing a volume from the compose leaves the old volume on installed boxes, and the nightly dump / an old backup's restore for a volume the compose no longer declares is unchecked. The RDB switch (catalog `5d9450b`) already removed the full-disk danger. (P4) | CLOSED 2026-10-18 — **measured, then changed (catalog `30eea97`):** both Redis services run with `--save ""`, tmpfs `/data`, no volume. On scratch 9202 with the new shape: both apps healthy, Immich's forced metadata job ran (counter 0 → 11, 0 failed), Nextcloud `cron.php` rc 0; the nightly dump skips the dropped volume; a second-drive restore from a copy made WITH the volume succeeded and, by design, brought back that copy's compose. The old volume stays attached under the tmpfs; **a removal left it behind — fixed in controller v0.331.0** (the removal deletes volumes still labelled with the app's project; red-proofed). | `audits/redis-volumes-2026-10-18/` |
+| **R-1135** | **CI's failure mail links the run at the in-cluster Gitea address** (`http://gitea.gitea-system.svc.cluster.local:3000/...`), which a reader outside the cluster cannot open. Seen in the forced test mail 2026-10-17 (job 1997). (P4) | CLOSED 2026-10-18 — the alarm link is now `https://gitea.dooplex.hu/<repo>/actions/runs/<GITHUB_RUN_ID>` in all four workflows (felhom.eu `1fe9f848`, controller `615940d`, agent `79ba884`, catalog `c97eb1c`). The run NUMBER was a second defect: Gitea 1.26 reads it as an id first and opened an unrelated run (felhom.eu runs/1116 → id 1116 = #613). Proof: forced job 2067 (catalog) at 18:46:01Z, one mail (Gmail, 18:46:02Z), link `…/actions/runs/2067`, also printed as `ALARM-LINK` in the job log. | helper evidence in the session scratchpad `p5/`; job 2067 |
+| **R-1136** | **felhom.eu CI runs take ~6.9 minutes and complete, so the 5-minute job timeout R-265 assumes does not hold there** (runs 1996, 1997; `script-tests` alone ~356 s). Found by the R-1129 proof helper 2026-10-17. (P4) | CLOSED 2026-10-18 — measured: the runner's real limit is act_runner 0.6.1's default `runner.timeout` **3 h** (`act-runner-config` sets only capacity, fetch_timeout, fetch_interval); the job-level `timeout-minutes: 5` is parsed and NOT enforced by act_runner 0.6.1 (only step-level is) — 231 felhom.eu jobs ran past 300 s and passed (longest 529 s, job 2038). `script-tests` (~7 min) is far from 3 h: no speed-up. R-265 corrected; the step-level timeout is R-1152. | act_runner v0.6.1 `config.go:128`, `act/runner/runner.go:164`, `step.go:206` |
+| **R-1137** | **A CI rerun may overwrite a failed job's log** — failure mails arrived for controller commits `c02c9d83` and `29a3ce8c` while their jobs (1944, 1959) now read green. UNPROVEN (a reading, 2026-10-17). (P4) | CLOSED 2026-10-18 — **confirmed:** a rerun replaces the job record the `jobs` endpoint shows (same id, `run_attempt` 2, the rerun's conclusion and log); the first attempt survives only as a task in `actions/tasks` (`status` failure) and its log is not readable by the API (controller job 1944 = tasks 1962 fail + 1964 ok; 1959 = 1978 fail + 1980 ok). The pull check in felhom.eu `CLAUDE.md` now reads `actions/tasks` when `run_attempt` > 1 (`b9b56c47`). A scratch-repo red run was not possible: the admin token lacks `write:user` and push-to-create is off — measured on the two real cases instead. | felhom.eu `CLAUDE.md` CI pull-check item 3 |
+
 ## 2026-10-18 (day) — hub 0.158.0 live, „anyway" restarts the apps, vault-first installer 1.34.0, the estimator's Immich figure (controller v0.330.0, agent v0.159.2)
 
 | Row | What | Closed | Evidence |
@@ -1254,7 +1265,7 @@ Nine rows closed. **Full original text: `git show <this commit>^ -- documentatio
 | **R-258** | **C3 — the customer's per-app backup tick is green on the PRESENCE of a restore point, and its only red condition is a GLOBAL one.** | **CLOSED 2026-08-08 — controller v0.210.0.** `appDumpVerdict` reads THIS app's own dump result; three states, no icon when nothing is known. **Recency deliberately not added** — see the observation in the follow-through section | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-259** | **C4 — a disk read that FAILS renders as „0.0 GB / 0.0 GB (0%)" in the nominal colour, on the dashboard's most-looked-at meter.** | **CLOSED 2026-08-08 — controller v0.210.0.** `readDiskUsage` reports success; `SystemInfo.DiskKnown`/`HDDKnown`; the template draws no figure, no percentage and no meter fill when unknown. **The hub leg is deliberately NOT fixed and is now R-266** | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-260** | **C5 — the agent reports at least eight decision-bearing facts the hub models NOWHERE, and the sharpest one blinds the check that answers „can the operator get into this box".** | **CLOSED 2026-08-08** — the class is GATED (G-1, `scripts/wire_contract_gate.py`) and the sharpest instance is fixed (hub v0.99.0). The remaining unconsumed facts are **R-264, OPEN** — allowlisted with reasons, which is not the same as decided. See the follow-through section below | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
-| **R-265** | **A CI run can fail with NO LOG PERSISTED, and the alarm mail then points the operator at a log that does not exist.** | **CLOSED 2026-08-08 — `timeout-minutes: 5` on the gates job, and the alarm mail now states elapsed seconds and qualifies its own "names itself in the run log" sentence.** ⚠ **The unknown is NOT closed and must not be read as closed:** whether the `if: failure()` alarm fires for a REAPED job is still unverified. The timeout makes the reap unreachable in practice; it does not answer what happens inside one | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
+| **R-265** | **A CI run can fail with NO LOG PERSISTED, and the alarm mail then points the operator at a log that does not exist.** | **CLOSED 2026-08-08 — `timeout-minutes: 5` on the gates job, and the alarm mail now states elapsed seconds and qualifies its own "names itself in the run log" sentence.** ⚠ **The unknown is NOT closed and must not be read as closed:** whether the `if: failure()` alarm fires for a REAPED job is still unverified. The timeout makes the reap unreachable in practice; it does not answer what happens inside one **⚠ CORRECTED 2026-10-18 (R-1136): the `timeout-minutes: 5` this row closed on has NEVER been in force.** act_runner 0.6.1 parses a job-level `timeout-minutes` and does not enforce it (only step-level is), and 231 felhom.eu jobs ran past 5 minutes and passed (longest 529 s, job 2038). The limits really in force are the runner's 3 h default (`runner.timeout` not set in `act-runner-config`) and Gitea's server-side reapers (defaults: 10 min with no task update, 3 h endless; `app.ini` not read). A hung step on a live runner runs up to 3 h. The unknown stays open: whether `if: failure()` runs for a reaped job. Step-level timeout: R-1152. | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-267** | **The Configuration page is 2.6× faster and is still ~10 s, and the remaining cost is ONE Gitea call whose latency swings 20× with load.** Shipped in 0.100.2, v0.100.0. | **CLOSED 2026-08-08 — hub v0.101.0 + a registry prune.** **Final: cold 5.4 s, warm 0.14 s** (was 26.2 s). Three serialisation legs took it to 9.85 s mean, the 60 s in-memory memo took the warm path to a quarter-second, and the prune halved what remains of the cold path. **⚠ TWO CORRECTIONS TO THIS ROW'S OWN EARLIER TEXT, because both were wrong and both mattered.** **(1) "Only 50 generic versions exist" WAS NOT A COUNT, IT WAS A PAGE LIMIT.** `?type=generic&limit=1000` returns at most 50; the 50 I measured was exactly the cap, and three older agent versions (0.81.0, 0.80.0, 0.79.0) only became visible after the first 30 deletions moved them onto page one. **An unpaginated listing is not evidence of a total** — this repo's own "an empty listing is not evidence of emptiness" rule, walked into while measuring. **(2) THE OPERATOR'S "REDUCE THE NUMBER OF ARTIFACTS" WAS THE BETTER CALL AND MY MEASUREMENT SAID OTHERWISE.** I reported it helps "sub-linearly" and "is not the lever". Measured after: trimming to 10+10 took the COLD load from 13.4 s to 5.4 s — a 2.5× improvement on the path the memo cannot help, because the fan-out is per-version. Recorded rather than quietly dropped (the R-96 standing rule). **Pruned to the newest 10 per package on the operator's rule**, with the live-vouched golden/agent/floor asserted into the KEEP set before a single DELETE was issued; 33 deletions, all HTTP 204, and golden 0.210.0 / agent 0.128.0 / agent 0.127.0 verified still fetchable afterwards. `drill-r50` runs agent 0.113.0, now deleted — flagged to the operator first; it is a disposable nested drill VM and only its re-download path is gone | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-268** | **A live per-guest local-API token was printed into a session transcript.** Shipped in 169.254.253. | **CLOSED — ROTATED + PROVEN LIVE 2026-08-09** (rehearsal pre-phase, `audits/REHEARSAL-byo-reinstall-2026-08-09.md` §3) | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-273** | **RANK 1 — the hub vouched an agent version that was never git-tagged, and every install fleet-wide now fails at step 5/8.** Shipped in 0.127.0, 0.128.0, v0.127.0. | **CLOSED 2026-08-09 — tag pushed, install PROVEN** | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |