verification-before-completion

Verification Before Completion

Overview

Claiming success without evidence is guessing. "It should work" is not verification.

Core principle: ALWAYS run verification commands and confirm output before claiming work is complete. Evidence before assertions.

Violating the letter of these checks is violating the spirit of quality.

The Iron Law

NO SUCCESS CLAIMS WITHOUT RUNNING VERIFICATION COMMANDS

If you haven't seen passing output with your own eyes, you cannot claim it works.

No exceptions:

• Don't say "tests should pass" — run them
• Don't say "build looks fine" — build it
• Don't say "no lint errors" — lint it
• Don't say "changes look good" — diff them

When to Use

Always, before:

• Claiming work is "done" or "complete"
• Committing code
• Creating pull requests
• Closing issues
• Reporting success to teammates
• Moving to the next task

Use this ESPECIALLY when:

• Under time pressure (rushing guarantees missed issues)
• Changes seem trivial ("just a typo" can break builds)
• You've made multiple changes across files
• Refactoring existing code
• Fixing bugs (verify the fix AND no regressions)

Don't skip when:

• Change seems too small to break anything (small changes break things)
• You're confident it works (confidence ≠ evidence)
• You "already tested manually" (manual ≠ systematic)
• CI will catch it (catch it NOW, not after push)

The Four Phases

You MUST complete all four phases before claiming completion. Order matters.

Phase 1: Test Execution

Run ALL relevant tests, not just the ones you think matter.

# Run tests for affected area
npm test -- --coverage path/to/affected/
# OR
yarn test path/to/affected/

# Run full test suite if changes are cross-cutting
npm test

Verify:

• All tests pass (zero failures)
• No test warnings or errors in output
• Coverage hasn't decreased
• New code has corresponding tests
• No skipped tests you forgot to unskip

Test fails? Fix it. Do NOT proceed to Phase 2.