What happened
PR #792 was authored by a human (waynesun09) implementing a complex architectural change across 3 ADRs. The fix agent was automatically dispatched after the first bot review on May 9. It ran twice (run IDs 25609052168 and 25609325022 in fullsend-ai/.fullsend), both failed at the 'Run fix agent' step. The fix agent posted a comment claiming to fix 3 of 6 findings and disagreeing with 3 others, but its commits were not preserved (the branch was later rebased). The human had to issue /stop-fix to prevent further iterations, then manually addressed all issues over the next 4 days.
The fix agent's attempted fixes (build verification, routing completeness, jsonschema pinning) were on lower-priority items that the human was already addressing. Meanwhile, the higher-priority security issues were never surfaced until human review on May 13.
What could go better
This reinforces the pattern identified in issue #829: the fix agent creates noise and potential merge conflicts when it runs on human-authored PRs. The human author is actively iterating on the code and doesn't need an agent making concurrent changes. The /stop-fix escape hatch works but requires the human to notice and react.
Confidence: High. This is a well-documented pattern (#829) with a clear solution. The fullsend-no-fix label was applied to this PR, suggesting the team already has a workaround, but the fix agent ran before the label was applied.
Proposed change
Implement the approach from issue #829: make the fix agent opt-in for human-authored PRs. The fix agent should check whether the PR author is a bot (e.g., fullsend-ai-coder[bot]) before running. For human-authored PRs, the fix agent should only run if explicitly requested (e.g., via a /fix command or a specific label like fullsend-fix). The fullsend-no-fix label should not be needed as a workaround.
This change belongs in the dispatch routing logic (dispatch.yml or the shim workflow) where the fix agent is triggered after a review verdict.
Validation criteria
After implementation, the fix agent should not run on any human-authored PR unless explicitly requested. Verify by checking the next 10 human-authored PRs: none should have unsolicited fix agent runs. Issue #829 should be closeable.
Generated by retro agent from #792
What happened
PR #792 was authored by a human (waynesun09) implementing a complex architectural change across 3 ADRs. The fix agent was automatically dispatched after the first bot review on May 9. It ran twice (run IDs 25609052168 and 25609325022 in fullsend-ai/.fullsend), both failed at the 'Run fix agent' step. The fix agent posted a comment claiming to fix 3 of 6 findings and disagreeing with 3 others, but its commits were not preserved (the branch was later rebased). The human had to issue
/stop-fixto prevent further iterations, then manually addressed all issues over the next 4 days.The fix agent's attempted fixes (build verification, routing completeness, jsonschema pinning) were on lower-priority items that the human was already addressing. Meanwhile, the higher-priority security issues were never surfaced until human review on May 13.
What could go better
This reinforces the pattern identified in issue #829: the fix agent creates noise and potential merge conflicts when it runs on human-authored PRs. The human author is actively iterating on the code and doesn't need an agent making concurrent changes. The
/stop-fixescape hatch works but requires the human to notice and react.Confidence: High. This is a well-documented pattern (#829) with a clear solution. The
fullsend-no-fixlabel was applied to this PR, suggesting the team already has a workaround, but the fix agent ran before the label was applied.Proposed change
Implement the approach from issue #829: make the fix agent opt-in for human-authored PRs. The fix agent should check whether the PR author is a bot (e.g.,
fullsend-ai-coder[bot]) before running. For human-authored PRs, the fix agent should only run if explicitly requested (e.g., via a/fixcommand or a specific label likefullsend-fix). Thefullsend-no-fixlabel should not be needed as a workaround.This change belongs in the dispatch routing logic (
dispatch.ymlor the shim workflow) where the fix agent is triggered after a review verdict.Validation criteria
After implementation, the fix agent should not run on any human-authored PR unless explicitly requested. Verify by checking the next 10 human-authored PRs: none should have unsolicited fix agent runs. Issue #829 should be closeable.
Generated by retro agent from #792