design(recovery): reactivate PR fixes on fresh evidence #1244

Problem

Actionable PR feedback can remain stranded behind an older no_change_needed, PARKED, or WAITING_EXTERNAL disposition. A prior attempt does not resolve feedback posted after its evidence snapshot.

Observed 2026-10-13: Courier PR #294 and Dispatch PR #1239 had newer review blockers after preceding attempts, while queue items were observed WAITING_EXTERNAL with scheduled retries and the note "no changes pushed; queued feedback resolution is not verified". PR #1239 had also received a successful push from another attempt: a single queue note is not the complete PR history. These observations motivate investigation; they do not prove the precise transition defect.

Required design

• Define fresh actionable evidence using authoritative PR head/review/check identities. Distinguish genuinely new feedback from duplicated webhooks, repeated review text, incidental updates and already-resolved comments.
• Specify when fresh evidence invalidates an old wait or operational parking, creates a new generation, and permits pickup. Preserve immutable prior attempts and reasons.
• WAITING_EXTERNAL must identify a concrete dependency/condition, evidence, and recovery trigger. Lack of a patch alone is not an external dependency.
• Separate operational parking from genuine human decisions. New evidence must not silently override a maintainer hold, authorization boundary, closed/merged PR, dependency block, or unresolved scope decision.
• Fence settlement by generation/attempt ownership. Old workers must not settle newer feedback; recovery must not duplicate active hand-outs or clear a healthy owner's lease.
• Design event-driven recovery plus bounded periodic reconciliation for missed events, with idempotency, cooldown/attempt budgets, audit trails, and explicit operator controls.
• Keep worker-independent: no requirement for Courier, its phases, or its telemetry. Coordinate only through documented source/client capabilities.

Acceptance / design deliverable

A state-transition table and recovery policy, with examples for feedback arriving during execution, after no-change, during an external wait, while operationally parked, after an explicit human hold, and after merge/close. Identify existing behavior versus gaps from current code. Specify unknown-evidence behavior and negative controls for duplicate/replayed events and retry loops before implementation.

Related: misospace/courier#320 covers execution-provider exhaustion, not Dispatch recovery ownership.

Non-goals

Design only. No implementation, automatic bulk requeues, attempt-counter erasure, credentials, timeout increases, or deployment changes.