feat: Add fix_retries for workflow verification failures

[ducks]

Summary

When a step with apply_edits and verify fails verification, the workflow can now automatically retry by re-querying the LLM with the error message.

Changes

• Add fix_retries field to Step struct
• Wrap apply/verify in 'fix_loop that retries on failure
• Roll back via git-agent before retry
• Re-query backend with error context appended to prompt

Usage

[[steps]]
name = "fix"
apply_edits = true
verify = "cargo clippy"
fix_retries = 2

When verification fails, the workflow will:

1. Roll back changes via git-agent
2. Re-query the LLM with: original prompt + error message
3. Apply new edits and verify again
4. Repeat up to fix_retries times

Test plan

• Compiles cleanly
• Existing tests pass
• Added to pick-and-fix workflow

🤖 Generated with Claude Code

[ducks]

lok Review (Claude + Codex + Gemini consensus)

Verdict: APPROVE

The fix_retries feature correctly implements a retry loop for verification failures with proper rollback and user feedback. Core implementation is sound but has gaps around timeout handling, error logging, and scope of what triggers retries. Recommended to address timeout wrapping and error logging before merge.

Critical: None

Important: - Re-query failures are silent: When backend.query fails during fix retry, no error is logged and the specific failure reason is swallowed, making debugging difficult (workflow.rs ~1385-1390, ~1418-1423)

• No timeout on fix re-queries: Original queries use tokio::time::timeout but fix re-queries have no timeout wrapper, risking indefinite hangs (workflow.rs ~1385-1390)
• Parse failures don't trigger fix retry: When parse_edits fails due to malformed LLM output, it returns immediately without attempting retry, missing a common failure mode (workflow.rs ~1307-1317)
• Edit application failures don't trigger fix retry: When apply_edits fails, it returns without entering the fix loop, so fix_retries only helps with verification failures (workflow.rs ~1278-1291)
• Stale timing metrics: elapsed_ms is calculated before fix_loop starts, so retry time is not captured in the final StepResult (workflow.rs ~1471)
• fix_retries behavior when apply_edits_flag is false: If apply is disabled but verify is enabled with fix_retries, retries re-verify without re-applying, which may not change anything (workflow.rs fix_loop)

Minor: - Inconsistent error message format: Verification errors are wrapped in code blocks but timeout errors are not (workflow.rs ~1379-1382 vs ~1413-1417)

• Naming confusion: fix_retries vs retries fields may confuse users; consider verify_retries for clarity
• Missing documentation: fix_retries field needs config docs, schema, or CLI help updates

---

Automated review by lok review-pr workflow