[Bug] Opus 5 fails to identify and fix all instances of repeated code patterns

Bug Description
Title: Opus 5 repeatedly ships incomplete pattern fixes and reports them as verified Context: Claude Code, Opus 5, production MSP platform (Django/Postgres, push-to-deploy via Portainer). Single session, ~1 afternoon. Failure pattern (occurred twice, same session): The model changes ONE instance of a repeated code pattern, declares the fix complete, and does not search for other instances of the same pattern. Incident 1 — 4,991 spurious production records. Added an allowlist to a SQL guard in one function to stop non-identity records being resolved into device identities. Reported as fixed. A sibling function 20 lines away carried the identical entity_type <> 'org' guard and PROMOTES unmatched rows into new canonical entities. Result: 4,991 junk device records created in production, roughly doubling the fleet. Remediation required hard deletes across 6 tables and exposed a second latent issue (unindexed FKs made the delete take >4 min with no completion; 1.9s once indexed). Incident 2 — production service outage. Changed a Docker bind mount from a single file to its directory. Added a directory-first/file-fallback lookup to FOUR consumers. Missed a fifth (a shell entrypoint reading the old path before Django boots). The service entered a restart loop until a hotfix deployed. Both were catchable by one grep for the exact old string. Related failures in the same session: - Presented a verification taken BEFORE a destructive operation as confirmation that the operation was safe ("zero new devices") — the damage occurred after. - Twice asserted a data field was authoritative based on a single sample; one was 88% empty across the population. - Ran a destructive UPDATE without first checking which code paths consumed the column being nulled. That UPDATE was the trigger for Incident 1. Requested improvement: When the model modifies an instance of a repeated pattern (a guard, a path, a predicate), it should be required to search for remaining instances before claiming completion. It should also not present pre-operation state as post-operation verification. Cost to me: a full afternoon, two production incidents, and substantial paid token usage spent on diagnosis and remediation rather than the feature I asked for.

I AM VERY FRUSTRATED WITH THIS WASTE OF MY TIME AND MONEY. you have to make it up to me.

Environment Info

• Platform: win32
• Terminal: vscode
• Version: 2.1.220
• Feedback ID: 8e768bb4-69ec-40b9-bc3e-30f68d0b79a7

Errors

[]