Git and code review

Rules

Branches and commits

• main MUST always be deployable and protected: pull requests only, required CI, no force pushes.
• Feature branches SHOULD be short-lived (days, not weeks).
• Commits MUST follow Conventional Commits: feat:, fix:, docs:, refactor:, test:, perf:, chore:, content:. Breaking changes add ! or a BREAKING CHANGE: footer.
• Commit messages SHOULD explain why, not only what.
• Releases MUST be tagged with semantic versions.

Pull requests

• One concern per PR. A PR SHOULD be reviewable in one sitting; split larger work.
• The PR description MUST link the spec section or issue and include the agent’s task report or equivalent.
• CI MUST pass before review starts.

Reviewing AI-written code

• A human MUST read every changed line. Skimming is not review.
• Check that every imported package and API actually exists in the version you use. Agents can invent plausible names.
• Check for silently weakened tests, broadened permissions, disabled checks, swallowed errors and new network calls.
• Check that the code does what the spec says, not what the agent described.
• Run the change locally or on the preview deployment for anything user-facing.

PR template

## What and why
<1–3 sentences; link spec section / issue>

## Changes
- …

## Checks
<paste summary of lint / types / tests / build / a11y / perf>

## Risk
<what could break; rollback plan if non-trivial>

## Not done / follow-ups
- …

## Checklist
- [ ] Definition of done met
- [ ] Docs + changelog updated
- [ ] Sensitive areas reviewed by a human (auth, payments, data, infra, content claims)