Contributing

Heavymatica is developed in the open at github.com/Dirnei/heavymatica. Bug reports and ideas go into issues. What is built and what comes next is in ROADMAP.md.

How a change is made

Features and behaviour changes are planned with OpenSpec before code is written:

• openspec/specs/ describes what the mod, the cloud and the websites do today, one capability per folder.
• openspec/changes/<name>/ holds a change in progress: a proposal (why), spec deltas (what changes), a design (how) and tasks. A finished change is archived and its deltas are merged into openspec/specs/.

Small fixes don’t need a change.

Commits

• Conventional Commits: type(scope): subject, for example feat(placement): add remote overlay or fix(library): keep selection after refresh. Types: feat, fix, refactor, test, docs, build, chore.
• A subject line only, at most 74 characters.
• Release notes are built from feat and fix commits, so their subjects are written for players.

Code comments

• Comment only what the code can’t say itself: a non-obvious constraint, a workaround, an API quirk.
• No reasoning or history in comments, and no references to OpenSpec changes or requirements. That belongs in the change’s design.

Before a pull request

• ./gradlew build from src/mod (both jars and all mod tests).
• dotnet test src/cloud/Heavymatica.slnx when the cloud changed.
• npm run check and npm test in src/web/player when the website changed.
• npm run build in docs when the documentation changed.

See Building and Local development.