resolve-issue-tickets

Scan all tickets in workspace/tickets/to-do/, extract their dependencies and touched file paths, then pack them into waves where no two tickets share files or dependency edges. Dispatch one executor agent per ticket in a single message so they run concurrently, capped at 4 per wave.

Use a separate verifier agent that reads the ticket's acceptance_criteria, runs each listed shell command, checks file paths and grep patterns, and returns APPROVED or REJECTED with failing criteria. The executor must never verify its own work.

Tickets that touch the same file must never share a wave, because parallel writes silently clobber each other while each agent's gates still pass in isolation. The wave-planning phase detects these file collisions before any executor is spawned.

Skip the executor when the fix is deterministic and resolves in under 5 file reads, such as a one-line change or rename. Edit it directly, run the acceptance gates, mark status: completed, and move the file to avoid unnecessary spawn overhead.

After 2 failed feedback rounds, the ticket stays in workspace/tickets/to-do/ and gets a Resolution Blockers section appended summarizing the unresolved findings. It is surfaced in the final report instead of being marked completed.

No, it only resolves tickets already present in workspace/tickets/to-do/. Use generate-issue-tickets to create tickets and triage-issue-tickets to cancel or close tickets without resolving them.