R-1081: the registry's 0.315.0 no longer holds the 0.315.0 release (caused while proving R-1080)

The guard that makes a version number unrepeatable went into controller/build.sh in the repo. The
documented release command runs $FELHOM_ROOT/build/felhom-controller/build.sh — a SEPARATE COPY
taken 2026-07-18, with no guard. So the first thing I did with the new refusal, running it against
a real existing tag to prove it fires, rebuilt and re-pushed 0.315.0 a fourth time, now carrying
v0.316.0's code (8887343011d6 -> b809201841f7).

The root cause is the copy, and it is fixed: the build directory's build.sh is a symlink to the
repo's, the stale copy is kept beside it as build.sh.stale-copy-2026-07-18, and the refusal was
then proven to fire from the documented path. Every build this session printed porcelain=0 first,
so nothing else was built from a tree that was not clean.

No box is affected — nothing runs 0.315.0, the floor is 0.314.0, the button offers the highest tag,
and demo-hp 9201 is on 0.316.2. What remains is a tag whose content no longer matches its name, and
the row says plainly that pushing the old content back would be a fifth push of one number.

R-1080's evidence line is corrected in the same commit: it cited "the registry's current digest",
which my own re-push made stale an hour later.

Apps & catalog header corrected 15 -> 16; its own sub-counts already added to 16.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117kRTSgs3rJWUFGxyoWN6Y

documentation/backlog/CLOSED-ITEMS.md

@@ -30,7 +30,7 @@
 
 | Row | What | Closed | Evidence |
 |---|---|---|---|
-| **R-1080** | **v0.315.0 was built and pushed THREE times from three different commits, and nothing stopped it.** (P2) Every build asked the browser for `/static/style.css?v=0.315.0`, so a cache holding the first build's stylesheet — which had no `.app-tabs` rules at all — kept serving it under the address the third build still asked for. Worse in principle than the symptom: the floor and the household's button both compare VERSIONS, so a box that pulled between the first and the last runs different code under a number that is already current, and can never be told. | CLOSED 2026-10-15 — **controller v0.316.0**, in two halves. (1) `build.sh` refuses `--push`/`--multiarch` for a tag already in the registry, before building; a registry it cannot reach is a refusal too. Six cases in `scripts/test_build_push_once.sh` against the real script with a fake docker; red-proved twice. (2) every shell's stylesheet URL is a per-build tag (version + GitCommit + BuildTime), so two builds of one version cannot share a cache entry. **No box is left on a bad image:** exactly one guest ran 0.315.0 (demo-hp 9201) and it ran the registry's current digest `8887343011d6`; the floor was 0.314.0, so nothing else could have taken it. | `audits/app-page-2026-10-15b/P0/VERDICT.md`, `felhom-controller/REPORT.md` |
+| **R-1080** | **v0.315.0 was built and pushed THREE times from three different commits, and nothing stopped it.** (P2) Every build asked the browser for `/static/style.css?v=0.315.0`, so a cache holding the first build's stylesheet — which had no `.app-tabs` rules at all — kept serving it under the address the third build still asked for. Worse in principle than the symptom: the floor and the household's button both compare VERSIONS, so a box that pulled between the first and the last runs different code under a number that is already current, and can never be told. | CLOSED 2026-10-15 — **controller v0.316.0**, in two halves. (1) `build.sh` refuses `--push`/`--multiarch` for a tag already in the registry, before building; a registry it cannot reach is a refusal too. Six cases in `scripts/test_build_push_once.sh` against the real script with a fake docker; red-proved twice. (2) every shell's stylesheet URL is a per-build tag (version + GitCommit + BuildTime), so two builds of one version cannot share a cache entry. **No box is left on a bad image:** exactly one guest ran 0.315.0 (demo-hp 9201) and it ran digest `8887343011d6`, which WAS the registry's 0.315.0 when this was measured; the floor was 0.314.0, so nothing else could have taken it. That guest is now on 0.316.2. **The registry's `0.315.0` no longer holds the 0.315.0 release** — see R-1081, caused while proving this very fix. | `audits/app-page-2026-10-15b/P0/VERDICT.md`, `felhom-controller/REPORT.md` |
 
 ## 2026-10-15 (evening) — controller v0.315.0, the app page
 

documentation/backlog/OPEN-ITEMS.md

