Decide what done will look like.
A check should answer the task's actual question. Before editing, state what observation would show the new behavior works and what neighboring behavior must remain stable. That turns verification into a concrete part of the iteration.
- 01
Match the check to the change
A parsing bug may need a focused regression test. A visual alignment change may need inspection at the affected screen sizes. A build verifies compilation, not every runtime outcome. Choose evidence proportional to the risk and the behavior you are changing.
- 02
Include a useful comparison
Check the reported failure and a nearby valid case. For an empty search result, verify that the empty state appears and that matching records still render. Avoid tests that merely repeat the implementation; prefer assertions about externally observable behavior or a meaningful module contract.
- 03
Record the limit of the result
State which commands ran and what each established. If an environment dependency prevents a check, report the missing evidence. Once the necessary checks pass, stop repeating them unless something changes or an unresolved concern justifies another run. More output is not automatically more confidence.
A useful finish
The acceptance condition is supported by a relevant observation, with untested behavior identified plainly.
A verification request
For [proposed change], identify the smallest meaningful verification and a nearby regression case. Explain what each check proves. Use existing project tooling. Report unavailable checks explicitly, and do not claim runtime behavior is verified from compilation alone.