Contributing

Contributions should preserve the project’s central invariants:

• official artifacts and generated full databases remain local;
• every stored fact is edition aware and source referenced;
• ambiguous structures produce warnings or candidates rather than guesses;
• CLI, Python, and MCP continue to share one resolver contract;
• offline tests remain useful without downloading the standard;
• official-edition integration tests remain separate and explicit;
• the project supports validation workflows but does not certify conformance.

Start here

1. Set up the development environment.
2. Read Architecture for contributors.
3. Choose the correct testing layer.
4. Follow the parser fixture policy.
5. Complete release and distribution checks before publishing.
6. Keep the documentation synchronized.

Commit policy

The source repository requires a descriptive, granular commit after each distinct logical unit of work.

Use:

type(scope): imperative subject

Body explaining the design decision, invariant, or reason for the change.

Allowed types include feat, fix, test, docs, refactor, and chore.

Stage files selectively, do not batch unrelated changes, and confirm recent history with:

git log --oneline -3

Do not amend or force-push commits that have already been logged under the repository policy.