Build your own Minesweeper.

# Build an original game inspired by Minesweeper

You are an experienced game designer and gameplay engineer. Build a working, polished MVP from the brief below. Implement the core journeys end to end; a static mockup is not sufficient. Inspect the current environment, make sensible implementation decisions, and get started. Ask a question only if a missing answer genuinely blocks implementation.

Starting platform: Web. Explicit customized Product & audience and Tech stack requirements take precedence over this starting target.

## Product & audience
Build an original browser mine-clearing puzzle called Clearfield. Players uncover a grid using neighbor counts and flags while avoiding hidden hazards. Use Minesweeper as a timeless rules reference and create original icons, theme, and instruction wording. The initial version offers three bounded board sizes and a safe first reveal.

## Design
Use a clean original board with visible reveal/flag mode, remaining-flag counter, timer, pause, and restart. Support right-click or a flag-mode button on touch devices, plus keyboard grid navigation. Use readable numbers, shapes, and accessible cell labels; a pause overlay hides the board and stops the timer.

## Features
1. Generation: delay mine placement until the first reveal and exclude that clicked cell and its neighbors. Use a seeded generator, enforce board/mine-count limits, and define whether the remaining board may require guessing.

2. Reveal: reveal a safe numbered cell or flood connected zero regions and their numbered boundary iteratively. Never reveal a flagged cell during flood expansion, and avoid recursion overflow on larger empty boards.

3. Flags and chording: toggle flags only on hidden cells. Optionally chord a revealed number when the adjacent flag count matches it; incorrect flags may cause loss, so document the behavior and apply the reveal atomically.

4. Outcomes and controls: win when every non-mine cell is revealed, regardless of flags; lose on a revealed mine. Pause/resume, reset a seeded practice board, and start a new run with confirmation. Start the timer on the first reveal.

5. Persistence: save generated mine positions, revealed cells, flags, elapsed active time, and status after each action. Reload resumes paused; keep records by difficulty and allow validated save export/import.

## Tech stack
Use TypeScript with a deterministic rules module independent of board rendering and an injectable seeded generator. Represent cells as indexed grid coordinates, precompute neighbor counts, and use an iterative flood queue. Local versioned storage should preserve generated boards rather than regenerating them on reload. Provide an in-memory fallback with a visible save warning.

## Data & behavior
Board {width, height, mineCount, seed, generated, mines, neighborCounts}; Session {revealed, flags, elapsedActiveMs, status, firstClick}; Records; Settings. Validate all imported counts against the actual mine layout and reject impossible revealed-state combinations.

Acceptance checks and scope:
Test safe first clicks at center, edge, and corner; flags in zero regions; correct and incorrect chord actions; victory with unflagged mines; repeated reveal idempotence; and reload. Do not promise a no-guess generator unless implemented and verified. Exclude copied Microsoft assets, online leaderboards, and unlimited board dimensions.

## Originality and assets
The named product is a reference for general workflows only. Use an original product name, visual identity, wording, layout, and assets. Do not copy proprietary code, branded logos, distinctive screens, private APIs, paid templates, or protected media. Use original or appropriately licensed sample data and assets. Build from this brief rather than scraping the reference service. Do not imply affiliation with the referenced company.

## Implementation quality
- Make every visible control work, with clear loading, success, empty, validation, and failure states. Remove controls for unimplemented features.
- Support the target platform and responsive or resizable layouts where appropriate. Use platform-appropriate accessibility semantics, labels, keyboard operation, visible focus, sufficient contrast, and reduced-motion preferences. Provide alternatives for drag-only interactions.
- Validate inputs at the relevant boundary. Treat imported or user-generated content as untrusted; render it safely. Confirm destructive actions or offer undo.
- Keep state changes reliable across navigation and reloads. Never silently lose edits. Handle persistence and network errors with an actionable message.
- Keep the scope realistic. Prioritize the complete primary journey. If a custom Features section differs from the baseline, update the data model, design, and acceptance checks to match it; explicit custom requirements take precedence over baseline assumptions.
- Provide realistic original sample content and a useful empty state. Keep sample data clearly separate from user-created data.

## Delivery and verification
1. Inspect the repository and outline the implementation in a few sentences.
2. Implement the app and connect its actual data flow. Continue until the primary journey works.
3. Run appropriate checks and test the acceptance cases above on the target platform. Verify responsive layouts and keyboard navigation when browser tools are available. For native projects, build with the available SDK and test an emulator or device when possible; report any missing native verification honestly. For games, verify the rules and gameplay loop, not only the menus.
4. Fix observed failures, then provide the runnable result, setup/run instructions, a brief explanation of what is implemented, and any specific configuration or verification limits.

This is a focused MVP. Do not add billing, AI services, or unrelated features unless explicitly requested in the brief. Start building now.