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
This commit is contained in:
Jesse.Markowitz
2026-08-29 06:04:55 -04:00
co-authored by Claude Opus 5
parent 5865c3a6b7
commit 9ae8e9e09d
+19 -1
View File
@@ -225,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 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. 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, 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 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 been driven through `session.intent`, never through two browsers: what a second player sees while