Implement the Core of Minesweeper

# Implement the Core of Minesweeper Design and implement the domain core of a Minesweeper game. It must generate a board, process player actions, reveal cells according to Minesweeper rules, and report whether play is ongoing, won, or lost. Do not implement flags. Explain how a separate user interface would interact with this core. ### Constraints & Assumptions - Board dimensions and mine count are supplied when a game is created. - Mine placement may be random, but randomness must be injectable for deterministic tests. - Revealing a mine loses immediately. - Revealing a non-mine cell shows its adjacent-mine count; a zero recursively reveals its unrevealed non-mine neighbors. - Repeating a reveal on an already revealed cell is harmless. ### Clarifying Questions to Ask - Should the first revealed cell be guaranteed safe? - Which neighbor definition applies: four directions or all eight surrounding cells? - Must games be serializable and restorable? - Can multiple clients act on one game concurrently? ### Part 1 - Domain model and generation Define board, cell, action, and game-status types, their invariants, and a testable mine-placement strategy. #### What This Part Should Cover - Valid dimensions and mine counts - Separation of hidden state from player-visible state - Injectable randomness or fixed placements - Adjacent-count computation ### Part 2 - Actions and termination Implement reveal behavior, zero-cell expansion, repeated actions, mine loss, and win detection. #### What This Part Should Cover - Bounds and terminal-state validation - Iterative flood fill - Monotonic status transitions - Efficient remaining-safe-cell accounting ### Part 3 - UI boundary and testing Define the commands and snapshots exchanged with a UI, then describe tests for correctness and failure cases. #### What This Part Should Cover - UI-independent commands and view models - No leakage of hidden mine locations - Deterministic unit tests - Concurrency or persistence boundaries if required ```hint Keep the engine independent of presentation Make the core accept actions and return player-visible state changes; inject mine placement so tests do not depend on random outcomes. ``` ### What a Strong Answer Covers - Clear state invariants and a deterministic testing seam - Correct, bounded reveal expansion and terminal-state handling - A UI contract that exposes only visible information - Edge cases, complexity, and representative tests ### Follow-up Questions 1. How would you guarantee that a player's first reveal is safe? 2. How would you persist and resume a game without exposing mines to the client? 3. What synchronization is needed if two devices reveal cells concurrently?