Circuit breaker trips too aggressively on first run with complex stories

[LarsCowe]

Problem

When Ralph starts on a new story that requires significant setup (reading codebase, planning, understanding context), the circuit breaker trips after just 3 loops because no git file changes are detected — even though Claude executed successfully in all 3 loops.

The default CB_NO_PROGRESS_THRESHOLD=3 is too low for stories that require multiple loops of analysis before producing code changes.

Reproduction

1. Enable Ralph with ultimate review mode
2. Start a story that requires codebase exploration (e.g., "Timezone Detection & Display")
3. Ralph runs 3 successful loops where Claude reads/plans but doesn't commit yet
4. Circuit breaker transitions: CLOSED → HALF_OPEN (loop 2) → OPEN (loop 3)
5. Subsequent bmalph run immediately halts: "Circuit breaker has opened - execution halted"

Observed behavior

Loop #1: Claude executes successfully → code review finds 7 issues → no git changes detected
Loop #2: Claude executes successfully → no git changes detected → HALF_OPEN
Loop #3: Claude executes successfully → no git changes detected → OPEN

Suggestions

1. Increase default CB_NO_PROGRESS_THRESHOLD to 5

3 is too aggressive for complex stories. Claude often needs 2-3 loops just to understand the codebase before writing code. A threshold of 5 gives more room while still catching genuine stagnation.

2. Count non-git progress signals

Currently "progress" requires git file changes, a STATUS: COMPLETE signal, or FILES_MODIFIED > 0. Consider also counting:

• Agent output length — a long, substantive response indicates work is happening
• Tool call activity — if Claude made many Read/Grep/Glob calls, it's actively exploring
• Plan creation — if Claude entered plan mode, that's productive work even without file changes

3. Differentiate "first loop on new story" from "stagnation mid-story"

The first few loops on a fresh story are exploratory by nature. The circuit breaker could use a "warm-up" period (e.g., don't count the first 2 loops toward no-progress).

4. Better defaults for CB_AUTO_RESET

When a user is interactively running bmalph run, having to wait 30 minutes or manually delete .circuit_breaker_state is frustrating. Consider:

• Auto-detect interactive vs. unattended mode
• Default CB_AUTO_RESET=true for interactive, false for CI/cron

5. Surface the reason in the monitor UI

The Ralph Monitor shows "Action: circuit_breaker_open" but doesn't explain why (no file changes vs. same error vs. permission denials). Adding the specific reason would help users self-diagnose.

Environment

• bmalph version: 2.10.0
• Platform: Windows 11 (bash via Git Bash)
• Driver: claude-code
• Review mode: ultimate