verify-and-ship

Verify and Ship

After implementing your changes, follow these steps to verify quality and ship the work.

1. Acceptance Criteria Validation (CRITICAL)

Use the issue tracker get_issue tool to fetch the current issue details. Extract ALL acceptance criteria from the issue description and verify each one is satisfied by the implementation. If no explicit criteria exist, validate against the implied requirements from the issue title and description.

2. Quality Checks

Choose validation by changed behavior, risk, and existing coverage. Verification is required; new automated tests and a full-suite run are not required for every change. Follow repository-specific checks and CI gates where applicable.

• Direct verification — For routine release scripts, packaging/build metadata, CI, documentation, and instruction edits, prefer syntax checks, a safe dry run, artifact inspection, an isolated install smoke check, or a consistency review when those are sufficient. Record the command/result or review performed in the PR; no new test file or validation report is needed merely to show work.
• Automated tests — Run relevant existing tests. Add or retain a regression test only when it catches a concrete consequential failure and its protection justifies its maintenance. Examples include publishing the wrong artifact, unintentionally moving stable tags, or accepting invalid release evidence. Explain the failure each new test catches. Do not add brittle assertions on documentation wording or source text, tests that mirror implementation, or elaborate scaffolding for low-risk edits. A script filename alone neither requires tests nor exempts consequential behavior from protection.
• Scope — Broaden testing when shared behavior, failures, or unresolved risk warrants it; do not automatically run the full suite or generate coverage reports. Once sufficient checks pass, stop repeating them unless changes or new evidence justify another run. Investigate relevant failures rather than retrying unchanged commands. Report any unresolved failures honestly.
• Lint, types, build — Run checks relevant to the changed files and required repository gates. Fix introduced failures.
• Review — Check correctness, scope, and maintainability, including whether proposed tests provide useful protection.