[Gastown] pr-feedback / rework dispatcher creates new beads indefinitely on MERGED/CLOSED PRs

[ThePlenkov]

What happened?

In town 6b110d52-9a70-4742-91d8-fab68a2bec3c (rig nx.ts), the pr-feedback and rework bead dispatchers do not check the current state of the target PR before creating or dispatching new beads.

Reproduction:

1. PR Add TruffleHog secret scanning workflow #18 (https://github.com/ThePlenkov/nx.ts/pull/18) was MERGED at 2026-06-23T10:44:29Z.
2. After the merge, pr-feedback beads with title Address review comments on PR #18 (nx.ts) continued to be created and dispatched. Polecats correctly identified the PR as merged and closed the bead as no-op, but a new bead was immediately created.
3. Over ~2 hours post-merge, at least 4 such beads accumulated, all dispatch_attempts: 5, all failed as no-op.

Expected: before creating a new pr-feedback or rework bead, the dispatcher (or patrol service) should query the target PR via gh api graphql ... pullRequest.state. If state is MERGED or CLOSED, the dispatcher should NOT create a new bead. The webhook-driven thread creation should also check state.

Related: the pr-feedback bead template includes a pre-flight gh pr view step. The bead is created before any pre-flight can run. So the gating needs to be in the dispatcher, not the bead.

Severity: medium. Wastes polecat compute, pollutes dashboard, distracts mayor from real work.

Area

Agent Dispatch / Scheduling

Context

• Town ID: 6b110d52-9a70-4742-91d8-fab68a2bec3c
• Agent: Mayor (e920f2fe-6fce-4534-ae2e-43549fd8c66f)
• Rig ID: 905bf756-546a-484c-9b4e-1a0b6b903457

Recent Errors

Recurring stale pr-feedback dispatch on merged PR #18 — 4th no-op. PR merged at 10:44Z, beads continued dispatching through 16:00Z.

Filed automatically by the Mayor via gt_report_bug.