TODO: extended play verified against the running server on phoenix.local

v0.7.3:0 is installed. #35 keeps its heading — nobody has played this at a table
with humans — but the engine and server half is no longer merely compiled.

Dealt a two-seat competitive game over the HTTP API with days: 1, played it to the
end of its timetable, and watched it reach `awaitingExtension` with the official
result frozen at config.days. Voted yes; the bot followed; the game returned to
active with extraDays: 1 and the official outcome unchanged. Both test games were
deleted afterwards.

The carry-over claim was checked the same way rather than asserted. phoenix held
five saves before the update, one resumable; after it the resume log is identical
— same game, same 7 intents, same three refusals at the same move with the same
code.

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

TODO.md

@@ -34,9 +34,11 @@ Queued 2026-08-21, from playing the StartOS build:
 
 Queued 2026-08-22, from playing on StartOS:
 
-7. **Make "Games in Progress" readable** — nested groups rather than one run-on line per game, plus
-   sorting by name, start time or last move. Reasoning in Multiplayer below. Small, and it is the
-   action most used for actual administration.
+7. **Make "Games in Progress" readable** — **ON HOLD, 2026-08-29 (Jesse).** StartOS 0.4.0.2 is
+   expected to improve how action results are displayed, which is most of what makes this unreadable
+   — so wait and see what the platform fixes before rewriting the action around a limitation that
+   may be gone. Re-open it against 0.4.0.2 and re-read the output before designing anything.
+   Reasoning in Multiplayer below.
 8. **Give a player a way back into a game after losing their browser** — a fresh browser is still
    locked out of a RUNNING game, even though the server knows who they are. Reasoning in Multiplayer
    below; needs Jesse's call on whether a token in a URL is acceptable. **The lobby half of this was
@@ -106,8 +108,16 @@ Queued 2026-08-22, from the v0.4.9e gameplay-testing report filed as Gitea issue
     Suppressed on the first frame, on Undo stepping back across a rollover, and on the Day the game
     ends — the outcome panel is the thing to read then.
 
-13. **Show me the other players' moves, bots included** — raised by Jesse 2026-08-22 from playing a
-    multiplayer game. Reasoning in Multiplayer below.
+13. **Watch the other players and the bots actually make their moves** — raised by Jesse
+    2026-08-22, and **settled 2026-08-29 as the harder of the two readings**: "I want to be able to
+    watch other players and bots make their moves. It's not fun to do my turn and have magic happen
+    in the background and then have to figure out what others did."
+
+    So this is not the log-legibility fix. It is the ordered, per-action presentation of everyone
+    else's turns — **the same mechanism Gitea#20 step 4 specifies for the common board**, routed to a
+    player's own screen as well. Jesse: "this relates to issue #20 and will require a lot more
+    thinking." Do not start it as a standalone piece; it wants designing with #20. Reasoning in
+    Multiplayer below.
 
 14. **INVESTIGATE: stamp the history with wall-clock time** — even if nothing displays it yet, so
     "how long did that turn take" can be answered afterwards. Reasoning in Replay / Save Games below.
@@ -215,7 +225,25 @@ Queued 2026-08-29, from building Gitea#11 and #16 (both shipped in v0.7.3, main
     the replay recorder has a `GameState`, so it is a small refactor rather than a one-line swap. Not
     done in v0.7.3 because nothing about it is player-facing and the change earns its own look.
 
-35. **Extended play has never been played at a real table.** v0.7.3 is tested — engine, server,
+35. **Extended play has never been played at a real table** — but it now works on a real server.
+    **Verified live on phoenix.local, 2026-08-29**, against the installed v0.7.3:0 rather than in
+    tests: a two-seat competitive game (one human client, one bot) was dealt over the HTTP API with
+    `days: 1`, played to the end of its timetable, and reached `awaitingExtension` on Day 2 with
+    `official = { win, winner 0, daysElapsed }` frozen at Day 1 (`config.days`) and votes
+    `[null, null]`. Voting yes as seat 0 was accepted, the bot followed as designed, and the game
+    returned to `active` with `extraDays: 1` and the official outcome **unchanged**. The tally rode
+    the Frame to the client. Both test games were deleted afterwards; the box is back to Jesse's own
+    `WHISTLE-4086` and the `FREIGHT-3230` lobby.
+
+    **The save carry-over claim was also checked rather than asserted**: phoenix held five saves
+    before the update, of which `WHISTLE-4086` resumed and three were already refused by the 0.7.2
+    deck change. After updating to 0.7.3 the log is identical — same game resumed with the same 7
+    intents, same three refusals at the same move with the same code.
+
+    **What is still untested is the part the item is named for: humans, at a table.** Nobody has sat
+    down and played a game off the end of its timetable, and the multiplayer vote has never been
+    driven through two browsers — what a second player sees while waiting on a first, and whether
+    "waiting on Carol" is legible once Carol has closed her laptop, are still unanswered. v0.7.3 is tested — engine, server,
     replay, an all-bot regression — and compiled and exercised headlessly, but nobody has sat down,
     run a game off the end of its timetable and voted. The multiplayer vote in particular has only
     been driven through `session.intent`, never through two browsers: what a second player sees while
