verification-before-completion

Verification requires running the exact command that proves your claim—like `npm test` for tests or a build command for compilation—reading its full output and exit status, and confirming the output substantiates your assertion. Only after this fresh evidence exists should you declare completion.

Run the regression tests or reproduction steps that exposed the original bug, review the full output to confirm they pass, and document the evidence. A bug is only fixed when the verification command succeeds, not when you believe the code is correct.

No. Confidence without fresh verification evidence violates the core discipline. Running verification commands prevents false positives and broken trust. Every completion claim must be backed by proof, regardless of confidence level.

Skipping verification causes false positives, wasted time debugging non-existent fixes, and erodes trust in your assertions. The five-step process—identify the command, run it, read the output, confirm it substantiates your claim, then declare completion—prevents this.

Before marking a pull request or build as complete, run the full test suite, linting checks, and build commands locally. Validate that all outputs show success, then document this evidence. This gates premature merges and prevents broken builds from reaching production.

Exit status alone can mask warnings, partial failures, or incomplete results. Reading the full output ensures you catch edge cases and confirms the evidence truly supports your claim, not just that a command terminated.