engineering-craftlisted

# Engineering craft — code the maintainers would approve The counterpart to `minimalism`. Minimalism asks *"is this the least code that works?"*; craft asks *"is the code that remains well-structured, honest, and safe to change?"* The target is the intersection: the **smallest change that a careful reviewer would approve without asking you to redo it**. This is a lens, not a stage — apply it while you implement, and confirm it in `self-review` before submitting. Craft is never a licence to add code. When craft and minimalism seem to disagree, they don't: the rule below (real repetition, not speculative) resolves it every time. ## The craft bar (hold all of these) 1. **Reuse only real repetition — never speculative abstraction.** DRY applies to duplication that *already exists* (the same logic in two places you can see). Do NOT introduce a base class, generic, config system, or "flexible" helper for a second caller that doesn't exist yet — that's the over-engineering `minimalism` forbids. Rule of thumb: extract on the *third* occurrence, inline the first two. When you do extract, give the shared unit one clear responsibility. 2. **Boundaries at the edges.** Keep transport (HTTP/CLI), business logic, and persistence (DB/filesystem) separable — don't put a SQL query or a `fetch` in the middle of domain logic. Depend on the seam the repo already uses; don't invent a new layering the codebase doesn't have. 3. **Handle errors explicitly — no silent failu