R-341 check taken, and the golden-currency bypass declared

Two gates blocked the R-331 hub push. One is FIXED, one is BYPASSED, and the
difference is stated rather than blurred.

FIXED -- due-checks (R-341, 5 days overdue). The +7d measurement was TAKEN on
ep0 rather than deferred again. Precondition passed: proxy still MainPID 551655,
ps -o lstart= still 2026-08-18 09:51:04, NRestarts=0, so this is the same proxy
generation as t0 (anchor is ps, not ActiveEnterTimestamp, which reads 03:54:54Z
here -- R-346's trap).

Result: fd = 17. Not 17 more -- seventeen TOTAL, exactly the documented
baseline, against 405 at the first check. Socket histogram: one LISTEN, ESTAB 0,
CLOSE-WAIT 0.

The verdict is UNANSWERABLE, not "the upgrade fixed it". R-341 asks whether the
PBS 4.2.5-1 upgrade changed the fd slope; inside this interval we removed the
leak OURSELVES (R-344, agent 0.130.0, now live on both boxes). A slope of ~0
measures our fix, not the upgrade, and reading it the other way would credit a
changelog that was read in advance and found to contain no such mechanism. The
perturbation pre-registered for this window was Phase C at ~3%; the actual
perturbation was the removal of the entire phenomenon. Row closed as moot.

What it DOES establish is worth more than the original question: twelve days
after the R-344 fix, same proxy generation, no restart to hide behind, ep0 sits
at baseline with zero established connections. R-336's ~323-day runway concern
retires with it.

BYPASSED -- golden-currency. Controller v0.224.0 and v0.225.0 are released and
the newest golden bake carries 0.223.0, so a machine installed right now gets
neither. The gate is RIGHT. This push therefore uses `git push --no-verify`,
declared here, in hub/CHANGELOG.md, in REPORT.md and on R-242.

A BYPASS, not a waiver: the gate offers a waiver only for a release that
DELIBERATELY needs no golden, and these need one. The operator was asked and
ruled bypass-now-bake-later, on the ground that neither fix bites a day-0 box --
R-330 is a nightly false alarm about apps a new box has not installed yet, R-331
is a hub display over backups a new box has not taken yet -- and both arrive by
self-update. That ground is recorded because it is what to re-check: it does NOT
extend to a release changing first-boot behaviour.

OWED: bake a golden carrying 0.225.0 and vouch it (RUNBOOK-manual-build.md 4.1,
three-field change, MinAgent 0.129.0). Fourth bypass of this gate, and the gap
is now two releases wide rather than one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LB8FmJaGd2cyjvy6dbEjpM

REPORT.md

@@ -94,7 +94,53 @@ PENDING at the time of writing — see the follow-up commit. The two halves ship
 either order: the hub renders "unknown" for any box still on controller 0.224.0, which is correct
 rather than wrong.
 
-## 7. Not done, and why
+## 7. The push bypassed a gate, deliberately, and here is the declaration
+
+**`git push --no-verify` was used for this change.** `repo_gates.py`'s `golden-currency` gate was
+CONVICTED and it was RIGHT: controller **v0.224.0** and **v0.225.0** are released and the newest golden
+bake carries **0.223.0**, so a machine installed right now receives neither fix.
+
+**This is a BYPASS, not a waiver.** The gate offers a waiver only for a release that *deliberately needs
+no golden*; these need one. **The operator was asked and ruled bypass-now-bake-later**, on the stated
+ground that neither fix bites a day-0 box — R-330 is a nightly false alarm about apps a new box has not
+installed yet, R-331 is a hub-side display over backups a new box has not taken yet — and both arrive by
+self-update afterwards. That ground is recorded on R-242 precisely because it is the thing to re-check:
+**it does not extend to a release that changes first-boot behaviour.**
+
+**A golden carrying 0.225.0 is OWED** (`RUNBOOK-manual-build.md` §4.1; the vouch is a three-field change,
+`MinAgent 0.129.0`). This is the **fourth** bypass of this gate, and the gap it names is now two releases
+wide rather than one.
+
+**The other failing gate was fixed, not bypassed.** `due-checks` was red on R-341's `+7 d` measurement,
+five days overdue. It was **taken** during this session — see §8.
+
+## 8. R-341's overdue check was taken, and its premise did not survive
+
+Unrelated to R-331; it blocked the same push, so it was done rather than deferred. Evidence:
+`documentation/audits/evidence-r341-plus7d-2026-08-30/step1-fd-and-sockets.txt`.
+
+**Precondition passed**, which is what makes the reading interpretable: `proxmox-backup-proxy` still
+`MainPID 551655`, `ps -o lstart=` still `2026-08-18 09:51:04`, `NRestarts=0` — the same proxy generation
+as t0, so nothing restarted and re-based the count. (The anchor is `ps`, not `ActiveEnterTimestamp`,
+which reads 03:54:54Z here — R-346's trap, avoided.)
+
+**Result: fd = 17.** Not 17 more — seventeen total, exactly the documented baseline, against **405** at
+the first check on 2026-08-20. The socket histogram holds **one LISTEN and nothing else**: ESTAB 0,
+CLOSE-WAIT 0.
+
+**The verdict is "unanswerable", not "the upgrade fixed it".** R-341 asks whether the PBS 4.2.5-1
+upgrade changed the fd slope. Inside this interval **we removed the leak ourselves** (R-344, agent
+0.130.0, now live on both boxes). A slope of ~0 measures our fix, not the upgrade — and reading it the
+other way would credit a changelog that was read in advance and found to contain no such mechanism. The
+perturbation pre-registered for this window was Phase C at ~3%; the actual perturbation was the removal
+of the entire phenomenon. The question is now **moot**, and the row is closed as such.
+
+**What it does establish, which is worth more than the original question:** twelve days after the R-344
+fix, on the same proxy generation with no restart to hide behind, ep0 sits at baseline with zero
+established connections. The 388-descriptor accumulation has not returned, and R-336's ~323-day runway
+concern retires with it.
+
+## 9. Not done, and why
 
 - **No staleness verdict on the card.** `monitor.OffsiteChecker` already owns that and alarms on it. A
   second verdict over the same data is two things that can disagree — a shape this codebase has already

documentation/audits/evidence-r341-plus7d-2026-08-30/step1-fd-and-sockets.txt

@@ -0,0 +1,14 @@
+=== R-341 +7d check (taken late: 2026-08-30, due 2026-08-25) ===
+MainPID=551655
+ps lstart: Tue Aug 18 09:51:04 2026
+NRestarts=0
+ActiveEnterTimestamp=Tue 2026-08-18 03:54:54 UTC  # R-346: NOT the anchor
+fd_count=17
+now_utc=2026-08-30T16:40:43Z
+--- ss -lnt sport :8007 ---
+State  Recv-Q Send-Q Local Address:Port Peer Address:Port
+LISTEN 0      1024               *:8007            *:*   
+--- socket state histogram ---
+      1 LISTEN
+--- agent-side check: who holds connections now ---
+Recv-Q Send-Q Local Address:Port Peer Address:PortProcess

hub/CHANGELOG.md

@@ -1,5 +1,15 @@
 ## v0.109.0 — the Backup card told every operator that every customer had no backups (2026-08-30, R-331)
 
+> **This push used `git push --no-verify`, and that is declared here rather than worked around.**
+> `golden_currency_gate.py` was CONVICTED: controller v0.224.0 and v0.225.0 are released and the newest
+> golden bake carries 0.223.0, so a machine installed right now receives neither. **A bypass, not a
+> waiver** — the gate offers a waiver only for a release that *deliberately needs no golden*, and these
+> need one. The operator ruled bypass-now-bake-later, on the ground that neither fix bites a day-0 box
+> (R-330 is a nightly false alarm about apps a new box has not installed; R-331 is a hub display over
+> backups a new box has not taken) and both arrive by self-update. **A golden carrying 0.225.0 is
+> OWED** — tracked on R-242 in `documentation/backlog/OPEN-ITEMS.md`, which also records that this
+> ground does not extend to a release changing first-boot behaviour.
+
 ### R-331 — `Snapshots 0` over a repository holding 67
 
 The customer page's **Backup** card read `Snapshots 0 · Repo Size 0 MB · Integrity Unknown` for