fix(patch): reject wrong-region matches in the fuzzy edit fallback

[MaxFreedomPollard]

Fixes #54572

Problem

The patch tool in replace mode locates old_string through the nine strategy chain in tools/fuzzy_match.py. The last two strategies, block_anchor and context_aware, accept a region based on a shared first and last line (with a 0.50 middle similarity) or on half of its lines matching. They run only after the seven formatting-tolerant strategies have failed, which means old_string is genuinely not in the file at that point. When one of them fires, the tool replaces a region whose content differs from old_string and returns a successful single match. patch_replace verifies that the bytes it wrote landed, but not that the matched region was the one described, so the wrong edit is not caught.

A concrete case: a file whose middle line is audit_log(request.user_id), edited with an old_string that names validate(request.token) (a line not in the file) but shares the surrounding two lines. block_anchor matches, the audit_log line is replaced, and the call reports success.

Fix

After a match is produced by one of the two content divergent strategies, drop any matched region that is not substantially the same text as old_string, comparing with unicode form and whitespace runs normalized away (_normalized_similarity, floor 0.90). Legitimate reflow, indentation and smart quote drift normalize to about 1.0 and still match. A region that merely shares an anchor line falls below the floor, so the match is discarded and the chain falls through to the existing no match path, which already attaches a "did you mean" hint that prompts a re-read.

The guard runs after the existing escape-drift check, so the more specific escape-drift error still wins where it applies.

This is intentionally narrow. The seven formatting-tolerant strategies are untouched, since they already guarantee the region equals old_string apart from formatting. A genuine near miss where a single line drifted stays well above the floor and still applies, so real edits are not regressed.

Tests

tests/tools/test_fuzzy_match.py:

• the block_anchor wrong-region case leaves the file unchanged and reports no match,
• the context_aware half-matching case preserves the two unrelated lines,
• a single line drift in an otherwise identical block still applies.

The full file suite passes (53 tests).

[teknium1]

Thanks for the focused guard. The premise is confirmed on current main: block_anchor accepts shared-boundary candidates at the 0.50 middle-similarity threshold (tools/fuzzy_match.py:665-691), while context_aware accepts a block when only half its lines are highly similar (tools/fuzzy_match.py:716-726). fuzzy_find_and_replace then applies the selected spans (tools/fuzzy_match.py:85-153).

Problems

• The new coverage is limited to fuzzy_find_and_replace in tests/tools/test_fuzzy_match.py. The externally visible mutation path is ShellFileOperations.patch_replace (tools/file_operations.py:1590-1616), so the no-write guarantee is not exercised through real file I/O.

Suggested changes

• Add a live patch_replace regression in tests/tools/test_file_tools_live.py using the wrong-region fixture and assert both an error/no replacement and unchanged on-disk contents. The neighboring live tests establish this convention at tests/tools/test_file_tools_live.py:281-301.

Automated hermes-sweeper review.

[teknium1]

Please also cover this fixture through ShellFileOperations.patch_replace and assert the file remains byte-identical. This is the user-visible mutation path, whereas this test only verifies the pure matcher.

[Likivik]

Wrote a live test for the no-write guarantee:

• test_block_anchor_wrong_region_is_rejected — calls patch_replace through real file I/O. old_string shares first/last lines with the file but the middle differs. Fails on main with the expected silent-replace diff; passes on your branch.
• test_legitimate_rescue_still_applies — sanity check that real edits (indent drift + value change) still apply.

Commit: Likivik@7610ac4ca

Disclosure: I wrote this test (and this comment) with help from an LLM. Reasoning is mine; wording has been polished.

Cherry-pick 7610ac4, or merge Likivik:fix/fuzzy-match-wrong-region — whatever's easier. Thanks.

[MaxFreedomPollard]

@Likivik thank you, this is exactly the coverage the review asked for and it is a nicer test than the one I would have written. Cherry-picked as c6c85d8 with your authorship on the commit, and rebased the fix onto current main at aae5298.

I checked your claim rather than taking it on trust, and it holds: with the fix reverted, test_block_anchor_wrong_region_is_rejected fails on clean main with patch_replace returning success=True and no error for a wrong-region match, and test_legitimate_rescue_still_applies passes throughout. So it fails for the right reason and the sanity case shows the guard is not just rejecting everything.

That closes @teknium1's point directly. The gap was that the coverage stopped at fuzzy_find_and_replace in test_fuzzy_match.py while the externally visible mutation path is ShellFileOperations.patch_replace, and your test goes through real file I/O and asserts the on-disk bytes are untouched, which is the part that actually matters for a no-write guarantee.

The rebase conflict was a clean one, main added is_already_applied and _format_match_locations in the same region where this branch adds _CONTENT_VERIFIED_STRATEGIES and _normalized_similarity, so both sides are kept.

81 tests pass across test_file_tools_live.py and test_fuzzy_match.py.

Thanks also for the note about how you wrote it. Appreciated, and it did not change how I reviewed it, the test either reproduces the bug or it does not, and this one does.