verification-before-completion

Verification-before-completion requires running the full test, build, or reproduction command, reading its output and exit status, confirming the evidence matches your claim, then reporting success only with that evidence. For example, run the failing test, confirm it passes, then state the fix is complete with the output proof.

Running verification commands eliminates false completion claims and rework. This practice catches logic errors, edge cases, and integration issues that code review alone misses, ensuring every assertion about task status, passing tests, or fixed bugs is backed by fresh, explicit evidence.

State your claim with supporting evidence: 'All tests pass [See: 34/34 pass]' or 'Build succeeds [See: exit status 0]'. This evidence-based reporting builds trust, eliminates ambiguity about work status, and provides a clear record before commits or pull requests.

No. Verification-before-completion acts as a mandatory gate: you must identify, run, and read the output of a command that proves your claim before stating any status. This prevents rationalization excuses like 'should work now' and ensures rigorous completion checks.

By mandating explicit verification before completion claims, this practice catches issues early, prevents false positives, and ensures code quality gates are actually met. Fresh command output and exit-status checks replace assumptions, reducing downstream debugging and failed deployments.