Pull requests

The repository's contribution flow is feature branch to staging, then staging to main for production release. Start your branch from staging and target staging with your pull request. Give the reviewer the problem, the change you made, how you checked it and any visible effect on the interface or data. Link an issue when one exists.

Prepare a changeCopy Anchor Link

Read the code style guide and the relevant architecture page. Keep a pull request focused on one change. Add or update tests for behaviour that can be verified, and update documentation when the user or developer contract changes. For an interface change, include a screenshot or recording that shows the result and any relevant states.

pnpm install activates the repository's .githooks/pre-push through the prepare script. That hook runs pnpm lint and pnpm typecheck when pushing to staging or main. The separate .pre-commit-config.yaml is available for on-demand checks and pre-commit.ci. As CONTRIBUTING.md explains, the configured Git hooks path prevents pre-commit install from installing the pre-commit hook in the usual way. Run them on demand with uv tool run pre-commit run --all-files instead of assuming they are installed for every local commit.

Run checksCopy Anchor Link

Choose the package scripts that match your change:

pnpm lint
pnpm typecheck
pnpm test:unit
pnpm test:integration

Integration tests use a dedicated PostgreSQL test database.

A pull request's Build workflow validates code, runs tests for code-relevant changes and performs the structural-quality audit. The image build runs on push or manual dispatch. The security audit step currently reports findings without failing validation. See the pipeline overview for the workflow conditions.

Write the commit and request reviewCopy Anchor Link

Use a lowercase conventional commit type, such as feat, fix, docs or test. An optional scope can follow the values described in .commitlintrc.json; no hook or CI step enforces this convention. For example, fix(auth): reject expired token describes a fix in the authentication area. The configuration describes a 50-character subject limit. Fix: and Feature: are not the format defined by this repository.

For a change to a documented API route, run pnpm docs:generate and include the regenerated public/openapi.json; CI checks for drift.

Open the pull request against staging. In its description, state what changed and why, include the checks you ran, and call out any migration, deployment or documentation effect. Respond to review comments with a new commit or an explanation of the relevant code. Maintainers decide when to merge and when to promote staging to main; releases from main are automated by semantic-release.