These checklists are only useful if they stay accurate and battle-tested. Contributions that add real, verifiable items are very welcome.
- Map to reality. Every item should map to a real failure pattern, audit finding, or operational lesson — not a hypothetical. If you can cite the pattern, do.
- Be specific. "Validate input" is weak; "validate that an address argument is the expected kind (account vs. contract) before calling it" is actionable.
- Tag severity and scope. Use
(critical)/(high)/(medium)/(low)in security items and[testnet]/[mainnet]where network scope matters. - Accurate to Quantova. Reflect how the chain actually works: Q-format addresses,
post-quantum signing, the
q_RPC namespace, deterministic finality, no token burn.
- Open an issue using the checklist-improvement template, or a PR directly.
- Keep task-list (
- [ ]) formatting so items stay clickable. - Make sure internal links resolve — the CI "Checklist integrity" job checks this.
- One focused change per PR is easier to review than a sweeping rewrite.
- One H1 per file (the checklist title).
- Group items under H2 sections.
- Use fenced code blocks with a language hint for any snippets.