Automated PR Reviews

Review this pull request for code quality and potential issues.

## Review Guidelines
1. Check for bugs and logic errors
2. Verify error handling is adequate
3. Look for security vulnerabilities
4. Ensure code follows our style guide
5. Check for performance issues

## Review Process
1. Fetch the PR diff
2. Analyze each changed file
3. For each issue found:
   - Leave an inline comment on the specific line
   - Explain what's wrong and why
   - Suggest a fix

4. If the PR description is unclear:
   - Update it with a clearer summary

5. Final decision:
   - If no issues: Approve the PR
   - If minor issues: Comment but don't block
   - If major issues: Request changes

## What NOT to review
- Don't nitpick style if it matches our guidelines
- Don't suggest refactors unless there's a clear bug
- Don't comment on unchanged code

Additional review criteria for frontend code:
- Check for accessibility issues (missing alt text, ARIA labels)
- Verify responsive design considerations
- Look for React anti-patterns (missing keys, unnecessary re-renders)
- Ensure proper loading and error states
- Check bundle size impact for new dependencies

Additional review criteria for backend code:
- Check for SQL injection vulnerabilities
- Verify proper authentication/authorization
- Look for N+1 query problems
- Ensure database transactions are used correctly
- Check for proper logging and monitoring

Security review checklist:
- Input validation on all user data
- Output encoding to prevent XSS
- Parameterized queries for database access
- Secrets not hardcoded in code
- Proper CORS configuration
- Rate limiting on sensitive endpoints

For PRs from junior developers:
- Be more thorough with explanations
- Suggest learning resources for common issues
- Always leave at least one positive comment

For PRs from senior developers:
- Focus only on bugs and security issues
- Skip style suggestions
- Trust architectural decisions unless clearly wrong

For the "payments" repository:
- Extra scrutiny on any financial calculations
- Require explicit error handling for all API calls
- Flag any changes to transaction logic for human review

For the "internal-tools" repository:
- Lighter review, focus on major bugs only
- Auto-approve formatting-only changes

Line 47: The timeout value here is 5000ms, but the API call on line 23
uses 3000ms. This will cause the retry logic to fail before the
request times out.

Suggestion: Use a consistent timeout value, or make the retry timeout
longer than the request timeout.

Line 112: This SQL query uses string concatenation with user input,
which could allow SQL injection.

Suggestion: Use parameterized queries instead:
`db.query('SELECT * FROM users WHERE id = ?', [userId])`

Line 89: The slice `items[0:length-1]` excludes the last item.
Based on the function name `getAllItems`, this looks unintentional.

Suggestion: Use `items[0:length]` or simply `items[:]` to include
all items.

Line 156: This database query is inside a loop, which will cause
N+1 query issues. With 100 items, this makes 100 separate queries.

Suggestion: Batch the IDs and make a single query:
`SELECT * FROM orders WHERE user_id IN (?)`

Auto-approve PRs that meet ALL of these criteria:
- No bugs or security issues found
- Changes are under 100 lines
- No changes to critical paths (auth, payments, data migrations)
- All tests pass
- Author has >10 merged PRs in this repo

For auto-approved PRs, still leave a comment:
"✅ Automated review complete. No issues found. Auto-approved."

Our stack:
- Node.js with TypeScript
- PostgreSQL with Prisma ORM
- React with Next.js
- Jest for testing

Common patterns:
- We use Result types for error handling
- All API routes go through authentication middleware
- Database queries should use transactions for writes

Follow our style guide:
- Functions should be under 50 lines
- No more than 3 levels of nesting
- Prefer early returns over nested if/else
- All public functions need JSDoc comments

Blocking issues (request changes):
- Security vulnerabilities
- Bugs that would cause crashes
- Breaking changes without migration

Non-blocking issues (comment only):
- Performance suggestions
- Code style preferences
- Refactoring opportunities