GitHub pull request templates worth copying

## What does this PR do?

<!-- One or two sentences. Link the issue if there is one. -->

Closes #

## Why is it needed?

<!-- The context a reviewer needs to judge the approach, not just the diff. -->

## How was it tested?

- [ ] Unit tests added or updated
- [ ] Tested manually (describe below)

## Anything reviewers should focus on?

<!-- Risky files, tricky logic, decisions you want a second opinion on. -->

## Screenshots (if the UI changed)

## What and why

<!-- Two sentences max. Assume the reviewer knows the codebase. -->

## Test plan

<!-- How you verified it works. "Ran it locally against X" is fine if true. -->

## Notes for the reviewer

<!-- Optional: tricky parts, open questions. Delete this section if empty. -->

## Feature

<!-- What can users do now that they could not do before? -->

Closes #

## Implementation notes

<!-- Key decisions and trade-offs. What else did you consider, and why not? -->

## How to try it

1.
2.
3.

## Checklist

- [ ] Tests cover the happy path and at least one failure case
- [ ] Docs or changelog updated if user-facing
- [ ] Feature flag or rollout plan noted (if applicable)
- [ ] Breaking changes called out explicitly (or there are none)

## The bug

<!-- What was broken, who hit it, how bad it was. Link the issue or report. -->

Fixes #

## Root cause

<!-- Why it happened. This is the most useful part of the whole description. -->

## The fix

<!-- What changed, and why this approach over alternatives. -->

## How do we know it is fixed?

- [ ] Regression test added that fails without this change
- [ ] Verified manually against the original reproduction steps

## Risk

<!-- What could this break? What should we watch after merge? -->

## Incident

<!-- What is on fire and who is affected. Link the incident channel or ticket. -->

## Minimal fix

<!-- What this PR does. Keep the diff as small as possible. -->

## What this deliberately does NOT fix

<!-- The proper fix goes in a follow-up. Link it here. -->

Follow-up issue: #

## Verification

- [ ] Reproduced the failure before the fix
- [ ] Verified the fix on staging or a production canary
- [ ] Rollback plan: revert this PR (or describe below)

<!-- One approval, merge, monitor. Post-mortem comes later. -->

<!-- If this fixes an actively exploitable issue, keep specifics out of the
     PR. Discuss details in a private channel and keep this description
     vague until the fix is deployed everywhere. -->

## Summary

<!-- The class of issue this addresses, without a working exploit recipe. -->

## Affected surface

<!-- Which endpoints, inputs, or roles were affected. Since when, if known. -->

## The fix

## Verification

- [ ] Exploit attempt fails after the fix (verified privately)
- [ ] Regression test added (without embedding the exploit, if sensitive)
- [ ] Searched the codebase for the same pattern elsewhere

## After merge

- [ ] Rotate any credentials or tokens that may have been exposed
- [ ] Decide whether users or customers need to be notified

## What this migration does

<!-- Tables or collections touched, and how. -->

## Runbook

- Reversible: yes / no. If yes, how:
- Estimated duration on production-sized data:
- Locks or downtime expected:
- Order of operations (deploy first or migrate first, and why):

## Safety

- [ ] Tested against a production-sized dataset (or a realistic copy)
- [ ] Old and new code can run side by side during rollout
- [ ] Backfill is idempotent (safe to re-run if interrupted)
- [ ] Rollback tested, not just written down

## Data checks

<!-- Queries you will run before and after to confirm nothing was lost. -->

## What changed in the API

<!-- Endpoints, request/response shapes, error codes. -->

## Compatibility

- [ ] Backward compatible (additive only)
- [ ] Breaking change: migration path documented below

Who calls this today? <!-- Internal services, mobile clients, public consumers. -->

## Contract

- [ ] OpenAPI spec / schema updated
- [ ] API docs updated
- [ ] Versioning handled (new version, deprecation notice, or sunset date)

## Testing

- [ ] Contract or integration tests updated
- [ ] Verified against at least one real consumer

## What changed

<!-- Pages or sections touched, and why. -->

## Type of change

- [ ] Fixing wrong or outdated information
- [ ] New documentation
- [ ] Restructuring or navigation changes
- [ ] Typos and wording

## Checklist

- [ ] Preview rendered locally (links, images, and code blocks work)
- [ ] Code samples were actually run, not just written
- [ ] Screenshots updated if the UI they show has changed

## Dependency

Package:
From version:
To version:

## Why now?

- [ ] Security advisory (link):
- [ ] Bug fix we need
- [ ] Routine maintenance
- [ ] Unblocks another upgrade

## Breaking changes

<!-- Summarize from the changelog and link the release notes.
     "None per the changelog" is a valid answer; "did not check" is not. -->

## Verification

- [ ] CI green
- [ ] App boots and core flows work locally
- [ ] Lockfile diff reviewed: only expected packages changed

## What is being refactored, and why

<!-- The pain this removes: duplication, coupling, a pattern being retired. -->

## Behavior change

None intended. If a reviewer spots one, that is a bug in this PR.

## How to review this

<!-- Suggest an order or a lens, e.g. "start with the new module,
     then check the call sites". Large diffs need a map. -->

## Safety net

- [ ] Existing tests pass unchanged (any test edits are mechanical only)
- [ ] No public API changes
- [ ] Mechanical changes (renames, moves) live in their own commits

## Release

Version:
Target environment:

## What is shipping

<!-- Bullet the user-facing changes and link the PRs. -->

-
-

## Pre-merge checklist

- [ ] Changelog or release notes drafted
- [ ] Migrations reviewed and reversible
- [ ] Feature flags set to their launch state
- [ ] On-call and support informed

## Rollback plan

<!-- How we get back to the previous version, and how long that takes. -->

## What does this PR do?

Closes #

## Motivation

<!-- Why this change matters to users of the project. -->

## Checklist

- [ ] I read the CONTRIBUTING guide
- [ ] For non-trivial changes, I opened an issue to discuss this first
- [ ] Tests added or updated
- [ ] Docs updated (README, docs site, or inline comments)
- [ ] Commit messages follow the project convention

## For maintainers

<!-- Anything you were unsure about, or where you would like
     specific feedback. Questions welcome. -->

## Ticket

Client ticket / request:
Billing reference (if tracked per task):

## What changed, in client terms

<!-- One or two sentences you could paste into the client update. No jargon. -->

## Scope check

- [ ] This stays within the agreed scope of the ticket
- [ ] Out-of-scope work spotted along the way was logged separately, not included

## QA

- [ ] Tested on staging (link):
- [ ] Matches the approved design or spec
- [ ] Works on the browsers and devices the client actually uses

## Deploy notes

<!-- Anything the person deploying this (possibly weeks from now) must know:
     env vars, config, manual steps, timing constraints. -->

## What changed visually

<!-- One sentence. Then let the screenshots do the talking. -->

## Before / after

| Before | After |
| ------ | ----- |
|        |       |

## Design reference

<!-- Figma link, or who approved deviating from it. -->

## Checks

- [ ] Responsive: mobile, tablet, desktop
- [ ] Keyboard navigation and visible focus states work
- [ ] Color contrast meets WCAG AA
- [ ] Dark mode (if the product supports it)
- [ ] Empty, loading, and error states covered

## What changed

Closes #

## Platforms

- [ ] iOS
- [ ] Android

## Tested on

<!-- Real devices and OS versions, not just the simulator. -->

## Release awareness

- [ ] Safe for the next release train (no server-side dependency)
- [ ] Depends on an API change (link the backend PR):
- [ ] Behind a remote config or feature flag
- [ ] Store review risk considered (permissions, background modes, payments)

## Screenshots / screen recording