MVP

Three genres on one engine, two frontends. Mostly landed.

Genres in scope

For each genre:

• Concrete Puzzle impl with constructor that populates the constraints Vec at build time. ✅
• Propagators per RuleKind the genre uses, riding the shared Propagator engine. ✅
• FastSolver + StandardGrader end-to-end. ✅
• OR-Tools cross-check via algorithm/ortools/. ✅
• Enumerator<G> impl walking the genre’s canonical structural space, with shared EnumStop semantics. ✅
• Starter grading profile shipped as TOML, validated against the registered technique list at load time. ✅
• ASCII renderer for terminal output. ✅
• Generator: shipped for Akari; not for Slitherlink/Sudoku yet (those load from the canonical dataset).

Frontends in scope

• CLI — see the CLI chapter for the live verb set. Genre routing is hand-wired per verb (no registry).
• eframe desktop app — one window, per-genre interactive views in eframe/src/games/, plus harness/ (solve / generate / grade panels), dataset_browser.rs, and db_browser.rs. Per-genre rendering lives in each genre’s module directly; no Render trait abstraction (it’ll earn one if/when the catalog grows enough to make the overlap clear).

Explicitly out of scope, for now

• More genres: Nurikabe, Heyawake, Hitori, Tapa, Yajilin, Masyu, Hashiwokakero, Numberlink, Fillomino, etc.
• Sudoku variants beyond what the canonical importer already understands (Killer, Sandwich, Thermo, Arrow, Sudoku-X, German Whispers, Renban, Kropki, XV are partially modelled but not uniformly graded).
• Pattern-phase techniques beyond a starter handful.
• Hex / non-square substrates.
• Backward-logic refinements (clue-cover beyond the basic case).
• A Render trait abstracted across genres.
• The wasm crate, wasm-bindgen surface, and the ordo/edit page that consumes them. The wire-format work (tagged puzzle and game serialization) is in scope and described above; the WASM bindings themselves and whichever registry shape they want are what’s still to land.