R-459 CLOSED (MariaDB converts itself, proven by harness + live), golden 0.236.0 (R-467), the golden waiver (R-468)

Operator rulings 2026-09-13, both shipped the same day:
- MariaDB finishes its own conversion (catalog eec1228/bd32830/3525e35). Harness E3/E3b `proven`
  with engine_state_after "already upgraded to 12.3.3-MariaDB [exit=1]", the skip line gone, C3
  still `failed`; landed on demo-hp through the real 15-min cycle, nothing recreated, one deliberate
  restart logged "MariaDB upgrade not required" with the app serving. Evidence:
  documentation/audits/r459-close-2026-09-13/. The engine-major rule + gate keep every engine
  inside its major until Slice 4 (R-448) — removal tracked as R-469.
- Goldens on a cadence, not per release. golden_currency_gate.py reads a dated waiver
  (documentation/tests/golden-waiver.yml, <= 14 days, row-bound): valid + BEHIND -> loud advisory,
  exit 0; expired -> red again naming the date; UNRECORDED (R-385) never covered; malformed -> 2,
  never 0. Tests cases 5-15 incl. the R-421 decoy; red-proof old-vs-new on the real behind tree.
  R-242's vouch half stays open. Cadence in RUNBOOK-manual-build.md §4.2 + the checklist.
- Golden 0.236.0 baked, round-tripped, vouched, floor raised 0.232.0 -> 0.236.0
  (documentation/tests/golden-0.236.0-2026-09-13/) — the last per-release bake; the waiver was
  issued AFTER it landed. No --no-verify anywhere in this session.

Rows: R-459 CLOSED, R-467 CLOSED, R-242 narrowed; R-468/R-469/R-470/R-471 opened. 09 §3 gains
decisions 5 and 6; STATUS items 11 and 12 closed; CONTEXT records the cadence ruling.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/runbooks/RUNBOOK-manual-build.md

@@ -202,8 +202,51 @@ bake's own acceptance check. The real guard was never weak: the script's own
    back is a form submission, not a rebuild.
 
 A golden is only needed when a publish train wants fresh installs current — demo deploys never need it.
+**Since 2026-09-13 the cadence is §4.2: weekly, and before any drill or fresh install.**
 The full 0.188.0 run, with the observables: `documentation/audits/tester-gate-golden-0.188.0-2026-07-31.md`.
 
+### 4.2 Cadence — goldens are WEEKLY and before any install, not per release (operator ruling 2026-09-13)
+
+**What was measured before the ruling:** 25 goldens in 26 days in August, almost one per release,
+because `golden_currency_gate.py` trips on every release by design and the only honest ways past it
+were a bake or a declared `--no-verify` (thirteen of those by 2026-09-01 — R-404/R-417). **The
+ruling:** bake on a cadence. Every release still raises the FLOOR (§4.1 step 5), so both demo boxes
+keep getting each release in ~20 s; only the golden — which protects a **fresh install** and nothing
+else — moves to a cadence.
+
+**The cadence, and it is a step in a routine, not a memory:**
+
+1. **Weekly.** Bake + vouch + raise the floor per §4.1, one golden carrying whatever is newest.
+2. **Before ANY drill or fresh install**, whether or not the week is up. A drill on a fresh install
+   with a stale golden measures the wrong controller (that is how R-120 surfaced).
+3. **The first external install retires the arrangement.** The waiver's own register row says so.
+
+**The gate reads a dated waiver** — `documentation/tests/golden-waiver.yml`, four lines:
+
+```yaml
+# documentation/tests/golden-waiver.yml — read by scripts/golden_currency_gate.py
+issued: 2026-09-13
+expires: 2026-09-27          # HARD LIMIT: at most 14 days after issued, or the gate refuses the waiver
+reason: pre-customer development; goldens on a weekly cadence (operator ruling 2026-09-13)
+register_row: R-468          # must exist as a `**R-468**` row in OPEN-ITEMS.md
+```
+
+While it is valid, a golden BEHIND the record makes the gate print a loud **ADVISORY** and exit 0;
+when it expires the gate is **red again** until someone bakes or renews. **It never covers a golden
+that is UNRECORDED** (no `## vX.Y.Z` heading — R-385): that is not a cadence choice. A waiver longer
+than 14 days, with a missing or unparseable date, an empty reason, or a row that does not exist, is
+**INCONCLUSIVE (exit 2)** — refused, and refused out loud. The cap lives in the gate
+(`WAIVER_MAX_DAYS`), not here, because a cap in prose is what failed the first time (R-242).
+
+**To issue or renew:** edit the two dates (issue = today, expiry ≤ 14 days later), keep the row,
+commit it **on its own** with a message saying why the bake is deferred, and push. Renewal is a diff
+someone can see — that is the point. **Do not issue a waiver over a bake that could be done today**;
+that is the habit the gate's docstring warns about. **To retire it:** delete the file in the commit
+that records the first external install.
+
+**What the waiver does NOT do:** it does not touch the vouch half of R-242 (still open — nothing
+gates the vouch), it does not change what the gate checks, and it does not stop the floor.
+
 ## 5. Hub (felhom.eu/hub → k3s, GitOps)
 
 **The manifest is the truth** — a built image deploys NOTHING until `manifests/hub.yaml`'s `image:`