Detect over-engineered and overcomplicated code - code that works but is more complex than necessary.

Scope: report only over-engineering this branch introduces or makes worse. Pre-existing complexity the branch does not touch is out of scope. Complexity explicitly required by the plan ({{PLAN_FILE}}) is not a finding.

Skip generated code (mocks, protobuf/codegen output), vendored dependencies, and test fixtures.

## Excessive Abstraction Layers

- Wrapper adds nothing - method just calls another method with same signature
- Factory for single implementation - factory pattern when only one concrete type exists
- Interface on producer side - interface defined where implemented, not where consumed (applies to Go and other structurally-typed languages)
- Layer cake anti-pattern - handler -> service -> repository when each just passes through
- DTO/Mapper overkill - multiple types representing same data with conversion functions

## Premature Generalization

- Generic solution for specific problem - event bus for one event type
- Config objects for 2-3 options - options pattern when direct parameters suffice
- Plugin architecture for fixed functionality - extension points nothing extends
- Overloaded struct - one type handling all variations with many optional fields

## Unnecessary Indirection

- Excessive method chaining - builder pattern for simple constructions
- Interface wrapping primitives - custom types for standard library types
- Middleware stacking - multiple middlewares that could be one

## Future-Proofing Excess

- Unused extension points - hooks, callbacks, plugins with no callers
- Versioned internal APIs - v1/v2 when only one version used
- Feature flags for permanent decisions - flags always on/off

## Unnecessary Fallbacks

- Fallback that never triggers - default path conditions never met
- Legacy mode kept just in case - old code path always disabled
- Dual implementations - old + new logic when old has no callers
- Silent fallbacks hiding problems - catching errors and falling back instead of failing fast

## Premature Optimization

- Caching rarely-accessed data - cache for data read once at startup
- Custom data structures - complex structures when arrays/maps work
- Worker pools for occasional tasks - pooling for operations/hour
- Connection pooling overkill - complex pooling for single connection

Before reporting any 'unused', 'no callers', or 'never triggers' pattern, verify the absence with a project-wide search (including tests, registrations, and config-driven references) and cite the search result in the finding.

## What to Report

For each finding:
- Location: exact file path and line number
- Pattern: which over-engineering pattern detected
- Problem: why this adds unnecessary complexity
- Simplification: what simpler code would look like
- Effort: trivial/small/medium/large

For large-effort findings, recommend a follow-up plan instead of an in-review fix.
