umputun / ralphex / 33922366768

86%

Build Type

push

github

Committed by umputun

Commit Message

fix: match claude limit patterns by diagnostic provenance

a successful claude run whose final response quotes a configured phrase was
treated as a fresh CLI failure. parseStream put assistant text, result metadata
and non-JSON stderr into one RecentText blob, and Run matched patterns against
that blob even on a clean zero exit, so an agent reporting "the run stopped
because You've hit your session limit" tripped limit detection. with
wait_on_limit set this never converges: the retry re-enters the same phase,
writes the same report, quotes the same phrase, and waits again.

no pattern string can fix this. any pattern specific enough to match the real
CLI message also matches an agent quoting it, so the missing information is
provenance, not vocabulary.

split the single blob into two windows with different authority. DiagnosticText
holds bounded structured diagnostics — result records that authenticate
themselves as errors, assistant API-error messages, system error events — plus
non-JSON CLI lines, and is always pattern authority. RecentText keeps the
surfaced narration for display and is promoted to pattern authority only when
the process itself failed: a non-zero exit or a stream read error. that
promotion path is what keeps limit classification working for the bundled
wrapper scripts, whose result records carry no is_error field and which surface
child stderr as ordinary deltas.

signal absence is deliberately not part of the promotion rule. a successful run
often emits no marker by design — review_first.txt path B stays silent after
fixing issues, and task.txt emits ALL_TASKS_DONE only once the plan has no
boxes left — so treating "no signal" as failure evidence would readmit
narration on clean runs.

a result record counts as diagnostic on is_error, terminal_reason "api_error",
or a non-zero api_error_status. a bare terminal_reason does not qualify because
a successful result can carry one, and capturing every result string would
readmit the quo... (continued)

Coverage Stats

116 of 116 new or added lines in 1 file covered. (100.0%)

1 existing line in 1 file now uncovered.

8251 of 9587 relevant lines covered (86.06%)

224.59 hits per line