bug(ci): pull_request CI workflow doesn't fire on force-push

[bokelley]

Context

Force-pushes to PR branches did not retrigger the Test Python matrix on PRs #406 and #407 fix-packs (only IPR + check ran). Required gh pr close && gh pr reopen to force a fresh trigger.

Acceptance Criteria

• Force-push to a PR branch triggers the full Test Python matrix
• No need for close/reopen workarounds
• Investigate workflow trigger config, concurrency limits, and paths filter

Files

• .github/workflows/*.yml (workflow trigger config)

Refs

• PR feat(server): /.well-known/adcp-agents.json discovery endpoint (#381) #406, feat(buyer-agent-registry): caching + rate-limit + audit emission (#380) #407 fix-pack agents

[bokelley]

Triage

Classification: Bug
Bucket(s): CI/DevOps (no matching repo label — gap noted)
Status: ready-for-human

What the experts said:

• code-reviewer: Root cause is the missing concurrency group, not missing event types. synchronize is already in pull_request's default type set — adding it explicitly is a no-op. Without cancel-in-progress: true, when a force-push fires a new synchronize event while the previous run is still queued, GitHub's free-tier runner slots are consumed by the fast single-runner jobs (conventional-commits, IPR). The 4-runner test matrix is never scheduled for the superseded SHA. The lightweight jobs finish in <10s and always win; the matrix gets silently dropped.

My take: The fix is a 5-line concurrency block in ci.yml. This triage routine cannot edit .github/workflows/**, so a human needs to land it.

Proposed fix — add after the on: block in ci.yml, before jobs::

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

This cancels any in-progress run for the same branch on force-push, freeing slots immediately so the new SHA's matrix jobs are actually scheduled.

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code