| 1 | 5 | 7 | 2 | 9 | 6 | 8 | 3 | 4 |
| 8 | 9 | 2 | 3 | 4 | 5 | 6 | 1 | 7 |
| 4 | 3 | 6 | 1 | 8 | 7 | 2 | 5 | 9 |
| 7 | 4 | 1 | 6 | 5 | 2 | 3 | 9 | 8 |
| 9 | 2 | 8 | 7 | 3 | 4 | 5 | 6 | 1 |
| 3 | 6 | 5 | 8 | 1 | 9 | 4 | 7 | 2 |
| 6 | 8 | 4 | 9 | 7 | 3 | 1 | 2 | 5 |
| 2 | 1 | 9 | 5 | 6 | 8 | 7 | 4 | 3 |
| 5 | 7 | 3 | 4 | 2 | 1 | 9 | 8 | 6 |
There are two types of pull requests, moves and others.
A move must only include filling in one number in one cell in the puzzle.
- A player can only make at most one move a day.
- A player can remove any moves made by himself or herself without the above limitation.
- Moves are accepted in order of first submission.
- Conflicting moves are skipped, they can be resubmitted ASAP once fixed.
- Multiple players can submit a single joint pull requests consistent of many moves, one from each player.
All other pull requests should improve the project in some way. Explained with what changes are made, and how it makes the project better.
- Other pull requests must not include move commits. They should also preserve git blame for moves as best as possible.
- Acceptance does not follow the rule of moves.
- They can be anything else typical of any project.
- They can even change the rules, but not apply retroactively.
More details here.
There is CI integration to make pull requests more flashy.
You can run the tests locally with go test if you have go installed.
You are also welcome to add redundant tests using other languages or improve existing ones.