# Boundaries Review Lens

Review the provided code for **architectural boundary violations and misplaced responsibilities**.

## What to Look For

### Layer Violations
- Domain/business logic in controllers, handlers, or CLI commands
- Infrastructure imports (ORM, HTTP, cloud SDKs) in domain modules
- UI/API layer directly calling repositories, bypassing service layer
- Database queries or SQL fragments in business logic

### Dependency Direction
- Inner layers importing outer layers (domain importing infrastructure)
- Stable modules depending on volatile modules
- Core logic importing presentation or delivery concerns
- Framework dependencies leaking into domain code

### Domain Cohesion
- Anemic models (data bags with getters/setters, logic elsewhere)
- Business rules scattered across manager/helper/util classes
- Single class handling unrelated domains (User + PDFExport)
- Domain concepts represented as primitives instead of types

### Responsibility Placement
- Validation logic in wrong layer (UI vs domain vs persistence)
- Authorization checks scattered instead of centralized
- Formatting/presentation logic in data layer
- Configuration parsing mixed with business logic

## Output Format

For each finding:
```
[BOUNDARY] <severity:HIGH|MED|LOW> <file:line>
Type: <layer-violation|direction|cohesion|placement>
Issue: <what's in the wrong place>
Suggest: <move X to Y layer, extract to domain, inject via interface>
```

## Guidelines

- HIGH = architectural constraint violated, hard to test/change
- MED = responsibility drift, refactor when touching this code
- LOW = minor placement issue, could be cleaner
- Focus on *where* code belongs, not *how* it's coupled (that's coupling.md)
- Consider the intended architecture (MVC, Clean, Hexagonal) if evident
- Some boundary crossing is pragmatic - flag violations of *stated* patterns
