Design the class model and public APIs for a two-player chess engine core: the object graph that holds the board, the pieces, and the rules that decide whether a move is legal and whether the game is over. This is the rules kernel a UI or a network layer would drive, not the UI itself.

Operating context. Standard 8x8 chess, one game in memory, two human sides alternating turns (White moves first). The core is asked "is this move legal?" and "apply it", and must also answer "is the side to move in check / checkmate / stalemate?" after every ply. It must support the three tricky special moves — castling (king-side and queen-side), en passant, and pawn promotion — and enforce the rule that a side may never leave or place its own king in check. There is no clock, no AI opponent, and no persistence; assume a single thread drives the game loop.

Out of scope. Move search / evaluation (no engine "thinking"), opening books or endgame tablebases, network protocol and matchmaking, rendering and input, chess-clock / time control, PGN/FEN file parsing (you may reference the notation, but do not design a parser), and threefold-repetition or fifty-move draw claims.

What to produce. The class hierarchy (Board, Square, Piece and its subtypes, Move, Game, and the rule/validation seam), the public API each class exposes, and the state transitions of a game (in-progress -> check -> checkmate / stalemate / draw). Be explicit about: how each piece type contributes its own movement rules polymorphically, how a candidate move is validated against board occupancy plus the king-safety constraint, how castling / en passant / promotion are represented rather than special-cased everywhere, and how the design stays open to a new variant piece without editing existing piece classes.