A pull request was not the finish line

Engineering case study · Production evidence from September–October 2026 · Scoped verification, not broad customer adoption

When an autonomous coding agent opens a pull request, it is tempting to treat that as the final result. In a mature engineering workflow, the pull request is an artefact for review. It is not proof that the change is correct, that the right checks ran against the right commit, or that the agent was authorised to merge or deploy.

DoneState was built around that separation. Two real, bounded workflows in 2026 demonstrate the distinction: a production maintenance canary and a selected-App customer acceptance run. Both reached independent verification without granting the agent final merge authority.

The execution contract#

DoneState takes an explicit software-maintenance objective and an authority envelope. It records admitted work durably, launches the coding harness under constrained permissions, validates the resulting tree, prepares a bounded branch and pull request, and seals the execution evidence. A separate verifier must supply a matching signed decision before the run can enter VERIFIED.

That sequence addresses two different problems. Durable state and an effect ledger limit what a restarted controller may repeat. Independent verification limits what an executor may claim as complete. A command's exit code, a local change and a green CI job are useful observations; none is individually a sufficient verdict on a sealed objective.

First: a production canary that stopped at review#

The canary associated with DoneState PR #115 used run ID c4a07fa6-90b2-4597-a4c6-eae66de5a3e8. The controller prepared one bounded implementation, retained a terminal implementation receipt, observed a post-receipt quiescence period and published an exact commit to a reviewable branch.

Three required CI checks passed on head 41f1ae3b0fed670e64bd99f1bcb1aea9c9e7e869: core (22), core (24) and hosted-plugin, in workflow 33806832575.

The first independent verification response was rejected because a numeric GitHub repository ID had been serialised as text. The executor was not rerun to hide the problem. After OpsTruth PR #26 repaired that evidence adapter, the same sealed exact-head subject received a complete matching verification response. DoneState settled at VERIFIED.

PR #115 remained deliberately open and unmerged. The relevant success criterion was not 'the AI merged its own fix'; it was 'an authorised agent produced reviewable work and an independently verifiable account of exactly what was checked'.

Second: a selected-App customer acceptance#

A later selected-App workflow on 9 October used a narrowly authorised three-file candidate in the DoneState repository. The acceptance record in DoneState PR #178 reports nine completed actions and 44 isolated tests. The customer-facing run opened PR #177 on exact head 1bf4c2823ca95da50c053dc888703e61e68a2464, with exactly the three authorised files changed and all required exact-head checks green.

Only after those checks did the pinned, independent OpsTruth verifier return VERIFIED. The initial uncertain automatic observation was preserved as part of the sequence. The test PR stayed unmerged, temporary GitHub Write authority was removed and separately read back as Read, and indexed test-account state and the stored execution key were deleted and independently inspected for absence.

This proves a scoped end-to-end customer workflow under the recorded account and authority conditions. It does not prove that every new user can sign up without friction or that DoneState has unrestricted private-repository access.

A particularly readable third fixture#

The October reviewer path provides a simple explanatory example. The fixture's line items totalled 55 but its stated total was 50. DoneState received a bounded objective: change only the total in fixtures/invoice.json, run the relevant test and open a PR. The result was review-fixture PR #2, head 306facf9002075ee16deb07e4fcafc94291f9021. The verifier checked the expected one-file change and the corrected total; the run reached VERIFIED.

The surrounding DoneState reviewer acceptance PR #200 records constrained reviewer credentials, positive and negative protocol cases, access isolation and token-revocation behaviour. That PR was still an open implementation candidate when inspected on 31 October; its dated live fixture is not proof that every surrounding change was merged into a general release.

What happens when it does not finish?#

The broader project history also contains preserved AMBIGUOUS_EFFECT, BLOCKED_CAPABILITY and FAILED_SAFE runs. Those states matter. When the controller cannot settle an uncertain implementation effect, it must not launch the same work again just because an assistant would prefer a successful summary. When a verifier has insufficient or malformed evidence, AWAITING_VERIFICATION is a valid and useful result.

DoneState's protected branch and CI requirements do not grant autonomous merge, release or deployment authority. Nor do the acceptance records demonstrate commercial demand, repeat external use or a service-level availability guarantee. A verified engineering fixture is product evidence; a paying satisfied customer is a different measurement.

Why this is worth documenting#

There is a legitimate division of responsibility between an assistant that proposes a patch, a controller that records and constrains execution, a code host that reports checks, a verifier that independently observes the exact subject, and a human or separately authorised process that decides whether to merge. Collapsing those roles into the phrase 'the agent completed the task' conceals the very evidence a reviewer needs.

These case studies preserve the boundaries in the output: reviewable changes, exact-commit checks, independent signed verification, original uncertainty and no implicit permission to merge. No fresh AI model execution or duplicate PR is necessary to demonstrate those historical results.

Inspect the original records#

This is an account of specific recorded runs. It is not a new customer endorsement, a promise of general agent autonomy, or evidence that the unmerged PRs were subsequently deployed.

Technical discussion#

I am inviting criticism of this specific evidence boundary: What is the minimal evidence that should turn an autonomous maintenance run from “PR opened” into independently verified completion? The cross-project conversation is open in Proof & State Discussion #44. No product integration has been agreed; counterexamples, simpler alternatives and reproducible failures are welcome.