Freeze the requested change and exclusions

Start the release packet before another agent run changes the diff:

  • user-visible outcome and critical workflow;
  • files and components allowed to change;
  • data, identity, integration, and infrastructure boundaries;
  • production credentials and customer data that are excluded;
  • human change owner and staff-engineer reviewer; and
  • done criteria, failure signals, and recovery owner.

OpenAI's current Codex best practices recommend giving the agent a goal, relevant context, constraints, and a testable definition of done. Those inputs improve scope and reviewability; they do not constitute release approval.

Put durable rules in the repository

Record build commands, test commands, conventions, prohibited actions, and verification expectations in repository guidance. OpenAI documents AGENTS.md as a layered source of durable instructions, with guidance closer to the working directory taking precedence.

Review the effective instructions with the diff. A chat instruction that was never retained is weak handoff evidence, while a checked-in rule can still be wrong or incomplete. The human owner remains responsible for matching the change to the application and environment.

Review a bounded diff

Bind review to an exact revision. The change owner should explain:

  1. what behavior changed and why;
  2. which trusted boundaries receive input;
  3. which persistent data or external effects can change;
  4. which generated or hand-written tests cover the risk;
  5. which assumptions remain environment-specific; and
  6. how to disable or reverse the change.

Reject unrelated edits, hidden dependency changes, unexplained generated files, and mutable artifact labels. If the diff changes after approval, review the new diff; approval does not follow a branch name.

Test the critical workflow and its failure cases

Run the smallest test set that demonstrates user-important behavior and likely failure:

  • least-privileged success;
  • missing, invalid, duplicate, and oversized input where relevant;
  • authorization denial;
  • dependency timeout or error without false success;
  • retry or replay without unintended duplicates;
  • partial failure with explainable state; and
  • recovery or containment after a controlled failure.

Generated tests are useful only when their assertions would fail for the bug or risk they claim to cover. Have someone other than the generating actor own at least the critical acceptance path.

Build an isolated preview

Create one preview from the approved revision using approved non-production configuration. It must not read or mutate production data merely because the URL is temporary.

Have the reviewer execute the critical workflow from a clean session and retain the preview result. Record environment, revision, test identity, time, and limitations. Stop if the workflow needs a production credential or an unapproved destructive action.

Promote one identified artifact

Build once, calculate or obtain an immutable artifact digest, and retain a receipt that binds:

{
  "revision": "<reviewed revision>",
  "artifactDigest": "sha256:<digest>",
  "environment": "<target>",
  "actor": "<human or service identity>",
  "result": "success or failure",
  "time": "<timestamp>"
}

Do not rebuild changing inputs between preview and promotion. GitHub's current environment documentation describes protection rules, required reviewers, branch restrictions, and environment secrets. Those controls can implement parts of the gate, but the packet must record what the selected repository actually enforces.

Run one safe failed-promotion scenario. The prior live identity should remain known, and the failure should leave a visible record rather than ambiguous partial success.

Prove what is running

Expose a minimal operator endpoint or equivalent provider command returning revision, artifact digest, and environment. Compare it with the successful promotion receipt after release.

Reject a stale, altered, failed, or unrecorded receipt even when one field matches. A matching identity proves which bounded artifact is running; it does not prove health, data compatibility, authorization, or dependency behavior.

Rehearse rollback and data recovery separately

Application rollback should promote a known prior artifact and create a new receipt. A source revert instead creates a new revision and artifact. Record which action the team means.

Before rollback, check schema compatibility, configuration, queues, caches, and external effects. Restoring an old artifact does not restore application data. Name separate authorities and procedures for code rollback and data recovery.

Evidence boundary for this draft

On August 4, 2026, the local P23, P24, and P61 fixtures passed 24 tests: seven for draft/live promotion, six for interrupted-write and snapshot recovery, and eleven for release identity and receipts. Production and preview network builds also passed, with previews marked noindex and analytics disabled.

No external application, provider environment, production-like critical workflow, staff-engineer review, or operational recovery was exercised. The local fixtures use in-memory state. This review version reports only that local model; complete an application release packet before applying its results to a real release.

Release packet checklist

  • Requested change and exclusions are human-owned.
  • Approval binds the exact diff.
  • Critical positive and negative workflows pass independently.
  • Preview uses approved non-production configuration.
  • A failed promotion is visible and preserves known live state.
  • One immutable artifact maps to the reviewed revision.
  • The receipt records actor, environment, time, and outcome.
  • Running revision and digest match the successful receipt.
  • Code rollback and data recovery have separate owners.
  • A staff engineer records the release decision.

Frequently asked questions

Can Codex approve the release after it runs the tests?

No. Codex can run and summarize checks, but the accountable human reviewer must judge scope, evidence, environment, and business risk.

Should production rebuild from the approved commit?

Prefer promoting the exact artifact that passed the gate. Rebuilding can change dependencies, tools, or other inputs and requires a new identity and review.

Does a matching version endpoint mean the app is healthy?

No. It proves a narrow source-to-artifact-to-runtime identity relationship. Health, authorization, data integrity, dependencies, and recovery need separate evidence.