Release Identity and Version Checks

The latest successful attempt does not prove that your attempt succeeded. Releases, asynchronous jobs and external submissions need results tied to an explicit operation and source identity.

The shared-queue problem

Dispatching a job and then taking the latest list entry can select an older run or another operator’s attempt. Even the same SHA can have multiple executions. Save the operation id when the API returns one. Otherwise, correlation needs the task type, intended source and a unique new record; ambiguity cannot count as success.

How current releases bind source

scripts/hotfix-deploy.sh now delegates directly to the hotfix lane in scripts/local-prod-deploy.sh. The entry point requires the intended local-main commit to have been pushed to remote main, then freezes source and the component plan. Later steps must not select new source from a moving branch name.

Game-runtime releases also obey the human-table protection rule. Static website releases have a separate scripts/website-deploy.sh path. Follow docs/ops/RELEASE.md.

Check execution and public effect separately

Read /readyz and public provenance for the scope actually released. The app’s build-stamp.txt and the website’s release-source.json and release-components.json expose version information. A website-only release does not require unchanged H5 and backend components to adopt the website’s new SHA.

The reusable sequence is to freeze the target, retain the attempt identity, verify that its result belongs to that operation, then check the version users can reach. A green entry alone cannot prove this delivery.