verification-before-completionlisted

# Verification Before Completion Use this capability when a change appears complete but the claim still needs evidence. The goal is not to run every possible check. The goal is to produce the **smallest sufficient evidence set for the exact claim being made**. ## Core Principle > The strength of the completion claim must never exceed the strength of the evidence. A passing unit test can support a narrow behavior claim. It cannot by itself prove that a production deployment succeeded, that an external provider ingested an event, or that a user journey works end to end. ## 1. Define the Claim Boundary Before verifying, state what is actually being claimed. Useful claim levels include: 1. **implemented** — the intended code/configuration change exists; 2. **locally verified** — relevant repository-native checks passed in the available environment; 3. **deployable** — build/package/configuration evidence supports deployment readiness; 4. **deployed** — deployment execution itself was observed to succeed; 5. **post-deploy verified** — relevant production/runtime behavior was observed after deployment. Do not collapse these states into a generic "done". If the task did not include deployment, do not imply deployment occurred. ## 2. Re-read the Acceptance Contract For every applicable acceptance criterion, identify: - what observable fact would prove it; - what test, command, inspection, runtime observation, or external evidence can establish that fact; - what evidence