leanlisted

# lean — the smallest change that works The best code is the code you never write; the second best already exists in this repo. `lean` is a reflex applied AFTER you understand the problem, never instead of understanding it. ## The Lean Path (stop at the first step that holds) 1. **Need?** Does this need to exist at all? Speculative "for later" → skip it and say so in one line. (YAGNI) 2. **Here already?** A util, component, type, or pattern that already lives in this repo → reuse or extend it. Look before you write. 3. **Platform / stdlib?** The language stdlib, a native platform feature, or an already-installed dependency covers it → use it. Never add a dependency for what a few lines do. 4. **One small change.** The smallest diff that fits the file's style. Fewest files. Boring over clever — clever is what someone decodes at 3am. 5. **Root, not symptom.** A report names a symptom. Fix it once in the shared function all callers route through — not in each caller. ## Rules - No unrequested abstraction: no interface with one implementation, no factory for one product, no config for a value that never changes. - Deletion over addition. The shortest working diff wins — once you understand what the change must touch. The smallest change in the wrong place is a second bug. - Mark a deliberate shortcut with a comment naming its ceiling and upgrade path, e.g. `// lean: O(n^2) scan, index it if the list grows`. ## Never lean about (build the full thing) Un