The guard and the tests around it pinned behavior that already existed.
fuzzy_find_and_replace rejects old_string == new_string at
tools/fuzzy_match.py:69-70, returning "old_string and new_string are
identical" — so main already answered success=False, and the three tests
asserting "identical" in the error passed with the guard deleted.
The earlier claim that this case "silently applies a no-op the model reports
as success" was wrong. Verified against main:
{"success": false, "error": "old_string and new_string are identical",
"file_preview": "..."}
The duplicate guard was also strictly worse: it fired before the skill
lookup and returned no file_preview, shadowing the richer message.
Removes the guard, the two identical-strings tests, and the third
parametrize case. What remains is the genuinely new behavior: an actionable
missing-old_string error, reachable through the public tool.
10e93c6ab9