feat(cli): give an engine-gap verdict one fresh retry before it's final - #552
Merged
HappyDevs1 merged 1 commit intoSep 6, 2026
Merged
Conversation
Empirical testing against a real Fiori tenant found the repair loop's engine_gap verdict isn't fully reliable on ambiguous live evidence: the identical symptom (a wait target briefly resolving to empty text) got diagnosed as an unfixable engine gap once and a fixable timing race twice, across otherwise-identical runs. A verdict driven by one ambiguous read of a flaky moment was ending the whole record attempt immediately, with no second opinion sought. record now treats an engine_gap verdict as provisional: it starts the entire flow over completely fresh (new driver session, new login) once before reporting a hard failure. If the fresh attempt passes outright, the first failure was a one-off flake. If it fails again, repair runs against the new failure as usual; if that also can't recover, both failures are recorded together in <flow>.repair.json as agreeing evidence of a real problem, not a coin flip. A budget-exhausted verdict (repair genuinely tried several real fixes and none stuck) does not get this free retry — only a verdict that concluded no fix was worth attempting at all. Verified: full workspace test suite green (only the pre-existing, environment-specific doctor_ai_e2e failure, unrelated). Live verification against the real tenant did not naturally reproduce the engine-gap path in this session's attempts (the underlying flakiness rate is lower/more variable than the original sample suggested); shipped on code review and clean fmt/clippy/test confidence, with the retry's behavior fully visible in <flow>.repair.json the next time it fires in real use.
HappyDevs1
force-pushed
the
docs/plan-autonomous-repair-loop
branch
from
September 6, 2026 20:32
5698825 to
9262bdb
Compare
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
Stacked on #551 (timing-race handling) — this is PR 4/4.
Empirical testing against a real Fiori tenant found the repair loop's
engine_gapverdict isn't fully reliable on ambiguous live evidence: the identical symptom (a wait target briefly resolving to empty text) got diagnosed as an unfixable engine gap once and a fixable timing race twice, across otherwise-identical runs. A verdict driven by one ambiguous read of a flaky moment was ending the wholerecordattempt immediately, with no second opinion sought.recordnow treats anengine_gapverdict as provisional: it starts the entire flow over completely fresh (new driver session, new login) once before reporting a hard failure.<flow>.repair.jsonas agreeing evidence of a real problem, not a coin flip.budget-exhaustedverdict (repair genuinely tried several real fixes and none stuck) does not get this free retry — only a verdict that concluded no fix was worth attempting at all.Verification status (honest note for reviewers)
Full workspace test suite green (only the pre-existing, environment-specific
doctor_ai_e2efailure, unrelated). I was not able to directly observe the new code path fire live in this session — several fresh attempts against the real tenant all resolved cleanly or within the normal repair budget, none hit the engine-gap verdict again (the underlying flakiness rate is lower/more variable than the original sample suggested). Shipped on code review and clean fmt/clippy/test confidence rather than continuing to burn live attempts chasing a rare event; the retry's actual behavior will be fully visible in<flow>.repair.jsonthe next time an engine-gap genuinely occurs in real use.Test plan
cargo fmt --checkcargo clippy --workspace --all-targets -- -D warningscargo test --workspace— green except the pre-existingdoctor_ai_e2efailure