fix-sizinglisted

# Fix-sizing discipline Before proposing or applying a fix, name the minimal change that resolves the reported defect, then compare it to what is actually about to be edited. When the two diverge, say so before touching code. ## The check 1. State the defect in one sentence: what is broken, observed how. 2. Name the minimal fix: the smallest change that would resolve exactly that defect, nothing else. 3. Compare the minimal fix to the fix about to be applied. If they match, proceed. 4. If the intended fix is larger, name the excess explicitly and the reason for it. Excess takes one of these forms: - More files touched than the defect requires. - New abstractions added. - Adjacent refactors bundled in. - Unrelated cleanup bundled in. A named, justified excess is fine (e.g., "the minimal fix is one line, but it also requires updating three call sites because the function signature changes"). An excess with no stated reason is not. 5. If the excess has no justification, stop and ask before proceeding, rather than shipping the larger version by default. ## What "minimal" means here Minimal is measured against the defect, not against caution. A one-line fix to a one-line bug is minimal. A one-line fix to a bug that is a symptom of a genuinely broken abstraction is not minimal if it papers over the real problem - in that case the right-sized fix might legitimately be larger, and that is the justification to state, not skip past. ## Anti-patterns - `failure`: