Fix agent: distinguish 'cannot modify protected path' from 'disagree with finding'

[fullsend-ai-retro]

What happened

On PR #742, the review agent requested changes on 5 findings, all in .github/workflows/fullsend.yaml. The fix agent posted a comment recording all 5 as 'disagreements' with remediation guidance. But the fix agent did not actually disagree with the findings — it agreed they were valid but could not modify the file because .github/workflows/ is a protected path. The word 'disagreed' is misleading and could cause a human reviewer to dismiss the findings as false positives rather than understanding they need manual attention.

What could go better

The fix agent's output schema and reporting should distinguish between three dispositions: (1) fixed, (2) cannot fix (permission/protected path), (3) disagree (finding is incorrect). Currently dispositions 2 and 3 are conflated. This matters because 'cannot fix' findings should be escalated to a human for action, while 'disagree' findings should be evaluated on their merits. Confidence: high — the fix agent's own comment text shows it understood the distinction ('protected CI configuration path') but had no structured way to express it.

Proposed change

Update the fix agent definition (internal/scaffold/fullsend-repo/agents/fix.md) to add a cannot-fix disposition alongside fixed and disagreed in the fix-result.json schema. The cannot-fix disposition should include a reason field (e.g., 'protected-path', 'out-of-scope', 'requires-human-judgment') and should be surfaced differently in the post-fix script's comment — clearly labeled as 'requires human action' rather than 'disagreed'. Also update the validate-output-schema.sh to accept the new disposition.

Validation criteria

The next time the fix agent encounters a finding in a protected path, its output should use the cannot-fix disposition with a clear 'requires human action' label in the posted comment, not 'disagreed'. Verify by inspecting the fix agent's comment on a PR where review findings target protected paths.

---

Generated by retro agent from #742

[github-actions]

fullsend triage is working on this — view logs

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Enhancement

Problem

The fix agent's output schema supports only two action dispositions (fix and disagree). When the agent encounters a valid finding in a protected path it cannot modify, it is forced to record the action as "disagree" — misleading human reviewers into potentially dismissing valid findings as false positives.

Root Cause

The fix-result.schema.json action type enum is ["fix", "disagree"] with no way to express "agree but cannot act." The agent understands the distinction (its comment text references the protected path) but the schema forces an incorrect categorization.

Recommended Fix

1. Schema (schemas/fix-result.schema.json): Add cannot-fix to the action type enum with a required cannot_fix_reason field (e.g., protected-path, out-of-scope, requires-human-judgment)
2. Agent definition (agents/fix.md): Instruct the agent to use cannot-fix when it agrees with a finding but cannot modify the target file
3. Post-fix script (scripts/process-fix-result.py): Render cannot-fix actions under a distinct "Requires Human Action" heading
4. Lifecycle tracing: Per Code agent: trace full lifecycle when adding new enum values or dispositions #853, search for all consumers of the action type enum to ensure complete coverage

Proposed Test Case

Test 1 - Schema validation:
  - Create fix-result.json with type: "cannot-fix" and cannot_fix_reason: "protected-path"
  - Verify it passes schema validation
  - Verify "cannot-fix" without cannot_fix_reason fails validation

Test 2 - Comment rendering:
  - Feed process-fix-result.py a result with mixed dispositions
    (one fix, one disagree, one cannot-fix)
  - Verify output has three distinct sections:
    "Fixed", "Disagreed", "Requires Human Action"

Test 3 - Backward compatibility:
  - Verify existing results with only fix/disagree still pass validation

Notes

This is closely related to #853 (tracing full lifecycle when adding new enum values). Implementing this change is a good opportunity to apply that guidance — ensuring all consumers of the disposition enum are updated together.