feat: add /fix workflow — iterative review → fix → re-review loop

[PureWeen]

Summary

Adds a new gh-aw workflow that implements an iterative review → fix → re-review loop, triggered via the /fix slash command on any PR.

How It Works

/fix on a PR
  ↓
┌─────────────────────────────────┐
│  Round 1: 3-model review        │
│  (Opus + Sonnet + Codex)        │
│  → Adversarial consensus        │
│  → CRITICAL/MODERATE findings?  │
│     YES → fix locally, commit   │
│     NO  → done ✅                │
└────────────┬────────────────────┘
             ↓
┌─────────────────────────────────┐
│  Round 2: Re-review updated code│
│  → New findings?                │
│     YES → fix, commit           │
│     NO  → done ✅                │
└────────────┬────────────────────┘
             ↓
        (up to 3 rounds)
             ↓
┌─────────────────────────────────┐
│  Push all commits at once       │
│  Post summary + final review    │
└─────────────────────────────────┘

Key Design Decisions

1. Single-run iteration — All review/fix cycles happen within one agent session. push-to-pull-request-branch pushes all commits at the end (safe-output runs after agent exits).

2. Max 3 fix rounds — Hard limit prevents infinite loops. After 3 rounds, remaining findings are posted as unresolved inline comments.

3. MINOR findings don't block — Only 🔴 CRITICAL and 🟡 MODERATE trigger another cycle. 🟢 MINOR are fixed opportunistically.

4. Shared concurrency group — Uses review-<PR> group, same as /review. A /fix cancels any in-progress /review on the same PR (and vice versa).

5. Protected files — protected-files: fallback-to-issue prevents the agent from modifying .github/, package manifests, etc. If it tries, an issue is created for human review instead.

6. One commit per finding — Keeps git history reviewable. Each commit references the finding it addresses.

Files

File	Purpose
.github/workflows/fix.agent.md	Slash command entry point (/fix)
.github/workflows/shared/fix-shared.md	Iterative loop prompt + safe-outputs
.github/workflows/fix.agent.lock.yml	Auto-generated lock file

Safe Outputs

• push-to-pull-request-branch (max 1) — pushes fix commits
• submit-pull-request-review (max 1, COMMENT only)
• create-pull-request-review-comment (max 30) — unresolved findings
• add-comment (max 5, hide-older-comments) — iteration summary

[github-actions]

🔍 Additional Design-Level Observations

These findings are not tied to specific diff lines but are relevant to the workflow design:

🟢 cancel-in-progress silently discards pre-push fix commits (3/3 reviewers after follow-up)

If /fix is triggered twice rapidly on the same PR, the first run is cancelled mid-execution. Since fixes are accumulated as local git commits and pushed only at the end (Step 4 via push-to-pull-request-branch), all uncommitted progress is silently lost — potentially 60–100 minutes of agent work with no trace on the PR.

This is the correct pattern for review-only workflows but the lost-work window is significant for a mutating workflow. Consider either:

• Adding a prompt note: "If interrupted before pushing, fixes cannot be recovered — user must re-trigger /fix"
• Restructuring to push after each fix round (requires push-to-pull-request-branch: max: 3)

🟢 allowed-events: [COMMENT] not enforced at infrastructure level (2/3 reviewers, informational)

The compiled lock file shows "submit_pull_request_review":{"max":1} with no allowed_events restriction in the handler config. The source declares allowed-events: [COMMENT] but this isn't propagated to the runtime handler in gh-aw v0.62.2. The restriction relies on LLM prompt compliance.

Note: The existing review-shared.md compiles identically (also missing enforcement), so this is a platform gap, not unique to this PR. The stronger intent ([COMMENT] only vs. [COMMENT, REQUEST_CHANGES]) is equally unenforced in both cases.

Generated by Expert Code Review (auto) for issue #640 · ◷

[github-actions]

Expert Code Review — PR #640

Methodology: 3 independent reviewers with adversarial consensus. Findings flagged by only 1 reviewer were validated through follow-up rounds with the other 2 models.

Findings Summary

#	Severity	Finding	Consensus	File
1	🔴 CRITICAL	workflow_dispatch commits fixes against wrong branch — no PR checkout for manual dispatch	2/3	fix.agent.md:10
2	🟡 MODERATE	Concurrency group review-(N) doesn't match review workflow's auto-generated group — no cross-cancellation	2/3	fix.agent.md:28
3	🟡 MODERATE	add-comment missing target: "*" — workflow_dispatch may fail to resolve target	3/3 after follow-up	fix-shared.md:28
4	🟡 MODERATE	dotnet test --no-restore fails in fresh agent workspace + security risk of running build on untrusted code	2/3 each	fix-shared.md:110
5	🟢 MINOR	"fix rounds < 3" counter ambiguity — LLM may miscount rounds	2/3 after follow-up	fix-shared.md:98
6	🟢 MINOR	Re-review diff git diff origin/main...HEAD may include unrelated changes	2/3	fix-shared.md:127
7	🟢 MINOR	Step 4c inline comment validation underspecified vs. review workflow	3/3 after follow-up	fix-shared.md:170
8	🟢 MINOR	cancel-in-progress silently discards pre-push fix commits	3/3 after follow-up	design-level
9	🟢 MINOR	allowed-events: [COMMENT] not compiled into handler config (platform gap)	2/3	design-level

CI Status

No CI checks are configured for this PR type (workflow-only changes).

Test Coverage

