niksavis Validate as a consumer
VERIFY already ran the deterministic checks and they are green. That is the entry condition to this state, so a transcript that re-runs them proves nothing anybody did not already know.
The test that decides whether you validated anything: could your transcript have been produced without the change? If yes, you re-ran the suite.
Three questions, in order
- Does the demonstration line do what the child claimed? Type the command. Make the request. Read what it prints.
- Does it satisfy the acceptance criterion, or merely execute without error? A criterion satisfiable without the behaviour is the failure mode to watch for — that is the whole reason each criterion names its own check at plan time.
- What does a consumer hit that nobody building it would? A missing prerequisite, an error naming an internal path, an instruction that assumes the repository you do not have.
The operational environment is part of the test
A consumer has no worktree, no fixtures, and no knowledge of the implementation. Where the change ships to a consumer, exercise it there: a fresh directory, an install, the documented command. Two recorded defects on this repository were invisible from the source tree — a projected file over a budget the local config raised, and a restart notice telling consumers to do something they do not need to do.
Read the requirement, not the change summary
The summary is the builder's account of the work. You are checking the work against what was asked, and those diverge quietly.
Paste output, never describe it
A described result is a claim about a result. The transcript is the artifact, and it is worth exactly as much as the literal bytes in it.
Do not fix what you find
A defect you repair is a defect nobody measured, and the rework ledger is how this harness learns where it fails. Report it and stop.