verify-before-done

Verify Before Done

A claim of "fixed", "done", "passing" or "deployed" needs evidence from this session: a command you ran, its output, and the resulting state you inspected. Finding the cause of a failure is systematic-debugging; writing the failing test first is test-driven-development.

When to Use

• About to tell the user something works, is fixed, passes, or is live
• About to commit, open a PR, close a task, or mark a todo complete
• A subagent, CI job or script reports success and you are about to relay it
• After a deploy, migration, config change or service restart

Don't use for: exploratory answers that make no claim of completion.

Evidence Table

Procedure

1. Name the claim and the path. Write one line: the claim, and the exact path a user takes to hit it (URL and method, CLI invocation, screen and button, job and input). Done when someone else could repeat the path from that line.
2. Pick a check that can fail. It must go red if the claim is false. Prefer the user's path over a proxy:
   • A green build or passing CI proves it compiles and the existing tests pass. Run the feature itself.
   • Test the write path, not only a read. A GET smoke test passes while uploads, saves and form posts are broken.
   • Test the value the consumer reads. Two components can each pass their own tests while the integrated output never changes. Check the rendered value, the table row, the bytes in the file.
   • For a bug fix, reproduce the original symptom first, then show it gone.
3. Build clean for anything shipped. An incremental build can ship stale code. Wipe the build output or build in a fresh checkout before producing the artifact you deploy, then confirm the artifact's version string or timestamp matches this build.
4. Run it fresh. Run the full check now with terminal. Output from before your last edit does not count. Done when you have the command, its exit code and its output from this session.
5. Inspect the resulting state. "Deployed", "Saved", "0 errors" and exit 0 are the tool's claims. Query the database row, read_file the written file, fetch the deployed page and compare its version, list the uploaded object, or take a screenshot with the browser tools and check it with vision_analyze.
6. Treat a quiet log as no evidence. Crashes can exit before writing a line, and log rate-limiting drops lines. "No errors in the log" counts for nothing until step 5 passes.
7. Check delegated claims. A subagent's or CI's "done" is a claim. Re-run its verification command or inspect the end state it describes.
8. Report with scope. For each claim state the exact path exercised, the command and result, and a Not verified: line naming what you left unchecked (other platforms, roles, the email step, production data). If a check failed, say so and show the output.