# TODO

## Testing
- [x] Add test suite (unit tests for parsing, result building; mock-based tests for probing)

## New diagnostics
- [x] DNS resolution timing — measure lookup time for common domains, detect slow/broken resolvers
- [ ] Bufferbloat detection — measure latency while simultaneously loading the connection
- [ ] Speed test — download/upload throughput estimation
- [ ] IPv6 health — check if IPv6 is configured but broken/slower than IPv4 (common cause of "feels slow" when apps try IPv6 first and fall back)
- [ ] Wifi signal strength — read signal/noise from iw/iwconfig, flag weak signal or high noise
- [ ] Route analysis — traceroute-style hop-by-hop latency to find where the bottleneck is
- [ ] MTU / fragmentation issues — detect path MTU problems
- [ ] DNS-over-HTTPS vs plain DNS comparison — detect if DoH config is hurting perceived speed
- [ ] TLS handshake timing — separate TCP connect from TLS negotiation to isolate slow TLS
- [ ] Bandwidth asymmetry — flag upload vs download disparity (kills video calls and syncing)
- [ ] Probe a user-specified target — "why is github.com slow?" mode
- [ ] Network interface health — read TX/RX errors, drops, retransmits from /proc/net/dev and /proc/net/snmp
- [ ] Competing traffic detection — check if something else on the machine is saturating the connection
- [ ] VPN detection, so we can account for extra latency, problems with the gateway
- [ ] Specific site probe, we can ask the user if a particular site or service is feeling slow

## Longer-running / monitoring mode
- [x] Continuous monitoring mode — `--watch` / `-w` flag, configurable interval, live dashboard
- [x] Session summary on exit (Ctrl+C) — total checks, healthy %, most common issues
- [x] Terminal bell + OSC 9 desktop notification on problem detection
- [ ] Stateful check modules — checks that accumulate data, control their own run frequency, produce smarter summaries over time
- [ ] Summary statistics over a monitoring session (percentiles, worst periods)
- [ ] Latency-under-load test — run probes while generating traffic to detect congestion/bufferbloat
- [ ] Historical comparison — save results to a local log, compare "is it worse than usual?"
- [ ] Time-of-day correlation — in monitoring mode, flag patterns like "always slow at 7pm"
- [ ] Network condition simulation for testing — Docker/tc/netem, network namespaces, or VMs

## Performance / UX
- [ ] Parallel probing — probe all targets concurrently instead of sequentially
- [x] Colored output (green/yellow/red for OK/warning/problem)
- [x] Summary verdict — single top-line sentence like "Your wifi is the bottleneck"
- [ ] Suggested fixes — actionable next steps based on findings (e.g., "Try switching DNS to 1.1.1.1")

## Platform
- [ ] macOS support (gateway detection, wifi tools differ)
