The workflow

1. Branch from main.
2. Write the spec first, or at least alongside the code. A *.spec.yaml that was written after the fact tends to describe what the code does rather than what it should do, which is worth very little.
3. Every invariant in a spec names at least one test, and that test must exist and pass. make verify enforces the binding, so you cannot declare an invariant and forget to test it.
4. Run make check locally. CI runs every target make check runs (make ci-parity asserts it), plus two that make check leaves out: the recovery drill (make test-recovery-drill, which needs a regtest bitcoind) and the image build (make image-system, then make verify-image, which need Docker and Linux). A local pass can still be followed by a CI failure in those.
5. Open a pull request. Reference spec ids in the description.

Commit messages

Write what changed and why, in the imperative, with the reasoning in the body where it is not obvious. Reference spec ids where applicable.

Reject dice sequences shorter than 100 rolls

99 rolls is 255.911 bits, which is short of 256. The earlier bound came from
the project brief and was wrong by 0.089 bits. Small enough not to matter in
practice, large enough that a project about checkable arithmetic should not
round in its own favour.

Spec: core.entropy.dice (INV-ENT-5)

No em dashes anywhere: not in commit messages, code comments, documentation, or UI copy. Use a comma, a colon, parentheses, or two sentences. This is enforced by make prose.

---