Use for releases, deployment, migration, production and CI changes.
- Establish exactly what is being delivered, to which environment, by whose authority, with which required reviews, checks and change window.
- Trace source revision -> build -> immutable artifact -> deployed identity. Record version/digest where available. Do not infer the running version from source files or a successful upload.
- Review CI permission and secret boundaries, especially untrusted pull requests. Keep required checks and environment protection intact.
- Define preflight, rollout, health checks, abort conditions, rollback or forward recovery, data backup/restore needs and responsible owner before the change.
- Reuse the project's delivery tooling. Observe the actual result of an authorized deployment and the relevant smoke/health checks. Avoid unrelated environment edits.
- Distinguish rollback of code from reversal of persisted data. Define post-release observation and support handoff; do not create ongoing automation unless requested.
Use explicit acceptance gates for required build, deployed-identity and live stages.
The helper's optional requires kinds can detect a declared build substituting for
live evidence, but cannot inspect the report or runtime itself. An explicit-file
snapshot helps identify dirty source; include relevant manifests/tests/instructions
and separately record artifact/environment identity. Unlisted inputs remain outside
that snapshot's coverage.
A successful command or healthy response can still come from the wrong artifact. Compare the staged/running identity with the expected built artifact and check the required behavior in that environment. After an abort, verify the restored artifact and its behavior; copying an old file alone is not rollback acceptance. This says nothing about reversing persisted data, which needs its own recovery.
For an upgrade, back up the scoped operator-owned settings, permissions/metadata and mutable files in a protected location. A sanitized package can still overwrite installed operator state. Compare relevant bytes, ownership/permissions and effective settings afterward; restore approved overrides from verified backups and recheck the affected behavior. State the comparison's coverage explicitly.
Verify served assets as well as installed files. An earlier successful request does not establish that a later client receives the same artifact. If fresh clients observe stale assets, use the project's supported cache invalidation within the authorized rollout scope; coordinate shared caches and recheck runtime identity. Do not infer cache internals or perform a service restart from that symptom alone.
delivery-readiness: artifact/source identity, required checks, rollout/recovery
plan and applicable authorization. This gate proves readiness only. If deployment
or live acceptance is in scope, add separate required gates for deployed identity
and observed runtime behavior; a successful build cannot satisfy those gates.