What happened
On PR #6455, the fix agent was dispatched 5 times, all failing. Runs 1 and 2 (32507571645, 32512193758) failed with identical actionlint errors — the agent produced multiline ${{ }} in if: conditions both times. Run 5 (32528536737) hit the workflows permission wall, a hard constraint the agent could not have overcome. Each dispatch started from scratch with no knowledge of prior failure reasons.
What could go better
Each fix agent dispatch currently starts with a blank slate — it receives the review findings but has no context about why previous fix attempts on the same PR failed. This leads to two waste patterns: (1) the agent repeats the same code mistake because it never saw the pre-commit error output from its last attempt (runs 1–2 both produced the same invalid actionlint pattern), and (2) the agent attempts work that is structurally impossible given its permission constraints (run 5 tried to push workflow file changes the GitHub App cannot write). Existing issues #1742 and #2980 address carrying forward review feedback across fix iterations, but neither covers carrying forward fix execution failure context (actionlint output, permission rejections, push errors). Issue #6494 (recently closed) addresses in-loop pre-commit retries, which helps within a single run but does not inform subsequent dispatches. Confidence: high that this is a distinct gap — the three existing issues address different aspects of the problem.
Proposed change
In the fix agent's pre-fix script or harness config (harness/fix.yaml in fullsend-ai/agents), when assembling context for a fix dispatch, check whether previous fix runs exist on the same PR. If they do, include a 'Prior fix attempts' section in the agent's context containing: (1) the run ID and timestamp of each prior fix attempt, (2) the failure category (pre-commit failure, push rejection, permission denial), (3) the specific error output (e.g., actionlint error text, permission rejection message), and (4) for permission-related failures, a list of file paths the agent cannot modify. This context should be gathered from the fix agent's status comments on the PR (which already contain failure classifications per #5382) or from the workflow run API. The agent definition (agents/fix.md) should include guidance to consult this section before attempting fixes and to skip findings targeting files it cannot push to.
Validation criteria
On the next PR where the fix agent fails and is re-dispatched on the same PR: (1) the second fix attempt should not repeat the exact same pre-commit error as the first attempt, and (2) if the first attempt failed due to a permission rejection on a specific file path, the second attempt should either skip that file or exit early with a clear message. Measure across 5 PRs where multiple fix dispatches occur — the repeat-same-error rate should drop from the current baseline (2/5 runs on this PR) to 0.
Generated by retro agent from fullsend-ai/fullsend#6455
What happened
On PR #6455, the fix agent was dispatched 5 times, all failing. Runs 1 and 2 (32507571645, 32512193758) failed with identical actionlint errors — the agent produced multiline
${{ }}inif:conditions both times. Run 5 (32528536737) hit theworkflowspermission wall, a hard constraint the agent could not have overcome. Each dispatch started from scratch with no knowledge of prior failure reasons.What could go better
Each fix agent dispatch currently starts with a blank slate — it receives the review findings but has no context about why previous fix attempts on the same PR failed. This leads to two waste patterns: (1) the agent repeats the same code mistake because it never saw the pre-commit error output from its last attempt (runs 1–2 both produced the same invalid actionlint pattern), and (2) the agent attempts work that is structurally impossible given its permission constraints (run 5 tried to push workflow file changes the GitHub App cannot write). Existing issues #1742 and #2980 address carrying forward review feedback across fix iterations, but neither covers carrying forward fix execution failure context (actionlint output, permission rejections, push errors). Issue #6494 (recently closed) addresses in-loop pre-commit retries, which helps within a single run but does not inform subsequent dispatches. Confidence: high that this is a distinct gap — the three existing issues address different aspects of the problem.
Proposed change
In the fix agent's pre-fix script or harness config (
harness/fix.yamlinfullsend-ai/agents), when assembling context for a fix dispatch, check whether previous fix runs exist on the same PR. If they do, include a 'Prior fix attempts' section in the agent's context containing: (1) the run ID and timestamp of each prior fix attempt, (2) the failure category (pre-commit failure, push rejection, permission denial), (3) the specific error output (e.g., actionlint error text, permission rejection message), and (4) for permission-related failures, a list of file paths the agent cannot modify. This context should be gathered from the fix agent's status comments on the PR (which already contain failure classifications per #5382) or from the workflow run API. The agent definition (agents/fix.md) should include guidance to consult this section before attempting fixes and to skip findings targeting files it cannot push to.Validation criteria
On the next PR where the fix agent fails and is re-dispatched on the same PR: (1) the second fix attempt should not repeat the exact same pre-commit error as the first attempt, and (2) if the first attempt failed due to a permission rejection on a specific file path, the second attempt should either skip that file or exit early with a clear message. Measure across 5 PRs where multiple fix dispatches occur — the repeat-same-error rate should drop from the current baseline (2/5 runs on this PR) to 0.
Generated by retro agent from fullsend-ai/fullsend#6455