fix(response_analyzer): progress detection in non-git multi-repo workspaces - #342
Open
DrumRobot wants to merge 1 commit into
Open
fix(response_analyzer): progress detection in non-git multi-repo workspaces#342DrumRobot wants to merge 1 commit into
DrumRobot wants to merge 1 commit into
Conversation
…spaces (frankbria#340) When the loop CWD is not a git repository (multi-repo workspace root), the git rev-parse gate skipped file-change detection entirely, so has_progress stayed false on every loop regardless of real work, and the circuit breaker opened unconditionally after the no-progress threshold. Three complementary signal paths fix the class of false positives: 1. RALPH_DIR repo fallback: _resolve_git_progress_dir() prefers the CWD repository and falls back to $RALPH_DIR's own repository — tracker updates (fix_plan.md) become the progress proxy. The .loop_start_sha commit-range comparison only applies in CWD-repo mode since the recorded SHA belongs to the CWD repository. 2. RALPH_STATUS self-report: parse_json_response() extracts FILES_MODIFIED: <N> and PROGRESS: true from the RALPH_STATUS block in the .result text, with the same explicit-intent semantics (and the same start-of-line anchoring) as the existing EXIT_SIGNAL extraction. Structured metadata stays authoritative; the self-report never lowers the count. 3. JSON-path has_progress from files_modified: a structured or self-reported positive files_modified now sets has_progress directly instead of relying exclusively on git detection. 5 regression tests: tracker-repo fallback detects a modified fix_plan.md; no-repo-anywhere still completes with has_progress=false; FILES_MODIFIED self-report sets count + progress; PROGRESS: true works without a file count; explicit FILES_MODIFIED: 0 does not fabricate progress. Fixes frankbria#340 Contributed by @daegunjhy Signed-off-by: Hayoung Jeong <drumrobot43@gmail.com>
DrumRobot
marked this pull request as ready for review
July 16, 2026 14:24
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #340 — in a multi-repo workspace whose root folder is not a git repository,
analyze_responsecould never see progress: thegit rev-parse --git-dirgate failed every loop, file-change detection was skipped entirely, and the Claude CLI result JSON carries nofiles_modifiedfield. Every loop counted as no-progress and the circuit breaker opened unconditionally after the threshold.This PR adds three complementary signal paths (any one of them ends the false-positive class):
$RALPH_DIRrepo fallback — new_resolve_git_progress_dir()helper prefers the CWD repository and falls back to the tracker directory's own repository. Tracker updates (fix_plan.md) become the progress proxy. The.loop_start_shacommit-range comparison stays CWD-repo-only, since the recorded SHA belongs to the CWD repository; fallback mode counts uncommitted changes only.RALPH_STATUSself-report —parse_json_response()now extractsFILES_MODIFIED: <N>andPROGRESS: truefrom theRALPH_STATUSblock embedded in the.resulttext, with the same explicit-intent semantics and the same start-of-line anchoring as the existingEXIT_SIGNALextraction (prose mentions do not trigger). Structured metadata stays authoritative — the self-report fills the gap, never lowers the count.has_progressfromfiles_modified— a structured or self-reported positivefiles_modifiedsetshas_progressdirectly, instead of relying exclusively on git detection.Scope note: the self-report extraction is implemented for the JSON path (
.resultfield) only, matching the Claude CLI output format where the bug was observed. Text-mode outputs already benefit from path 1.Test plan
tests/unit/test_exit_detection.bats(issue Circuit breaker false positive: progress detection is blind when the loop CWD is not a git repository (multi-repo workspace) #340 section):fix_plan.mdwhen the CWD is not a repo (fails onmain, passes here)has_progress=false(no crash, no fabricated progress)FILES_MODIFIED: 3self-report →files_modified=3,has_progress=true(fails onmain)PROGRESS: truewithout a file count →has_progress=true,files_modified=0(fails onmain)FILES_MODIFIED: 0→has_progressstaysfalsetest_exit_detection.batssuite: 72/72 passtest_json_parsing.bats: no failures (RALPH_STATUS anchoring tests unaffected)test_circuit_breaker_recovery.bats: no failures