A refresh does not cost you your seat: a member is their session, and a dropped socket holds the body for a few seconds #317

Reload the page in a room and you lose the round. src/server.ts builds the member id at the upgrade as ${session}.${crypto.randomUUID().slice(0, 8)} — a new id every connection — so the “already here” branch at the top of join in src/rooms/room.ts can never fire: the reload is a stranger, the bot takes your money, your guns and your position back, and you are seated wherever freeSeat next points — or refused, if ten seats are held. A train going into a tunnel costs the same.

Done looks like

• [ ] A member is their session: the id handed to join is the session cookie's value and nothing else, so the reconnect path that is already written in join actually runs.
• [ ] One session is one seat: a second socket for a session replaces the first, and the first is closed with a sentence rather than left holding a body. A test opens two sockets on one session and asserts one seat and one live connection.
• [ ] A dropped socket does not immediately vacate: the seat is held for a stated grace (a number in src/rooms/hub.ts with a sentence — long enough for a reload and a tunnel, short enough that a leaver does not hold a seat out of a round), during which the body is driven by its bot brain rather than standing still, and the room's roster shows it as away.
• [ ] Coming back inside the grace is the same body: same seat, same money, same weapons, same position, same score. After the grace the bot keeps it under its own name, exactly as leave does today.
• [ ] The caps still mean what they say: a room's member cap counts seats held — live and in grace — so a held seat cannot be handed to a stranger and cannot be double-counted; SILENT_MS and IDLE_MS are reconciled with the new number in one place, and the interaction is stated.
• [ ] Tests in src/rooms/rooms.test.ts that fail today: reconnect within the grace keeps the seat and the money; after it the seat is a bot's again; two sockets on one session hold one seat; a full room still refuses a new session with the sentence it already has.
• [ ] bun test green, and the README says what a reload and a dropped connection do.

Files I expect to change

src/server.ts (the id at the upgrade), src/rooms/room.ts (a member that can be away), src/rooms/hub.ts (the grace, the sweep, the counting), src/rooms/rooms.test.ts, README.md.

Risks

Two tabs on one machine share a cookie and therefore a seat — that is the right rule, and the page has to say it rather than silently closing the first tab's game. A held seat is a body a bot is driving while its owner is gone: the grace has to be short enough that this is not how people farm a round. This waits on the side-picking issue because both change join/freeSeat; landing them in the wrong order is a conflict in the one function that decides who sits where.

Suggested: Torque — server-side bookkeeping with the numbers and the rule stated.

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.