Thanks for your interest in the Minotaur reference solver. This guide covers the basics — how to file an issue, how to run the tests locally, and what to expect from the review process.
- Bugs: open a GitHub issue with a minimal reproduction (commands run, expected vs. actual). Include version info — git commit hash, Python/Node/Foundry versions, OS.
- Security vulnerabilities: do not open a public issue. See SECURITY.md for the responsible-disclosure path.
- Feature requests / design discussion: open an issue describing the use case and the constraint that motivates it. We're more likely to accept feature work that's grounded in a concrete user need than a pure idea.
-
Fork the repo and create a topic branch off
main. -
Keep PRs focused — one logical change per PR. Drive-by formatting fixes belong in their own PR.
-
Run the test suite locally before pushing:
# The solver image is built and exercised by the validator pipeline. # Locally, build the image and verify it imports cleanly: docker build -t minotaur-solver-test . docker run --rm --entrypoint python3 minotaur-solver-test \ -c "from solver import SOLVER_CLASS; print(SOLVER_CLASS().metadata())"
-
Open the PR with a description that covers: what the change does, why it's needed, what was tested.
-
CI runs on every PR; failing checks block merge.
- Match the surrounding code's style — formatting, naming conventions, comment density.
- New public APIs should have docstrings explaining the contract, not just the implementation.
- Don't add comments that narrate what the code is doing; reserve comments for why a decision was made when it's non-obvious.
By submitting a PR you agree to license your contribution under the project's LICENSE (MIT).
For day-to-day questions that don't fit a GitHub issue, the project lives in the broader Subnet 112 (Minotaur) ecosystem — see that repo's README for community channels.