dev-lead: issue-pickup runs cancelled by concurrency group → 111 labeled issues stuck with no PR

[don-petry]

Summary

Across the org, 187 of 293 open issues have no linked PR. Investigation (started from the 2026-06-06 org summary, #399) shows the dominant cause is dev-lead issue-pickup runs being cancelled by a misconfigured GitHub Actions concurrency group — not the agent erroring, and not (mostly) missing labels.

The dev-lead label is applied and the workflow triggers on the issues: [labeled] event, but the pickup run is cancelled before it can open a PR, because issue pickups share a concurrency slot with high-volume PR follow-up traffic (reviews, comments, check_run relays).

Evidence

issues-event run conclusions (the labeled-pickup trigger):

• ContentTwin: 7 of 7 issues-event runs → cancelled
• TalkTerm: 13 of 13 issues-event runs → cancelled

Cancellation annotation on a TalkTerm pickup run:

Canceling since a higher priority waiting request for dev-lead-20 exists

Data — open issues by dev-lead label × linked PR

Repo	label + PR	label, no PR	no label + PR	no label, no PR
.github	4	13	1	15
.github-private	7	34	6	27
bmad-bgreat-suite	17	5	0	6
broodly	27	7	0	4
google-app-scripts	22	6	0	2
markets	17	5	0	2
ContentTwin	3	19	0	17
TalkTerm	3	22	0	3
TOTAL	100	111	7	76

• 187 issues have no linked PR = 111 labeled-but-cancelled + 76 never-labeled.
• The "labeled, no PR" failures concentrate in .github-private, ContentTwin, TalkTerm, .github — the busiest repos, where PR follow-up traffic starves issue pickup.

Root cause — three drifted (all broken) concurrency configs

The reusable workflow (.github-private/.github/workflows/dev-lead-reusable.yml) defines no concurrency; each caller stub owns it, and they have drifted:

1. Repo-wide single group 'dev-lead', cancel-in-progress: false — .github, .github-private (inline), ContentTwin, markets, bmad. Every event (issue labels + PR comments + reviews + check_runs) funnels through one slot per repo; issue pickups sit pending and are superseded by PR traffic. This is the canonical template — so the "correct" config is itself broken.
2. Per-number group + cancel-in-progress: true — TalkTerm (drifted stub):

   group: dev-lead-${{ github.event.pull_request.number || github.event.issue.number || github.sha }}

   Collapses issue #N and PR #N into the same group (dev-lead-20); cancel-in-progress: true means activity on PR chore(deps): Bump actions/setup-go from 5.5.0 to 6.4.0 #20 cancels the in-flight pickup of issue chore(deps): Bump actions/setup-go from 5.5.0 to 6.4.0 #20.
3. No concurrency block at all — broodly, google-app-scripts. These actually convert best (27/34, 22/28) precisely because nothing cancels their pickups.

Remediation

1. Fix the reusable workflow — give it intent-aware top-level concurrency: separate per-issue (dev-lead-issue-<n>) and per-PR (dev-lead-pr-<n>) lanes, a per-SHA ci-relay lane, and a unique fallback. PR comments (issue.pull_request set) map to the PR lane to avoid the issue#/PR# collision. Single source of truth.
2. Align all caller stubs — remove their drifted concurrency blocks and re-pin to the fixed reusable, so concurrency lives in one place and can't drift again.
3. Backfill the 111 cancelled pickups — they will not self-heal (the label is already applied, so no new labeled event fires). They need a re-dispatch. dev-lead-retry.yml currently only re-dispatches rate-limited PR markers, not cancelled issue pickups — extend it (or run a one-off repository_dispatch) to re-trigger labeled issues with no linked PR.
4. Triage the 76 unlabeled issues — decide which should be agent-worked vs. human-only (many in .github/.github-private look like governance/compliance tracking) and label accordingly.

This issue tracks items 1–2 via a PR series; 3–4 are follow-ups.