Makes recogn.c use g_iDrawScore. Some refactoring in the pawn

hash / _EvalPawn including some scoring changes.  Self-play
positive.

1 files changed, 52 insertions, 0 deletions

diff --git a/src/TODO b/src/TODO
index dce08d2..25b7214 100644
--- a/src/TODO
+++ b/src/TODO
@@ -125,3 +125,55 @@ the same way this session did. Needs a full core budget (N cores) so
 it collides with self-play match runs -- schedule it for whenever the
 box isn't already saturated by match_play.py workers, not concurrently
 with them.
+
+2026-09-18: We should experiment with more aggressive R factors for
+nullmove at deep search depth remaining levels.
+
+2026-09-18: blunders.pgn review (typhoon vs Crafty losses). Two distinct
+loss shapes, different fixes:
+  (1) "Slow grind" -- the majority of losses. Score sits near equal for
+  many moves then drifts 0.1-0.3 pawns/move in Crafty's favor with no
+  single bad move visible, compounding to -3/-4 over 20-40 moves.
+  Annotated depths run ~10-17 ply for us vs ~18-30 for Crafty the whole
+  game, consistently -- this is the NPS/depth gap compounding over time,
+  not an eval or tactics bug. Only real fix is search efficiency (nodes
+  needed per ply) or raw nps, not eval richness -- eval doesn't look wrong
+  here, it's just arriving late.
+  (2) "Cliff" losses -- a handful of moves per game where the score drops
+  3-4 pawns in one move at a suspiciously shallow depth vs the moves
+  around it (e.g. game 3, move 20: -0.5 for several moves then
+  `20. Nc4 {-4.26/12}`, depth 12 vs neighboring 20-ply reads), mostly in
+  40/60 (fast) time controls. Looks like a time-management gap, not
+  search quality: candidate fix is EBF-based "don't start ply N+1 if
+  there's no time to finish it" (cheap, Scott: "easy") PLUS a
+  root-instability-triggered "buy more time" signal for volatile
+  positions (PV changing across iterations, last iteration failed
+  high/low, score still swinging over the last few completed depths, or
+  a narrow best-vs-second-best gap) -- recognizing "this position is
+  tactically critical" from scratch is hard/rejected, but search-
+  instability is a cheap proxy already sitting in the ID loop. Not built.
+
+2026-09-18: profile a super-lazy-always (material-only Eval() exit,
+forced unconditionally, throwaway diagnostic build a la the zero-
+selection-budget move-ordering trick -- never commit it) binary against
+Crafty at matched depth/positions to find out where our nps actually
+goes once eval is ~free. Scott's educated guess is SEE and the
+is-this-move-a-check / legal-reply-to-check generators dominate once eval
+is out of the way, not eval itself -- also suspect given the earlier
+`<=`-to-`<` SEE-skip experiment on line ~4178 (skip SEE on same-piece-
+for-same-piece captures) barely changed speed but made trees fatter
+(more nodes needed), i.e. that SEE call was doing real pruning work, not
+just costing time. Before assuming check-detection costs are irreducible,
+confirm "is this move a check" is answered via O(1) bitboard AND against
+the enemy king square from the post-move attack bitboard, not via a
+generate-and-filter pass -- Scott believes he already does this "cheaply"
+but isn't sure it's the fastest available method. Single-legal-reply-to-
+check detection is likely the genuinely unavoidable cost of the three
+(needs a real legal-move count in the child position) -- worth checking
+whether it early-exits as soon as a 2nd legal move is found rather than
+generating the full list.
+
+2026-09-18: consider adding cLikelyUnstoppablePasser to the POSITION
+structure and using it to extend searches.  Just like we already do
+with cTrapped and cEnprise -- signals from eval.c to affect search.
+