diff options
| author | Scott Gasch <[email protected]> | 2026-09-04 09:33:50 -0700 |
|---|---|---|
| committer | Scott Gasch <[email protected]> | 2026-09-04 09:33:50 -0700 |
| commit | 1cfc6859fc0dfa9d3094213e2604f791513cc278 (patch) | |
| tree | ad044b7b1e7127df8221f3821e62336af911e623 /src/genetic/GeneticProcess.java | |
| parent | cc83e8d355c7adadfbd09228b76eecbaf1c6d53c (diff) | |
Add move-generation bitboard migration scoping doc (planning only)
Drafted after GetAttacks's migration landed, to evaluate extending the
same bbPieces/bbPawns/ray-table substrate to generate.c's seven
piece-type move generators. Kept as a separate document from
MIGRATION.md rather than a new section there, same reasoning as
dropping CountKingSafetyDefects from that plan: this is a
substantially bigger, higher-risk surface (7 functions, ~3400 lines,
no existing reference implementation to diff against, and the
pseudo-legal over-generation contract is load-bearing -- a bitboard
rewrite that accidentally becomes more legal-aware is a silent
behavior change, not a free improvement).
Covers: per-function rollout plan (knight/king first as
lowest-risk/best-precedented, rook/bishop as the real segment-marking
design work, queen mechanical once those land, pawns last and
possibly not worth it), a stronger correctness gate than GetAttacks
had (perft node-count matching against externally-known-correct
numbers, not just internal self-consistency), and a confirmed (not
just flagged) scope gap: _GenerateEscapes, the in-check move
generation path, has its own independent mailbox implementation and
is not covered by the seven piece-type functions this plan targets.
No code changes -- planning only.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Jntky4yGUTyQVaGCXms4F2
Diffstat (limited to 'src/genetic/GeneticProcess.java')
0 files changed, 0 insertions, 0 deletions
