v0.8.0.2 — the speed control that was only ever a URL parameter, and a Day-end

contradiction

Two things found by playing v0.8.0.1, neither in the mechanism itself.

?pace= never worked. index.html's doors are play.html?lobby and
play.html?solitaire, so arriving through the splash replaces the query string and
the play page only ever saw ?lobby — a whole game was played at 1x while believing
it was at 7x. v0.8.0 shipped that parameter as the only way to change speed and the
game's own front door destroyed it. There is a control on the play screen now,
beside zoom, persisted per viewer; the doors carry pace through as well, so the URL
lever is honest for handing two playtesters different speeds. PACE_LEVELS moved to
sim/pacing.ts with DWELL and MAX_PACE — the tuning surface in one file, and
testable. The committed default is unchanged: what it should be is a question for a
game played at a speed that took effect.

And the Day-end dialog said "0 today, 2 in all". advance.ts increments the Day and
then zeroes collisionsToday, and noteDayEnd() fires when the Day goes up — so the
dialog reporting the Day that just finished was drawn from the very frame in which
that Day's count was reset. Reproduced on four of five seeds before changing
anything. The count is captured at the rollover now; it is not derivable on the
client, because in multiplayer the push announcing the new Day is the same push
that carries the reset. And "today" was the wrong word regardless: it names the Day
instead — "Collisions: 2 on Day 1, 2 in all".

Unrelated to v0.8.0 — that one has been wrong since the dialog was built for
Gitea#10, and needed somebody to play a Day with a collision in it and then read
the summary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X6cF1iYvJ1kNmzYBzu4QX6

CHANGELOG.md

@@ -19,6 +19,78 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
 
 ---
 
+## 0.8.0.2 — 2026-09-09
+
+Two things found by playing v0.8.0.1 on `phoenix.local`, neither of them in the mechanism itself.
+
+### `?pace=` never worked, and a whole game was played at the wrong speed
+
+Jesse: *"I'm playing at pace = 7, and the bots are still moving too fast for me to follow."* At 7×
+a switching move holds for seven seconds, so that could not be calibration — and it was not. **He was
+at 1× the entire time.**
+
+`index.html`'s two doors are `./play.html?lobby` and `./play.html?solitaire`. Arriving through the
+splash therefore **replaces** the query string, and `location.search` on the play page is `?lobby` —
+so `PACE_OVERRIDE` was null and it fell back to the stored setting of 1. v0.8.0 shipped `?pace=` as
+the only way to change speed and the game's own front door destroyed it. Verified rather than
+assumed: the queue at pace 7 holds a bot's turn for 32.9s with the bot's district up for 24.5s, so
+the mechanism was right and the value never arrived.
+
+Fixed twice over, because one of them is the durable answer:
+
+- **A speed control on the play screen**, beside zoom — `− 1× +`, persisted per viewer, reading
+  through to the queue on the very next move. `PACE_LEVELS` is `0, 0.5, 1, 2, 3, 5, 7, 10`: off is
+  the first rung (TODO #18's "a player who has seen it a hundred times will want it off") and the
+  ladder reaches the speeds people actually reach for. At the top, a six-move switching turn takes a
+  full minute to watch.
+- **The doors now carry `pace` through**, so the URL lever is honest for handing two playtesters
+  different speeds — the only thing it was ever for. When one is present the control says
+  `7× (URL)` and disables itself rather than showing buttons that do nothing.
+
+`PACE_LEVELS` lives in `sim/pacing.ts` with `DWELL` and `MAX_PACE`, not in `main.ts` — the whole
+tuning surface in one file, and testable, which a constant inside the page entry point is not.
+
+**The committed default is unchanged at 1×.** What it should be is a question for a game played at a
+speed that actually took effect.
+
+### "0 today, 2 in all" — the Day-end dialog contradicted itself Jesse, at the end of a Day 1 with
+two collisions in it: *"It shows a total of two collisions, but zero today. Since we just finished day
+one, that does seem to be a contradiction."* Unrelated to v0.8.0 — this has been wrong since the
+dialog was built for Gitea#10, and nobody had played a Day with a collision in it and then read the
+summary.
+
+#### One line of ordering
+
+`advance.ts`, at the rollover:
+
+```ts
+s.clock.day += 1;
+s.collisionsToday = 0;
+```
+
+And `noteDayEnd()` fires when `f.day` goes UP — so the dialog reporting the Day that just finished is
+drawn from the very frame in which that Day's count was zeroed. It printed the *new* Day's zero beside
+a running total that could not possibly agree with it. Reproduced on four of five seeds before
+touching anything: Day 1 ended with `today=3 total=3`, and the dialog read `today=0 total=3`.
+
+**Not derivable on the client, which is why the fix is in the engine.** A Day turns over inside the
+phases that run themselves, so in multiplayer the push announcing the new Day is the same push that
+carries the reset — a client may never see the ended Day's final count to remember it. So
+`collisionsPrevDay` is captured in state at the rollover, immediately before the reset, and rides on
+the frame like the other two counts.
+
+#### And "today" was the wrong word anyway
+
+Even with the right number, a dialog headed "Day 1 has ended" should not say "today" — by then
+"today" is Day 2. It now names the Day: **"Collisions: 2 on Day 1, 2 in all."** The end-of-game
+results screen passes no Day and keeps "today", where the Day has not turned over and the word is
+accurate.
+
+`test/redaction.test.ts`'s allow-list did its job on the way through: adding a public property failed
+the suite until it was declared out loud.
+
+---
+
 ## 0.8.0.1 — 2026-09-09
 
 **Bot play was way too fast.** v0.8.0 was installed on `phoenix.local` and played within the hour;