vtuber-awards/docs/CHECKLISTS.md

# Checklists

Use these concise checklists as quality gates. Expand them only when repeated
project experience proves that more detail is necessary.

For workflow details, see [workflow.md](workflow.md). For code standards, see
[CONVENTIONS.md](CONVENTIONS.md). For releases, see
[release-process.md](release-process.md).

## Feature Development

- [ ] Objective, users, acceptance criteria, and non-goals are clear.
- [ ] Relevant docs and existing implementation were read.
- [ ] Frontend/backend contract and source of truth are identified.
- [ ] Permission, workflow, empty, loading, error, and disabled states are handled.
- [ ] Large touched files were checked against [maintainability-backlog.md](maintainability-backlog.md).
- [ ] Docs are updated when behavior, setup, or architecture changed.
- [ ] Frontend build, backend build, and targeted manual checks are run.

## Bug Fix

- [ ] Observed behavior is understood.
- [ ] Expected behavior is confirmed.
- [ ] Root cause is identified before changing code.
- [ ] Fix is scoped to the cause.
- [ ] Regression coverage or targeted manual verification covers the failing path.
- [ ] Remaining risk is documented.

## Frontend UI Change

- [ ] Existing components, composables, and design guidance were checked.
- [ ] Public UI uses backend/admin truth when available.
- [ ] Admin UI is scannable and permission-aware.
- [ ] Text wraps without overlap at mobile and desktop widths.
- [ ] Browser checks include relevant routes and responsive widths.
- [ ] `npm run build` passes.

## API Change

- [ ] Request and response contracts are stable and typed.
- [ ] Authorization is enforced server-side.
- [ ] Validation errors are consistent and actionable.
- [ ] Public writes are rate-limited where appropriate.
- [ ] Idempotency, pagination, filtering, or sorting are considered when relevant.
- [ ] Frontend clients and TypeScript types are updated.

## Database Change

- [ ] Data ownership and invariants are clear.
- [ ] Migration operations are reviewed manually.
- [ ] Constraints and indexes match expected behavior.
- [ ] Backfill and deployment order are documented when needed.
- [ ] Rollback or forward-fix path is understood.
- [ ] Database health and pending migrations are checked after applying.

## Security Review

- [ ] Authentication is required where expected.
- [ ] Authorization is enforced on the backend.
- [ ] Inputs are validated.
- [ ] Outputs are safely serialized or encoded.
- [ ] Secrets are not logged or committed.
- [ ] Sensitive user or team data exposure is minimized.
- [ ] Demo, seed, and local-only behavior cannot leak into production.

## Pull Request

- [ ] Summary explains what and why.
- [ ] Scope is focused.
- [ ] Validation commands and manual checks are listed.
- [ ] Screenshots or recordings are included for visible UI changes.
- [ ] Migration and deployment notes are included when relevant.
- [ ] Risks, skipped validation, and follow-ups are documented.
- [ ] No generated output, secrets, debug code, or unrelated files are included.

## Release

- [ ] Release scope and target commit are known.
- [ ] Required CI checks passed.
- [ ] Migration risk is reviewed.
- [ ] Configuration and secrets are ready.
- [ ] Predeploy backup is confirmed by the pipeline.
- [ ] Health, database, and frontend asset checks pass.
- [ ] Rollback or recovery path is understood.

## Production Readiness

- [ ] Runtime environments and URLs are documented.
- [ ] Health checks exist and are reachable.
- [ ] Database connectivity and pending migrations can be inspected.
- [ ] Production CORS, seed mode, and demo login settings are safe.
- [ ] Backups and restore expectations are documented.
- [ ] Operational ownership and alerting gaps are explicit.