[JacobStephens2]

Summary

Ticket accounting could edit a Spec PR after a Ticket retargeted it. One pull request owner now validates the captured number before accounting writes and landings, and stays available through Delivery and failure accounting.

Spec PR owner
  Ticket accounting: resume/create → validate PR number → draft/checklist/landing
  Delivery: end accounting capture → Spec review → capture PR → restore checklist → ready
  Failure: preserve work → finish captured PR → final checklist

Delivery still permits replacement during the opening Spec review and rejects replacements after capture. The duplicate Spec PR cache, identity-following shim, and before-ready callback/result plumbing are removed. Spec PR and Delivery glossary entries describe both capture scopes.

Evidence

• Before: a_failed_ticket_that_retargets_the_spec_pr_leaves_its_body_untouched failed: accounting appended the Tickets checklist to the retargeted untouched sentinel.
  After: the regression passes: the sentinel stays unchanged, the target problem is reported, and Ticket CI watching, CI-fix Repair and the Repair cap #22 remains failed.
• Successful Ticket completion with a retargeted or closed accounting PR fails the landing, starts no Spec review, and leaves any replacement untouched.
• All 64 Spec CLI scenarios pass, including replacement during successful/failed review, late replacement rejection, checklist restoration, first landing after interruption, and drained-child accounting.
• Validation: cargo check --all-targets, cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test (1442 passed, 1 ignored).

Test seams

• PullRequest outcomes through the scripted GitHub adapter: numbered accounting, creation, capture transition, readiness and failure completion.
• CLI Spec runs through real git and fake GitHub/harness: failed and successful Tickets with invalid accounting PRs, review ordering and interruption.
• GitHub process transport: exact created-PR selection and completion operations.

Review against main

• Standards: no documented-standard violations; one repeated-fixture finding addressed with a typed observation fixture.
• Spec: no findings.

Merge Danger

Door: two-way

Reversible module refactor; no data migration or merge-policy change.

Blast Radius: Delivery

Ordinary Runs and Spec runs share PR identity validation. Existing Repair, Self-merge, failure preservation and child teardown behavior remain covered.

Unaddressed findings

Standards

None. The one finding was addressed.

Spec

None. No findings were reported.

Closes #515

Built with codex · gpt-6.1-sol · xhigh