Summary
When a feature implementation fails tests or breaks existing functionality, the loop continues forward with broken state. There's no mechanism to revert to the last known-good commit and retry or skip the feature.
Current Behavior
- Each iteration commits changes at Step 9
- If Step 6 (testing) fails, the agent may still commit broken code
- If regression testing (Step 3) detects a break, there's no automated recovery
- Manual
git revert is required to restore working state
Proposal
- Before starting a feature, tag or record the current commit SHA as a checkpoint
- If testing fails after N retry attempts, automatically
git reset --hard to the checkpoint
- Mark the feature with a
"status": "blocked" or "attempts": N field in feature_list.json
- Skip blocked features in subsequent iterations and move to the next eligible feature
- Add a
--max-retries flag (default: 2) to control retry behavior per feature
Workflow
1. Record checkpoint (git SHA)
2. Attempt feature implementation
3. Run tests
4. If tests pass → commit, continue
5. If tests fail → retry (up to max-retries)
6. If all retries fail → git reset to checkpoint, mark feature blocked, continue to next
Considerations
- Need to handle partially-staged changes cleanly during rollback
- Blocked features should be surfaced in the final summary
- Consider a
--strict mode that halts the entire loop on any failure
Summary
When a feature implementation fails tests or breaks existing functionality, the loop continues forward with broken state. There's no mechanism to revert to the last known-good commit and retry or skip the feature.
Current Behavior
git revertis required to restore working stateProposal
git reset --hardto the checkpoint"status": "blocked"or"attempts": Nfield in feature_list.json--max-retriesflag (default: 2) to control retry behavior per featureWorkflow
Considerations
--strictmode that halts the entire loop on any failure