One way to do each of the things the driver was doing several ways

[amrali-eg]

Cleanup pass over EcGuiDriver.cs, which has been edited across six commits in
three pull requests, so duplication that spans those edits was invisible to any
single diff. Behaviour is unchanged everywhere except one message that is now
built later than it was. No production code changes.

Fixed

Rendered text was read three ways. ReviewText, StatusText and the body of
StatusLine were the same LINQ chain, identical but for the root element. One
VisibleText holds it; the three callers keep the doc comments explaining why
each wants a different root.

The select-all wait built its failure message eagerly. An automation call sat
unguarded inside a message - the one thing Safely exists to prevent, and the
same hazard SmokeSuite documents for its own Check. WaitUntil gained an
overload taking the message as a function, evaluated only on failure and routed
through Safely.

It also did two full walks of a thousand result rows on every passing call, but
that is a correctness-of-diagnostics fix rather than a performance one: timing
--phase I on both builds gives 7-8s against 8s, so the saving is about a second,
and only in the one phase that has a thousand rows. Not a speedup worth citing.

"Has the run ended" had two spellings, one named and one inlined in the cancel
probe. FinalConversionStatus() answers it once; ConversionHasFinished() is the
null test over it, and the stranded summary moved onto the member it describes.

Smaller: ResultCount hand-rolled what ResultItems already does (including
an is var pattern that always matches); the safe status read was inlined at
three failure sites beside a sibling wrapper that already had the name;
SetToggle's confirmation refetched the toggle pattern each poll instead of
reading the one it holds; two comments described code that is no longer there.

Deliberately not done

Caching the status bar and results-list elements would remove a whole-window walk
from every 50 ms poll - the single largest win available here. A stale held
AutomationElement is exactly the hypothesis EC-28 is
open on, so adding more of them while that is unexplained would be reckless.

Provider-side ControlType filtering, a narrower scope for the review-window
lookup, and a handle-valued PropertyCondition for FindWindow are all cheaper,
but each changes UI Automation query semantics on the timing-sensitive path whose
cancellation margin is a tracked number.

Also skipped: collapsing the four process-scoped finders, where the
Children/Descendants differences are load-bearing; extracting the
review-close prologue; and two larger structural changes - a first-class one-shot
attempt in the wait mechanism, and unifying Safely / Ask /
DescribeWindowsSafely.

Evidence

Check	Result
Build	0 warnings, 0 errors
Unit tests	756 passed
Full suite	8/8
Cancellation margin	48-56 of 1000, unchanged

EC-28 remains open; nothing here explains it.

🤖 Generated with Claude Code