fix(maestro): prefer terminal failure over transient retries in parseMaestroFailure (closes #118)

[Lykhoyda]

Summary

Closes #118 — parseMaestroFailure was returning the first lexical match anywhere in the buffer, which on real maestro-runner output captured a transient [INFO] ... not found ... retrying line and sent the (already-resolved) selector to cdp_repair_action. Burned auto-repair budget on a non-existent problem; missed the real failure.

Fix

Nested-loop selection that preserves both invariants:

Outer	Inner	Effect
PATTERNS in declared order (most-specific first)	Lines reverse (end → start)	Pattern specificity outranks line position; within a single pattern the terminal (last) match wins

Falls back to a whole-buffer scan when no line matches — preserves prior behavior for single-line inputs and defensively covers any future pattern that straddles a \n.

Concretely, for the issue's example:

[INFO] Tapping on element with id \"transient-foo\"
[INFO] Element with id \"transient-foo\" not found in current screen — retrying
[INFO] Tapping on element with id \"transient-foo\"   ← retry succeeded
[ERROR] Element with id \"real-failure\" not found
Test FAILED

• Before: parser returns transient-foo (first lexical match) → cdp_repair_action tries to repair a working selector
• After: parser returns real-failure (terminal match) → auto-repair targets the actual broken selector

The 1.0.9 Element not found: id=... pattern still wins over the generic Element 'X' not found fallback even when they appear on adjacent lines — covered by the pre-existing 1.0.9 id= shape has priority over the generic fallback test, which would have caught a naive line-first-then-pattern selection.

Test plan

• 1467/1467 cdp-bridge unit tests passing locally (+2 net new)
• Inverted the existing returns first match test to returns LAST match (the test had been encoding the regression behavior)
• Added the issue's exact transient-retry shape as a regression test
• Added single-line input test to exercise the fallback whole-buffer path
• Updated stale section comment that documented the old first-match semantic
• All pre-existing pattern-specificity tests still pass (1.0.9 id= priority, generic fallback, quote handling, etc.)
• CI green
• Live verification: any future maestro-runner failure with retry hooks active now picks the terminal selector

Out of scope

• Hypothetical edge case flagged by codex-pair: a single line containing multiple failure snippets where line.match() would return the leftmost. No real-world maestro-runner output emits this shape; the recommended fix (collect all match indexes per line + return rightmost) materially complicates the code for an unobserved case. Can revisit with real captures.
• The [ERROR]/FAILED: prefix-preference layer (strategy 1 in the issue) — terminal-match alone fixes the reported behavior without depending on prefix detection that would miss vanilla Maestro CLI output (which doesn't emit [ERROR] markers).

Refs

• feat(cdp_run_action): auto-repair-aware action replay — closes #104 #115 — original parser PR + the multi-LLM review (Gemini I3) that flagged this at confidence 82
• scripts/cdp-bridge/src/domain/maestro-error-parser.ts:parseMaestroFailure
• scripts/cdp-bridge/test/unit/maestro-error-parser.test.js

🤖 Generated with Claude Code