Code Review Checklist for Pull Requests with Quality Standards

Create a complete Code Review Checklist for Pull Requests for:\\\\\\\\n\\\\\\\\nProject: [PROJECT NAME]\\\\\\\\nTech stack: [EX: TypeScript/Node.js/React/PostgreSQL or Python/FastAPI/Redis]\\\\\\\\nEnvironment: [SaaS / E-commerce / Fintech / HealthTech / etc.]\\\\\\\\nTeam size: [NUMBER] developers\\\\\\\\nCurrent PR process: [DESCRIBE: e.g., branch to main, 1 minimum approval]\\\\\\\\nHistorical problems: [EX: null pointer bugs, N+1 queries, sensitive data in logs]\\\\\\\\n\\\\\\\\n## CHECKLIST STRUCTURE (for reviewer and author)\\\\\\\\n\\\\\\\\n---\\\\\\\\n\\\\\\\\n### PART A — AUTHOR CHECKLIST (before opening PR)\\\\\\\\n\\\\\\\\n**Mandatory self-review:**\\\\\\\\n- [ ] I read the entire PR diff before publishing\\\\\\\\n- [ ] PR has a clear description: WHAT was done, WHY, and HOW to test\\\\\\\\n- [ ] PR size is appropriate: < 400 lines changed (justify if larger)\\\\\\\\n- [ ] Removed ALL TODOs, console.logs, debuggers, commented code without explanation\\\\\\\\n- [ ] Did not commit credentials, API keys, tokens, or sensitive data\\\\\\\\n- [ ] Added or updated tests for the changes made\\\\\\\\n- [ ] Tests pass locally (\\\\\\\\\\\\\\\\\\\\\\\`pnpm test\\\\\\\\\\\\\\\\\\\\\\\` / \\\\\\\\\\\\\\\\\\\\\\\`pytest\\\\\\\\\\\\\\\\\\\\\\\`)\\\\\\\\n- [ ] Build passes locally (\\\\\\\\\\\\\\\\\\\\\\\`pnpm build\\\\\\\\\\\\\\\\\\\\\\\` / equivalent)\\\\\\\\n- [ ] Updated documentation if API or interface changed\\\\\\\\n- [ ] No conflicts with base branch\\\\\\\\n\\\\\\\\n**PR description template (required):**\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`markdown\\\\\\\\n## What this PR does\\\\\\\\n[Clear description in 1-3 sentences]\\\\\\\\n\\\\\\\\n## Why this change is needed\\\\\\\\n[Context: ticket, bug, improvement]\\\\\\\\n\\\\\\\\n## How to test\\\\\\\\n1. [Step 1]\\\\\\\\n2. [Step 2]\\\\\\\\n3. [What to verify]\\\\\\\\n\\\\\\\\n## Screenshots (if visual change)\\\\\\\\n\\\\\\\\n## Checklist\\\\\\\\n- [ ] Tests added/updated\\\\\\\\n- [ ] Documentation updated\\\\\\\\n- [ ] Breaking changes documented\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\n\\\\\\\\n---\\\\\\\\n\\\\\\\\n### PART B — REVIEWER CHECKLIST (when reviewing)\\\\\\\\n\\\\\\\\n#### B1) CORRECTNESS AND LOGIC\\\\\\\\n- [ ] Is the code logic correct for the main use case?\\\\\\\\n- [ ] Edge cases handled? (null, undefined, empty list, zero value, empty string)\\\\\\\\n- [ ] Race conditions considered in async operations?\\\\\\\\n- [ ] Error handling: exceptions caught and handled appropriately?\\\\\\\\n- [ ] Rollback: if partial failure occurs, is the system left in an inconsistent state?\\\\\\\\n- [ ] Acceptance criteria from the ticket met?\\\\\\\\n\\\\\\\\n#### B2) SECURITY\\\\\\\\n- [ ] User inputs validated and sanitized before use?\\\\\\\\n- [ ] No sensitive data logged (passwords, tokens, national IDs, credit card numbers)?\\\\\\\\n- [ ] Database queries use prepared statements or ORM (no SQL injection)?\\\\\\\\n- [ ] New APIs have proper authentication and authorization?\\\\\\\\n- [ ] No hardcoded secrets, API keys, or credentials?\\\\\\\\n- [ ] New dependencies trusted and up to date?\\\\\\\\n- [ ] Sensitive data encrypted at rest and in transit?\\\\\\\\n- [ ] CORS, CSP, and security headers configured correctly?\\\\\\\\n\\\\\\\\n#### B3) PERFORMANCE\\\\\\\\n- [ ] Any N+1 queries? (loop making individual queries inside another loop)\\\\\\\\n- [ ] Necessary indexes added for new queries?\\\\\\\\n- [ ] Heavy operations async / not blocking the main thread?\\\\\\\\n- [ ] Caches used where appropriate? (and properly invalidated?)\\\\\\\\n- [ ] Loops and algorithms have acceptable complexity for expected volume?\\\\\\\\n- [ ] Large payloads paginated or streamed?\\\\\\\\n- [ ] Memory leaks: listeners, timers, subscriptions removed when needed?\\\\\\\\n\\\\\\\\n#### B4) MAINTAINABILITY AND READABILITY\\\\\\\\n- [ ] Code is self-explanatory without excessive comments?\\\\\\\\n- [ ] Functions have single responsibility (SRP)?\\\\\\\\n- [ ] Variable, function, and class names descriptive and follow project convention?\\\\\\\\n- [ ] Duplicated code extracted into reusable functions/modules?\\\\\\\\n- [ ] Magic numbers and strings have named constants?\\\\\\\\n- [ ] Existing comments accurate (not outdated)?\\\\\\\\n- [ ] Cyclomatic complexity: functions with > 10 branches warrant refactoring\\\\\\\\n- [ ] Code follows project standards (linter, formatter pass)?\\\\\\\\n\\\\\\\\n#### B5) TESTING\\\\\\\\n- [ ] Tests for happy path?\\\\\\\\n- [ ] Tests for error cases (unhappy path)?\\\\\\\\n- [ ] Tests for identified edge cases?\\\\\\\\n- [ ] Tests are deterministic (not dependent on time, randomness, order)?\\\\\\\\n- [ ] Mocks/stubs used appropriately (not mocking what's being tested)?\\\\\\\\n- [ ] Code coverage: new critical lines covered?\\\\\\\\n- [ ] Tests readable: arrange/act/assert clear?\\\\\\\\n\\\\\\\\n#### B6) ARCHITECTURE AND DESIGN\\\\\\\\n- [ ] Change follows project's architectural patterns?\\\\\\\\n- [ ] Dependencies between modules in correct direction (no circular dependencies)?\\\\\\\\n- [ ] Public APIs (endpoints, interfaces) follow established contract?\\\\\\\\n- [ ] Breaking changes flagged and versioned correctly?\\\\\\\\n- [ ] Change extensible without requiring rewrite? (Open/Closed Principle)\\\\\\\\n- [ ] New endpoints have idempotency for operations that should be idempotent?\\\\\\\\n\\\\\\\\n#### B7) OBSERVABILITY\\\\\\\\n- [ ] Appropriate logs at critical points (start, end, errors)?\\\\\\\\n- [ ] Correct log level (debug, info, warn, error)?\\\\\\\\n- [ ] Metrics/traces added for new high-impact operations?\\\\\\\\n- [ ] Errors have sufficient context for debugging (no raw stack trace to user)?\\\\\\\\n\\\\\\\\n#### B8) DATA AND DATABASE\\\\\\\\n- [ ] Migrations reversible (have rollback)?\\\\\\\\n- [ ] Schema changes don't break current code version (backward compatible)?\\\\\\\\n- [ ] No data deletion without soft delete or backup?\\\\\\\\n- [ ] Transactions used when multiple operations must be atomic?\\\\\\\\n- [ ] Database locks not causing deadlocks?\\\\\\\\n\\\\\\\\n---\\\\\\\\n\\\\\\\\n### PART C — REVIEW PROCESS\\\\\\\\n\\\\\\\\n**Review SLA:**\\\\\\\\n- PRs marked [URGENT]: review within 4 hours\\\\\\\\n- Normal PRs: review within 1 business day\\\\\\\\n- PRs > 400 lines: author must schedule pair review session\\\\\\\\n\\\\\\\\n**Feedback tone:**\\\\\\\\n- Blocking comments (BLOCK): critical issue preventing merge\\\\\\\\n- Suggestion comments (NIT/SUGGESTION): optional improvement\\\\\\\\n- Question comments (QUESTION): to understand author decision\\\\\\\\n- Praise (PRAISE): explicitly acknowledge good practices\\\\\\\\n\\\\\\\\n**Examples of well-written comments:**\\\\\\\\n- GOOD: \\\\\\\\