- Shipped
- September 9, 2026 at 3:32 AM UTC
- Author
- Kamo
- Commit
- 1826da0
The invariant added in 80aee0ee falls back to the whole allowance when `clockStages` reports no critical boundary — which happens when the clock opens critical and never changes. The loop started at five seconds, and five has a boundary at three. So did every other allowance in it. The fallback was never once executed by the suite that was supposed to cover it. Two and three seconds are in the loop now, which are the only allowances that reach it. Proven by breaking it: substituting 0 for the fallback fails with "2s allowance: the tone must not lead the colour: expected 2 to be less than or equal to 0", and restoring it goes green. Neither is a table anybody can sit at — `ACTION_SECONDS` is 30 on the server and that is the only allowance in production — so this is a future short-clock table being protected, and the comment says so rather than implying a live case. And a note on where the fallback lives, because the tempting fix is the wrong one: `clockStages` returning an empty array is the CORRECT answer for a three-second clock, not a degenerate one. Such a clock is critical from its first frame and has no transitions to arm, which is exactly what the production timers in TurnClock want to hear. Hardening that function to synthesise a boundary would have made a correct function lie in order to keep an assertion simple. The assumption that a boundary must exist was the test's, so the repair is the test's. Boundary identified by projects-81, who also corrected my account of it: their draft named a single 30-second allowance, which does have a boundary and would not have thrown. It is the generalised version that needed the fallback.