Parallel triage

What's clear: The Phase 5 implementation limit (1 at a time) should remain, and the agent should be encouraged to do triage and planning in parallel across multiple issues.

Observation: The Concurrency section (line 30) already states "Multiple issues may be in Phases 1-4 or 6-8 concurrently." So the rules already permit parallel triage/planning. However, the wording could be more explicit about encouraging this — currently it reads as a permission rather than guidance.

Questions:

Is the request to make the existing concurrency rules more prominent/encouraging, or is there a specific behavior change you want? For example, should the Loop Iteration section explicitly say "triage and plan multiple issues within the same iteration" rather than just allowing it?
Should the "each in a different phase" constraint (line 23) be relaxed? Currently it implies two issues can't both be in Phase 2 (triage) simultaneously. If you want truly parallel triage, this constraint needs to be removed.

Point 2 seems like the key issue — "each in a different phase" currently prevents two issues from being triaged at the same time. Please confirm.

## Triage Assessment **What's clear:** The Phase 5 implementation limit (1 at a time) should remain, and the agent should be encouraged to do triage and planning in parallel across multiple issues. **Observation:** The Concurrency section (line 30) already states "Multiple issues may be in Phases 1-4 or 6-8 concurrently." So the rules already permit parallel triage/planning. However, the wording could be more explicit about *encouraging* this — currently it reads as a permission rather than guidance. **Questions:** 1. Is the request to make the existing concurrency rules more prominent/encouraging, or is there a specific behavior change you want? For example, should the Loop Iteration section explicitly say "triage and plan multiple issues within the same iteration" rather than just allowing it? 2. Should the "each in a different phase" constraint (line 23) be relaxed? Currently it implies two issues can't both be in Phase 2 (triage) simultaneously. If you want truly parallel triage, this constraint needs to be removed. Point 2 seems like the key issue — "each in a different phase" currently prevents two issues from being triaged at the same time. Please confirm.

ReadyPlayerNaN commented

2026-03-19 13:43:40 +00:00

Author

Owner

It should be about priorities. If there is nothing else to do, start a triage for another task. We should still keep processing single task per a loop iteration.

ReadyPlayerNaN commented

2026-03-19 13:50:40 +00:00

Author

Owner

Thanks for the clarification. The intent is clear: prioritize advancing in-flight work, but when blocked (waiting for approval/review), use that time to triage or plan other issues rather than sitting idle. Proceeding to planning.

ReadyPlayerNaN added

planning

and removed

triaging

labels

2026-03-19 13:50:46 +00:00

ReadyPlayerNaN commented

2026-03-19 13:50:59 +00:00

Author

Owner

Plan

Goal: Clarify the concurrency rules so that multiple issues can be in triage or planning simultaneously, with clear priority guidance on when to start new work vs. advance existing work.

Approach: Edit the Concurrency section and Loop Iteration section in merge-request-flow.md.

Tasks:

Relax "each in a different phase" constraint — Change "up to 3 issues simultaneously, each in a different phase" to remove the different-phase restriction for Phases 1-4. Multiple issues may be in triage or planning at the same time. Keep the Phase 5 single-issue limit.
Clarify priority order in Loop Iteration — Reinforce that each iteration should: (a) advance the most progressed in-flight issue first, (b) only start triage/planning for new issues when no other issue can be advanced in this iteration.
Keep single-task focus per iteration — Add a note that within a single loop iteration, the agent processes one task action at a time (not parallelizing triage across multiple issues within the same iteration), but may triage/plan different issues across successive iterations.

Risks:

None — this is a wording clarification that aligns the doc with intended behavior.

Test strategy:

Verify the concurrency rules no longer prohibit two issues in the same phase (for Phases 1-4).
Verify the Loop Iteration section clearly states the priority order.
Verify the Phase 5 single-issue limit is preserved.

## Plan **Goal:** Clarify the concurrency rules so that multiple issues can be in triage or planning simultaneously, with clear priority guidance on when to start new work vs. advance existing work. **Approach:** Edit the Concurrency section and Loop Iteration section in `merge-request-flow.md`. **Tasks:** 1. **Relax "each in a different phase" constraint** — Change "up to 3 issues simultaneously, each in a different phase" to remove the different-phase restriction for Phases 1-4. Multiple issues may be in triage or planning at the same time. Keep the Phase 5 single-issue limit. 2. **Clarify priority order in Loop Iteration** — Reinforce that each iteration should: (a) advance the most progressed in-flight issue first, (b) only start triage/planning for new issues when no other issue can be advanced in this iteration. 3. **Keep single-task focus per iteration** — Add a note that within a single loop iteration, the agent processes one task action at a time (not parallelizing triage across multiple issues within the same iteration), but may triage/plan different issues across successive iterations. **Risks:** - None — this is a wording clarification that aligns the doc with intended behavior. **Test strategy:** - Verify the concurrency rules no longer prohibit two issues in the same phase (for Phases 1-4). - Verify the Loop Iteration section clearly states the priority order. - Verify the Phase 5 single-issue limit is preserved.

👍 1

ReadyPlayerNaN added

implementing

and removed

planning

labels

2026-03-19 13:51:06 +00:00

ReadyPlayerNaN referenced this issue from a commit

2026-03-19 14:00:57 +00:00

docs: allow parallel triage and planning with priority guidance

ReadyPlayerNaN referenced this issue from a pull request that will close it,

2026-03-19 14:01:05 +00:00