verify-release
Verify release
Establish that the intended change is serving in the intended environment and that its agreed behavior works there. Keep the verification proportional to the change. Use the repository's existing deployment tools, tests, and observability; no particular provider, framework, browser, or telemetry service is required.
Carry forward the request
Recover the target environment, candidate release, expected behavior, selected checks, and existing authorization from the request and any tracker or handoff. Inspect deployment configuration and the relevant diff only as needed to fill gaps. Ask only for a consequential choice you cannot establish; do not repeat settled scope or permission questions.
Identify the components and dependencies that actually serve the selected path. Do not make unrelated or intentionally disabled services gates. Keep environments and test identities separate. A preview result proves only what that preview exercised.
Establish the live candidate
Map the intended change to an immutable deployed identity: commit, image digest, build ID, package version, or equivalent. Use the release manifest when components have different versions; do not require every component to share one SHA. A merge commit may differ from the PR head: establish the mapping instead of assuming a mismatch or equivalence.
Check the deployment's state and its running artifact, not merely a green CI job or a completed deploy label. Where available, corroborate with a live version endpoint or fresh runtime evidence. A missing version endpoint is not itself a defect if another trustworthy source proves the running artifact. If identity cannot be established, report that gap instead of claiming the candidate passed.
If rollout is still progressing, use bounded waits appropriate to its normal duration and continue independent checks. Resume dependent checks as soon as their prerequisites pass. Stop unchanged retries when evidence shows failure, unavailable access, or an exhausted execution limit. State the next diagnostic or resumption condition. Claim ongoing monitoring only when a real monitor is running, with an owner and a way to retrieve its result; otherwise save a resumable checkpoint.