@@ -235,6 +263,23 @@ Queued 2026-08-29, from building Gitea#11 and #16 (both shipped in v0.7.3, main
     folds a batch of events AFTER `advance` has already mutated past the moment they describe. Worth
     settling with the badge pass (#33) rather than on its own, since that is the only consumer.
 
+37. ~~**Bump the StartOS wrapper to 0.7.3.**~~ — done 2026-08-29 (`74aea24` in
+    `station-master-startos`). Submodule pinned to `v0.7.3` (`45580d8`), `current.ts` at `0.7.3:0`,
+    release notes in all five locales, `README.md` and `instructions.md` updated. No new version file
+    and no migration — the outgoing `0.7.2:0`'s `up` was empty, `versions.md`'s common case, so
+    `current.ts` bumped in place. Verified: `npm run check` clean, prettier clean, `make x86` packs
+    as `v0.7.3:0`. **NOT installed on a box and not played** — see #35.
+
+    **Unlike 0.7.2, games in progress survive this one**, and both docs lead with it. No card data
+    changed and the engine changes are additive, so every intent in a 0.7.2 save is still legal;
+    proven rather than assumed by `test/harness.test.ts`, which replays the three files in
+    `public/replays` (all recorded under an older ruleset) and asserts every intent still applies.
+
+    **The v0.7.3 tag is made locally and signed, but not pushed** — agents cannot push to
+    `origin`. Until Jesse pushes it, the tag exists only here and in the wrapper's submodule clone;
+    the recorded pin is the commit SHA, which is already on `origin`, so the wrapper is not blocked
+    on it.
+
 ---
 
 ## Replay / Save Games
@@ -713,11 +758,31 @@ Deferred while planning the server; decisions and reasoning are in `docs/archite
       is a line of text. The Division map is the one shared picture, and it shows trains on the
       Mainline, not switching inside a district.
 
-      **Not yet established: which of the two Jesse means.** "I need to see other players' moves" fits
-      both "the history panel is not telling me" (a legibility problem — the panel scrolls, a bot can
-      take a dozen actions between your turns, and nothing marks where your last turn ended) and "I
-      want to watch their railroad" (a Frame problem). Ask before building: the first is an afternoon,
-      the second is a new view.
+      **ANSWERED 2026-08-29, and it is the harder reading.** Jesse: "I want to be able to watch other
+      players and bots make their moves. It's not fun to do my turn and have magic happen in the
+      background and then have to figure out what others did." So the complaint is not that the
+      history panel is hard to read — it is that the moves are not WATCHABLE. Marking the log is a
+      consolation prize, not the fix.
+
+      **This is Gitea#20 step 4, pointed at a player's screen instead of the common board.** That
+      issue — the public common-board display published into Jitsi — already specifies the mechanism,
+      and `docs/plans/jitsi-common-board.md` §"Step 4 — Preserve individual human and bot actions"
+      has the design: a display-step collector inside `GameSession` that captures a projected frame
+      after EVERY successful `submit()`, human and bot alike, deltas it, and emits one step per
+      accepted intent (not one per `GameEvent` — an intent drains automatic work behind it, and the
+      event list is not a complete reducer).
+
+      **The reason it is not simply free once #20 lands** is that the plan deliberately stops short
+      of here: *"Keep player pushes unchanged: players still receive the final coalesced result after
+      all immediately due bots finish."* Extending the step stream to seated players raises questions
+      the common board never has to answer — a spectator can be a second behind, a player waiting to
+      act cannot; and a player animating three bot turns while their own move is due is a game that
+      feels slower, which is the opposite of the complaint. **Jesse, 2026-08-29: "this relates to
+      issue #20 and will require a lot more thinking."** Design it with #20; do not start it alone.
+
+      **The constraint below still binds either way**, and hardest here: the common board is seatless
+      and shows only public state, whereas a step stream sent to a SEATED player is a Frame, and
+      Frames are redacted per seat.
 
       **The constraint on the second**, and it is the one that must not be got wrong: a district's
       BOARD is public — cards on the table, cars standing on them, trains — and a player's HAND,
@@ -784,8 +849,14 @@ Deferred while planning the server; decisions and reasoning are in `docs/archite
       not yet decided whether a token in a URL is acceptable; the alternative is a bare token
       pasted into a field, which is uglier and stays out of history.
 
-- [ ] **The StartOS "Games in Progress" action is one long unreadable run-on per game.** Raised by
-      Jesse 2026-08-22 after using it against four games. Lives in the WRAPPER repo
+- [ ] **The StartOS "Games in Progress" action is one long unreadable run-on per game.**
+      **ON HOLD, 2026-08-29 (Jesse): StartOS 0.4.0.2 should make action displays better.** The
+      diagnosis below is that the action-result view collapses newlines — which is exactly the sort
+      of thing a platform release fixes. Re-read the real output on 0.4.0.2 before building anything;
+      the nested-group rewrite may turn out to be unnecessary, and designing around a limitation that
+      has just been lifted is worse than waiting.
+
+      Raised by Jesse 2026-08-22 after using it against four games. Lives in the WRAPPER repo
       (`station-master-startos`, `startos/actions/gamesInProgress.ts`), whose `AGENTS.md` says work
       belongs in issues on that repo rather than a `TODO.md` — recorded here because this is where
       the project's list actually is; move it if that policy is meant to bind.