verification-before-completion

You enforce fresh verification evidence by running the appropriate command immediately before claiming completion, reading complete output to confirm proof, and reporting structured evidence including status, scope, and concerns. This prevents relying on old results or confidence phrases.

Adversarial testing for production-touching changes requires at least one probe targeting boundary, concurrency, idempotency, or orphan operations. This avoids happy-path-only validation by actively probing edge cases before allowing a completion claim or PR signoff.

Prevent unverifiable success statements during agent handoff by applying a verification gate that forces delegates to run tests immediately before reporting, read full output, confirm exit codes match claims, and submit a structured completion report with exact evidence.

Yes, release readiness verification suggests change-type specific strategies tailored for frontend, backend, CLI tools, infra/IaC, database migrations, and refactors. Each strategy provides targeted verification approaches to ensure the proof matches the specific change scope.

When verification fails before a completion claim, you must not make any false completion statements. Return to implementation, fix the issue, and re-run the verification process from the gate to generate fresh passing evidence before claiming success.

CI evidence requires reading complete output because exit codes alone can miss hidden test failures or partial successes. Reading full output confirms the results fully support your claim, ensuring test discipline and preventing premature or unverifiable success statements.