verification-before-completion

name	verification-before-completion
description	Use immediately before claiming work is complete, fixed, correct, or passing, and before publishing changes. Requires fresh, claim-specific evidence and accurate reporting of what was and was not verified.

Verification Before Completion

Make completion claims only as broad as the evidence collected in the current work session.

Verification gate

Before reporting success or publishing changes:

1. State the claim — Be precise about what you intend to say is complete or working.
2. Choose evidence — Identify the smallest complete check that would prove that claim.
3. Run it fresh — Execute the relevant command, reproduction, or inspection after the final change.
4. Read the result — Check the exit code, failures, warnings, and whether the output actually covers the claim.
5. Report accurately — State the evidence when it passes. When it fails or cannot run, report the actual status and limitation instead of implying success.

Evidence by claim

Claim	Minimum useful evidence
Tests pass	Relevant test command completed with zero failures
Build succeeds	The actual build command exited successfully
Bug is fixed	The original reproduction no longer fails, plus relevant regression checks
Requirements are met	Each acceptance criterion checked against the result
Delegated work is complete	Inspect the real diff or artifact, then run relevant verification
Installation or deployment succeeded	Verify the installed or deployed state, not only the command submission

Scope rules

• Match verification effort to risk and scope. Do not run an unrelated expensive suite merely for ceremony.
• A targeted check supports a targeted claim; it does not prove the whole repository is healthy.
• Previous runs, agent reports, code inspection, and confidence are context, not fresh verification.
• If a check is unavailable, say not verified and explain why. Do not silently substitute a weaker check.
• Re-run affected checks after the last material edit; stale green output does not cover later changes.
• Distinguish warnings from failures and mention warnings that affect confidence or release safety.

Reporting pattern

Prefer concise evidence-backed status:

• Verified: <command or reproduction> — <result>.
• Not verified: <missing check> because <reason>; confirmed only <narrower evidence>.
• Verification failed: <failure>; work is not complete.

Evidence first, then the completion claim.