Did the test catch the change you actually made?
Why it matters
When reviewing an AI-assisted fix, you need to explain which failure the test catches. A red test alone does not answer that question.
Reading note
Matt Pocock’s October 7 debugging update adds a check: if you deliberately alter code or test data to make a test fail, compare it with an unchanged copy first. This confirms the edit happened; the failure still needs to match the intended bug. This is workflow guidance, not measured performance evidence.
Before this step: Repository · Acceptance criteria
“prove the mutation landed before you trust it.”One English pattern
The test failed because …, which confirms …; it does not establish ….Here, red means a failing test, and mutation means a deliberate change to code or test data. Use “because” for the observed cause and limit what “confirms” claims. The sentence pattern is our teaching example.
In a disposable practice file, create an isAdult(age) function using age >= 18 and a test expecting isAdult(18) to be true. Confirm it passes. Save an unchanged copy, change >= to >, and inspect the diff. Run the test and check that the age-18 assertion fails, not a setup step. Restore the condition and confirm it passes again. In English, record the change, the observed failure and one case this test does not cover.
Check your draft
Did you explain the mechanism, name a condition, and make a concrete work decision? Saving records your draft, not a mastery score.