release-verification

Confirm the installed version matches the distributed version, redo the installation exactly as a user would, then check each acceptance criterion one by one. Record the executed command, exit code, timestamp, and result for every criterion.

Quality gates validate diffs in the development worktree before merge to prove no regressions. Post-release verification validates the distributed artifact through the user's installation path to prove acceptance criteria hold in the real environment.

Start only after distribution completes: when users can fetch the published package, the service deployment has propagated, the app binary is placed or store-approved, or the configuration change has been delivered. Running it earlier misses failures introduced by distribution itself.

No. Verification must be repeated per distribution stage because environments differ in data, configuration, and the distribution procedure itself. Results from staging do not count as production verification, and the target environment must be noted in the record.

Do not fix it in place. File the failure as a new change and route it through the normal development workflow, since a post-distribution fix is itself a new change requiring mode determination. Record the failure verdict before proceeding.

Mark them as pending with an explicit reason and a planned time for execution in the verification record. Never leave them blank, because an empty entry reads as already verified.