@@ -308,10 +308,11 @@ stopping line that lies.
 | **R-990** | Business & legal | P4 | **Operator: read `documentation/audits/forum-research-2026-10-12/FELHOM.md` §5 and rule on each recommendation.** READ-ONLY research 2026-10-12: three years (#7943–#11092, 2,908 posts, 195 people, 82 beginner threads) of the public PROHARDVER! topic „Home server / házi szerver építése”, tagged and counted by person (`FINDINGS.md`, method and spot-check in `METHOD.md`; no username or post text in git). Ten ranked recommendations, none acted on; the top three: a „which machine works” page (8 of 33 beginners who name their hardware own only a Synology, a router disk or a Raspberry Pi — the installer cannot run there; the same gap is R-989's first recommendation from a different source, and the shipped-page half is R-991), „you do not choose an operating system — we do” (the biggest beginner question, 20 of 82 threads), and „bring your old office PC” as the cheap entry. Catalog gap (≥ 3 people): a DLNA server (7), an ad/DNS blocker (5), a camera recorder (5). | **WAITING-ON-OPERATOR** — filed 2026-10-12 | the operator's reading | Operator: rule on each of the ten (yes / no / later). If nothing is done: nothing changes; the research ages | operator |
 | **R-1035** | Business & legal | P4 | **Did the „felhő tárhely” page earn anything? Two dated checks.** **Baseline (reported by the operator from Search Console, 2026-10-14, last 3 months):** 1 click, 48 impressions, CTR 2.1 %, average position **73.6**; „felhő tárhely” 19 impressions, „felhőtárhely” 5, „felhő alapú tárhely” 3. CC measured separately that the phrase „felhő tárhely” appeared **0 times** on the home, FAQ and backup pages — Google was showing the home page for those queries by accident. `/sajat-felho-tarhely` + `/en/own-cloud-storage` published **2026-10-14**; full baseline, price sources and the power provenance in `audits/seo-2026-10-14/BASELINE.md`. **What to measure, both times:** impressions and average position for „felhő tárhely” and „saját felhő tárhely”, plus the new page's own impressions, clicks and position. **A null result at +4 weeks means nothing on its own** — a new page on a site at position 73.6 takes weeks to months to move, and „felhő tárhely” alone is held by Microsoft, Google and the big list sites; the page aims at the two longer phrases. That is why there are two checks and not one, and why neither should be read as a verdict on the copy. **There is no Search Console connector in this project, so CC cannot read these numbers** — the operator reads them, CC records and compares. **Blocked until the operator asks for indexing** (Search Console → URL-ellenőrzés → the URL → „Indexelés kérése”): until that happens, or Google finds the page itself, both checks read zero for a reason that is not the page. **This is a slow channel and does not replace talking to people.** | **WATCHING** | operator: request indexing, then supply the Search Console read | 2026-11-11: first read (+4 weeks); 2026-12-09: second (+8 weeks), compared with the first | operator + CC |
 
-## Process & tooling — 27 rows (P3 10, P4 17)
+## Process & tooling — 28 rows (P3 10, P4 18)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
+| **R-1081** | Process & tooling | P4 | **The registry's `felhom-controller:0.315.0` no longer contains the 0.315.0 release.** Caused by CC on 2026-10-15 while proving R-1080's own fix: the guard was added to `controller/build.sh` in the repo, but the documented release command runs `$FELHOM_ROOT/build/felhom-controller/build.sh`, which was a **separate copy taken 2026-07-18** and had no guard. Running the refusal against a real existing tag therefore rebuilt and re-pushed 0.315.0 — a fourth time — with v0.316.0's code under it (digest `8887343011d6` → `b809201841f7`). **Fixed at the root in the same session:** the build directory's script is now a symlink to the repo's, the old copy kept beside it as `build.sh.stale-copy-2026-07-18`, and the refusal was then proven to fire from the documented path. **No box is affected:** nothing runs 0.315.0 (demo-hp 9201 is on 0.316.2), the floor is 0.314.0, and the household button offers the highest tag. What remains is the tag: it must never be deployed, and 0.315.0 is no longer reproducible from the registry. Deliberately NOT „fixed" by pushing the old content back — that would be a fifth push of one number. | **OPEN** — filed 2026-10-15; nothing to do unless someone needs 0.315.0's image, and then the answer is 0.316.x | — | Leave it. If an audit ever needs the real 0.315.0, build it from git tag `v0.315.0` under a NEW number and say so | CC |
 | **R-992** | Process & tooling | P3 | **The drill-catalog route that `09` §6.5 documents cannot be followed: `admin/app-catalog-drill` is PRIVATE and no box has catalog credentials.** Measured 2026-10-12 while publishing the Usenet pair: the box's clone fails with `fatal: could not read Username for 'https://gitea.dooplex.hu'` (exit 128), the Gitea API reports the drill repo `private=true` and the live catalog `private=false`, and NEITHER the current controller.yaml on 9202 NOR any of its 30 saved copies has ever carried `git.username` or `git.token` (the controller supports both — `internal/config/config.go` GitConfig). The route worked for the campaigns of 2026-10-10 and the torrent pair earlier the same day, so the repository's visibility changed between then and now. **Worked around, not fixed:** that campaign staged its two templates in the box's own catalog cache (`audits/usenet-2026-10-12/tools/stage_in_cache.py`), which is where the sync copies a catalog change anyway, with the sync interval raised to 12h for the duration and rescan used in place of sync. The real fix is an operator decision: either a read-only catalog credential on the scratch box (a secret on a Tier-0 guest) or making the drill repository readable. Until then every new-app campaign hits this. | WAITING-ON-OPERATOR | the operator's choice between a box credential and a readable drill repo | Decide; then either set `git.username`/`git.token` on 9202 from the credentials store, or flip the drill repo, and correct `09` §6.5 either way | operator |
 | **R-1017** | Process & tooling | P3 | **A comment names a guard test that does not exist.** `felhom-controller/controller/internal/appbackup/paths.go:58` says „`TestNoBareDrivePathToUserdataDir` is the guard that keeps the count from growing”; no test of that name (or `NoBareDrive*`) exists in the repo (grep 2026-10-14; positive control: `TestRemoveStack_R800_UserdataKeptIsNamed` is found). A comment asserting an invariant with no test pinning it — the class in the `felhom-testing` skill. | **READY** — filed 2026-10-14 | — | Write the guard (a test that fails when a bare drive path reaches `UserdataDir`), red-proof it, or correct the comment | CC |
 | **R-1022** | Process & tooling | P3 | **Tester 1 follows the drill catalog and carries two test drives — teardown owed (operator ruling (e), 2026-10-14).** Steps, only on the operator's word: (1) remove the test apps (Sonarr, Radarr, qBittorrent, Transmission, Plex, Jellyfin) through the dashboard WITHOUT „delete data” (R-1027); (2) decommission Media A and Media B through Tester 1's dashboard; (3) `repoint.py restore` — `controller.yaml` from `controller.yaml.pre-media-2026-10-14`, read back byte-identical, `repo_url` the live catalog; remove `drill-catalog.git` from the controller volume; (4) on demo-hp: `qm set 341 --delete scsi2,scsi3`, then delete the two volumes BY NAME (`nvme-scratch:341/vm-341-disk-3.raw`, `-disk-4.raw`) — never `qm destroy`; (5) VM memory unchanged (8192, not raised); (6) drill repo reset to live `main`. Tools: `audits/media-all-drives-2026-10-14/``tools/`. **Added 2026-10-14 night:** (4b) Media C — `qm set 341 --delete scsi4`, then the volume `nvme-scratch:341/vm-341-disk-5.raw` by name (decommission it on the dashboard first; it holds 4 test files); (7) DONE 2026-10-15: `plex-k6` and its volume removed after the claim (0 left) — the operator removes its server entry „plex-k6” from plex.tv (Settings → Authorized Devices); (8) drill commit `925f3fd` (media_c binds) goes with step 6; Prowlarr and the test drive tag „driva-a” go with step 1. Tools also in `audits/media-drive-events-2026-10-14/tools/`. **Added 2026-10-15 (media build):** (4c) Media D — decommission it on the dashboard, then `qm set 341 --delete scsi5` and the volume `nvme-scratch:341/vm-341-disk-6.raw` by name (20 GB; 2 own-bytes torrents on it); (9) Tester 1 runs controller `0.313.0-rc.3/rc.4` by hand — put the vouched release back (`/etc/felhom-controller-image`); (10) the rig's Sonarr/Radarr hold two sets of drive tags and clients (the night script's `drive-a…` and the product's `media-a…`) — they go with step 1. | **WAITING-ON-OPERATOR** — filed 2026-10-14 | the operator's teardown word | Run the six steps; quote each read-back | CC |