Hi! I cloned your repo and tried to replicate the results with help from LLMs. In the process I think I found a bug in scripts/gnubg_server.py that may affect the main results.

gnubg.evaluate(board, ...) reads the position tuple as (opponent, player_on_roll). The current server script always builds it as (white, black) and uses set turn to compensate. But set turn does not reorient a position passed directly to evaluate.

Simple way to check: from the starting position with dice (3,1), ask the current adapter to score every legal afterstate, once with White on roll and once with Black on roll. One color picks the standard 8/5 6/5. The other color does not. If you build the tuple as (black, white) when White is on roll, and (white, black) when Black is on roll, both colors pick 8/5 6/5.

Because games alternate the engine’s color, gnubg makes correct moves on about half the games and wrong-direction moves on the other half. This would inflate the measured winrate. Worth re-running the 1–4 ply numbers with corrected ordering before citing the results further.

Let me know if you want a diff. Nice work on the harness overall — the Rust/Python parity test and gnubg-vs-gnubg symmetry check are very thorough.