Lisa Quality Review

Quality Review

Review code quality for changed files. Explain all findings in plain English as if speaking to someone with no programming background.

Review Checklist

For each changed file, evaluate:

1. Correctness -- Does the code do what the task says? Logic errors, off-by-one mistakes, missing edge cases?
2. Coding philosophy -- Immutability patterns (no let, no mutations, functional transformations)? Correct function structure (variables, side effects, return)?
3. Test coverage -- Tests present? Testing behavior, not implementation details? Edge cases covered?
4. Documentation -- JSDoc on new functions explaining "why"? Preambles on new files?
5. Code clarity -- Readable variable names? Unnecessary complexity? Could a new team member understand this?

Output Format

Rank findings by severity:

Critical (must fix before merge)

Broken logic or violates hard project rules.

Warning (should fix)

Could cause problems later or reduce maintainability.

Suggestion (nice to have)

Minor improvements, not blocking.

Finding Format

For each finding:

• What -- Plain English description, no jargon
• Why -- What could go wrong? Concrete examples
• Where -- File path and line number
• Fix -- Specific, actionable suggestion

Example

What: The function changes the original list instead of creating a new one. Why: Other code using that list could see unexpected changes, causing hard-to-track bugs. Where: src/utils/transform.ts:42 Fix: Use [...items].sort() instead of items.sort() to create a copy first.

Rules

• Run bun run test to confirm tests pass
• Run the task's proof command to confirm the implementation works
• Never approve code with failing tests
• If no issues found, say so clearly -- do not invent problems