Press Save sounds simple until two controls share that name. The first list item does not establish which one is intended. In Northstar I retained ambiguity and stopped, leaving room to read a more precise condition grounded in the request.
Ordering can change meaning when the screen changes
The same control may appear at top and bottom or in a page and popup. DOM order is not the user's work order. A responsive layout or another panel can turn yesterday's first item into a different operation today.
The resolver therefore compares name, role and any needed destination, proceeding only with one match. This is not an attempt to maximize errors; it avoids dispatch based on an unsupported choice. Exposing the missing information lets the next read supply an actual distinguishing condition.
Search hints and final selection conditions differ
A find query gathers candidates, but final matching is not just substring inclusion. Core matching normalizes whitespace and case before exact name comparison. Save and Save draft are not automatically the same action.
The convenience page locator requires exact role and name with optional href. Its matching and the core normalization are not identical implementations. The caller must inspect the API actually in use rather than assuming one layer's normalization automatically repairs another layer's input.
Check that the returned slice is sufficient
One match in the reply cannot establish uniqueness if more candidates remain. Both flow and page-locator routes refuse truncated selection rather than choosing from the first slice of a large page.
Further reading should narrow conditions and establish actual role and location. Merely increasing a limit does not clarify meaning. Repeated names may require understanding a panel, link or document ownership. One remaining candidate and the candidate intended by the request are different conclusions.
Constrain how ambiguity is resolved
A viewport condition can help when it actually reflects the request. Arbitrarily choosing the first visible control merely hides the ambiguity. Earlier reuse evidence separately recorded a target refinement and preservation of the original steps. When the same two controls remain present, extending a timeout does not supply a reason to choose between them. Repeated discovery without a changed condition needs a better target description, not another wait.
Current flow also rejects a unique target that is disabled or sensitive. Uniqueness is one action condition, not complete permission. Matching a name and role cannot override disabled state or authentication handoff. Selection precision and execution boundaries remain connected.
Zero input is meaningful evidence too
The page-API fixture introduces duplicate names, expects ambiguity and then checks zero mutations. Correct error wording alone would be inadequate if input had already happened earlier. Dispatch count matters alongside the rejection.
I read the current selection code and that test rather than clicking live-account buttons for another comparison. The independent shared module separately tests truncation, duplicates and explicit narrowing and provides a public ZIP. Original-source review and fresh execution tests of the synthetic module are different evidence.
Make the stopping reason useful for the next input
An ambiguity response should expose what duplicated and which condition is missing. That lets the agent choose a more precise read rather than repeat the same command. An explainable stop before a wrong selection is useful functionality.
Clear names and roles in websites and work tools can reduce this cost too. I treat selection failures as evidence for structural improvement instead of concealing them. The linked module lets readers compare actual synthetic records for unique, ambiguous, truncated, stale and explicitly narrowed observations.