v0.5.5 — a remembered session for a game that no longer exists

Reported after updating to v0.5.4: clicking Multiplayer went straight into
a game with no lobby and no controls, and the board was blank.

Three things lined up. start() enters a remembered session WITHOUT checking
it still exists — that is what makes reconnection seamless, and it is why
the lobby was skipped. The v0.5.4 update had refused to resume that game,
its save being recorded under v0.5.3 and the engine-version check being
exact (D7). And createRemoteSession had no onerror at all, so EventSource
retried the resulting 404 forever in silence while frame stayed null and
nothing rendered. The only escape was clearing site data, and nothing on
screen said so.

v0.5.3's Manage Game -> End had just widened the same dead end: it closes
every watcher's stream, so a player whose game an administrator ended would
sit frozen on a stale board indefinitely, for exactly the same reason.

GET /api/session?token= is new: a cheap yes/no on whether a token still
names a live game. EventSource fires error identically for a transient blip
— the expected shape of a game idle for minutes (§9) — and for a 404 it
will retry forever, and exposes no status code either way, so the client
asks rather than guessing. Only a definite 404 closes the stream and
reports the game gone; a flaky network still self-heals.

The page then forgets the stored session, says why (ended by an
administrator, or the service was updated, which does not carry games
across), and drops into the lobby. Forgetting the token is what stops the
next load repeating it. It also stops rendering nothing while it waits —
"… connecting to the game" sits in the presence banner until the first push
arrives, because a page showing nothing is indistinguishable from a broken
one, which is what this looked like.

Recorded but NOT fixed, in TODO.md: three releases in a row destroyed every
game in progress, and v0.5.4's changes were rendering only. The refusal is
right, but the test is exact equality against the PACKAGE version, which
moves for reasons unrelated to the rules. Three options costed; the
recommendation is to replay the save and refuse only if an intent actually
rejects — the real question rather than a proxy for it, and a full replay
measures ~100 ms.

Verified live: /api/session answers 200 for a seated token, 404 once an
administrator ends the game, 404 for a garbage token, and /api/stream 404s
in the same state — which is the response EventSource had been retrying
silently. 673 tests pass.

CHANGELOG.md

@@ -19,6 +19,51 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
 
 ---
 
+## 0.5.5 — 2026-08-21
+
+One bug, found by updating to v0.5.4 and clicking Multiplayer: the page went straight into a game
+with no lobby and no controls, and the board was blank.
+
+### A remembered session for a game the server no longer has
+
+Three things lined up. `start()` enters a remembered multiplayer session **without checking it
+still exists** — that is what makes reconnection seamless, and it is why the lobby was skipped.
+The v0.5.4 update had **refused to resume** that game, because the save was recorded under v0.5.3
+and the engine-version check is exact (D7). And `createRemoteSession` had **no `onerror` at all**,
+so `EventSource` retried the resulting 404 forever, in silence, while `frame` stayed null and the
+page rendered nothing.
+
+The only escape was clearing site data, and nothing on screen said so.
+
+The same dead end had just been widened by v0.5.3's **Manage Game → End**, which closes every
+watcher's stream: a player whose game an administrator ended would sit frozen on a stale board
+indefinitely, for the same reason.
+
+**The fix.** `GET /api/session?token=…` is new — a cheap yes/no on whether a token still names a
+live game. `EventSource` fires `error` identically for a transient blip (the expected shape of a
+game idle for minutes, §9) and for a 404 it will retry forever, and exposes no status code either
+way, so the client asks. Only a definite 404 closes the stream and reports the game gone; a flaky
+network still self-heals as before.
+
+The page then forgets the stored session, says why — ended by an administrator, or the service was
+updated, which does not carry games across — and drops into the lobby. Forgetting the token is what
+stops the next load repeating it.
+
+It also stops rendering nothing while it waits: "… connecting to the game" sits in the presence
+banner until the first push arrives, because a page showing nothing is indistinguishable from a
+page that is broken, which is precisely what this looked like.
+
+### Recorded, not fixed
+
+`TODO.md` now carries the underlying problem: **three releases in a row destroyed every game in
+progress, and v0.5.4's changes were rendering only.** The refusal is right — a move legal under old
+rules may not be legal under new ones — but the test is exact equality against the *package*
+version, which moves for reasons that have nothing to do with the rules. Three options are costed
+there; the recommendation is to replay the save and refuse only if an intent actually rejects,
+since that answers the real question rather than a proxy for it, and a full replay measures ~100 ms.
+
+---
+
 ## 0.5.4 — 2026-08-21
 
 Six things found by playing the StartOS build, all of them about the game telling you what it