Feature Request: Add "Optional" or "Future" Section Support in fix_plan.md

[1642409273]

Summary

Currently, Ralph's exit condition checks if all - [ ] checkboxes in fix_plan.md are completed. However, there's no semantic distinction between "Low Priority (required but deferred)" and "Optional (not
required)".

This leads to AI confusion:

• AI sees "Low Priority" items with - [ ] format
• AI interprets them as "optional" and doesn't implement
• But Ralph treats them as "required", blocking exit
• Result: AI neither implements nor exits → infinite loop

Problem Statement

Current behavior:

• • format = required for exit (blocks Condition 6)
• No way to mark items as "truly optional"

AI's interpretation challenge:

• "Low Priority" is ambiguous - does it mean "required but do later" or "optional/future"?
• AI may choose not to implement, but also hesitate to exit
• Creates deadlock: not implementing + not exiting

Example Scenario

High Priority

• Core feature implementation

Medium Priority

• Additional features

Low Priority

• Configurable settings
• Frontend integration
• SMS/Email notifications ← Are these required or optional?

AI thinks: "Core done, Low Priority seems optional, I'll wait"
Ralph thinks: "Not all checkboxes done, keep looping"

Proposed Solution

Add semantic support for truly optional items:

Option A: Recognize special section headers

Optional

• Frontend integration
• SMS verification

Future Enhancements

• Multi-language support

These sections would NOT block Condition 6 exit.

Option B: Use different list format

Low Priority (Required)

• Must implement later

Optional / Nice to Have

• Frontend integration (not blocking)
• SMS verification (not blocking)

Items using * instead of - [ ] would not count toward completion check.

Option C: Add configuration in .ralphrc

Sections that don't block exit

OPTIONAL_SECTIONS="Optional,Future Enhancements,Nice to Have"

Benefits

1. Clearer semantics for AI: knows which items are truly optional
2. Faster exit when core work is done
3. Reduces wasted loops on optional items
4. Better user control over exit conditions

Environment

• Ralph version: latest
• Observed: 177 loops wasted on a completed captcha feature because AI couldn't decide whether to implement "Low Priority" items or exit

[coderabbitai]

🔗 Related PRs

#90 - fix(loop): respect Claude's EXIT_SIGNAL when checking completion indicators [merged]
#218 - fix(loop): prevent stale exit signals from causing premature exit (#194) [merged]
#230 - fix(analyzer): suppress heuristic exit in JSON mode, raise text threshold (#224) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Triage: Enhancement / Feature Request ✨

This issue has been labeled enhancement.

Summary of the request: Add semantic support for "optional" or "future" sections in fix_plan.md so that unchecked items in those sections do not block Ralph's exit condition (Condition 6 — all checkboxes complete).

Why it matters: As described, ambiguous section names like "Low Priority" can cause a deadlock where the AI neither implements the items nor exits, resulting in wasted loop iterations (177 loops cited in the report).

Proposed approaches (from the issue):

• Option A — Recognize special section headers (## Optional, ## Future Enhancements) that are excluded from the exit check.
• Option B — Use * bullet format instead of - [ ] for non-blocking items.
• Option C — .ralphrc config (OPTIONAL_SECTIONS="Optional,Future Enhancements") to let users define which sections are non-blocking.

Recommended next steps:

• Evaluate the options against implementation complexity and backward compatibility (Option A or C seem most explicit).
• Update the fix_plan.md completion check logic in ralph_loop.sh and the template in templates/fix_plan.md.
• Add unit tests in test_exit_detection.bats to cover optional-section scenarios.
• Update documentation in CLAUDE.md and README.md.

Thanks for the detailed write-up and real-world example — this is a well-scoped enhancement request!

Generated by Issue Triage Assistant for issue #239