Circuit breaker false positive: progress detection is blind when the loop CWD is not a git repository (multi-repo workspace)

[DrumRobot]

Description

lib/response_analyzer.sh detects loop progress exclusively through git: it runs git rev-parse --git-dir from the loop's working directory and, only if that succeeds, counts changed files via git diff (JSON path around response_analyzer.sh:568-602, text path around :763-796 at e8533cc).

When Ralph supervises a multi-repo workspace — a root folder that contains several sub-repositories plus .ralph/, where the root itself is not a git repository — the git rev-parse gate fails every loop, so the entire file-change check is skipped. The Claude CLI JSON result contains no files_modified / metadata.files_changed field either, so files_modified stays 0 and has_progress stays false on every loop, regardless of how much real work was done.

Work that is invisible to the analyzer in this layout includes:

• commits made in sub-repositories via git -C <sub-repo> (encouraged by the compound-command guidance, since cd is unavailable)
• GitHub-side work (gh pr comment, review consolidation, issue updates) that changes no local file
• .ralph/fix_plan.md tracker updates (even when .ralph/ is itself a git repository — git rev-parse from the parent CWD searches upward, not downward)

The result: consecutive_no_progress increments unconditionally and the circuit breaker opens after the threshold, no matter what the agent actually accomplished. The operator's only recourse is repeated manual ralph --reset-circuit, or raising CB_NO_PROGRESS_THRESHOLD so high that the no-progress breaker is effectively disabled — both of which discard the stagnation signal entirely.

This is the non-git-CWD sibling of #141 ("no progress when Claude commits within the loop"). The #141 fix added committed-changes detection, but it still assumes the loop CWD is inside a git repository.

Current Behavior

In a non-git multi-repo workspace root:

1. A loop completes genuine work (e.g. consolidates a PR review, posts the review summary, updates .ralph/fix_plan.md, syncs a RAG store) and exits with subtype: success, no permission denials.
2. The analyzer still records has_progress: false, files_modified: 0.
3. consecutive_no_progress reaches the threshold and the breaker opens: "No recovery, opening circuit after N loops".
4. Every subsequent run repeats this, so the breaker re-opens perpetually.

Expected Behavior

Progress detection should have at least one signal path that works when the loop CWD is not a git repository.

Possible directions (any one of these would fix the class of false positives):

1. Fall back to the .ralph/ directory's own repository: if git -C "$RALPH_DIR" rev-parse succeeds, diff there too — tracker updates (fix_plan.md) are a reasonable progress proxy.
2. Trust an explicit agent self-report: the analyzer already extracts EXIT_SIGNAL from a RALPH_STATUS block embedded in the .result text. A FILES_MODIFIED: N (or PROGRESS: true) line in the same block could set has_progress with the same explicit-intent semantics.
3. Configurable progress roots: e.g. RALPH_PROGRESS_GIT_DIRS="sub-repo-a sub-repo-b .ralph" in .ralphrc; the analyzer iterates them with git -C.

Workaround (if any)

Raising CB_NO_PROGRESS_THRESHOLD to a very high value in .ralphrc — which effectively disables no-progress stagnation detection rather than fixing it.

Environment

• ralph-claude-code: e8533cc (main)
• CLAUDE_OUTPUT_FORMAT="json", PROJECT_TYPE="multi"
• macOS (bash loop, not SDK)
• Workspace layout: non-git root folder containing multiple sub-repositories + .ralph/

[Keesan12]

This exposes a useful distinction: Git progress is only one kind of progress evidence, and in a multi-repo workspace it is scoped to the wrong boundary.

I’d make the analyzer collect evidence per declared work root:

• changed files per child repo
• verifier/test result delta
• completed task/checklist delta
• output artifact hash
• last meaningful tool result

Then the circuit breaker can ask whether any accepted progress signal changed, rather than treating git rev-parse failure as no progress. The final status should also record which signal authorized the next iteration; that makes false positives much easier to debug.

[DrumRobot]

Field follow-up: this reproduced again today, and diagnosing it surfaced a second, independent blind spot that sits downstream of the git one described above. Direction 2 in the issue body turns out to be blocked by the fix for #146 unless it is implemented as a separate path.

What was observed

A loop reported real work and exited cleanly, yet was scored as no-progress:

.ralph/status.json          exit_reason: stagnation_detected
.circuit_breaker_state      consecutive_no_progress: 10, last_progress_loop: 0, total_opens: 4
metrics.jsonl               duration 457s against CLAUDE_TIMEOUT_MINUTES=20  (not a timeout)
ralph.log                   "Could not find result message" count: 0

