Quality Assurance Code Review

Review code for quality, consistency with project conventions, and Deno best practices.

Scope

Review changes from: !git diff --name-only HEAD~1 or files specified in $ARGUMENTS

Pre-checks

Run automated checks first:

cd api && deno lint
cd api && deno fmt --check

Quality Checklist

1. Code Style & Formatting

• • Line width: Max 120 characters (per deno.jsonc)
• • Import organization: Use Deno's organize imports (no ../../../ paths, use @/)
• • Consistent naming: PascalCase for classes/interfaces, camelCase for functions/variables
• • No unused imports: Remove dead imports
• • No commented code: Remove or document why it's kept

2. TypeScript Standards

• • Explicit types: Function parameters and return types should be typed
• • No any: Avoid any, use unknown or proper types
• • Interface naming: Use Interface suffix for interfaces
• • Type imports: Use import type for type-only imports
• • Null handling: Prefer undefined over null unless interfacing with external APIs

3. ILOS Framework Conventions

• • Action structure: Actions extend Action class with proper handle method
• • Handler decorator: Correct @handler() configuration
• • Service signatures: Format service:method for RPC calls
• • Repository pattern: SQL via sql template literal, no string concatenation
• • Dependency injection: Use Inversify decorators properly

4. Error Handling

• • Specific exceptions: Use typed exceptions (NotFoundException, etc.)
• • Error context: Include relevant context in error messages
• • Async/await: Proper try/catch for async operations
• • No swallowed errors: All catch blocks either rethrow or log

5. Testing

• • Test coverage: New logic has corresponding tests
• • Test naming: .unit.spec.ts or .integration.spec.ts suffix
• • Edge cases: Tests cover boundary conditions
• • Test isolation: Tests don't depend on each other

6. Code Organization

• • Single responsibility: Functions/classes do one thing
• • File length: Files under 300 lines preferred
• • Function length: Functions under 50 lines preferred
• • Nesting depth: Max 3-4 levels of nesting

7. Project Coherence

• • Existing patterns: Follow patterns from similar existing code
• • Shared types: Use types from shared/ or define in service contracts
• • Configuration: Use env_or_* helpers for environment variables
• • No over-engineering: Simple solutions preferred (per CLAUDE.md)

8. Deno 2.x Best Practices

• • Import maps: Use aliases from deno.jsonc
• • Standard library: Prefer jsr:@std/* packages
• • Node compatibility: Use node: prefix for Node.js APIs
• • Permission-aware: Consider minimal permission requirements

Output Format

## Quality Review Summary

**Quality Score**: [A | B | C | D | F]
**Files Reviewed**: X files
**Lint Issues**: X errors, Y warnings

### Code Issues

#### [SEVERITY] Issue Title
- **File**: path/to/file.ts:line
- **Issue**: What's wrong
- **Standard**: Which convention is violated
- **Fix**: How to correct it

### Style Issues
- Minor formatting or naming issues

### Suggestions
- Non-blocking improvements for code quality

### Approved Changes
- Changes that meet quality standards

### Required Actions
- [ ] Fix all ERROR level issues
- [ ] Address WARNING level issues
- [ ] Run `deno fmt` before commit

Invocation

/check-qa                          # Review uncommitted changes
/check-qa src/pdc/services/auth/   # Review specific directory
/check-qa --strict                 # Enable stricter checks