Go prototype: Ticket run Delivery, CI Repair loop, and exhaustive state modeling #1833

This was generated by AI during triage.

Parent

#1830

What to build

Extend the Go prototype's Ticket run from the completed Harness session through Delivery: pushing the Issue branch, opening or verifying the pull request, watching head CI checks, merging Base branch updates, running bounded Repair sessions when CI checks fail or the branch conflicts with the Base branch, and salvaging a draft pull request on a Failed ticket run. Model Run, Claim, Delivery, and CI check states using closed sum-type patterns in Go (sealed interfaces and/or enum-exhaustiveness checks) so unhandled state variants fail automated checks.

Acceptance criteria

• After the opening Harness session commits to the Issue branch, Delivery pushes the branch, opens or verifies the pull request for that branch, and marks it ready for review once CI checks pass.
• When CI checks on the watched head fail or the branch conflicts with the Base branch, the Ticket run runs bounded Repair sessions (up to the Repair limit) and re-verifies CI before completing Delivery.
• When a Ticket run fails with commits ahead of the Base branch, Failed ticket run salvage pushes the branch and opens or keeps a draft pull request while preserving the in-progress Claim; when it ends with nothing on origin, it releases the Claim and restores ready-for-agent.
• Run outcomes, Claim transitions, Delivery states, and CI check states are represented with closed sum-type patterns and an automated exhaustiveness check verified in go test.
• End-to-end CLI tests with fake gh and Harness executables cover green Delivery, CI failure Repair recovery, merge-conflict Repair recovery, and Failed ticket run draft salvage.

Blocked by

• Go prototype: isolated static binary, embedded skills, and Ticket run through Harness session #1832