Prerequisites

Before accepting an agent-generated change, name:

  • the repository and protected base revision;
  • the human change owner and staff-engineer reviewer;
  • the test owner for independent negative cases;
  • the build system and immutable artifact identifier;
  • the release authority and target environment;
  • the running-version verification path; and
  • the rollback owner and data-compatibility decision.

If one person fills several roles on a small team, keep the decisions separate and time-stamped. The goal is an inspectable boundary, not an org-chart ritual.

Gate 1: record the Claude intake boundary

Capture the tool name, exact output of claude --version, session identifier, starting revision, and project policy digest in the change packet. Do not copy a version from this article; record the one actually used.

Anthropic's current CLI reference documents allowed and disallowed tool configuration, permission modes, and the --dangerously-skip-permissions option. Its settings documentation separates managed, project, local, and user configuration scopes.

Commit team-shared project policy where it belongs, and preserve a digest of the effective policy with the packet. Refuse a production candidate generated with permission bypass when the team has not explicitly approved and isolated that mode.

Permission controls limit what the coding process can do. They do not prove the result is correct, secure, maintainable, or ready for production.

Gate 2: freeze the exact diff

Compute an identity for the proposed diff against its base revision. The packet should bind:

base revision
diff digest
Claude session ID
tool version
effective policy digest
human change owner

Review code, configuration, dependencies, migrations, tests, deleted files, and changes outside the requested scope. If the diff changes after approval, the approval is stale. Review the new identity instead of carrying the old checkmark forward.

This makes “the reviewer looked at it” falsifiable: the record says which exact change the reviewer accepted.

Gate 3: run independent negative tests

Run the repository's normal tests, static checks, dependency checks, and the specific behavior test for the change. Then add failure cases that were not merely generated to confirm the new implementation.

OWASP's current AI secure-coding guidance warns that an agent can weaken or delete tests and recommends human review of test changes plus adversarial and negative cases. NIST IR 8397 lists broader verification techniques such as threat modeling, automated testing, static scanning, secret checks, structural tests, and fuzzing.

Record the command, environment, result digest, negative cases, and test owner. A passing suite written and judged only by the generating process is useful feedback, but it is not independent release evidence.

Gate 4: build one immutable artifact

Build from the approved revision and bind the artifact to the diff digest. Use an immutable content digest or equivalent artifact identity, not a mutable label such as latest.

The packet now has a chain:

Claude session → exact diff → independent test record → approved artifact

If rebuilding produces a different artifact, investigate and issue a new receipt. Do not silently replace the approved object under the same release label.

Gate 5: separate promotion from generation

The Claude session should not hold the final production authority simply because it created the change. A release owner or protected automation should promote the approved artifact to the named environment.

Require the promotion record to include:

  • actor or protected workflow;
  • environment;
  • immutable artifact digest;
  • start and completion time;
  • observed health or smoke result; and
  • failure state when promotion does not complete.

A failed promotion must leave the prior running identity visible. Preserve the failed receipt rather than editing history to look successful.

Gate 6: verify what is actually running

Query the deployed service or platform through a documented version endpoint, deployment record, or independently observed artifact identity. Compare that value with the approved digest.

Do not infer production state from a merged pull request, branch name, ticket status, or deployment command returning without an error. The release completes when the observed running identity and the approved artifact agree.

Gate 7: make rollback a data decision

Name the prior known artifact, the rollback authority, and the verification path. Then decide whether the current release changed database schemas, durable records, queues, object storage, caches, configuration, credentials, or external systems.

Code rollback is safe only when those states remain compatible or have their own recovery procedure. If compatibility is unknown, stop. “Redeploy the old image” is not a complete recovery plan for a data-changing release.

Reproduce the nine release-gate cases

Run:

npm test --prefix sites/odexing.com/evidence/P27

On Node.js 22.18.0, all nine tests passed. The fixture accepts one complete packet and rejects missing provenance, permission bypass, absent negative cases, tests owned by the generating actor, approval of an earlier diff, a mutable artifact, a running-artifact mismatch, and rollback without a data-compatibility decision.

The fixture validates packet mechanics. It does not prove a real application is correct or a real reviewer is independent and qualified.

Minimal release packet

  • Exact Claude Code version and session ID recorded.
  • Effective project policy and permission mode identified.
  • Base revision and diff digest frozen.
  • Out-of-scope, dependency, configuration, migration, and test changes reviewed.
  • Independent negative cases passed with an owner and command record.
  • Human approval names the exact diff digest.
  • Immutable artifact names its source diff.
  • Separate release authority promoted that artifact.
  • Running identity matches the approved artifact.
  • Rollback owner and data compatibility are explicit.

Failure signals

Stop the release when any identity in the chain is missing or differs. A stale approval, green but non-independent test record, mutable image tag, unverified running revision, or code-only rollback plan is a failed gate—not paperwork to complete after deployment.

Frequently asked questions

Is this workflow unique to Claude Code?

Most release mechanics apply to any generated change. Claude-specific fields include the actual tool version, session provenance, and effective Claude Code permission and project settings.

Do permission prompts make generated code safe?

No. They constrain tool actions. Code review, behavior tests, artifact identity, promotion controls, observation, and recovery remain separate.

Can a small team use the same person for review and release?

Sometimes, but record the review and release decisions separately and keep independent negative evidence. For higher-risk changes, require another qualified person or reduce the change and environment risk before promotion.