v0.8.0.1 — bot play was way too fast, and the last step never got its moment

Two things from the first real play on phoenix.local. One bug: busy() was
pending.length > 0, so the final step of a burst reported the queue idle the
instant it was shown — the district panel snapped back to the viewer's own board
and the countdown row vanished before either could be read.

And calibration. "Start at 1s and tune down" was applied to switching, while a
250ms action tier was invented beside it — fine for a switching burst, wrong for
the common case, since switching is not legal until there is track down. A real
early-game bot turn measured 750ms end to end. Actions are 700ms now, and
localOps.choose moved out of bookkeeping: it is the line announcing what a bot is
about to do, and at zero dwell nobody ever saw it.

The viewer's own moves now cost nothing — their board comes from their own Frame,
so holding their click only delayed the thing they wanted to watch. And pace
supports 2 and 3 as asked, bounded by MAX_PACE so a typo cannot look like a
frozen board; every tier scales together, so the weighting survives any speed.

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

src/sim/pacing.ts

@@ -37,7 +37,9 @@ export type StepKind = 'switching' | 'action' | 'phase' | 'bookkeeping';
  * 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".
+ * hundred times will want it off". **Multipliers above 1 are supported and expected** — Jesse asked
+ * for 2 and 3 explicitly after the first play — up to `MAX_PACE`, and every tier scales together so
+ * their relative weighting survives.
  *
  * 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
@@ -46,8 +48,17 @@ export type StepKind = 'switching' | 'action' | 'phase' | 'bookkeeping';
 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,
+  /**
+   * A card, a car or a load changing hands somewhere visible — and the announcement of what a
+   * player is about to do.
+   *
+   * WAS 250ms, WHICH WAS WRONG, and wrong in the way that mattered most: an early-game bot turn has
+   * no switching in it at all, so it was six steps of 250ms and 0ms — **750ms for a whole turn**.
+   * Jesse, from the first real play on `phoenix.local`: *"bot play was way too fast. I briefly saw
+   * that it was the bot's office area then their turn was done."* His instruction had been "start at
+   * 1s and tune down", and that was applied only to switching while this number was invented.
+   */
+  action: 700,
   /**
    * An automatic phase that DID something — TODO #18.
    *
@@ -107,9 +118,17 @@ export function kindOf(cause: StepCause): StepKind {
     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.
+    /**
+     * `localOps.choose` IS AN ANNOUNCEMENT, NOT BOOKKEEPING — moved out 2026-09-09 after the first
+     * real play. It is the line that reads "Player Bot 1 chose to SWITCH — six Moves to shunt cars
+     * around the yard": the heading for everything that follows, and at zero dwell nobody ever saw
+     * it, so a bot's turn began with no indication of what it was about to do.
+     */
     case 'localOps.choose':
+      return 'action';
+
+    // Ending a phase or a turn, and voting. Nothing to see: the consequences were the thing, and
+    // there are more of these than of anything else.
     case 'loadUnload.end':
     case 'draw.end':
     case 'switch.end':
@@ -119,9 +138,26 @@ export function kindOf(cause: StepCause): StepKind {
   }
 }
 
-/** How long to show one step, in ms, at a given speed. `pace` of 0 means "do not animate at all". */
+/**
+ * The widest multiplier that is a speed rather than a mistake.
+ *
+ * `pace` has no lower surprise — 0 means off — but an unbounded upper one does: `?pace=300` from
+ * somebody typing 3.00, or a corrupt `localStorage` value, would give a switching move a five-minute
+ * dwell and look exactly like a frozen board. Ten is far beyond any speed anyone would choose (2 and
+ * 3 are the ones actually asked for) and well short of unusable.
+ */
+export const MAX_PACE = 10;
+
+/**
+ * How long to show one step, in ms, at a given speed.
+ *
+ * `pace` scales every tier by the same factor, so **the tiers stay in proportion at any speed** — a
+ * switching move outlasts an ordinary action at 0.5× and at 3× alike. That is deliberate: the
+ * relative weighting is the design (a train moving is worth more attention than a card changing
+ * hands), and the multiplier is only how fast the whole thing runs. `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));
+  return Math.round(DWELL[kindOf(cause)] * Math.min(MAX_PACE, Math.max(0, pace)));
 }
 
 /**

src/web/main.ts

@@ -165,7 +165,12 @@ let session: Session;
  * on the next step instead of the next game. `?pace=` wins over the saved setting for this session
  * only.
  */
