On August 6, 2026, Harness Ready's ten tests passed in 3.227 seconds, but the result still failed my coding-agent merge gate. [E7]
The green signal covered selected behavior rather than merge authority. A hidden production risk remained: no task boundary, known gaps, approval owner, or rollback path.
The exact 6-Part Release Receipt checklist below records what the test result omitted before the next agent-authored patch ships. [E7]
Save this framework before your next agent-authored merge.
A green check proves less than the merge button implies
Tests are observations against a chosen set of cases.
A passing command records one event: the command exited successfully for the code and environment it received.
It says nothing about requirements that never became assertions.
One agent response can contain the patch, chosen commands, result interpretation, and summary. When that evidence is partial, fluent prose does not make it complete. [E2][E3]
OpenAI describes Codex returning citations to terminal logs and test outputs so a developer can trace its actions. The same guidance says users still need to review and validate generated code before integration and execution. [E2]
GitHub gives Copilot coding-agent sessions a similar trail. Session logs expose the tools used to inspect, change, and validate a repository. Agent commits link back to those logs. GitHub still requires a human to review and merge the draft pull request. [E3][E4]
The product pattern is consistent: agents can produce evidence, but evidence and approval remain separate jobs. [E2][E3][E4]
A green test is one line in a release decision. It is not the decision.
A usable handoff answers six questions without replaying the session
I want to review an agent change without scrolling through a transcript or asking the same agent what it meant. The handoff should stand on its own.
That requires six answers.
1. What was the agent authorized to change?
Record the request, acceptance criteria, base revision, allowed paths, and explicit exclusions. If the task says "fix checkout," the receipt should make clear whether pricing, fulfillment, analytics, and email delivery were in scope.
2. What changed?
List the files and the reason for each material change. Include dependency, configuration, schema, and generated-artifact changes. A diff shows the bytes. The receipt states which bytes carry the intended behavior.
3. What was verified?
Record exact commands or manual observations, exit codes, summaries, and artifact paths. "Tests passed" cannot be audited. pnpm test, exit 0, 184 tests passed, with a linked run can.
4. What remains unknown?
Name skipped checks, environment differences, unsupported cases, flaky results, and production-only dependencies. This field prevents a clean test run from swallowing the caveat that matters.
5. Which authority or side effects were used?
State whether the run wrote files, executed repository scripts, changed remote systems, used network access, added a dependency, or touched data. Then name the human approval still required.
6. How does this change come back out?
Define the rollback trigger, exact reversal action, data recovery step, and owner. "Revert if needed" is not enough for a migration, webhook, payment change, or generated instruction layer.
The six questions compress a long agent trajectory into something another operator can challenge.
The receipt separates claims, evidence, and authority
This is the mechanism underneath the checklist.
I call the operating model the Release Receipt protocol. Its artifact is the Six-Part Release Receipt.
An agent finishes with a claim: the requested work is complete.
Tests and inspection produce evidence: selected properties held in a particular environment.
The task contract defines the boundary: which repository state and behavior the evidence must cover.
Known gaps record the exceptions: what the run did not establish.
Permissions and review rules define authority: which actions the agent could take and who may approve the result.
Rollback defines recovery: how the team returns to a known state if the claim fails later.
The release decision is downstream of all six. Flatten them into one "done" message and the reviewer has to reconstruct the missing pieces from logs.
Software supply-chain systems already use this shape. SLSA defines provenance as verifiable information about where, when, and how an artifact was produced. NIST's Secure Software Development Framework includes collecting and sharing provenance for software-release components. [E5][E6]
A coding-agent receipt is not a SLSA attestation, and it should not pretend to be one. It borrows the useful principle: preserve enough structured evidence that the next operator can trace the result without trusting the producer's memory.
The receipt is a boundary between producing work and accepting work.
The Six-Part Release Receipt fits inside one pull request
Use this template after an agent changes code and before a human approves the merge:
SIX-PART RELEASE RECEIPT
Receipt ID / owner / date:
1. TASK BOUNDARY
Request:
Acceptance criteria:
Base revision:
Allowed paths:
Explicitly excluded:
2. CHANGE SET
Files changed and why:
Dependencies, config, or unexpected changes:
3. VERIFICATION
Command or observation:
Exit code and actual result:
Artifact or log:
4. KNOWN GAPS
Checks not run:
Environment differences:
Unsupported or untested cases:
5. AUTHORITY
Permissions used:
External side effects:
Human approval required before:
6. RECOVERY
Rollback trigger:
Exact rollback action:
Data recovery:
Recovery owner:
DECISION: READY | READY WITH RISK | BLOCKED
Reviewer:
Next action:Keep the receipt beside the change. A pull request body works. A versioned file under receipts/ also works for releases that need an audit trail.
The agent may draft the receipt, but it must derive every command and file from the current run. A stale template with copied results is worse than no receipt because it creates counterfeit certainty.
You should see exact commands, explicit gaps, and a rollback action another person can follow. If any field contains "probably," "should," or "not applicable" without a reason, the review is unfinished.
Have the agent draft all six sections from the current run. The human reviewer verifies the evidence, owns the decision, and completes the receipt before merge.
Harness Ready shows what the receipt catches beyond ten tests
Harness Ready gives me a small, concrete release package to inspect.
Its current release archive contains 12 files and is 19,498 bytes. The published SHA-256 is 5b7176b15c7cc72caf1096cf88723fdf56ac0a6391cf5730f4dfec78eaca506f.
I matched that value against the archive on August 6, 2026, before writing this article. [E1]
The test suite passed ten cases across release validation, unsupported repositories, consent, idempotency, command-plan drift, symlink rejection, verification, and rollback.
The receipt still needs more than "10 tests passed":
- Boundary: the supported release is macOS or Linux, Python 3.10+, Git, Next.js, and TypeScript.
- Change set: the CLI manages marked sections in root
AGENTS.mdandCLAUDE.mdfiles plus a local receipt directory. - Verification:
auditandplanwere tested as read-only;verifyinspects unless the operator adds--run. - Known gaps: those synthetic repositories do not establish compatibility with every package script, monorepo, framework plugin, or repository policy.
- Authority:
applyandrollbackrequire explicit--yes; repository-script execution requires a separateverify --runchoice. - Recovery: rollback removes only the receipt-scoped managed sections and refuses to erase a section edited after apply.
The tests establish those behaviors in the test fixtures. The receipt tells the buyer where the claim stops.
That last sentence matters. Strong verification includes the edge of the evidence, not a larger promise written after the run.
Four receipt failures create false confidence
The template is short enough to use, but easy to corrupt.
The result has no command
"Lint passed" hides the package manager, working directory, flags, exit status, and ignored warnings. Save the exact command and actual output summary.
The agent verifies its own interpretation
An agent can run the tests it chose and explain why they are sufficient. That is useful input, not independent review. Acceptance criteria should come from the task contract, repository policy, or human owner before the result is judged.
Unknowns disappear after success
Logs usually preserve failures. Summaries often discard checks that never ran. Force the receipt to name production-only dependencies, unavailable credentials, browser paths, migrations, and unsupported environments.
Rollback is a generic Git sentence
git revert may reverse source files. It may not reverse a sent email, consumed webhook, database migration, deleted object, published package, or remote configuration change. Recovery must match the side effect.
If rollback begins with "check git history," the recovery plan was written too late.
Five mismatches should block READY
A receipt has one useful failure mode: it can refuse to collapse uncertainty into a green label.
Mark the decision BLOCKED when any of these mismatches appears.
The base revision moved
The agent verified commit A, but the branch now contains commit B. Rebase or merge the current branch, rerun the affected checks, and issue a new receipt. Evidence from the old tree does not transfer automatically.
The command plan changed after apply
The patch modified package.json, CI configuration, or repository instructions after the verification commands were selected. Resolve the new command set before execution. Otherwise the agent can validate yesterday's contract against today's repository.
The artifact changed after verification
A build, archive, generated client, or lockfile has different bytes from the recorded artifact. Recompute the digest and repeat the checks that depend on it. This is why the Harness Ready release record carries a SHA-256 rather than a filename alone.
A side effect has no owner
The run sent a webhook, changed remote configuration, published a package, mutated data, or used an approval token, but nobody owns inspection and recovery. A successful API response does not supply accountability.
The reviewer cannot reproduce the important result
The receipt points to an expired log, a local-only environment, a missing fixture, or a command that now fails. Preserve the artifact or label the result non-reproducible and decide whether independent evidence is required.
These are mechanical mismatches. The agent does not need to debate their severity. Repository policy can turn each one into a stop condition.
READY is a statement about the current change, current evidence, and current owner. Change one of them and the decision expires.
Low-risk changes should carry a smaller receipt
Not every typo needs a ceremony.
Use a light receipt for a documentation or copy change with no dependency, data, schema, permission, or remote-system effect:
LIGHT RECEIPT
Request:
Files changed:
Check run and result:
Known gap:
Side effects: none
Rollback: revert this change
Decision owner:Use the full Six-Part Release Receipt for application behavior, build configuration, dependencies, APIs, checkout, authentication, deployment, or agent-policy changes.
High-consequence work needs more than this template. Payments, security controls, data migrations, legal commitments, and destructive operations may require staging evidence, backups, independent review, or a named approval outside the repository.
The receipt is a minimum handoff contract. It does not certify correctness, replace code review, or turn weak tests into strong evidence.
A complete receipt can still describe a bad change
The receipt does not decide whether the acceptance criteria were wise. An agent can satisfy a narrow task exactly while the task misses a customer, security, or operational requirement. The reviewer still needs enough domain context to challenge the boundary itself.
The receipt also cannot strengthen weak evidence. Ten shallow tests remain shallow when copied into a clean template. What the protocol does is keep their exact scope visible beside the release decision, so “passed” cannot silently expand into “safe.”
That is the honest limit: the receipt makes a decision inspectable. It does not make the decision correct.
The merge gate should reject missing evidence, not imperfect prose
Do not score the receipt by how polished it sounds.
Reject it when the task boundary is missing, a material change is unexplained, or verification has no exact result.
Reject it when known gaps are blank, side effects are hidden, or the named owner cannot execute the rollback.
Accept READY WITH RISK when the remaining gap is explicit, bounded, owned, and compatible with the release decision. Use BLOCKED when a missing check could reverse that decision or a recovery path does not exist.
An agent can produce the handoff. A human reviewer still owns the decision that the handoff is complete.
Tests describe evidence. A release receipt records the decision.
Your next action: use the Six-Part Release Receipt on the next agent-authored change before you merge it.
Save the 6-Part Release Receipt for this week's agent-authored merge: which field would you pick as the first merge blocker?
Evidence
- [E1] Harness Ready v1.0.0 public release record, verified locally on August 6, 2026: www.nyk.dev/downloads/harness-ready/release.json
- [E2] OpenAI, "Introducing Codex": openai.com/index/introducing-codex/
- [E3] GitHub Docs, "Managing agent sessions": docs.github.com/en/copilot/how-tos/copilot-on-github/use-cop
- [E4] GitHub Docs, "Risks and mitigations for GitHub Copilot cloud agent": docs.github.com/en/enterprise-cloud@latest/copilot/concepts/
- [E5] SLSA v1.2, "Provenance": slsa.dev/spec/v1.2/provenance
- [E6] NIST, "Secure Software Development Framework": csrc.nist.gov/projects/ssdf
- [E7]: Author verification record and operating note for this article: the 10-test run completed in 3.227 seconds on August 6, 2026. The Six-Part Release Receipt is a first-party review protocol applied to the Harness Ready release, not an externally validated standard.
