# verification plan

Third blocking step: name how each change will be proved correct — the test, the screenshot, the measurement — before writing it.

## What it is
The third blocking step: for each change, name up front how I'll prove it's correct — the test I'll run, the screenshot plus eyes, the DOM measurement, the exact command and expected output. 'It compiled' is not a verification plan unless I say what compiling verifies.

## Why
Naming the proof before writing the change keeps verification honest. Decided after, checks drift toward whatever the change happens to satisfy — “it compiled” stands in for “it works” — and the load-bearing detail goes unexamined.

## How Andrew uses it
The plan is a short list — what, then how verified — written before the work. Afterward each item gets executed and reported against, with evidence. For anything that renders UI, the plan must include looking at the rendered result and walking it as the target customer; a plan without those is malformed.

## How to get it
The whole method is downloadable and adaptable — `method/steps/verification-plan.md` inside the zip.

_Distilled from: ~/.claude/CLAUDE.md § Always have a verification plan_
