06 / Verify the behavior
A check should answer a real question.
Verification is most useful when each check has a purpose. A formatter can confirm formatting; it cannot prove a saved setting survives a reload. Choose evidence that matches the changed behavior and the places where a regression could travel.
Match the check to the boundary
For a parser change, exercise representative valid and invalid inputs. For a storage change, verify the write and a subsequent read. For a visible interaction, inspect the relevant screen sizes, focus behavior, and failure state. Changes to shared helpers deserve checks of their callers as well as the helper itself.
Make the result legible
Record the command, result, and anything that prevented it from running. "Tests pass" is incomplete when only one unrelated test ran. If a dependency or service is unavailable, mark the affected check as unverified and explain the consequence. Recheck after a meaningful correction; avoid adding ritual tests that merely repeat implementation details.
A starting prompt
Evidence for this patch: - Type check: command and outcome - Focused behavior check: command and outcome - UI inspection: states and widths inspected - Not verified: missing service or other limitation