verification-before-completion

Run the full verification command fresh—tests, builds, linting—after applying your fix. Read the results directly from the output, confirm the fix holds under regression testing, and only then claim completion. This prevents marking work done without evidence.

Enforce a verification gate: identify what needs testing, run the verification command, read the output yourself, verify the results match your claim criteria, then make your completion claim. This disciplined process reduces over-claims and improves accountability.

Run verification checks fresh at task completion, before release milestones, and whenever you claim a fix is done. Verification applies to tests, builds, linting, bug fixes, and governance checkpoints—any workflow context where completion requires evidence.

No. The verification gate requires running the complete verification command—tests, builds, linting, all steps—and reading the actual results. Partial checks create blind spots; fresh, full runs catch regressions and prevent unverified claims.

Define clear claim criteria upfront: what test pass rate, build status, or linting results constitute completion. Run verification fresh, evaluate results against those criteria, then report what you found. The evidence must exist before you claim the task is done.

Fresh verification catches regressions, environmental changes, and side effects introduced by recent work. Running the full suite again before claiming completion ensures your fix actually holds and hasn't broken something else.