# 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. - [ ] 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.