-const stepQueue = createStepQueue(() => PACE_OVERRIDE ?? settings.pace);
+const stepQueue = createStepQueue(
+  () => PACE_OVERRIDE ?? settings.pace,
+  // Whose moves not to bother replaying — this client's own. Read lazily: `session` is assigned when
+  // a game starts, long after this queue is built.
+  () => (session ? session.seat() : null),
+);
 
 /**
  * Pulls whatever the session has for us into the queue. Called on every push, before rendering.

src/web/step-queue.ts

@@ -47,14 +47,32 @@ export type StepQueue = {
   busy(): boolean;
 };
 
-/** `pace` is read on every step rather than captured, so changing the setting takes effect at once. */
-export function createStepQueue(pace: () => number = () => 1): StepQueue {
+/**
+ * `pace` is read on every step rather than captured, so changing the setting takes effect at once.
+ *
+ * `viewer` says which seat is watching, so THIS PLAYER'S OWN MOVES COST NO TIME. They are already on
+ * screen: a seated player's own board is drawn from their authoritative `Frame`, not from the queue,
+ * so holding their click for a dwell shows them nothing and delays the thing they actually want to
+ * watch — the 700ms before a bot's turn starts animating is 700ms of their own move being replayed
+ * at them. The step is still APPLIED, because the delta chain runs through it.
+ *
+ * Automatic phases have no player and are unaffected, which is what keeps TODO #18 working in
+ * solitaire where every intent is the viewer's own.
+ */
+export function createStepQueue(
+  pace: () => number = () => 1,
+  viewer: () => number | null = () => null,
+): StepQueue {
   let shown: PublicFrame | null = null;
   let last: DisplayStep | null = null;
   let pending: DisplayStep[] = [];
   /** When the step now on screen is due to give way. Null when nothing is waiting. */
   let dueAt: number | null = null;
 
+  /** How long this step holds the screen — zero for the viewer's own moves; see above. */
+  const dwell = (step: DisplayStep): number =>
+    step.player !== null && step.player === viewer() ? 0 : dwellForStep(step, pace());
+
   /** Applies one step to the displayed board. A step's delta chains off the previous step's frame. */
   const show = (step: DisplayStep): void => {
     shown = applyPublicDelta(shown, step.frame);
@@ -76,7 +94,10 @@ export function createStepQueue(pace: () => number = () => 1): StepQueue {
 
     advance(now) {
       if (pending.length === 0) {
-        dueAt = null;
+        // The LAST step of a burst still owes its dwell. Clearing `dueAt` here reported the queue
+        // idle the instant that step was shown, which snapped the district panel home before anyone
+        // could look at it — see `busy()`.
+        if (dueAt !== null && now >= dueAt) dueAt = null;
         return false;
       }
       // First step of a burst: show it immediately rather than waiting out a dwell for a board the
@@ -84,7 +105,7 @@ export function createStepQueue(pace: () => number = () => 1): StepQueue {
       if (dueAt === null) {
         const first = pending.shift()!;
         show(first);
-        dueAt = now + dwellForStep(first, pace());
+        dueAt = now + dwell(first);
         return true;
       }
       let drew = false;
@@ -97,7 +118,7 @@ export function createStepQueue(pace: () => number = () => 1): StepQueue {
       while (pending.length > 0 && now >= dueAt) {
         const next = pending.shift()!;
         show(next);
-        dueAt = dueAt + dwellForStep(next, pace());
+        dueAt = dueAt + dwell(next);
         drew = true;
       }
       if (pending.length === 0 && now >= dueAt) dueAt = null;
@@ -113,8 +134,19 @@ export function createStepQueue(pace: () => number = () => 1): StepQueue {
     },
 
     current: () => shown,
-    behind: () => pending.filter((s) => dwellForStep(s, pace()) > 0).length,
+    behind: () => pending.filter((s) => dwell(s) > 0).length,
     showing: () => last,
-    busy: () => pending.length > 0,
+    /**
+     * STILL SHOWING SOMETHING, not just still holding something back.
+     *
+     * This was `pending.length > 0`, which went false the moment the last step of a burst was
+     * shown — so the animation loop stopped and the district panel snapped back to the viewer's own
+     * board without that step ever being visible. Reported from real play: "I briefly saw that it was
+     * the bot's office area, then their turn was done and it pointed back to my office area."
+     *
+     * `dueAt` is non-null exactly while the step on screen has time left, so the two together mean
+     * "there is more to come, or what is up has not had its moment yet".
+     */
+    busy: () => pending.length > 0 || dueAt !== null,
   };
 }