Server::serve_end plus doc::ending, wired into both of run_game's exits.
Where the browser used to get Connection refused it now gets the ending
page with the result and the final table. It serves until the page posts
'done' (the page carries a close control), with a 600s linger so an
abandoned tab cannot hold the process open.
document() split into body() and move_section() so the ending shows the
same table rather than a second rendering of it.
The control had to be built twice and the first was worthless:
the_end_of_the_game_reaches_the_browser calls serve_end directly, and
deleting the call from run_game left it GREEN -- it tested the link and
not the chain, which is CB-EV-0012's finding recurring.
a_real_game_played_to_its_end_leaves_the_ending_on_screen runs the real
play() with a browser seat, drives a real game to its end over a real
socket, and goes red under that mutation printing an empty page -- the
reported symptom exactly.
A weak assertion of mine caught by itself: the first draft grepped the
page for location.reload, which would have forced a second script to
satisfy a test rather than a requirement. It now asserts the ending
endpoint cannot answer 'ok'.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A discard pile already exists -- solution_discard on GroundState,
SolutionDiscarded removes from hand, and the page renders it. Building
one would have been building a thing that is there. What was dragged are
ACTION cards, which are not cards and are correctly never consumed;
solution cards leave the hand at Resolve because a selection is a
face-down commit.
But the report points at something real. Measured live: Investigate
draws correctly (2 -> 3 -> 4 cards), and Solve was then played three
times on problem-1 with the hand unchanged at 4 and discard empty --
because problem-1 was face down and GR-A02's resolver silently
continues. legal_commands offers Solve on every face-up problem without
consulting the hand.
Whether SOLVE should be selectable against a face-down problem or an
unmatchable suit is a game-semantics question and INTENT defers those to
ground-game. What is ours is that a provably-inert move is offered,
accepted and never accounted for. Folded into T02 as the case the log
must handle: a command that produced NO events is the one the player
needs to see.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Provenance: the maintainer reported 'after some time i get an empty page
back. I guess the game crashes or ends but that is unclear as the ui
disappears.' Reproduced by driving a real game to completion over HTTP:
move 5 accepted, then GET / -> Connection refused. The game ENDED
normally, 5 rounds and 30 commands, and its whole result -- coalitions,
scores, winners, hash -- went to the terminal. next_choice only accepts
connections inside a human decision point, so when play() returns the
listener dies and the post-ok reload is refused. A crash and a win
render identically: nothing. Same class as CB-WP-0016's silent drop.
Also carries the chaos rate change CB-EV-0015 owed to the next
declaration (d4 -> d8, second window of 12), which is what makes this
structurally M. Rolled at the old d4=3, no override, because a rate
changes when the decision lands and not retroactively.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
