fix(#1408): debounce retro workflow to make concurrency group effective

[rh-hemartin]

Summary

• Adds a 60-second debounce job before the retro job in the scaffold's retro.yml
• Multiple dispatches for the same PR close (from burst webhook deliveries or shim retries) all start simultaneously; the sleep keeps each run active long enough for the existing cancel-in-progress: true concurrency group to cancel stale ones — only the last run survives and proceeds to the actual retro
• No API calls, no TOCTOU races — pure GitHub Actions concurrency semantics

How it works

dispatch 1 → retro starts → sleeping 60s
dispatch 2 → retro starts → cancels dispatch 1's run (cancel-in-progress: true)
dispatch 3 → retro starts → cancels dispatch 2's run
...
dispatch N → retro starts → sleeps 60s uninterrupted → retro job runs

Trade-offs

• Adds 1 minute of runner time per retro run (~$0.008/retro at standard ubuntu-latest pricing)
• Effective when dispatches arrive within the 60-second window; longer gaps (> 60 s between sequential shim executions) may still produce occasional duplicates, mitigated by the pre-existing concurrency group canceling any still-running retro

Relation to prior work

Supersedes #1412, which implemented the alternative (pre-dispatch API dedup check in dispatch.yml). This PR implements the preferred approach from #1408: concurrency group in retro.yml with cancel-in-progress: true, made effective via debounce.

Closes #1408

Test plan

• Merge a PR in an enrolled repo and verify only one retro run completes
• Monitor next 10 PR merges for duplicate retro runs within 5-minute window

🤖 Generated with Claude Code

[github-actions]

Site preview

Preview: https://59a408d3-site.fullsend-ai.workers.dev

Commit: 4c3923e4278be114da09ba2e9b8d590706267945

[fullsend-ai-review]

Review

Findings

No findings.

Previous run

Review

Findings

No findings.

[ben-alkov]

LGTM

[fullsend-ai-retro]

Retro: PR #1468 — Debounce retro workflow

Workflow quality: Good. This was a clean end-to-end cycle: retro agent identified a real resource waste bug (#1408), triage scoped it, a human implemented a simple 7-line fix (debounce job with sleep 60), review agent correctly approved with no findings, and a human reviewer merged it.

Timeline

1. May 25 — Retro agent filed #1408 documenting 2–6× duplicate retro runs per PR merge, with specific run IDs and timestamps as evidence.
2. May 25 — Triage agent triaged the issue. Recommended the API dedup approach (option 2 from the issue), diverging from the issue author's stated preference for the concurrency-group approach (option 1).
3. May 26 — Human (rh-hemartin) opened PR #1468 implementing the preferred debounce approach. This superseded PR #1412, which had implemented the triage agent's recommended approach.
4. May 28 — Review agent ran in ~2 min, approved with no findings. E2E CI failed (unrelated).
5. Jun 4 — Prioritize agent scored the issue at RICE 1.8.
6. Jun 8 — Human (ben-alkov) approved with "LGTM". PR merged after 13 days open.

Assessment

Review quality was appropriate — the review agent correctly approved a clean, minimal change with zero-permission security profile. No false positives, no missed issues.

Rework rate was zero — single iteration, no review-requested changes.

Token cost was reasonable — review agent completed in ~2 min with ~18 tool calls for a 1-file PR.

Existing issues cover identified improvement areas

• 13-day merge latency for a trivial agent-approved PR awaiting human review → #1974
• Triage agent overrode the issue author's explicit preference ranking, leading to a superseded PR (fix(#1408): deduplicate retro dispatches on PR merge #1412) → #1868
• FULLSEND_OUTPUT_SCHEMA pointing to a directory instead of a file, requiring agent workaround → #1516

No new proposals — all identified improvements are already tracked.