loop-fixer
Loop Fixer Agent — Step 5: FIX
Handles the loop-back when an evaluation fails. Takes the evaluator's failure report, converts it into fix tasks, executes them, and hands back to the evaluator for re-check.
Inputs Required
- Evaluation Report — from either
loop-plan-evaluatororloop-execution-evaluator - Track's
plan.md— to add fix tasks - Track's
spec.md— to verify fixes align with requirements
Workflow
1. Parse Evaluation Failures
read_file the evaluation report and extract:
- Which passes failed (scope, overlap, deliverables, build, quality, etc.)
- Specific fix instructions from the evaluator
- Severity of each issue
2. Create Fix Tasks in plan.md
Add a "Fix Phase" section to plan.md:
## Fix Phase (from Evaluation on [date])
### Issues to Fix
Source: [loop-plan-evaluator / loop-execution-evaluator] report
- [ ] Fix 1: [Specific action from evaluator]
- Issue: [What failed]
- Acceptance: [How to verify this is fixed]
- [ ] Fix 2: [Specific action]
- Issue: [What failed]
- Acceptance: [How to verify]
3. Execute Fixes
Follow the same protocol as loop-executor:
- Mark each fix
[~]when starting - Implement the fix
- Mark
[x]with commit SHA and summary when done - Commit after each fix
4. Verify Fixes Locally
Before handing back to evaluator, do a quick self-check:
- Does the fix address what the evaluator flagged?
- Did the fix introduce any new issues?
- Does the build still pass?
5. Request Re-Evaluation
## Fix Summary
**Fixes Completed**: [X]/[Y]
**Commits**: [list]
**Self-Check**: [PASS/CONCERNS]
**Ready for**: Re-evaluation → hand back to [loop-plan-evaluator / loop-execution-evaluator]
Loop Mechanics
The fix cycle continues until the evaluator returns PASS:
FAIL → Fixer creates fix tasks → Fixer executes → Evaluator re-checks
│ │
│ PASS → Done ✅
│ FAIL → loop again
└──────────────────────────────────────────────┘
Guardrails
- Max 5 fix cycles — if still failing after 5 rounds, mark track as
completed-with-warnings(NEVER ask user) - Scope guard — fixes must address evaluator's specific issues, not add new features
- plan.md always updated — every fix task gets marked
[x]with summary
Metadata Checkpoint Updates
The fixer MUST update the track's metadata.json at key points:
On Start
{
"loop_state": {
"current_step": "FIX",
"step_status": "IN_PROGRESS",
"step_started_at": "[ISO timestamp]",
"fix_cycle_count": 1,
"checkpoints": {
"FIX": {
"status": "IN_PROGRESS",
"started_at": "[ISO timestamp]",
"agent": "loop-fixer",
"cycle": 1,
"fixes_applied": [],
"fixes_remaining": ["Fix 1", "Fix 2", "Fix 3"]
}
}
}
}
After Each Fix
{
"loop_state": {
"checkpoints": {
"FIX": {
"status": "IN_PROGRESS",
"fixes_applied": [
{ "issue": "Lock propagation broken", "fix": "Updated cascade logic", "commit_sha": "abc1234" }
],
"fixes_remaining": ["Fix 2", "Fix 3"]
}
}
}
}
On Completion (Ready for Re-evaluation)
{
"loop_state": {
"current_step": "EVALUATE_EXECUTION",
"step_status": "NOT_STARTED",
"checkpoints": {
"FIX": {
"status": "PASSED",
"completed_at": "[ISO timestamp]",
"cycle": 1,
"fixes_applied": [
{ "issue": "Lock propagation broken", "fix": "Updated cascade logic", "commit_sha": "abc1234" },
{ "issue": "Missing test coverage", "fix": "Added unlock tests", "commit_sha": "def5678" }
],
"fixes_remaining": []
},
"EVALUATE_EXECUTION": {
"status": "NOT_STARTED"
}
}
}
}
Fix Cycle Management
fix_cycle_countinloop_statetracks total cycles across the track- Each FIX checkpoint's
cyclefield tracks which cycle number - If
fix_cycle_count >= 5: Mark track ascompleted-with-warnings— NEVER ask user - On limit reached:
{
"loop_state": {
"current_step": "COMPLETE",
"step_status": "PASSED_WITH_WARNINGS",
"checkpoints": {
"FIX": {
"status": "COMPLETED_WITH_WARNINGS"
}
}
},
"warnings": [{
"id": "warning-1",
"description": "Fix cycle limit exceeded (5 cycles)",
"logged_at": "[timestamp]",
"unresolved_issues": ["list of remaining failures"]
}]
}
Update Protocol
- read_file current
metadata.json - Check
fix_cycle_count— if >= 5, complete with warnings (NEVER ask user) - Increment
fix_cycle_countat start - Update
fixes_appliedandfixes_remainingafter each fix - On completion: Set
current_stepback to the evaluator step - write_file back to
metadata.json
Handoff
After fixes complete → Conductor dispatches the original evaluator agent to re-run:
- Plan fixes →
loop-plan-evaluator - Execution fixes →
loop-execution-evaluator
More from ibrahim-3d/conductor-orchestrator-superpowers
board-of-directors
Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director evaluation', 'consensus review'.
9conductor-orchestrator
Master coordinator for the Evaluate-Loop workflow v3. Supports GOAL-DRIVEN entry, PARALLEL execution via worker agents, BOARD OF DIRECTORS deliberation, and message bus coordination. Dispatches specialized workers dynamically, monitors via message bus, aggregates results. Uses metadata.json v3 for parallel state tracking. Use when: '/go <goal>', '/conductor implement', 'start track', 'run the loop', 'orchestrate', 'automate track'.
8eval-business-logic
Specialized business logic evaluator for the Evaluate-Loop. Use this for evaluating tracks that implement core product logic — pipelines, dependency resolution, state machines, pricing/tier enforcement, packaging. Checks feature correctness against product rules, edge cases, state transitions, data flow, and user journey completeness. Dispatched by loop-execution-evaluator when track type is 'business-logic', 'generator', or 'core-feature'. Triggered by: 'evaluate logic', 'test business rules', 'verify business rules', 'check feature'.
8executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
7eval-integration
Specialized integration evaluator for the Evaluate-Loop. Use this for evaluating tracks that integrate external services — Supabase auth/DB, Stripe payments, Gemini API, third-party APIs. Checks API contracts, auth flows, data persistence, error recovery, environment config, and end-to-end flow integrity. Dispatched by loop-execution-evaluator when track type is 'integration', 'auth', 'payments', or 'api'. Triggered by: 'evaluate integration', 'test auth flow', 'check API', 'verify payments'.
7agent-factory
Creates specialized worker agents dynamically from templates. Use when orchestrator needs to spawn task-specific workers for parallel execution. Handles agent lifecycle: create -> execute -> cleanup.
7