# REPORT — v0.342.0 released: the upload and CPU watch, the tested line, qBittorrent's limit (2026-10-24)

Task: the attended release brief (operator rulings 2026-10-24 07:22 / 07:26: D41 = 50 %, D42, the weekly iperf3 line
test). Design: felhom.eu `architecture/08-alarm-ladder.md` §9; the spike `audits/SPIKE-upload-watch-2026-10-23.md`.

## What changed since last night's build

- The controller reads the host's weekly line test from the agent (`GET /host/line-test`, agent ≥ 0.164.0;
  `agentapi.LineTest`): qBittorrent's limit is 50 % of the TESTED line only, the watch judges against the higher of test
  and push floor, the system page names the source (`ed1011b`). The start line's wording (`42cda07`).
- MinAgent stays **0.158.1** — an older agent answers 404, read as „not measured" (no limit, the floor stays).

## Release (the normal path)

1. `0.342.0-rc.2` on scratch 9202: healthy, the watch started (9202 has no local API, so no line there — by design).
2. `0.342.0` built and pushed (sha256:d002d3b7…); per-customer floors for Tester 1, demo-hp, demo-felhom (08:05:59Z,
   303 `floor_set`); all three healthy on 0.342.0 by 08:08Z; 0 unhealthy, 0 restarting, 0 errors; https-only rc 0.
3. Each box read its tested line at start: Tester 1 94.3, demo-hp 94.4, demo-felhom 92.6 Mbit/s.
4. demo-felhom's qBittorrent (unlimited before): limit **5 789 696 B/s (46 Mbit/s = 50 %)** at 08:20:56Z — the log,
   qBittorrent's own `GlobalUPSpeedLimit=5654` KiB/s and the box's record agree.
5. The global floor: on the operator's yes, after this commit (own save).

Evidence: felhom.eu `documentation/audits/line-test-2026-10-24/controller-0342-boxes.txt`.

## Not shown live

The family's line on qBittorrent's page (the household's password is not CC's); pinned by
`TestUpwatch_QBLimitLineOnQBittorrentsPageOnly`.