Skip to content

mcts-cpu-validate

mcts-cpu-validate is a 15x15 self-play and MCTS experiment project built around a simplified Go-like ruleset. The project does not try to reproduce a full Go referee. Its job is to keep a long-running training loop inspectable, restartable, measurable, and easy to replay from saved data.

Docs site:

  • GitHub Pages: https://billzi2016.github.io/mcts-cpu-validate/

Core route

The project keeps one main route:

  • Rust handles rules, bitboard operations, MCTS, self-play workers, and game record generation.
  • Python handles orchestration, PyTorch residual CNN training, checkpoints, metrics, and tooling.
  • MPS and CUDA only change the PyTorch training device. They do not switch the model family.
  • Hardware differences are expressed through configuration, worker counts, affinity, and training device selection.

The model does not silently downgrade itself. If you want a smaller model, different batch size, or different GPU usage, change configs/*.toml explicitly.

SDD

This project uses Spec-Driven Development.

Before implementing anything, read:

  • AGENTS.md
  • specs/00-project-principles.md
  • the spec files related to your task
  • specs/tasks.md

If code and spec disagree, treat the code as wrong until proven otherwise. If a requirement changes, update the spec first.

Operations and configuration

Primary operations guide:

  • STEP_BY_STEP_GUIDE.md

Configuration reference:

  • CONFIGURATION.md

Data directory

Run outputs must be written under:

data/runs/<run_id>/

Do not create long-lived top-level data/checkpoints/, data/games/, data/metrics/, or data/plots/ directories.

Python and toolchain environment

The default training entry point ./tmux_train.sh installs uv, Rust/cargo, the Python environment, and caches under the repository-local .local/ directory. It does not write into the user's home directory or modify system locations. Training, testing, and debugging all use .local/venv/bin/python.