Add concurrency group to dispatch-review job (supports #365)

[fullsend-ai-retro]

What happened

PR #845 was a Dependabot submodule bump (1-line diff). Two review runs were dispatched to fullsend-ai/.fullsend within 4 seconds of each other: run #975 (18:47:46, completed 18:53:42, 93KB artifact) and run #976 (18:47:50, completed 18:51:18, 16KB artifact). Run #976 produced the approval at 18:51:11. Run #975 ran for ~6 minutes redundantly. The likely cause is the pull_request_target event firing both opened and ready_for_review actions for a non-draft Dependabot PR, each dispatching a separate review.

What could go better

The dispatch-review job should have a concurrency group like dispatch-triage already does, so that only one review dispatch runs per PR at a time. This is a known gap — issue #365 was filed on 2026-04-23 with the exact fix, RICE-scored at 2.7, and remains open. This retro provides concrete evidence: one redundant run consuming ~6 minutes of compute and producing a 93KB artifact that was never used. Confidence is high — the root cause is clearly the missing concurrency group, matching the pattern already established by other dispatch jobs in the same workflow.

Proposed change

Add a concurrency block to the dispatch-review job in .github/workflows/fullsend.yaml, mirroring the pattern from dispatch-triage:

dispatch-review:
  runs-on: ubuntu-latest
  concurrency:
    group: review-${{ github.event.pull_request.number }}
    cancel-in-progress: true

Also audit dispatch-code and dispatch-retro for the same gap, as suggested in #365. This is not a new proposal — it is a priority bump for #365 based on fresh evidence.

Validation criteria

After applying the fix, the next 10 Dependabot or bot-authored PRs on fullsend-ai/fullsend should each produce exactly 1 review run in fullsend-ai/.fullsend (not 2+). Check by comparing review.yml run counts to PR counts over a 1-week window.

---

Generated by retro agent from #845

[github-actions]

fullsend triage is working on this — view logs

[fullsend-ai-triage]

This issue describes the same root problem and proposes the same fix as #365 (dispatch-review job lacks concurrency control). The issue body confirms this directly: it frames itself as a priority bump for #365 rather than a new proposal.

The concrete evidence from PR #845 — two review runs dispatched 4 seconds apart, one running redundantly for ~6 minutes — is valuable supporting data. It would be helpful to add that evidence as a comment on #365 so it informs prioritization of the existing issue.

Closing as duplicate of #365.