Correspondents/CONTRIBUTING.md

Contributing Workflow

Use this guidance when you spin up a new project from the template or accept contributions from collaborators.

Branching model

• Work from short-lived topic branches cut from main.
• Prefix branches with the work type: feat/, fix/, docs/, chore/, refactor/, test/.
• Keep branch names descriptive but short (e.g. feat/billing-invoices, fix/auth-timeout).

Commit messages

Follow Conventional Commits.

<type>(<scope>): <subject>

Examples:

• feat(api): add artist listing endpoint
• fix(infra): handle wrangler env missing
• docs(adr): record storage strategy

Pull request checklist

1. Rebase onto main before opening the PR.
2. Fill out .gitea/pull_request_template.md so reviewers know how to test.
3. Ensure automated checks pass locally:

   pnpm install
   pnpm lint
   pnpm test
   pnpm build
   

   Adjust the commands if your project uses a different toolchain.
4. Link issues with Fixes #id or Refs #id as appropriate.
5. Squash-merge once approved to keep history clean (use the Conventional Commit format for the squash message).

Quality expectations

• Keep docs current. Update the README, edge-case catalogue, or stack decisions when behaviour changes.
• Add or update tests alongside your changes—tests are treated as executable documentation.
• Avoid committing secrets or large binaries; rely on .env files, secret managers, or storage buckets instead.

Questions?

Open an issue or start a draft PR and document what you are unsure about. Future readers will thank you for the breadcrumbs.