What happened
On roming22-org/fullsend-python#19, the first triage misdiagnosed the root cause, leading to PR #20 that didn't fix the primary error. A re-triage at 21:33 UTC explicitly stated the existing PR does not address the primary error. When the user ran /fs-code at 21:46 UTC, the pre-code check found PR #20 still open and skipped with the message that an open PR already addresses the issue. The user had to use /fs-code --force to override and trigger the second code run that produced the correct PR #21.
What could go better
The pre-code existing-PR check uses a simple heuristic: if any open agent-authored PR addresses the issue, skip. This ignores re-triage conclusions that explicitly flag the existing PR as insufficient. In autonomous workflows without human monitoring, this creates a dead end — the triage pipeline identifies the problem (existing PR is wrong) but the code agent cannot self-correct because the skip prevents a new code run. The --force escape hatch works only with human intervention. Confidence is high — the log evidence clearly shows the skip firing after a re-triage invalidated the existing PR. Note: existing issue agents#772 addresses a different bug in the same mechanism (the skip not halting the run when it fires); this proposal is about the skip firing when it should not.
Proposed change
In pre-code.sh (or the equivalent harness-level existing-PR check), add a secondary condition before skipping: check whether the most recent triage comment on the issue (identified by the fullsend:triage-agent HTML comment marker) post-dates the existing PR and contains signals that the PR is insufficient. The triage agent already emits structured markers like 'Re-triage: PR does not address the primary error.' If such a post-PR triage comment indicates the existing fix is incomplete, suppress the skip and proceed with a new code generation on a fresh branch. This preserves the skip for the common case (existing PR is valid) while enabling self-correction when re-triage identifies a problem.
Validation criteria
On the next occurrence where a re-triage flags an existing agent PR as insufficient and /fs-code is invoked (without --force), the code agent should detect the re-triage conclusion, suppress the existing-PR skip, and proceed with code generation. Verify over the next 5 instances of re-triage across any repo: in each case where the re-triage identifies the existing PR as insufficient, the subsequent code dispatch should not require --force.
Generated by retro agent from roming22-org/fullsend-python#21
What happened
On roming22-org/fullsend-python#19, the first triage misdiagnosed the root cause, leading to PR #20 that didn't fix the primary error. A re-triage at 21:33 UTC explicitly stated the existing PR does not address the primary error. When the user ran
/fs-codeat 21:46 UTC, the pre-code check found PR #20 still open and skipped with the message that an open PR already addresses the issue. The user had to use/fs-code --forceto override and trigger the second code run that produced the correct PR #21.What could go better
The pre-code existing-PR check uses a simple heuristic: if any open agent-authored PR addresses the issue, skip. This ignores re-triage conclusions that explicitly flag the existing PR as insufficient. In autonomous workflows without human monitoring, this creates a dead end — the triage pipeline identifies the problem (existing PR is wrong) but the code agent cannot self-correct because the skip prevents a new code run. The
--forceescape hatch works only with human intervention. Confidence is high — the log evidence clearly shows the skip firing after a re-triage invalidated the existing PR. Note: existing issue agents#772 addresses a different bug in the same mechanism (the skip not halting the run when it fires); this proposal is about the skip firing when it should not.Proposed change
In
pre-code.sh(or the equivalent harness-level existing-PR check), add a secondary condition before skipping: check whether the most recent triage comment on the issue (identified by thefullsend:triage-agentHTML comment marker) post-dates the existing PR and contains signals that the PR is insufficient. The triage agent already emits structured markers like 'Re-triage: PR does not address the primary error.' If such a post-PR triage comment indicates the existing fix is incomplete, suppress the skip and proceed with a new code generation on a fresh branch. This preserves the skip for the common case (existing PR is valid) while enabling self-correction when re-triage identifies a problem.Validation criteria
On the next occurrence where a re-triage flags an existing agent PR as insufficient and
/fs-codeis invoked (without--force), the code agent should detect the re-triage conclusion, suppress the existing-PR skip, and proceed with code generation. Verify over the next 5 instances of re-triage across any repo: in each case where the re-triage identifies the existing PR as insufficient, the subsequent code dispatch should not require--force.Generated by retro agent from roming22-org/fullsend-python#21