architecturelisted

# Architecture & Refactor Judgment Samuhlo's stance for **design/refactor decisions** (sdd-design phase, restructuring, choosing whether to use a pattern). This is a **judgment** skill, not a pattern catalogue: the model already knows the GoF patterns — your job is to apply restraint and Samu's preferred structure, not to recite them. Use it when: refactoring, defining or fixing a project's structure, deciding "what pattern fits here", or reviewing an over/under-engineered design. ## 0. Core stance (read first) - **Simplicity wins by default.** The best design is the one that's easiest to change and to test, not the one with the most patterns. - **A pattern must earn its place.** Add it only when it removes *real, present* pain (duplication, rigidity, untestability). Never speculative ("might need it later"). - **YAGNI + rule of three.** Don't abstract until the third real occurrence. Two is a coincidence; three is a pattern. - **In TS prefer functions and modules over class hierarchies** unless you genuinely need shared state + polymorphism. A `Strategy` is often just a map of functions; a `Factory` is often just a factory function. - **The test of a good abstraction**: naming it makes the code *easier to change*. If it doesn't, delete it. A wrong abstraction is more expensive than duplication. - **Refactor incrementally.** A whole-project refactor is **a roadmap of bounded slices**, never one mega-change: one slice = one SDD = one PR, each small, testable and reviewable