Fix iteration cap should be resettable without manual squash-rebase

[guyoron1]

What happened

In PR #5427, the fix iteration cap of 10 was hit after legitimately complex work: a new CF Worker deployment platform, WASM bridge adapter, scope changes from two concurrent dependency merges (fullsend-ai#5447, fullsend-ai#5481), and detailed findings from an external multi-agent review squad. The babysitter had to manually squash-rebase the branch at ~2026-07-23T13:21Z to reset the commit-based counter. This squash-rebase introduced a regression: the 45-minute behaviour-test timeout was lost, requiring fix iteration 12 (run 30018653663) just to restore it.

What could go better

The cap is a valuable safety guardrail (related: #902), but the only reset mechanism (squash-rebase) modifies commit history and can introduce regressions. This PR demonstrates concrete harm: a squash-rebase lost a Makefile timeout setting, adding an extra fix iteration to restore it. Confidence: high that the UX friction is real. Moderate confidence on frequency — this may be uncommon, but when it occurs the workaround is error-prone. Related issues #976 (silent failure at cap), #2561 (commit strategy), and #4958 (squash on redo) address adjacent concerns but not the cap reset mechanism itself.

Proposed change

Add a /fs-fix-reset slash command (or /fs-fix --reset-cap flag) to the dispatch router in reusable-dispatch.yml or reusable-fix.yml that resets the fix iteration counter for a PR without requiring a branch squash. Implementation option: track the counter via a GitHub PR comment marker or label rather than commit count, making it resettable by command. The cap (default 10) still applies after reset — the command resets the counter, not disables it. This preserves the safety guardrail while eliminating the regression-prone squash-rebase workaround.

Validation criteria

The next time a PR legitimately needs >10 fix iterations, the babysitter can reset the counter via a slash command without squashing the branch. Zero squash-rebase-induced regressions from cap resets. The cap still prevents runaway loops when not explicitly reset.

---

Generated by retro agent from fullsend-ai#5427

[guyoron1]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 8:47 AM UTC · Completed 8:50 AM UTC
Commit: c887fc4 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Feature request: /fs-fix-reset slash command to reset fix iteration counter

The fix iteration cap is a safety guardrail, but the only reset mechanism (squash-rebase) modifies commit history and can introduce regressions. The motivating incident from PR fullsend-ai#5427 demonstrates concrete harm: a squash-rebase lost a Makefile timeout setting, costing an extra fix iteration to restore.

Proposed approach

• Move the fix iteration counter from a commit-count-based mechanism to a PR comment marker or label
• Add a /fs-fix-reset slash command to the dispatch router that resets the counter
• The cap (default 10) still applies after reset — this resets the count, not disables the guardrail
• Authorization: only babysitters/maintainers should be able to reset
• Key files: reusable-dispatch.yml and reusable-fix.yml

Proposed test case

1. Simulate a PR at iteration count 10 (cap reached)
2. Dispatch /fs-fix-reset command from an authorized actor
3. Verify counter resets to 0 and fix iterations can proceed
4. Verify the cap still applies after reset (10 more iterations hits cap again)
5. Edge cases: reset at count 0, unauthorized actor (rejected), multiple resets

⚠ Workflow file changes required

This feature requires modifications to GitHub Actions workflow files (reusable-dispatch.yml and/or reusable-fix.yml). The code agent cannot modify workflow files under current permissions — manual intervention (human PR or maintainer action) is required to implement this change.

Related work

• Upstream canonical issue: fullsend-ai/fullsend#5547 (open, triaged, priority/medium)
• Related local issues: Add /fs-stop <agent> slash command with in-flight cancellation #743 (slash command infrastructure for /fs-stop), Dispatch command parser should strip trailing punctuation from slash commands #544 (command parser improvements)
• Related upstream issues: Add circuit breaker to review-fix feedback loop fullsend-ai/fullsend#902 (safety guardrail), Fix agent fails silently when it cannot produce output within iteration limit fullsend-ai/fullsend#976 (silent failure at cap), Fix agent: configurable commit strategy (amend, squash, reset, append) fullsend-ai/fullsend#2561 (commit strategy), Fix agent should squash commits when human requests a redo from scratch fullsend-ai/fullsend#4958 (squash on redo) — adjacent concerns, not blockers

---

Labels: This is a feature request involving the dispatch workflow router. The enhancement and component/dispatch labels are already applied and correct. Adding priority/medium based on upstream triage alignment.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

Previous run

Triage Summary

Feature request: /fs-fix-reset slash command to reset fix iteration counter

The fix iteration cap is a valuable safety guardrail, but the only reset mechanism (squash-rebase) modifies commit history and can introduce regressions. The motivating incident from PR fullsend-ai#5427 demonstrates concrete harm: a squash-rebase lost a Makefile timeout setting, costing an extra fix iteration to restore.

Proposed approach

• Move the fix iteration counter from a commit-count-based mechanism to a PR comment marker or label
• Add a /fs-fix-reset slash command to the dispatch router that resets the counter
• The cap (default 10) still applies after reset — this resets the count, not disables the guardrail
• Key files: reusable-dispatch.yml and reusable-fix.yml

Proposed test case

1. Simulate a PR at iteration count 10 (cap reached)
2. Dispatch /fs-fix-reset command
3. Verify counter resets to 0 and fix iterations can proceed
4. Verify the cap still applies after reset (10 more iterations hits cap again)
5. Edge cases: reset at count 0 (no-op), unauthorized actor (rejected)

⚠ Workflow file changes required

This feature requires modifications to GitHub Actions workflow files (reusable-dispatch.yml and/or reusable-fix.yml). The code agent cannot modify workflow files under current permissions — manual intervention (human PR or maintainer action) is required to implement this change.

Related issues

The issue references related upstream issues (fullsend-ai#902, fullsend-ai#976, fullsend-ai#2561, fullsend-ai#4958) that address adjacent concerns (silent failure at cap, commit strategy, squash on redo) but not the cap reset mechanism itself. Also related: #743 (slash command infrastructure for /fs-stop) and #544 (slash command parser improvements).

---

Labels: This issue involves dispatch workflow routing (component/dispatch) and is a new feature request (enhancement). The requires_workflow_changes flag is set because the fix involves reusable-dispatch.yml and reusable-fix.yml.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 8:56 AM UTC · Completed 9:00 AM UTC
Commit: c887fc4 · View workflow run →

[guyoron1]

/fs-code

[fullsend-ai-coder]

🤖 Finished Code · ❌ Failure · Started 9:32 AM UTC · Completed 9:44 AM UTC
Commit: c887fc4 · View workflow run →

[fullsend-ai-coder]

⚠️ Post-code script failed — Pre-commit blocked (exit code 1)

The code agent completed, but the post-code script failed before finishing.

Workflow run: https://github.com/guyoron1/fullsend/actions/runs/30741791372

Details:
check toml...........................................(no files to check)Skipped
mixed line ending........................................................Passed
ruff (legacy alias)..................................(no files to check)Skipped
ruff format..........................................(no files to check)Skipped
ty check.............................................(no files to check)Skipped
bandit...............................................(no files to check)Skipped
Detect hardcoded secrets.................................................Passed
shellcheck...........................................(no files to check)Skipped
pinact (SHA-pin check)...................................................Failed
- hook id: pinact
- exit code: 2

�[31mERROR�[0m failed to handle a line: action can't be pinned
.github/workflows/fullsend.yaml:52
    uses: guyoron1/fullsend/.github/workflows/reusable-dispatch.yml@main
::error file=.github/workflows/fullsend.yaml,line=52,title=pinact error::action can't be pinned

Lint GitHub Actions workflow files.......................................Passed
gofmt....................................................................Passed
go vet...................................................................Passed
lint mint embed sync.................................(no files to check)Skipped
lint interface doc sync..............................(no files to check)Skipped
lint ADR statuses....................................(no files to check)Skipped
lint ADR numbers.....................................(no files to check)Skipped
lint ADR frontmatter.................................(no files to check)Skipped
lint broken symlinks.....................................................Passed
lint docs link scope.....................................................Passed
lint markdown links......................................................Passed
lint workflow file size..................................................Passed
lint-staged (web)....................................(no files to check)Skipped

Please check the workflow logs for full details and retry with /fs-code if appropriate.