fix(router): scope trigger dedup by work item

[maksymilian-majer]

Summary

• Scope trigger-level dedup by work item when a PM/Linear trigger resolves a workItemId.
• Preserve the existing project+agent dedup behavior for triggers without a work item scope.
• Keep duplicate events for the same work item suppressed while allowing batch moves of different work items to enqueue concurrently up to maxConcurrency.

Context

Moving multiple Linear issues into the same status in quick succession currently dispatches the first agent run and suppresses the rest as Agent type concurrency limit reached, even when the agent has maxConcurrency > 1. The dedup layer was keyed only by projectId:agentType, so different work items in the same batch collided before the concurrency limit was considered.

Test Plan

• npm test -- tests/unit/router/agent-type-lock.test.ts tests/unit/router/webhook-processor.test.ts tests/unit/pm/webhook-handler.test.ts
• pre-push npm run test:fast -- --changed origin/dev

[codecov]

Codecov Report

❌ Patch coverage is 92.85714% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/pm/webhook-handler.ts	85.71%	1 Missing ⚠️
src/router/webhook-processor.ts	50.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[nhopeatall]

Summary

LGTM - The implementation elegantly scopes the 60-second deduplication window to the work item without breaking the project-wide maxConcurrency limits.

Architecture & Design

The approach correctly splits the deduplication key (projectId:agentType:workItemId) from the concurrency locking key (projectId:agentType). This allows multiple different issues in a batch update to pass the router's deduplication phase and queue up to the agent type's maxConcurrency limit, while still suppressing duplicate webhooks for the same work item.

Tactical Verification

• The changes are well-contained and correctly thread result.workItemId down into checkAgentTypeConcurrency and markRecentlyDispatched.
• agentTypeRunningCount mapping is intentionally left untouched so global rate-limiting remains robust.
• The unit tests accurately simulate the new behaviour.
• Although src/triggers/shared/concurrency.ts was not updated to pass dedupScope, this is perfectly safe because workers are ephemeral (one job per container), rendering the in-memory dedupMap checks inside the worker practically a no-op anyway.

🕵️ opencode · google/gemini-3.1-pro-preview · run details