pre-commit-review

# Pre-Commit Design Review (React/TypeScript)

ADVISORY validation of code against design principles, accessibility, and practices that linters cannot fully enforce.
Categorizes findings as Design Debt, Readability Debt, or Polish Opportunities.

## When to Use
- Automatically invoked by @linter-driven-development (Phase 4)
- Manually before committing (to validate design quality)
- After linter passes and tests pass

## What This Reviews
- **NOT code correctness** (tests verify that)
- **NOT syntax/style** (ESLint/Prettier enforce that)
- **YES design principles** (primitive obsession, composition, architecture)
- **YES maintainability** (readability, complexity, testability)
- **YES accessibility** (semantic HTML, ARIA, keyboard nav)

## Review Scope

**Primary Scope**: Changed code in commit
- All modified lines
- All new components/hooks
- Specific focus on design principle adherence
- Accessibility compliance

**Secondary Scope**: Context around changes
- Entire files containing modifications
- Flag patterns/issues outside commit scope
- Suggest broader refactoring opportunities

## Finding Categories (Debt-Based)

### 🔴 Design Debt
**Will cause pain when extending/modifying code**

Violations:
- **Primitive obsession**: string IDs, unvalidated inputs, no branded types
- **Wrong architecture**: Technical layers instead of feature-based
- **Prop drilling**: State passed through 3+ component levels
- **Tight coupling**: Components tightly coupled to specific implementations
- **Missing error boundaries**: No error handling for async operations
- **No type validation**: Runtime data not validated (no Zod schemas)

Impact: Future changes will require more work and introduce bugs

### 🟡 Readability Debt
**Makes code harder to understand and work with**

Violations:
- **Mixed abstractions**: Business logic mixed with UI in same component
- **Complex conditions**: Deeply nested or complex boolean expressions
- **Inline styles/logic**: Complex logic directly in JSX
-