--- name: verify-change description: Verify a software change against acceptance criteria. Run relevant checks and report evidence, failures, and gaps. Use for verification requests or the verification phase of delivery; verification alone does not authorize fixes or publication. --- # Verify change Establish what the current candidate demonstrates and what remains unverified. Read the [shared workflow contract](../../references/workflow-contract.md) before starting. The plugin includes this reference. Keep its directory layout intact. ## 1. Establish the verification scope Identify the requirements owner, acceptance criteria, workspace, candidate, and explicit limits under the shared contract. Include relevant uncommitted inputs in the candidate identity. Reuse existing evidence only while its inputs remain valid. Inspect project instructions and executable check configuration. Establish which commands, environments, and side effects are authorized. Preserve existing work. Propose missing criteria or procedures for the selected owner; keep dependent verification pending when the expected behavior requires an unresolved decision. Done when each requested behavior has an authoritative expectation or an explicit gap, and the permitted verification actions are clear. ## 2. Select checks and assess their evidence Map acceptance criteria and material risks to existing checks. Apply the shared contract's test selection, original-failure, independent-oracle, and defect-detection requirements. Distinguish checks already supported by valid evidence from checks that still need execution. Test names and coverage totals do not establish acceptance. For integration/E2E and material regressions, verify stable case IDs using the project's generated catalog and validation. Check missing IDs, duplicate IDs, and duplicate definitions that test collection can hide. Require valid executable evidence that the checker rejects all three failures. Reuse evidence whose inputs remain valid; otherwise run probes in authorized disposable copies. If probes cannot run within scope, report a required validation gap. Supplement collection with source checks where needed. A handwritten mapping is not validation. If required coverage, test-ID validation, or defect-detection evidence is missing, report the gap and propose scoped work. Verification alone does not authorize editing the candidate, adding infrastructure, or installing dependencies. Done when each criterion and material risk has applicable evidence, an executable check, or a stated gap. Keep criterion IDs separate from test-case IDs. ## 3. Run authorized checks Before execution, record the current revision and content fingerprints for relevant code, tests, requirements, and check configuration. Use these as the checked baseline. Run checks that need new evidence through the applicable real caller or user interface. Use project procedures for readiness, instance ownership, isolation, side effects, and cleanup under the shared contract. Retain evidence before cleaning up resources the run created. Record the actual commands, candidate, relevant configuration and environment, results, and limitations. Classify setup failures separately from application failures. A substitute interface supports only the behavior it exercises. On failure, preserve the evidence and identify the affected criteria. Fixes require implementation or remediation authority. Continue useful unaffected checks within scope. Done when selected checks have recorded outcomes or explicit execution gaps. ## 4. Check freshness, report, and stop After checks finish, obtain the current revision and content fingerprints again. Compare them with the checked baseline, including relevant staged, unstaged, and untracked contents. Include relevant requirements, configuration, and environment changes. HEAD and Git status alone cannot establish unchanged contents. Renew affected evidence when inputs change. Keep superseded results bound to their earlier candidate. Return the candidate checked, criteria-to-evidence mapping, actual results, limitations, freshness outcome, and next action. Distinguish pass, fail, pending, unavailable, and inconclusive. Report any freshness comparison that could not be completed; do not claim unchanged inputs without observed evidence. Report the observed before/after identities and comparison result. Without that comparison, report freshness as unverified and verification as incomplete. Done when every requested criterion has a supported result or explicit gap. Failed, unavailable, or inconclusive required checks leave dependent delivery incomplete. Verification does not replace independent review or authorize publication. For a standalone request, stop here. A separately authorized delivery workflow can continue under the shared contract.