The 300ms ceiling moved to 2000 is a perfect example, because every individual step looks reasonable. The check was failing, the agent changed something, the check passed. The only thing missing was the question of whether the limit was allowed to move.

Your list of loosened guard patterns is worth turning into a review rule as it stands: threshold jumps, a throw turned into a warning, continue on error, equality turned into a range. None of them is always wrong, which is why they slip through.

Separating guard changes from code changes is the part I would push hardest. On client builds we treat thresholds as part of the agreed scope. They are written down when the work is defined, and changing one needs the owner's name and a reason in the same commit. An agent can still propose it, but it cannot quietly decide it.

Have you found a reliable way to detect a loosened guard automatically, or does it still depend on a reviewer noticing?