design-review-lenslisted

# Design Review Lens The comprehensive checklist for a design review pass. Every item is a question about the diff, not a definition. Type-level thresholds that count as automatic findings: a type exceeding ~300 lines or ~15 stored properties, holding state with two different lifetimes, or gaining a responsibility its name doesn't cover. **SOLID (Robert C. Martin, "Uncle Bob")** - **SRP** — one reason to change, one actor per type; the thresholds above apply. - **OCP** — is new behavior added via new types/cases, or by editing every existing `switch`? A diff that touches N sites to add one concept is a finding (shotgun surgery). - **LSP** — do subtypes and protocol conformances honor the full contract? Strengthened preconditions, weakened guarantees, or "not supported" stubs are findings. - **ISP** — is any consumer forced to depend on members it never calls? Fat protocols split along client lines. - **DIP** — does high-level policy import low-level detail? Dependencies point at abstractions the *consumer* owns; a library stays consumer-agnostic. **Clean Architecture (Uncle Bob) — boundaries** - Source dependencies point inward: domain ← application ← infrastructure/UI. Framework types don't leak across a boundary; boundaries cross with plain data. **GRASP (Craig Larman)** - **Information Expert** — does behavior live with the data it needs? A method interrogating another object's state to decide belongs on that object. - **Creator** — are instances created