Your green check belongs to a commit, not a pull request
Claude Code changes a payment retry handler. The tests pass. The agent prepares a tidy review packet, and a reviewer approves the pull request.
Then someone rebases the branch.
A dependency lockfile changes during conflict resolution. The agent makes a small follow-up edit. The pull request still shows green checks, and the original explanation still sounds convincing. But the tested code and the merge candidate are no longer the same artifact.
That gap is easy to miss because people attach confidence to the pull request. A pull request is a conversation that can keep changing. Test results belong to the exact code that produced them.
If the commit changes, the claim “tested and approved” has expired.
green does not mean current
Most delivery systems show status at the pull request level. That is useful for a quick view, but it can hide the identity of the artifact behind the status.
Consider this sequence:
10:02 Claude Code creates commit 7ac81f2
10:05 unit and integration tests pass on 7ac81f2
10:14 reviewer approves 7ac81f2
10:21 branch is rebased onto a newer main
10:23 conflict is fixed in the retry handler
10:24 new head commit is b821e90
10:25 pull request still displays the earlier approval
The green result says something useful about 7ac81f2. It says nothing certain about b821e90 until the checks run again.
This is not a complaint about Claude Code. Human-written branches have always had stale checks, surprising rebases, and conflict fixes. Agentic coding increases the pressure because another patch takes seconds to generate. The branch can move faster than the review habit around it.
A small diff does not make the problem harmless. One line can remove an authorization check, change a retry count, alter a customer boundary, or update the dependency graph. Diff size is a weak proxy for impact.
put the artifact identity in the review packet
A serious review packet should name the code it describes. Record enough context to reproduce the claim and reject it when that context changes.
artifact:
repository: payments-api
commit: 7ac81f2
base_commit: a140d9c
tree_hash: 91d4c70
execution:
runner_image: agent-ci@sha256:4bd1...
dependency_lock_hash: d7e21a9
policy_version: prod-agent-policy-v12
evidence:
unit_tests:
command: pnpm test payments/retry
result: passed
integration_tests:
command: pnpm test:integration payments
result: passed
security_policy:
result: passed
skipped_checks: []
approval:
reviewer: release-owner-42
artifact_commit: 7ac81f2
approved_for_merge: true
The commit identifies the source revision. The base commit shows what the change was built against. A tree hash can identify the resulting file tree even when commit metadata changes. The runner image, dependency state, and policy version describe the environment that turned code into evidence.
None of these fields helps if they sit in a comment that nobody verifies. The merge gate must compare the approved artifact with the current candidate. If the values differ, it should expire the affected checks and approval.
This turns a vague review question into a mechanical one:
approved_commit == current_candidate_commit
When the comparison fails, stop. Run the required checks against the new candidate, rebuild the packet, and ask for another decision.
For a practical preflight covering scope, tools, evidence, review, and rollback, use my free Claude Code production checklist.
define what invalidates each claim
Not every change needs every test, but the invalidation rule should be written before the branch changes.
Source file changed
Rerun tests and static checks affected by that file.
Dependency lock changed
Rebuild in a clean environment and rerun dependency and integration checks.
Base branch changed
Rerun conflict-sensitive tests and integration checks.
Policy version changed
Evaluate the candidate against the current policy.
Runner image changed
Recreate evidence that depends on the build environment.
Artifact changed after approval
Expire the approval and request review for the new artifact.
Teams sometimes try to save time by carrying approval forward when the follow-up edit looks unrelated. That can be reasonable only if a trusted system can prove which evidence remains valid. A reviewer glancing at the latest diff and saying “probably fine” is not that system.
Impact analysis can narrow the rerun set. It should fail safely when the dependency graph is incomplete. Payments, identity, deployment, data access, and security policy changes deserve a stricter default because a missed edge is expensive.
The same rule applies to generated files. If a formatter, code generator, package manager, or agent rewrites the tree after approval, the approved artifact no longer exists. Run the checks on the output that will move forward, not on the input you remember reviewing.
test the merge candidate, not only the branch
Branch checks can all be current and still miss the artifact that enters production.
A merge queue may combine the feature branch with work that landed after the tests ran. A squash merge creates a new commit. A release process may inject generated metadata or rebuild dependencies. Each step can produce a candidate that differs from the earlier branch head.
The release gate should work with the final candidate created by the queue:
1. Create the merge candidate.
2. Freeze its commit and tree hash.
3. Build it in the approved runner image.
4. Run the required tests and policy checks.
5. Record the results against that candidate.
6. Approve that artifact for release.
7. Compare its digest at the release boundary.
If the release system receives a different digest, it should refuse the handoff. This is a plain software supply chain control, and coding agents make it more useful rather than less.
It also separates two kinds of authority. Claude Code can prepare the change and its evidence. A separate gate decides whether that exact artifact may merge or deploy. The agent does not get to revise the case after review and carry the old decision into the new run.
This is the same operating idea behind Claude Code stop conditions and review packets for agent work. A stop condition defines when the run has crossed its contract. The review packet records what happened. Commit binding proves which artifact those records describe.
make the audit record answer one question
Months after release, nobody wants a beautiful summary that cannot be connected to the deployed code. The audit record should answer: did we release the artifact that passed the required checks and received approval?
Keep a compact chain:
release_evidence:
source_commit: b821e90
source_tree: 884ec13
build_digest: sha256:71aa...
test_run: ci-98114
policy_result: policy-2208
approval: approval-6501
deployed_digest: sha256:71aa...
outcome: matched
A mismatch should be visible as an incident signal, not buried in a deployment log. Record who or what changed the candidate, which claims became stale, whether the gate stopped the release, and which checks ran again.
This evidence matters beyond engineering. Security and risk teams need to know that human approval was tied to the action that occurred. An approval attached to a mutable pull request can become reusable authority. An approval attached to an immutable artifact is much easier to inspect, expire, and defend.
where the books fit
I wrote Claude Code: Building Production Agents That Actually Scale for engineers building this operating loop around Claude Code. It covers task contracts, permissions, MCP tools, evals, observability, review packets, rollback, cost controls, and release gates.
The Kindle edition is available on Amazon: get the Claude Code book on Amazon Kindle.
Securing Enterprise AI Agents takes the security view. It covers bounded authority, agent identity, approval controls, MCP and RAG governance, policy enforcement, evidence, revocation, and incident response.
If you own both the delivery pipeline and the control model, the Enterprise AI Agents in Production bundle connects the engineering and security sides.
A green check is useful evidence. Keep it attached to the code that earned it.