A room that finished plays again: the match ends, the board takes it, and the next one starts #350

match_over is a terminal phase (src/client/match.ts:88 — the state machine returns immediately once it is reached), and nothing in src/rooms/ reads it. stepRoom keeps stepping a finished world 64 times a second and sending 16 snapshots a second of a scoreboard nobody can change, until the room is empty for 90 seconds and the sweep takes it. Friends who finish a match together have no way to play another one: somebody opens a new room and reads out a new six-character code.

Verified here on a booted server: two members joined one room, took seats 0 and 1, saw each other in the roster and saw the seat handed back to the bot on leaving — all correct. The end of the match is the part nobody has written yet.

Done looks like

• [ ] A room whose match reaches match_over stops stepping the world and says so once, to everybody in it: the final score, who won, and that the next match is one press away.
• [ ] Anybody in the room can start the next one. It keeps the code, the map and the length, it reseeds the round the way POST /api/room does, everybody keeps the seat they hold, and the bots come back with their own names in the seats nobody holds.
• [ ] The result is written exactly once, by the server, before the reset — the same write #318 does, under the identity that joined — and a reset does not write a second one.
• [ ] A finished room that nobody restarts costs nothing: no world stepped, no snapshot sent, and it is swept on the existing idle rule. The pull states the measured CPU of a finished room before and after.
• [ ] A restart cannot be used as a lever: it is rate-limited per member the way the room API is, a member who is not in the room cannot send one, and a second press while a match is live does nothing.
• [ ] Tests that would fail without this, through the hub and the room with no port open: a match driven to match_over stops stepping; a restart from a member starts a round with everyone's seats kept; a restart from a stranger is refused; the result is written once across an end and a restart.

Files I expect to change

src/rooms/room.ts and its test, src/rooms/hub.ts and its test, src/rooms/wire.ts (one more thing a member can say), src/client/session.ts and its test, src/client/main.ts for the button, README.md.

Risks

• Waits on #318: the result must be written before the world it was played in is thrown away, and both touch the same moment.
• #333 splits wire.ts into two codecs; a new upstream message should land on the shape that exists when this is worked, not fork it.
• Do not reset by making a new room. The code is what the friends already told each other.

Suggested: Torque.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.