Re-parsing the five most recent claude_output_*.log files with parse_json_response gave the same verdict for every one of them:

loop output	STATUS in RALPH_STATUS	FILES_MODIFIED	parsed status	has_completion_signal	scored
06:47	COMPLETE	2	UNKNOWN	false	no-progress
02:50	COMPLETE	2	UNKNOWN	false	no-progress
02:42	COMPLETE	1	UNKNOWN	false	no-progress
23:13	COMPLETE	0	UNKNOWN	false	no-progress
20:28	COMPLETE	1	UNKNOWN	false	no-progress

So the breaker was not reacting to stagnation — it was blind to five consecutive productive loops.

The second blind spot: #146's guard also suppresses the progress signal

parse_json_response reads status only from top-level .status / .metadata.completion_status, and files_modified only from .metadata.files_changed // .files_modified. The Claude CLI result JSON carries none of those, so both stay at their defaults. The RALPH_STATUS block that does carry them lives inside the .result text, and the parser reads only EXIT_SIGNAL out of it.

The STATUS: fallback that exists right below is deliberately gated on explicit_exit_signal_found != true — correct behaviour for #146, which was about STATUS: COMPLETE wrongly overriding an explicit EXIT_SIGNAL: false. But has_completion_signal is derived from status:

if [[ "$status" == "COMPLETE" || "$exit_signal" == "true" ]]; then
    has_completion_signal="true"

and lib/circuit_breaker.sh record_loop_result uses has_completion_signal (and files_modified) as its only non-git progress evidence. So the #146 guard, whose scope is loop-exit semantics, silently also withholds the progress signal — and it does so precisely for EXIT_SIGNAL: false, which is the normal "work done, keep looping" case. Combined with the git blindness above, a non-git-CWD workspace has no progress path left at all.

Worth noting the two consumers are disjoint: has_completion_signal is read only by the circuit breaker, never by the exit logic (update_exit_signals uses exit_signal). So adopting STATUS: for progress cannot regress #146.

Implementation of direction 2, tested

Gap-fill inserted immediately after the files_modified assignment. It only fills defaults, never overrides JSON-supplied values, and never touches exit_signal:

if [[ "$has_result_field" == "true" ]]; then
    local _rs_text
    _rs_text=$(jq -r '.result // ""' "$output_file" 2>/dev/null)
    if [[ -n "$_rs_text" ]] && echo "$_rs_text" | grep -qE -- "^[[:space:]]*(---RALPH_STATUS---|RALPH_STATUS:)"; then
        if [[ "$status" == "UNKNOWN" || -z "$status" ]]; then
            local _rs_status
            _rs_status=$(echo "$_rs_text" | grep -E "^[[:space:]]*STATUS:" | head -1 | cut -d: -f2 | xargs)
            [[ -n "$_rs_status" ]] && status="$_rs_status"
        fi
        if [[ -z "$files_modified" || "$files_modified" == "0" || "$files_modified" == "null" ]]; then
            local _rs_files
            _rs_files=$(echo "$_rs_text" | grep -E "^[[:space:]]*FILES_MODIFIED:" | head -1 | cut -d: -f2 | xargs)
            [[ "$_rs_files" =~ ^[0-9]+$ ]] && files_modified="$_rs_files"
        fi
    fi
fi

The ^ anchor keeps RALPH_STATUS: from matching the STATUS: extraction.

Results against real outputs and synthetic regressions:

case	status	exit_signal	has_completion_signal	files_modified
the failing loop above	COMPLETE	false	true	2
EXIT_SIGNAL: true	COMPLETE	true	true	3
no RALPH_STATUS block at all	UNKNOWN	false	false	0

exit_signal is unchanged in every case, and a response with no block still produces no signal, so there is no false-positive path.

Diagnostic note for anyone landing here

This class is easy to confuse with the timeout-starvation cause. They separate cleanly:

• timeout starvation — metrics.jsonl duration approximately equals CLAUDE_TIMEOUT_MINUTES * 60, and ralph.log contains Could not find result message in stream output
• this class — short durations, zero Could not find result message, and STATUS: COMPLETE present in claude_output_*.log while .response_analysis still shows has_completion_signal: false

Happy to open a PR with the above if direction 2 is the one you want; it is the smallest of the three and needs no new configuration surface.