R-404 CLOSED with the ruling; R-417 CLOSED by cause removal; R-418/419/420 filed

THE RULING WAS NEITHER OPTION AS FRAMED. Both offered answers - narrow the gate, or leave it and
write waivers - argued about the gate, and the gate was never the problem.

DIAGNOSIS, from live source: golden_currency_gate.py never looks at the push. It compares the
controller's newest CHANGELOG heading against this repo's bake evidence and returns the same
verdict whatever you are pushing - correct for a standing invariant, wrong as a push gate. And
controller_gates.py had NO golden-currency entry at all. So the repo where a release happens never
checked, and the repo that cannot create the debt was refused on every push. 18 of the last 24
pushes here touched no code - measured, and the new classifier agrees EXACTLY - most of them by
construction, because the controller's code is in one repo and its register lives in this one. SIX
of those 18 were bake records, so the push that PAYS the debt is itself documents-only: the gate
was blocking its own cure.

Not the waiver its docstring prescribes: that clause was written for a release nobody wants a
golden for. R-417 was a release we DID want a golden for, on a night the runbook forbade baking. A
waiver would have recorded a lie.

RULING: block the push that can create the debt, notify the push that cannot.

The gate's logic, exit codes and wording are BYTE-IDENTICAL. Only the consequence changed, for one
gate, on one kind of push, with a loud ADVISORY block so nothing goes quiet.

R-242's vouch half is amended in place to say it is UNTOUCHED and still open - a baked-but-unvouched
golden still passes both the gate and the new notice. Do not read R-404's closure as closing it.

FILED: R-418 - this runner's docstring listed ELEVEN gates while THIRTEEN were registered;
one-register and closed-register ran undocumented since 2026-08-24. Enumeration fixed here, the
correspondence is still unenforced. R-419 - observations_gate.py accepts an item whose body merely
CONTAINS "NOT-A-FINDING", even in prose disclaiming it; found by accident when a planted test
observation passed and my live validation proved nothing. R-420 - controller_gates.py could not
express a non-blocking gate at all before today.

Register: OPEN 171 -> 172, CLOSED 158 -> 160.

scripts/repo_gates.py

@@ -18,7 +18,20 @@ Gates, in order (all must pass; **non-zero exit on any failure**):
   8. wire-contract   every emitted field is decodable by its receiver (G-1)
   9. hub-copy        the hub's customer-facing words, against the retired-name list (R-324)
  10. due-checks      a dated check in OPEN-ITEMS.md that has come due (R-341)
- 11. observations    a REPORT.md observation with no register row behind it (R-389)
+ 11. one-register    open work living outside OPEN-ITEMS.md (R-369)
+ 12. closed-register a CLOSED row whose verdict still reads open, or an id in both (R-405)
+ 13. observations    a REPORT.md observation with no register row behind it (R-389)
+
+**THE `GATES` TABLE BELOW IS THE LIST; THIS IS A POINTER TO IT.** It drifted once already —
+it read eleven while thirteen were registered, from 2026-08-24 until 2026-09-01, so
+`one-register` and `closed-register` ran on every push while being documented nowhere
+(R-418). Add a gate here in the same commit, or delete this list rather than let it lie.
+
+SCOPE (R-404, 2026-09-01). `--scope=docs` marks a push whose whole range touches documents.
+It changes ONE thing: a CONVICTION by a gate whose fifth `exemptible` field is True — today
+`golden-currency`, and only it — prints as ADVISORY and does not refuse the push. The gate
+still RUNS and still CONVICTS; its verdict, exit codes and wording are untouched. Every
+other gate refuses every push, in every scope. An unscoped run behaves exactly as before.
 
 WHY 11 IS HERE (2026-08-24, R-389). On 2026-08-23 a session measured on live hardware that only the
 FIRST broken app per hour reaches the operator — the notification cooldown keys on the event type,