v0.8.0 — the board replays what everyone else did, instead of arriving rearranged

TODO #13, #15 and #18 — Gitea#20 steps 2-4 pointed at a seated player's own screen.
Every accepted intent, and every automatic phase that does anything, becomes an
ordered presentation step. A bot's whole switching turn used to land in one push;
now it arrives as a run of steps, the district panel follows whoever is acting,
and a [N behind] … [Skip] row says how far the board is from the game.

Solitaire runs the same path — one collector inside submit(), which both session
kinds already funnel through — which is where its automatic phases finally get a
visible beat.

Dwell is assigned by kind: switching holds the screen, turn bookkeeping costs
nothing, and the clock turning over earns the beat. Tunable per viewer without a
rebuild, and off entirely at pace 0.

Also: switching was the one class of action logging unattributed, and now names
its train. Reasoning, measurements and the three things that turned out wrong are
in CHANGELOG.md.

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

src/sim/pacing.ts

@@ -0,0 +1,167 @@
+/**
+ * HOW LONG EACH STEP IS SHOWN — v0.8.0, `docs/plans/jitsi-common-board.md` § v0.8.0 § 5.
+ *
+ * Shared rather than living in `src/web/`, so the 0.8.1 seatless board paces identically to a
+ * player's own screen. Two views of one game that disagreed about how fast it looks would be worse
+ * than either alone.
+ *
+ * WHY BY KIND RATHER THAN BY BUDGET. The obvious scheme is to give the whole backlog a time budget
+ * and divide it by the queue length. Measured against real games, that does exactly the wrong
+ * thing. From `public/replays/`: ~60 stages per game and ~5 intents per player per stage, so a
+ * four-player table produces ~15 other-player steps per stage — but 44 of a 307-intent game are
+ * `draw.end` and 60 are `loadUnload.end`, bookkeeping nobody wants to watch, while the thing that
+ * is worth watching is rare and clustered. Two of the three published replays contain no
+ * `switch.move` at all; the third has bursts of 14, 6, 6 and 6, and `trayMoved`'s own narration says
+ * "N of 6 Moves left" because six is the engine's cap per crew. So a uniform budget spends the
+ * player's attention on `draw.end` and rushes the switching.
+ *
+ * Assigning dwell by kind and letting the total fall out costs ~40s of animation across a whole
+ * 60-stage game, against ~3.6 minutes for a flat 700ms — better switching visibility for a fifth of
+ * the time. Jesse, 2026-09-09, on what matters: *"I definitely want to watch other players struggle
+ * with the switching exercises … I don't think reading the switching in the log will be anywhere
+ * nearly as interesting as watching the trains actually move on the board."*
+ *
+ * PACING IS CLIENT-SIDE ONLY. The server emits steps as fast as it likes and the client decides how
+ * to show them, which is what keeps Gitea#20's "do not slow the authoritative game" true.
+ */
+
+import type { StepCause } from './display-step.ts';
+
+export type StepKind = 'switching' | 'action' | 'phase' | 'bookkeeping';
+
+/**
+ * THE TUNING TABLE — dwell in milliseconds per kind.
+ *
+ * Start generous and tune down by playing; Jesse, 2026-09-09: *"start at 1s and tune down."* This is
+ * the committed default and changing it needs a web rebuild, which in the `.s9pk` is a release — so
+ * it is deliberately not the only way to change the pacing. A viewer's own `pace` multiplier
+ * (`Settings`, `localStorage`) and a `?pace=` URL parameter both scale these without one, and
+ * `pace = 0` turns the animation off entirely, which is also TODO #18's "a player who has seen it a
+ * hundred times will want it off".
+ *
+ * NOT IN GAME-CREATION SETTINGS, on Jesse's call 2026-09-09: dwell is presentation, not a rule, and
+ * `config` rides along in saves and replays. If it ever moves there, the config field supplies this
+ * table's multiplier — the table, the classification and the queue do not change.
+ */
+export const DWELL: Record<StepKind, number> = {
+  /** A train physically moving on the board. The thing worth watching, and protected accordingly. */
+  switching: 1000,
+  /** A card, a car or a load changing hands somewhere visible. */
+  action: 250,
+  /**
+   * An automatic phase that DID something — TODO #18.
+   *
+   * Only reached when the phase actually narrated: `submit()` collects no step for a phase that
+   * changed nothing, so this is never spent on the empty ones Jesse is content to guess at. Between
+   * an ordinary action and a switching move, because the Mainline phase moves trains the length of
+   * the Division and is the clearest case of "stuff just happened without being able to see how".
+   */
+  phase: 600,
+  /** Turn and phase bookkeeping. Nothing moved; do not spend the player's attention on it. */
+  bookkeeping: 0,
+};
+
+/**
+ * Which kind an intent is.
+ *
+ * Exhaustive over `Intent['type']` on purpose — a `default` would silently drop a newly added intent
+ * into whatever tier the fallback names, and the failure mode is invisible (a move that never gets
+ * a beat, or bookkeeping that stalls the queue for a second). `test/pacing.test.ts` walks every
+ * member of the union so a new intent cannot land here unclassified.
+ */
+export function kindOf(cause: StepCause): StepKind {
+  switch (cause) {
+    // The Division advancing itself — New Train, the Mainline, the shift change (TODO #18).
+    case 'phase':
+      return 'phase';
+
+    // The crew and its train moving, coupling, setting out and re-ordering — §6.1 and Appendix A.
+    case 'switch.move':
+    case 'switch.dropCars':
+    case 'switch.sortConsist':
+    case 'maneuver.flyingSwitch':
+    case 'maneuver.redFlags':
+      return 'switching';
+
+    // Something visible changed hands or position, but no train drove anywhere.
+    case 'card.play':
+    case 'card.discard':
+    case 'draw.fromHomeOffice':
+    case 'draw.fromDepartment':
+    case 'newTrain.placeCar':
+    case 'newTrain.passCar':
+    case 'newTrain.secondSection':
+    case 'newTrain.startExtra':
+    case 'porter.board':
+    case 'porter.detrain':
+    case 'laborer.startLoad':
+    case 'laborer.advanceLoad':
+    case 'laborer.beginUnload':
+    case 'freightAgent.stockOutbound':
+    case 'freightAgent.clearInbound':
+    case 'freightAgent.unjam':
+    case 'mainline.clearance':
+    case 'mainline.modify':
+    case 'mainline.redFlag':
+    case 'mainline.yardOffice':
+    case 'redFlag.play':
+      return 'action';
+
+    // Ending a phase or a turn, choosing what to do, voting. The consequences are worth watching;
+    // the declaration itself is not, and there are more of these than of anything else.
+    case 'localOps.choose':
+    case 'loadUnload.end':
+    case 'draw.end':
+    case 'switch.end':
+    case 'freightAgent.end':
+    case 'game.extend':
+      return 'bookkeeping';
+  }
+}
+
+/** How long to show one step, in ms, at a given speed. `pace` of 0 means "do not animate at all". */
+export function dwellFor(cause: StepCause, pace = 1): number {
+  return Math.round(DWELL[kindOf(cause)] * Math.max(0, pace));
+}
+
+/**
+ * How long to show one STEP — the form the queue actually uses.
+ *
+ * A step that said nothing gets no dwell, whatever caused it. That is one rule covering two cases
+ * arrived at separately: a phase where nothing happened (Jesse, 2026-09-09 — *"if nothing happens
+ * during a phase then we shouldn't lose time to it"*), and a phase that only handed the turn on,
+ * which changes the board but has nothing on it to look at. Structurally typed so this file does not
+ * have to import `DisplayStep` back from the module that imports `StepCause` from it.
+ */
+export function dwellForStep(
+  step: { cause: StepCause; lines: readonly unknown[]; frame: { table: object } },
+  pace = 1,
+): number {
+  if (step.lines.length > 0) return dwellFor(step.cause, pace);
+  /**
+   * A SILENT STEP EARNS A BEAT ONLY WHEN THE CLOCK TURNED OVER — which is TODO #18 exactly: "give
+   * every phase a visible beat", for New Train, the Mainline and the shift change.
+   *
+   * Measured, because the obvious rule was wrong twice. "No narration, no dwell" looked right and
+   * silently killed #18: a phase can move trains without saying anything, and those steps were being
+   * flashed past. "Anything that changed the board" is wrong the other way: `submit()` steps
+   * `advance()` about 4.6 times per intent and most of those merely hand the turn on, so beating on
+   * all of them would cost a quarter of an hour a game. The phase turning over is the thing a player
+   * is being shown, and there are about 180 of those in a full game.
+   */
+  const table = step.frame.table as Record<string, unknown>;
+  const turned = 'phase' in table || 'phaseKey' in table || 'stage' in table || 'day' in table;
+  return turned ? dwellFor(step.cause, pace) : 0;
+}
+
+/**
+ * How many steps in a queue are actually going to be WATCHED.
+ *
+ * This is the number the "N behind" counter shows, and it is deliberately not `queue.length`. With
+ * bookkeeping dwelling at zero, a backlog of 17 where 12 are `*.end` would read "17", plummet to 5
+ * the instant it started, and then crawl — which is not the steady countdown the counter is for.
+ * Thirteen dwelling steps means thirteen things you are going to see.
+ */
+export function watchableCount(causes: readonly StepCause[], pace = 1): number {
+  return causes.filter((c) => dwellFor(c, pace) > 0).length;
+}