What happened
Issue #6430 reported that GitLab dispatch was missing RETRO_COMMENT. The issue explicitly referenced #6418 as the "same class of issue" and noted that PR #6419 had already added RETRO_COMMENT extraction from EVENT_PAYLOAD_B64 in the scaffold template.
The triage agent (run 32402265126) acknowledged the prior fix, writing: "PR #6419 added RETRO_COMMENT extraction from EVENT_PAYLOAD_B64 in the scaffold template, but enrolled repos need re-enrollment to pick up that change." It then recommended new dispatch-level code to "decouple the fix from scaffold deployment timing" and labeled the issue ready-to-code.
The code agent (run 32403029198) built PR #6431 with dispatch variable + HMAC changes across 3 files. The review agent (run 32404187486) provided quality tactical feedback but did not question necessity.
40 minutes later, human reviewer ggallen closed the PR: the scaffold already handled RETRO_COMMENT; the test repo just needed re-enrollment. The entire pipeline — triage, code, review, CI — produced no value.
What could go better
The triage agent had all the information needed to reach the correct conclusion. It read the issue, saw the reference to #6418/#6419, and explicitly acknowledged that "PR #6419 added RETRO_COMMENT extraction." The correct assessment was: "The fix already exists in the scaffold (PR #6419). The test repo needs to re-enroll to pick up the change. No code change needed — recommend re-enrollment."
Instead, the triage decided to recommend adding dispatch-level complexity (new variable, HMAC key changes, shell template updates) to avoid an operational step (re-enrollment). This judgment error led to a wasted pipeline producing a PR that was immediately closed.
The specific failure pattern is distinct from existing issues about triage investigation breadth. The triage DID find the prior fix — it acknowledged #6419 by name. The problem was that it didn't verify whether that fix actually solved the current problem (it did), and it preferred proposing new code over recommending an operational action. Existing issues #764 (investigate issue-referenced components) and #352 (verify merge status of cross-repo PR references) address adjacent but different patterns — #764 is about investigating code components, and #352 is about verifying merge status. Neither covers the pattern of semantically verifying whether a referenced prior fix already resolves the current problem.
Confidence: high that this is a correctable pattern. The triage had the evidence and drew the wrong conclusion.
Proposed change
Add guidance to the triage agent definition or triage skill in fullsend-ai/agents for handling issues that reference prior fixes. When an issue references a prior fix (via "Related", "See also", linked PR/issue numbers, or phrases like "same class of issue"):
- Read the referenced PR diff and description to understand what the prior fix actually changed
- Verify whether the prior fix addresses the current problem — don't just acknowledge it exists; check whether its code changes solve the reported issue
- If the fix exists but hasn't been deployed to the affected environment, recommend the operational action (re-enrollment, redeployment, config sync) as the resolution rather than proposing new code
- Do not label
ready-to-code when the resolution is operational rather than a code change — instead, comment with the recommended operational steps and consider closing the issue or adding a needs-enrollment / operational label
Example prompt addition for the triage agent or skill:
When the issue references prior fixes or related issues, read the referenced PR's diff. If a prior fix already addresses the problem but the affected environment hasn't picked it up (e.g., stale CI config, needs re-enrollment, pending deployment), recommend the operational action as the resolution. Do not label ready-to-code for issues that require deployment or configuration updates rather than new code.
Validation criteria
In the next 5 triage runs where the issue references a prior fix that already addresses the problem:
- The triage agent should follow the reference and read the prior fix's PR diff
- The triage should correctly identify when re-enrollment, redeployment, or config sync is the fix rather than new code
- The triage should not label
ready-to-code for issues where the resolution is operational
- Zero closed-without-merge PRs should result from this pattern (operational issues incorrectly promoted to ready-to-code)
Generated by retro agent from fullsend-ai/fullsend#6431
What happened
Issue #6430 reported that GitLab dispatch was missing
RETRO_COMMENT. The issue explicitly referenced #6418 as the "same class of issue" and noted that PR #6419 had already addedRETRO_COMMENTextraction fromEVENT_PAYLOAD_B64in the scaffold template.The triage agent (run 32402265126) acknowledged the prior fix, writing: "PR #6419 added RETRO_COMMENT extraction from EVENT_PAYLOAD_B64 in the scaffold template, but enrolled repos need re-enrollment to pick up that change." It then recommended new dispatch-level code to "decouple the fix from scaffold deployment timing" and labeled the issue
ready-to-code.The code agent (run 32403029198) built PR #6431 with dispatch variable + HMAC changes across 3 files. The review agent (run 32404187486) provided quality tactical feedback but did not question necessity.
40 minutes later, human reviewer ggallen closed the PR: the scaffold already handled
RETRO_COMMENT; the test repo just needed re-enrollment. The entire pipeline — triage, code, review, CI — produced no value.What could go better
The triage agent had all the information needed to reach the correct conclusion. It read the issue, saw the reference to #6418/#6419, and explicitly acknowledged that "PR #6419 added RETRO_COMMENT extraction." The correct assessment was: "The fix already exists in the scaffold (PR #6419). The test repo needs to re-enroll to pick up the change. No code change needed — recommend re-enrollment."
Instead, the triage decided to recommend adding dispatch-level complexity (new variable, HMAC key changes, shell template updates) to avoid an operational step (re-enrollment). This judgment error led to a wasted pipeline producing a PR that was immediately closed.
The specific failure pattern is distinct from existing issues about triage investigation breadth. The triage DID find the prior fix — it acknowledged #6419 by name. The problem was that it didn't verify whether that fix actually solved the current problem (it did), and it preferred proposing new code over recommending an operational action. Existing issues #764 (investigate issue-referenced components) and #352 (verify merge status of cross-repo PR references) address adjacent but different patterns — #764 is about investigating code components, and #352 is about verifying merge status. Neither covers the pattern of semantically verifying whether a referenced prior fix already resolves the current problem.
Confidence: high that this is a correctable pattern. The triage had the evidence and drew the wrong conclusion.
Proposed change
Add guidance to the triage agent definition or triage skill in
fullsend-ai/agentsfor handling issues that reference prior fixes. When an issue references a prior fix (via "Related", "See also", linked PR/issue numbers, or phrases like "same class of issue"):ready-to-codewhen the resolution is operational rather than a code change — instead, comment with the recommended operational steps and consider closing the issue or adding aneeds-enrollment/operationallabelExample prompt addition for the triage agent or skill:
Validation criteria
In the next 5 triage runs where the issue references a prior fix that already addresses the problem:
ready-to-codefor issues where the resolution is operationalGenerated by retro agent from fullsend-ai/fullsend#6431