Proposal: improve ca-continuous-pr-reviewer — escalate approved-but-stuck PRs to implementation pool instead of re-reviewing #3691

New issue

Open

opened 2026-04-05 22:11:16 +00:00 by freemo · 0 comments

freemo commented

2026-04-05 22:11:16 +00:00

Owner

Agent Improvement Proposal

Pattern Detected

Type: workflow_fix
Affected Agent: ca-continuous-pr-reviewer
Evidence:

During session #3654, the system hit a plateau at 50 open PRs with zero progress for 30+ minutes (documented in heartbeat comments #125517 and #125607). The product builder diagnosed this as an "extended plateau" and identified 7 PRs with needs feedback labels as potential blockers.

The PR reviewer agent (lines 200-213 of ca-continuous-pr-reviewer.md) detects "approved-but-stuck" PRs — PRs that have been approved for >1 hour but haven't merged. When it finds these, it dispatches a ca-pr-self-reviewer to investigate. However, the agent's own description explicitly states:

CRITICAL CHANGE: You are ONLY responsible for dispatching code reviewers.
You do NOT:

Fix CI failures

Merge PRs

Handle merge conflicts

Close stale PRs

Verify issue closures

This creates a dead loop: the reviewer detects stuck PRs, dispatches investigation, but the investigator also cannot merge or fix the PR. The stuck PR remains stuck, and the next cycle detects it again, dispatching yet another investigation. Meanwhile, the implementation pool — which CAN merge PRs — is unaware that these PRs are stuck.

Proposed Change

Modify the "approved-but-stuck" handling in ca-continuous-pr-reviewer.md to escalate rather than re-review:

When an approved-but-stuck PR is detected, instead of dispatching a ca-pr-self-reviewer, post a structured comment on the session state issue flagging the stuck PR:

[STUCK-PR] PR #NNN has been approved for >1 hour but has not merged.
CI status: passing/failing/unknown
Merge conflicts: yes/no/unknown
Action needed: Implementation pool should attempt merge or fix blockers.

Add the stuck PR number to a recently_escalated set (similar to recently_reviewed) to avoid re-escalating the same PR every cycle. Only re-escalate if the PR is still stuck after 6 hours.
Remove the "approved-but-stuck" reason from the review dispatch path entirely — it should not consume a reviewer slot since no review is needed.

Expected Impact

Stuck PRs will be surfaced to the implementation pool (which monitors the session state issue) instead of being silently re-investigated
Reviewer slots will not be wasted on PRs that don't need code review
The feedback loop between the reviewer and implementation pool will be closed, reducing the PR plateau duration
The 50-PR plateau observed in session #3654 should resolve faster in future sessions

Risk Assessment

Low risk: This changes the escalation path for a specific edge case (approved-but-stuck), not the core review logic
Potential downside: If the implementation pool doesn't monitor session state comments for [STUCK-PR] signals, the escalation will go unnoticed. However, the implementation pool already monitors the session state issue for coordination.
Mitigation: The escalation comment uses a structured [STUCK-PR] prefix that can be easily searched for by other agents.

This is a proposal from the agent evolver. A human must approve this issue before the change will be implemented. To approve: remove the needs feedback label, add State/Verified, or comment with approval.

Automated by CleverAgents Bot
Supervisor: Agent Evolver | Agent: ca-agent-evolver

## Agent Improvement Proposal ### Pattern Detected **Type**: workflow_fix **Affected Agent**: `ca-continuous-pr-reviewer` **Evidence**: During session #3654, the system hit a plateau at 50 open PRs with zero progress for 30+ minutes (documented in heartbeat comments #125517 and #125607). The product builder diagnosed this as an "extended plateau" and identified 7 PRs with `needs feedback` labels as potential blockers. The PR reviewer agent (lines 200-213 of `ca-continuous-pr-reviewer.md`) detects "approved-but-stuck" PRs — PRs that have been approved for >1 hour but haven't merged. When it finds these, it dispatches a `ca-pr-self-reviewer` to investigate. However, the agent's own description explicitly states: > **CRITICAL CHANGE: You are ONLY responsible for dispatching code reviewers.** > You do NOT: > - Fix CI failures > - Merge PRs > - Handle merge conflicts > - Close stale PRs > - Verify issue closures This creates a **dead loop**: the reviewer detects stuck PRs, dispatches investigation, but the investigator also cannot merge or fix the PR. The stuck PR remains stuck, and the next cycle detects it again, dispatching yet another investigation. Meanwhile, the implementation pool — which CAN merge PRs — is unaware that these PRs are stuck. ### Proposed Change Modify the "approved-but-stuck" handling in `ca-continuous-pr-reviewer.md` to **escalate** rather than re-review: 1. When an approved-but-stuck PR is detected, instead of dispatching a `ca-pr-self-reviewer`, post a **structured comment on the session state issue** flagging the stuck PR: ``` [STUCK-PR] PR #NNN has been approved for >1 hour but has not merged. CI status: passing/failing/unknown Merge conflicts: yes/no/unknown Action needed: Implementation pool should attempt merge or fix blockers. ``` 2. Add the stuck PR number to a `recently_escalated` set (similar to `recently_reviewed`) to avoid re-escalating the same PR every cycle. Only re-escalate if the PR is still stuck after 6 hours. 3. Remove the "approved-but-stuck" reason from the review dispatch path entirely — it should not consume a reviewer slot since no review is needed. ### Expected Impact - Stuck PRs will be surfaced to the implementation pool (which monitors the session state issue) instead of being silently re-investigated - Reviewer slots will not be wasted on PRs that don't need code review - The feedback loop between the reviewer and implementation pool will be closed, reducing the PR plateau duration - The 50-PR plateau observed in session #3654 should resolve faster in future sessions ### Risk Assessment - **Low risk**: This changes the escalation path for a specific edge case (approved-but-stuck), not the core review logic - **Potential downside**: If the implementation pool doesn't monitor session state comments for `[STUCK-PR]` signals, the escalation will go unnoticed. However, the implementation pool already monitors the session state issue for coordination. - **Mitigation**: The escalation comment uses a structured `[STUCK-PR]` prefix that can be easily searched for by other agents. --- *This is a proposal from the agent evolver. A human must approve this issue before the change will be implemented. To approve: remove the `needs feedback` label, add `State/Verified`, or comment with approval.* --- **Automated by CleverAgents Bot** Supervisor: Agent Evolver | Agent: ca-agent-evolver

freemo referenced this issue

2026-04-05 22:11:59 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 (Resumed) #3654

freemo referenced this issue

2026-04-05 22:13:12 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 (Resumed) #3654