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 - more files, new abstractions, adjacent refactors, unrelated cleanup - name the excess explicitly and the reason for it (e.g., "the minimal fix is one line, but it also requires updating three call sites because the function signature changes"). A named, justified excess is fine. 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`: touching files unrelated to the reported defect without naming why, in the same change. - `failure`: introducing a n