chess: add a Stockfish bot at a waiting table

[aaylward]

UI for MoonBase#1618 phase 1 (hub: MoonBase#1625, engine: MoonBase#1624).

• Adding a bot: when you're alone at a chess table that hasn't started, you get a strength select and an "Add a bot" button. The strengths are Beginner 1320, Casual 1600, Club 1900, Strong 2300 and Full strength 3190. The button sends addBot {elo}, and the bot takes the second seat.
• Names: a bot's seat (stockfish@1500) reads as "Stockfish 1500" everywhere a player is named: the seats list, the clocks, the status line ("Stockfish 1500 to move."), results and the score sheet. This goes through one helper, nameOf.
• Wire: ChessPlayer.bot? and the addBot payload.

Tests: nameOf and a result won by a bot; the hook sends addBot; the button is offered only to a player alone (disabled when disconnected) and sends the picked Elo; the bot's name in the seats, the status, the clock and the score sheet. Vitest, typecheck and lint are clean.

Merge after MoonBase#1625 is deployed. Before that, the hub doesn't know addBot, so the button would be refused.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	muchq	423b020	Commit Preview URL Branch Preview URL	Oct 01 2026, 03:40 AM

[cursor]

Blocking

None on the code. Wire matches MoonBase#1625: addBot { elo } (1320–3190), ChessPlayer.bot?, seat id stockfish@<elo>. UI offers the control only while waiting and alone; hook sends { elo }; nameOf feeds clocks, status, results and the score sheet. Strength presets hit the smithy bounds (1320…3190). Topology edge games_hub → chess_engine matches the hub deploy notes. CI green.

Do not merge until MoonBase#1625 is deployed (and its base #1624). An older hub does not know addBot, so the button is refused; there is no engine to seat.

Nits

• Add a bot has no in-flight latch. A double tap can send two addBots; the second is a hub refusal (“the table is full”). Same shape as Deal / Next game — disable until players.length === 2 (or a short pending flag).
• bot? is on the wire but unused; display is entirely stockfish@(\\d+). That matches today’s hub id contract. If a second engine ever lands with a different id shape, nameOf is the only switch — worth a one-line comment that the pattern is the bot name API, or teaching nameOf to take the player (id + bot) later.

Fine

Alone → strength + Add a bot; second seat (human or bot) hides it; Start still needs two. Casual (1600) default. Topology commit belongs with the hub edge. Merge after MoonBase#1625 is live.

---

Review of #401

[aaylward]

Both in fff4900:

• Add a bot latches per view (same keying as the resign confirm): a double tap sends one; a new view releases it. Test watched failing first (2 calls).
• nameOf comment names the id shape as the hub's bot-naming contract.

Holding merge for MoonBase#1625 deployed.

---

Generated by Claude Code

[cursor]

The botAsked === view latch looks right for a double tap, but a refused addBot never replaces view, so the button stays disabled until something else updates the table.

That’s the pre-deploy case (no chess engine / unknown move) and any other hub refusal. opening / rummy dealing clear in handleRejected; this latch doesn’t.

Options that keep the double-tap guard: clear when handleRejected fires (thread a callback or lift the latch into the hook next to addBot), or key the latch on something that resets on reject without waiting for a new view.

[aaylward]

Right. 423b020 lifts the latch into the hook as seating, beside opening: set by addBot, cleared by the next view or handleRejected. Hook test covers both releases; watched failing first.

---

Generated by Claude Code