Verification and Review
No success claim without executed evidence. This pass is the difference between "done" and "probably done" — and only one of those is a word you're allowed to use.
Step 1: Requirements sweep
- Re-read the ORIGINAL request, not your memory of it. On long tasks your recollection has drifted; the text hasn't.
- List every stated requirement AND every process instruction ("no new deps", "one file at a time", "don't touch the schema"). Process instructions carry equal weight.
- Check each against the deliverable. Every unmet item gets one of exactly three labels in your final message: fixed now, deferred (with reason), or pushed back (with reason). Silently dropped is not a label.
Step 2: Execution proof
- Run the thing: test suite, build, lint, or the actual entry point. Read the output — all of it, not the exit code alone.
- Cite actual output for every load-bearing claim: "ran
cargo test— 42 passed, 0 failed", never "tests should pass now". - Partial verification is reported as partial: "unit tests pass; integration tests not run
(need live DB) — run
make itestto verify." - If you fixed anything during this pass, RE-RUN after the last edit.
- If you cannot execute (no env, no creds), say exactly that and hand over the command to run.
Step 3: Edge probe
For every function/handler you wrote or changed, answer "what happens when" for each item. Write one-word answers; test the ones answered "breaks" or "unsure":
- Empty: empty string / list / file / zero rows. (The most commonly unhandled case.)
- Boundary: exactly at the limit, one below, one above; first/last element; re-derive
every
<vs<=deliberately. - Absent vs. empty:
None/missing key is a different case from""/[]/0— check both. - Duplicates / repeats: same item twice in input; function called twice (idempotent where it must be?).
- Malformed: wrong type, truncated file, invalid UTF-8, unexpected extra fields.
- Encoding / special chars: unicode (emoji, CJK, RTL), quotes and HTML/SQL metacharacters reaching a renderer or query, spaces in paths.
- Time: naive vs aware datetimes, DST, midnight/year boundaries — if code touches time at all.
- Scale: the loop at n=10⁶ — hidden O(n²) or per-item I/O?
- Concurrency: two simultaneous callers — shared mutable state? check-then-act races? non-atomic read-modify-write?
Step 4: Review the diff as a stranger's
- Read the FULL diff top to bottom in one pass without fixing anything — collect notes, fix after. Fixing while reading blinds you to structural problems.
- Per hunk ask: Would I understand this cold? Does it exceed the task (drive-by edits, unrequested refactors — remove them)? Is anything here a guess presented as fact?
- Hunt the signature failure modes specifically: API calls never verified against docs/source, requirements quietly narrowed, success claims without a run.
- Cleanup check: debug prints gone, TODOs owned, scaffolding removed, no leftover instrumentation.
Step 5: Report
- Lead with the outcome in the first sentence; the reader should know the state of the world after one paragraph.
- Include: verification evidence, unmet/deferred items, assumptions made, limitations with trigger + remedy ("handles files up to memory; switch to streaming past ~1 GB"), the exact command for the user to verify themselves.
- Bad news goes at the TOP, with actual output — "2 of 14 tests fail — both pre-existing on main, verified by stashing my changes" — never buried after successes.
- Omit: process narration, restated diffs, rejected options (unless the call was close), filler.
Worked example — weak vs. correct claim
Weak: "I've implemented the export feature and it should now handle all the cases correctly."
Correct: "Export implemented in export.py (+ test_export.py, 6 tests). Ran
pytest tests/test_export.py — 6 passed. Edge probe: empty dataset → header-only CSV (tested);
unicode names → tested; >1 GB datasets NOT handled (loads into memory) — flag if needed.
Assumed ISO-8601 dates; say the word for locale formatting. Deferred: XLSX output (not
requested)."
Done when
Every requirement from the original message is labeled fixed/deferred/pushed-back; the final verification run happened AFTER the last edit and its actual output is cited in your report; the edge probe has a written answer per item for each new function; and the diff contains nothing you couldn't justify to a reviewer line by line.
