# Code Architecture Review

> Evaluate the overall design and structural health of a codebase.

## When to Use
- New project onboarding ("help me understand this codebase")
- Architecture health check
- Pre-refactoring assessment

## Approach
1. **Map the dependency graph** — what depends on what?
2. **Identify the core domain** — where does the business logic live?
3. **Check separation of concerns** — is business logic mixed with I/O, UI, or infrastructure?
4. **Evaluate coupling** — can components be changed independently?
5. **Assess testability** — can the core logic be tested without spinning up databases/servers?
6. **Check for architectural smells** — circular dependencies, god classes, feature envy, shotgun surgery

## Architecture Health Scorecard
| Dimension | Score (1-5) | Notes |
|-----------|------------|-------|
| Modularity | | Can components be changed independently? |
| Testability | | Can core logic be unit tested? |
| Dependency direction | | Do dependencies point inward toward domain? |
| Error handling | | Are errors handled consistently? |
| Configuration | | Is config externalized and environment-aware? |
| Security boundaries | | Are auth/authz checks at every boundary? |
| Data integrity | | Are invariants enforced? Transactions used correctly? |
| Scalability readiness | | What breaks first under 10x load? |

## Output
- Architecture diagram (components + data flow)
- Health scorecard with scores and evidence
- Top 5 architectural risks ranked by impact
- Recommended improvements with effort estimates
