Vision
- Refer to the vision in @docs/vision.md for this application at the start of every session. It is the through-line in all of the work done here. 

Project structure
- frontend/ and backend/ are fully separate npm packages — own package.json, own tsconfig.json, own dist/.
- Backend's only job right now: serve frontend/ as static files.

TypeScript setup
- Strict mode on in both tsconfigs.
- No bundler — plain tsc, so relative imports must use the compiled .js extension (./canvas.js) even in .ts source, for native browser ESM resolution.
- dist/ and node_modules/ gitignored in both packages.

Module style
- Namespace imports only: import * as canvas from "./canvas.js", then canvas.thing — no named imports.
- One-line file-header comment stating the module's responsibility (// ui.ts provides the translation layer...).

Code shape (functional core / imperative shell)
- Pure functions do geometry/logic (canvas.ts's layout math, ui.ts's handleClick reducer) — no DOM/canvas access, take data in, return data out.
- Impure code (drawing, event listeners) stays thin and isolated at the edges, composed on top of the pure functions.
- App state lives in one place (main.ts), passed to other modules via getState/setState closures rather than modules owning their own mutable state.

Types
- A type lives in the file that owns that concept (Piece/BoardLayout in canvas.ts, Player/BoardState in game.ts), exported for other modules to reference via their namespace import.

Naming
- When a namespace import (canvas) collides with a local variable of the same concept (an HTMLCanvasElement), the local variable gets suffixed (canvasEl), not the import.

Workflow
- Human developer gives seer a task from docs/task to design and deliver to a coder agent whot hem implements the design as specified.
- Once the implementation is complete, the implementing agent edits the task document to set the Status field to 'Complete'.