Contribute to Dark Pawns

Read the fidelity rules, format your changes, and run the required build, static analysis, and test checks before committing.

Read the governing rulebook

Before changing player-observable behavior, read docs/fidelity/RULEBOOK.md. Its five rules govern the port:

Player-facing bytes are law.
The command surface is part of the game.
Random draws and operation order must remain deterministic.
Do not invent behavior the C game did not have.
Verify the reachable call path and audit the whole class of repeated failures.

Before editing, read the development setup guide and the repository's agent instructions for worktree, oracle, and evidence-handling rules.

Format and verify

First format the repository:

make fmt

Then run the four required Go checks separately, and check each exit status:

go build ./...
go vet ./...
go test ./...
golangci-lint run ./...

Also run the dead-code ratchet before committing:

make deadcode-ratchet

If a change exports a symbol used by tools/db-migrate, also run make db-migrate-test.

For website changes, run the site's content and build checks from the repository root:

make site-check

Work with the oracle

The src/ tree and the separate C oracle are read-only ground truth. Never repair a mismatch by editing them. Add or extend a differential scenario, prove the Go output against the reachable C function, and cite the applicable rule number in the change record.