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](https://www.conventionalcommits.org/en/v1.0.0/).
```
<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:
   ```bash
   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.