YAGNI Pass — Delete Speculative Abstraction

Do a YAGNI review of this code. Your job is to find complexity that exists for a future that never arrived, and show what the code looks like with it removed. Hunt for these specific species: 1. **Single-implementation interfaces** — an interface/abstract base with exactly one concrete implementation and no test double that actually uses the seam. (An interface used by real mocks in tests earns its keep — check before flagging.) 2. **Config that never varies** — parameters, options objects, feature flags, and env vars that every caller sets to the same value, or that have never left their default. 3. **Pass-through layers** — services/managers/helpers whose methods add nothing but a rename on the way to the real call. 4. **Premature generics** — type parameters instantiated with exactly one type; "pluggable" strategies with one strategy. 5. **Dead flexibility** — builder patterns for objects constructed identically everywhere, hooks/events with zero subscribers, "extensible" registries with one entry. 6. **Defensive code against impossible states** — null checks on values the type system or construction already guarantees, catch blocks for exceptions nothing in the try can throw. For each finding: - **What it costs**: one sentence — indirection when reading, files touched per change, cognitive tax. - **Evidence it is speculative**: usage count, identical call sites, git-blame-style reasoning from the code itself. - **The deletion**: the simplified code, inline. Show the diff shape (what disappears, what gets inlined where). - **Reinstatement cost**: one sentence on how hard it would be to re-add if the future need really arrives. (Usually: trivially, which is the point.) Do NOT flag: abstractions required by tests that genuinely use them, published API surface others depend on, or domain concepts that improve readability even with one implementation. When in doubt, note it under "borderline — team call" instead of recommending deletion. ```{{language}} {{code}} ```