No tests apply — these are gh-aw workflow prompt files (.md + auto-generated .lock.yml). The workflow's correctness is validated at runtime by the gh-aw platform.

Key Recommendations

1. Fix #1 is the most important — add a steps: or pre-agent-steps: block to handle PR checkout for workflow_dispatch
2. Fix #4 — remove --no-restore from the test command
3. Fix #2 — either add matching concurrency to review.agent.md or update the comment to reflect that cross-cancellation doesn't actually work
4. Fix #3 — add target: "*" to add-comment safe output

Generated by Expert Code Review (auto) for issue #640

[github-actions]

🔴 CRITICAL — workflow_dispatch commits fixes against wrong branch (Flagged by: 2/3 reviewers)

When triggered via workflow_dispatch, the platform's checkout_pr_branch.cjs step is skipped (it only runs for pull_request/issue_comment events). The workspace stays on the default branch (main).

Failing scenario: User triggers /fix via workflow_dispatch with a PR number. The agent reads the PR diff via API (works), but makes git commit calls against main-branch files — not the PR branch. The resulting patch from push-to-pull-request-branch is built from the wrong base and will either fail to apply or apply incorrect changes.

Fix: Add a steps: or pre-agent-steps: block that handles checkout for workflow_dispatch, or use the shared Checkout-GhAwPr.ps1 pattern per .github/instructions/gh-aw-workflows.instructions.md.

[github-actions]

🟢 MINOR — Re-review diff may include unrelated changes (Flagged by: 2/3 reviewers)

git diff origin/main...HEAD computes the three-dot diff from the merge base. For PRs targeting non-main branches or rebased branches, this may include changes unrelated to the PR.

Suggested fix: Replace with gh pr diff (number) for re-review rounds, which always returns exactly the PR diff regardless of git topology.

[github-actions]

🟢 MINOR — "fix rounds" counter ambiguity (Flagged by: 2/3 reviewers after follow-up)

"fix rounds < 3" vs "fix rounds = 3" is ambiguous: does it count completed rounds (retrospective) or the about-to-start round (prospective)? An LLM tracking state across multiple sub-agent dispatches may miscount.

Suggested fix: Restate as: "After completing your Nth fix round, if N ≥ 3, go to Step 4 regardless of findings. Otherwise continue to Step 3."

[github-actions]

🟡 MODERATE — add-comment missing target: "*" for workflow_dispatch (Flagged by: 3/3 reviewers after follow-up)

The gh-aw instructions state target: "*" is "Required for workflow_dispatch (no triggering PR context)". Without it, the add_comment safe output may fail to resolve the target PR when triggered via manual dispatch.

Note: The existing review-shared.md has the same omission — both should be fixed.

Fix:

  add-comment:
    max: 5
    target: "*"
    hide-older-comments: true

[github-actions]

🟢 MINOR — Inline comment validation underspecified vs. review workflow (Flagged by: 3/3 reviewers after follow-up)

Compare with review-shared.md which includes: (1) explicit gh pr diff --name-only path validation, (2) @@ hunk line range parsing, (3) the critical fallback "move to add_comment", and (4) the warning "A single invalid inline comment causes the entire submit_pull_request_review to fail and ALL inline comments are lost."

This failure mode is especially important in the fix workflow since losing the review submission also loses the summary of committed fixes.

Fix: Port the full validation block from review-shared.md Step 4.

[github-actions]

🟡 MODERATE — Concurrency group does not cross-cancel /review as claimed (Flagged by: 2/3 reviewers)

The comment on line 26 states this shares a prefix with review workflows, but the groups are different:

• /fix compiles to: review-(N) (custom group)
• /review compiles to: gh-aw-Expert Code Review-(N) (compiler-generated default — review.agent.md has no custom concurrency: block)

Failing scenario: Running /fix on a PR while /review is in-progress. Both run simultaneously instead of /fix cancelling the /review. Interleaved comments, stale review findings, and potential race on push-to-pull-request-branch vs. review comment posting.

Fix (either):

1. Add a matching concurrency: block to review.agent.md so both use review-(N)
2. Or remove the custom concurrency block here — the compiler will generate gh-aw-Review & Fix-(N) (but then they won't cross-cancel either, which matches the current reality)

[github-actions]

🟡 MODERATE — Two issues with test command (Flagged by: 2/3 reviewers each)

Issue A: --no-restore will fail in agent workspace. The gh-aw agent runs in a fresh checkout with no NuGet cache. --no-restore skips the implicit restore, causing "unable to find package" failures. The agent will burn fix rounds trying to "fix" restore failures. Repo convention (copilot-instructions.md) is dotnet test without --no-restore.

Issue B: Executing dotnet test on untrusted PR code. The gh-aw instructions warn: "DO NOT run dotnet build, npm install, or any build command on untrusted PR code inside the agent — build tool hooks (MSBuild targets, postinstall scripts) can read COPILOT_TOKEN." dotnet test implicitly runs dotnet build.

Mitigations already present: roles: [admin, maintainer, write] limits triggers to trusted collaborators; no forks: blocks fork PRs; protected-files blocks .csproj modifications.

Fix for Issue A: Remove --no-restore:

cd PolyPilot.Tests && dotnet test --verbosity quiet

For Issue B: Accept the risk given role restrictions and add a comment documenting the tradeoff, or move test execution to pre-agent-steps:.

[PureWeen]

Superseded by #661 (merged). Clean rebased version with all 9 review findings addressed.