R-1129: CI's failure mail was never sent (RESEND_API_KEY empty in the runner, back to 2026-09-22)

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

REPORT-tester1-limits-filebrowser-2026-10-17.md

@@ -129,16 +129,17 @@ password is never touched. Two tests, each red-proved.
 ## 6. Rows
 
 **Before 168 (this session's start).**
-- **Opened by me: 6.**
+- **Opened by me: 7.**
   - R-1123 (`reuse_refs` searches stray clones)
   - R-1124 (kept mount units)
   - R-1125 (requests, yours)
   - R-1126 (tunnel, yours)
   - R-1127 (no automatic full run)
   - R-1128 (the controller suite edits files without a lock)
+  - R-1129 (CI's failure mail was never sent — P2, yours or mine with your word)
 - **Closed: 3** (R-1022, R-1116, R-977). R-994 narrowed.
 - **Opened by the parallel cc-creds session: 5** (R-1118–R-1122).
-- **After: 176.**
+- **After: 177.**
 
 ## 7. Observations
 
@@ -153,6 +154,7 @@ password is never touched. Two tests, each red-proved.
 9. The memory index reached 202 lines and would block every push. NOT-A-FINDING: two blank lines removed and two of my lines merged (199); the gate works as meant.
 10. R-1116's felhom.eu part was already covered by `script-tests`. NOT-A-FINDING: recorded in the close.
 11. The first sync on 9201 answered 429. NOT-A-FINDING: the sync's own debounce; the next try worked.
+13. CI's failure mail fails in every failed run (back to 2026-09-22, three repos): „RESEND_API_KEY is empty". FILED: R-1129
 12. Another session's local commit carried my uncommitted register edits, and our numbers collided. NOT-A-FINDING: the shared-clone risk is known (`felhom.eu-shared-worktree` memory); fixed by renumbering mine and asking before any push.
 
 ## 8. Teardown (three layers)

STATUS.md

@@ -58,6 +58,7 @@
 | D8 | R-206 | Install DooPlex's Docker settings from git (restarts Docker), and prune the build cache weekly: yes or no? | **Yes, in a quiet window** | — | a rebuild of DooPlex still has the settings in git | — |
 | D10 | R-1125 | Raise the 23 memory requests to what the apps really use? Then an 8 GB box no longer installs the full household set (its sixth app is refused). | **Your call** — values ready | Keep: the box's install check stays optimistic | nothing changes | — |
 | D11 | R-1126 | The tunnel runs before the claim (the claim needs it). Close FileBrowser's first-start window (A), or claim only at home (B)? | **A** — small, no promise changes | B: the claim mail and flow change, the household must be at home | FileBrowser's default is open for ~2 s at its first start | — |
+| D12 | R-1129 | CI has never sent its failure mail (the key is empty in the runner since at least 2026-09-22). Set the key in the four repos? | **Yes** — you set it, or CC with your word (it is a credential) | — | a red CI run or a `--no-verify` push reaches nobody | — |
 | D9 | R-1062 | The N100's USB drive is also its whole-box backup drive. Split it in two anyway? | **No — keep one drive**; the lived-in box keeps its nightly whole-box backup | Split: the box loses its local whole-box backup (or add a second drive first) | it stays one drive; multi-drive tests stay on Tester 1 | — |
 | D10 | R-1118 | Where should CC keep its secrets, so it can use one without ever printing it? (spike 2026-10-17: the guards work; `audits/SPIKE-cc-creds-2026-10-17.md`) | **B — an encrypted file in a private Gitea repo (SOPS + age)**; then you make one empty private repo, CC cannot (its tokens lack the right) | Vaultwarden: one more service to run and back up; the spike's store test would be redone | the plain credentials file stays, and every known leak shape (sourcing it, `printenv`, curl URL echo, `kubectl get secret`) stays open | the build of the broker and guards |
 

documentation/backlog/OPEN-ITEMS.md

@@ -311,10 +311,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 — 31 rows (P3 10, P4 21)
+## Process & tooling — 32 rows (P2 1, P3 10, P4 21)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
+| **R-1129** | Process & tooling | P2 | **CI's failure mail has never been sent: every failed gate run ends „ALARM FAILED: RESEND_API_KEY is empty”, so the safety net four CLAUDE.md files promise („CI re-runs the entry point on every push and emails on failure”, R-168) does not exist.** MEASURED 2026-10-17 from the CI logs: felhom-controller jobs 1887, 1990, 1991; felhom.eu 1747, 1796, 1889; app-catalog 876, 877 (back to 2026-09-22) — all `ALARM FAILED`. `.gitea/workflows/gates.yml:192-199` reads `secrets.RESEND_API_KEY`, which is empty in the runner. A `--no-verify` push or a red CI run therefore reaches nobody. Found by the R-977/R-1116 session (a red run of its own, caused by an unpushed register row). | OPEN — filed 2026-10-17 | — | Set the Actions secret `RESEND_API_KEY` in the four repos (the operator's key, or CC with the operator's word — it is a credential), then prove one mail with a deliberately red throwaway run; correct the four CLAUDE.md sentences until it works | operator |
 | **R-1083** | Process & tooling | P3 | **The scratch box 9202 cannot use any feature that needs the agent: its `bootstrap.json` has no `local_api` block, so its controller never gets an agent client.** MEASURED 2026-10-15 (storage-identity build A): 9202 put on controller 0.317.0 by hand to show that a NAS share no longer hides the one-copy notice (R-1075); its `bootstrap.json` (read on the box) holds no `local_api`, so the controller has no agent to ask and keeps the old `st_dev` rule — the check could not tell old from new — 9202 was put back on 0.314.0. Every agent-coupled feature (drives, same-disk, format, network storage) is untestable on the scratch box today, and the NAS leg of build A is proven by a red-proofed unit test only. Evidence: `audits/storage-identity-buildA-2026-10-15/9202-upgrade.txt`. | OPEN | — | Give 9202 a local-API token the normal way (the agent mints it for its guest), or record in `runbooks/target-selection.md` that 9202 is controller-only; then show the NAS notice live. | CC |
 | **R-1081** | Process & tooling | P4 | **Two published controller tags hold content that is not what their number says: `0.315.0` and `0.316.3`.** Both were caused by CC on 2026-10-15, and both by the same shape — a guard that was not on the path the work takes. **`0.316.3`:** the build directory's `build.sh` is a symlink into the SHARED clone's working copy, which predated the `FELHOM_REPO_DIR` override, so the override was silently ignored and the build copied that tree — which held 31 uncommitted files of another session's physical-disk storage work. The banner printed `Commit: 0225255` with no `Repo:` line. **Nobody deployed it; that was luck, not a control.** Fixed at the root in controller v0.316.4: `build.sh` now refuses `--push` from a tree that is dirty, not at `origin/main`, or not a git checkout, with four test cases red-proved. **Neither tag is re-pushed or deleted** — a version number is pushed once, and that applies to numbers CC spoiled. **No box runs either:** demo-hp 9201 is on 0.317.0, the floor is 0.314.0, and the button offers the highest tag. **`0.315.0`:** 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 two tags that must never be deployed and are no longer reproducible from the registry. | **OPEN** — filed 2026-10-15; nothing to do unless someone needs one of those two images, and then the answer is the current release | — | Leave them. If an audit ever needs the real 0.315.0 or 0.316.3, build it from the matching commit 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 |