If you want to send a patch, here's the practical workflow.
You need a Rust stable toolchain. The GUI also needs a working desktop OpenGL stack on your machine (any modern Linux/macOS/Windows install with up-to-date graphics drivers should be fine). Then:
cargo test
cargo build --release
./target/release/focalors guiThe repo's .cargo/config.toml matches the GitHub Actions release workflow: x86_64 builds (Linux/Windows/Intel Mac) use target-cpu=x86-64-v3 (AVX2 baseline, supported by every Intel/AMD CPU from 2013 onward); aarch64 builds (Apple Silicon) use rustc defaults. Your local binary has the same instruction set as the binaries users download — what you test is what they run. Pre-2013 x86 hardware can compile from source by lowering target-cpu in .cargo/config.toml.
The NNUE training pipeline and the HCE tuner are documented in docs/TECHNICAL.md — the same commands work for contributors. There's nothing special to set up beyond what's already in the repo.
Keep changes focused. If a patch touches the engine, the GUI, and the docs all at once, it's usually easier to review (and easier to revert) when split. Add or update tests when changing search, move generation, evaluation, persistence, or analysis logic — the test suite is the cheap insurance against regressions in those areas.
The GUI is intentionally compact rather than dashboard-heavy. New features land best when they fit the existing layout instead of adding new top-level surfaces.
Don't commit secrets or anything under target/.
CI lives in .github/workflows/ci.yml. Pull requests and pushes run the test suite on Linux, macOS, and Windows. Pushing a tag of the form v* also builds release binaries for all three and attaches them to the GitHub release.
Engine work happens in src/search.rs, src/eval.rs, and src/nnue/. GUI and player experience live in src/gui.rs. Persistence and stats are in src/db.rs and src/analysis.rs. Documentation and release polish are in the root docs and .github/workflows/. Pick one and stay there.