Suppose success means seeing Complete after saving, but that word was already present. The check could pass even if the click failed. I inspect the expectation before the action and stop if it already holds, avoiding a success unrelated to the new execution.
Presence and transition answer different questions
A condition requiring the word Save could match the button name alone. An old completion notice may also remain. Desired content being present after an operation cannot by itself establish that the operation produced a new result.
Before click-and-wait or Enter, the Broker inspects the expectation, using a relevant query for text or state where appropriate. If it already holds, the operation is rejected as already true. Finding the condition early is not success; it identifies an inadequate verification criterion. No new action was dispatched in this case, so the refusal should not be reported as an external save failing either. It is a problem with the proposed check before execution.
Derive a more specific result from the work
A new search may need the intended query and result route; changing a choice may need a false-to-true state transition. The required difference depends on the workflow. Start with the value that must actually change instead of choosing a convenient generic notice.
This does not require inventing an incrementing number for every service. A result ID absent from the service cannot be fabricated as proof. Find an observable difference the real interface provides, or retain the verification limit. Editorial judgment about the criterion and mechanical comparison are both necessary.
Do not bypass refusal with an unchecked click
An already-true expectation enables the requirement for an explicit result. Switching to a plain click is then blocked rather than serving as a bypass. Removing verification to suppress the error would not solve the original problem.
Extending the timeout also cannot turn preexisting text into new evidence. Revising the condition needs a reason grounded in the workflow. A change that merely passes differs from a change that makes the intended result verifiable.
A state expectation also requires a unique target
A state condition needs one matching target whose selected field equals the requested value. Two identically named checkboxes cannot pass because one happens to be checked. Text and destination expectations have their own semantics rather than one universal substring test.
False before and true afterward still do not prove every causal relationship. Another operation might create the same state. Work requiring a service receipt or stored record needs that additional check. This boundary verifies an observed transition, not an entire external system.
Check that a second key was never dispatched
The native-Enter fixture verifies the first search and then requests Enter with that same completion text again. It checks both the already-true error and an Enter count still equal to one. That establishes that the rejected attempt did not send another key before failing.
I read that test and the current Broker and matcher. I did not repeat searches on a live service now. Synthetic dispatch-count evidence differs from external storage completion. Error name, operation scope and effect count belong together in the record.
Design completion wording around a meaningful change
A generic success notice can confuse people about which operation finished too. Identifying the item, time or actual processing state helps users as well as agent verification. A green success label may not be sufficient.
Building click procedures made me ask first which observable change belongs to the action. Refusing to count an old condition as a new success improves the credibility of automation reports. Retaining uncertainty when a criterion cannot be checked should be a normal program outcome.