Slice 4 shipped (R-448/R-443/R-439 CLOSED, proven live); R-472..R-476; the floor-between-bakes claim corrected

Controller v0.237.0-v0.238.1: the Update button is a guarded job — refusals, backup-first when the
proven Tier-2 copy is stale, safety dump, pin, pull (pin back on failure), health, HOLD on failure.
Proven live on demo-hp: A, B, E, F, H and the restore walk (audits/slice4-2026-09-13/).

Correction to this morning's pages: between golden bakes the hub HOLDS a floor above the vouched
golden, so a release does not reach the fleet by floor (R-472, operator decision). Corrected in the
runbook, STATUS, CONTEXT, R-468 and the gate docstring.

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

scripts/golden_currency_gate.py

@@ -81,9 +81,10 @@ What happened between 2026-08-07 and 2026-09-01: **25 goldens in 26 days**, almo
 because this gate trips on every release by design (see WHY VERSION AND NOT BEHAVIOUR) and the only
 honest ways past it were a bake or a `--no-verify`. Thirteen bypasses were counted by 2026-09-01
 (R-404/R-417). The operator ruled on 2026-09-13: **bake on a cadence — weekly, and always before any
-drill or fresh install — not per release.** Every release still raises the FLOOR, so the fleet keeps
-getting each release in ~20 s; only the golden, which protects a fresh install and nothing else,
-moves to a cadence.
+drill or fresh install — not per release.** The ruling assumed every release would still raise the
+FLOOR and reach the fleet in ~20 s. CORRECTED THE SAME DAY (R-472): the hub HOLDS a floor above the
+vouched golden, so between bakes a release reaches the demo boxes only by hand-deploy. This gate's
+behaviour is unaffected — it reads the bake record, not the fleet.
 
 The mechanism is a small tracked file, `documentation/tests/golden-waiver.yml`: