A mistyped room code says so: the room door's refusals reach the page #341

src/server.ts:909 answers an upgrade for an unknown room with 404 no room with that code — it may have been idle too long, and no browser can ever read it: a WebSocket handshake that fails gives the page onerror and onclose with no status and no body. Measured here against a booted server — a socket to /ws?room=ZZZZZZ closed with code 1002 and the browser's own "Expected 101 status code". So a friend who mistyped six characters is told exactly what somebody whose wifi died is told, and the four careful sentences the server writes are read by nobody.

Done looks like

• [ ] Each refusal the room's door makes reaches the page as an application close code in 4000–4999 with a short reason, rather than as a handshake the browser reports as a protocol error: no such code, the room is full, too many connections from here, and a code that is not six characters — the ones the server already tells apart.
• [ ] src/client/session.ts turns each code into the sentence a person reads, beside the code they typed. An unexplained drop keeps the sentence it says today, and a refusal does not retry forever.
• [ ] A prober is no better off than today: the same limiter in front, no new endpoint, no listing of rooms, and a reason that names nothing but the code the caller already had. The pull states what one wrong guess costs and what a thousand cost.
• [ ] A plain GET or HEAD of /ws is still the app's own 404, and no other response changes.
• [ ] Tests that would fail without this, in the suite that boots the real server (#335's): a socket against an unknown code closes with that code and that reason; a room at capacity closes with its own; a Standing built from each says the sentence a person reads.

Files I expect to change

src/server.ts — or src/rooms/serve.ts if #338 has landed first — src/rooms/hub.ts, src/client/session.ts and its test, src/server.test.ts.

Risks

• Answering with a close code means accepting a socket in order to refuse it. Keep the window small, keep the limiter in front of the accept, and say in the pull what an accepted-then-closed socket costs.
• #335 pins these doors as they are and should land first, or its assertions and this change collide.
• #338 moves the same code into its own module. Whichever is second rebases; neither rewrites the other's tests.

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.