# A pull request was not the finish line By ayobamih Canonical: https://aiworkaccountability.com/writing/a-pull-request-was-not-the-finish-line/ Published: 2026-10-31 Updated: 2026-11-01 *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](https://github.com/AyobamiH/donestate/pull/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](https://github.com/AyobamiH/donestate/actions/runs/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](https://github.com/AyobamiH/opstruth-chatgpt-plugin/pull/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](https://github.com/AyobamiH/donestate/pull/178) reports **nine completed actions and 44 isolated tests**. The customer-facing run opened [PR #177](https://github.com/AyobamiH/donestate/pull/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](https://github.com/AyobamiH/donestate-review-fixture/pull/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](https://github.com/AyobamiH/donestate/pull/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 - [DoneState production canary PR #115](https://github.com/AyobamiH/donestate/pull/115). - [Exact CI run 33806832575](https://github.com/AyobamiH/donestate/actions/runs/33806832575). - [Selected-App customer acceptance PR #178](https://github.com/AyobamiH/donestate/pull/178) and [customer PR #177](https://github.com/AyobamiH/donestate/pull/177). - [Review fixture PR #2](https://github.com/AyobamiH/donestate-review-fixture/pull/2). - [Reviewer path and strict authority evidence — PR #200](https://github.com/AyobamiH/donestate/pull/200). - [DoneState's owned-domain launch/acceptance boundaries](https://github.com/AyobamiH/donestate/blob/main/docs/GA-LAUNCH.md). - [The separate OpsTruth identity-contract fix](https://github.com/AyobamiH/opstruth-chatgpt-plugin/pull/26). *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](https://github.com/AyobamiH/proof-and-state/discussions/44). No product integration has been agreed; counterexamples, simpler alternatives and reproducible failures are welcome. Original author-published engineering case study by Ayobami John Haastrup (ayobamih). Drafting and evidence organisation used AI assistance. Historical findings are scoped to the cited tests and provider observations; not independently peer-reviewed. No new execution or provider effect was performed for this article.