v0.342.0 (unreleased): the upload watch reads the host's weekly line test (GET /host/line-test, agent >= 0.164.0); qBittorrent's limit = 50 % of the TESTED line only (D41), the watch uses the higher of test and push floor, the system page names the source; red-proved

controller/README.md

@@ -3531,9 +3531,11 @@ up per app and, when an app sends a lot or burns CPU for a long time, asks the a
 qBittorrent's and Transmission's own upload counters, Plex's playing and transcoding sessions. Explained → normal use.
 Not explained → one operator-only event (`app_unexplained_upload` / `app_unexplained_cpu`) and a clear when it stops.
 Numbers: upload ≥ max(5 Mbit/s, 25 % of the line) for 15 min; CPU ≥ max(150 %, 50 % × cores) for 30 min; an app with no
-explainer only at ≥ 10 × its own p95 for an hour, after ~20 h of history. The upload line is learnt from the nightly
-off-site push (one-second samples of the controller's own counter; best 10 s; a lower bound) and shown on the system
-settings page. qBittorrent gets a default upload limit of 50 % of that line (never over a household's own limit), and its
+explainer only at ≥ 10 × its own p95 for an hour, after ~20 h of history. The upload line comes from two places: the
+host's **weekly iperf3 line test** (the agent's `GET /host/line-test`, agent ≥ 0.164.0 — a 10-second upload to ep0 inside
+the tunnel, R-1247) and a floor learnt from the nightly off-site push (one-second samples of the controller's own counter;
+best 10 s). The watch judges against the higher; the system settings page names the source. qBittorrent gets a default
+upload limit of 50 % of the TESTED line only (D41; no test yet → no limit; never over a household's own limit), and its
 page says so in one line. State: settings.json `upwatch`. Spike: felhom.eu `audits/SPIKE-upload-watch-2026-10-23.md`.
 
 ### 8d. Storage that knows its physical disks — the internal place, partitions (v0.317.0 build A, v0.318.0 build B)