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'.