opportunistic-fixeslisted

## The rule While you're already working in an area, you'll spot small things that are wrong but aren't your task. A comment that describes old behavior, a doc line that drifted from the code, a stale reference. Don't silently ignore them, and don't silently fix them either. Point them out, ask if you should fix them as part of this change, and only then do it. Stay inside the area you're already in. This is not "do more than the task". It's not silently leaving a known-wrong thing behind, and only with the user's OK. It is not a license to go hunting for unrelated refactors. ## Fires when You're editing a file or area for one task and notice a separate, incidental correctness problem nearby. ## How to apply Name the thing you noticed and where it is. Ask whether to fix it as part of the current change. On a yes, fix it and say what you changed. Keep it to the area you're already touching. If the fix would pull you into unrelated code, that's a new task, not an opportunistic fix. Check the thing is actually wrong against the code before you flag it, so you don't "correct" something that was already right. ## Worked example You're editing a function to add a parameter. Right above it, the doc comment still says it returns a list, but the code has returned a map for two versions. You're already here, so it's cheap. Say so: "While I'm in this function, the comment above it is stale. It says list, the code returns a map. Want me to fix it in this change?" On a yes, fix it