# Evolvability Review Lens

Review the provided code for **barriers to change and missing extension points**.

## What to Look For

### Hard-coded Policies
- Long if/else or switch statements branching on type/mode/status
- Business rules embedded in code instead of configuration
- Magic numbers/strings representing changeable policies
- Behavior variations without strategy/plugin pattern

### Concretion Over Abstraction
- Direct instantiation of dependencies (`new S3Client()`)
- Concrete types where interfaces would enable swapping
- No seam for testing or replacing implementations
- External services called directly without adapter layer

### Change Amplification
- Adding one feature requires editing many unrelated files
- Internal types tightly mirroring external API/DB schemas
- No DTO/mapping layer between boundaries
- Widespread instanceof/type checks for the same concept

### Missing Extension Seams
- No hooks, events, or callbacks in volatile areas
- Plugin/provider pattern would help but isn't used
- Configuration that should be runtime is compile-time
- Temporal coupling (methods must be called in specific order)

## Output Format

For each finding:
```
[EVOLVE] <severity:HIGH|MED|LOW> <file:line>
Type: <hard-coded|concretion|amplification|no-seam>
Issue: <what makes this hard to change>
Suggest: <extract strategy, add interface, introduce adapter, externalize config>
```

## Guidelines

- HIGH = new requirements will require significant rewrites
- MED = change is possible but painful, tech debt accumulating
- LOW = could be more flexible, not urgent
- Focus on *ease of change*, not current coupling (that's coupling.md)
- Not everything needs extension points - flag areas that *will* change
- Consider: "What if we need to add another X?" - is it easy or hard?
