What happened
On PR #1084, ralphbean issued /fs-fix remove the has(..) guards in here as bloat (comment, Aug 30 15:24 UTC). The fix agent correctly executed this in iteration 1 (human-triggered, TRIGGER_SOURCE=human), removing all 5 has(event.source) guards. Tests failed because the CI runtime hadn't picked up fullsend#6748's fix yet. The review agent then filed CHANGES_REQUESTED for [missing nil/null guard] (run 33319851319). Fix iteration 2 was bot-triggered (TRIGGER_SOURCE=bot): it read only the review body from review-body.txt, had no visibility into the human's prior /fs-fix instruction, and restored all guards — directly reversing the human's explicit request. The human had to intervene again in iteration 3 to reach the correct solution (guards + fallback pattern).
What could go better
The fix agent definition (agents/fix.md, lines 46-55) correctly establishes that human /fs-fix instructions take precedence over review feedback — but only in human-triggered mode. In bot-triggered mode, the fix agent receives only the review body as input. It has no mechanism to discover that a human recently issued a /fs-fix directive on the same PR, or what that directive said. This creates a structural blind spot: the fix agent can undo human-directed work in the very next iteration without knowing it's contradicting the human.
This is distinct from #767, which addresses the disagreement threshold within a single human-triggered run. The gap here is cross-iteration context: the fix agent needs to know about prior human instructions even when triggered by the review bot. Confidence: high — the agent definition explicitly establishes human instruction precedence, but the bot-triggered input pipeline bypasses it.
Proposed change
In the pre-fix script (scripts/pre-fix.sh) or the fix agent's harness config (harness/fix.yaml), add a step for bot-triggered runs that fetches recent PR comments containing /fs-fix instructions and injects them as supplementary context alongside the review body. Specifically:
- When
TRIGGER_SOURCE=bot, query the PR's comment history for /fs-fix comments from humans (not bots) posted within the last 48 hours.
- If found, write the most recent human
/fs-fix instruction to a context file (e.g., /sandbox/workspace/human-instruction.txt) and set an env var (e.g., HUMAN_INSTRUCTION_HISTORY) so the fix agent can reference it.
- In
agents/fix.md, add guidance for bot-triggered mode: "Before addressing review findings, check whether a human recently issued a /fs-fix instruction on this PR. If a review finding directly contradicts the human's instruction, flag the conflict and prefer the human's intent unless the change would break tests or introduce a regression — in which case, explain the conflict in the summary rather than silently reverting."
- In
skills/fix-review/SKILL.md, add a step between the current steps 1 and 2 for bot-triggered runs: "Read human-instruction.txt if present. Note any conflicts between the human's instruction and the review findings. When a conflict exists, prefer the human's intent."
Validation criteria
On the next 3 PRs where a human issues /fs-fix with explicit instructions and the subsequent review agent run files CHANGES_REQUESTED that contradicts those instructions: the bot-triggered fix agent should (a) reference the prior human instruction in its reasoning, (b) not silently reverse the human's directed change, and (c) either preserve the human's intent or explicitly flag the conflict in its summary comment. Zero silent reversals of human-directed changes across those 3 PRs.
Generated by retro agent from #1084
What happened
On PR #1084, ralphbean issued
/fs-fix remove the has(..) guards in here as bloat(comment, Aug 30 15:24 UTC). The fix agent correctly executed this in iteration 1 (human-triggered,TRIGGER_SOURCE=human), removing all 5has(event.source)guards. Tests failed because the CI runtime hadn't picked up fullsend#6748's fix yet. The review agent then filed CHANGES_REQUESTED for[missing nil/null guard](run 33319851319). Fix iteration 2 was bot-triggered (TRIGGER_SOURCE=bot): it read only the review body fromreview-body.txt, had no visibility into the human's prior/fs-fixinstruction, and restored all guards — directly reversing the human's explicit request. The human had to intervene again in iteration 3 to reach the correct solution (guards + fallback pattern).What could go better
The fix agent definition (
agents/fix.md, lines 46-55) correctly establishes that human/fs-fixinstructions take precedence over review feedback — but only in human-triggered mode. In bot-triggered mode, the fix agent receives only the review body as input. It has no mechanism to discover that a human recently issued a/fs-fixdirective on the same PR, or what that directive said. This creates a structural blind spot: the fix agent can undo human-directed work in the very next iteration without knowing it's contradicting the human.This is distinct from #767, which addresses the disagreement threshold within a single human-triggered run. The gap here is cross-iteration context: the fix agent needs to know about prior human instructions even when triggered by the review bot. Confidence: high — the agent definition explicitly establishes human instruction precedence, but the bot-triggered input pipeline bypasses it.
Proposed change
In the pre-fix script (
scripts/pre-fix.sh) or the fix agent's harness config (harness/fix.yaml), add a step for bot-triggered runs that fetches recent PR comments containing/fs-fixinstructions and injects them as supplementary context alongside the review body. Specifically:TRIGGER_SOURCE=bot, query the PR's comment history for/fs-fixcomments from humans (not bots) posted within the last 48 hours./fs-fixinstruction to a context file (e.g.,/sandbox/workspace/human-instruction.txt) and set an env var (e.g.,HUMAN_INSTRUCTION_HISTORY) so the fix agent can reference it.agents/fix.md, add guidance for bot-triggered mode: "Before addressing review findings, check whether a human recently issued a/fs-fixinstruction on this PR. If a review finding directly contradicts the human's instruction, flag the conflict and prefer the human's intent unless the change would break tests or introduce a regression — in which case, explain the conflict in the summary rather than silently reverting."skills/fix-review/SKILL.md, add a step between the current steps 1 and 2 for bot-triggered runs: "Read human-instruction.txt if present. Note any conflicts between the human's instruction and the review findings. When a conflict exists, prefer the human's intent."Validation criteria
On the next 3 PRs where a human issues
/fs-fixwith explicit instructions and the subsequent review agent run files CHANGES_REQUESTED that contradicts those instructions: the bot-triggered fix agent should (a) reference the prior human instruction in its reasoning, (b) not silently reverse the human's directed change, and (c) either preserve the human's intent or explicitly flag the conflict in its summary comment. Zero silent reversals of human-directed changes across those 3 PRs.Generated by retro agent from #1084