felhom-controller/REPORT.md

REPORT — the line test for a box that seeds all day (R-1250), 2026-10-24 (attended)

Brief: „two DooPlex backup alarms …", Part 4 (commit only; the release rides the next normal train). Design: felhom.eu architecture/08-alarm-ladder.md §9 item 5. Commit 046b808 (CI 2287 success). Not released, no image built.

• What: when the agent says the weekly test is due and waits only for quiet, and qBittorrent or Transmission runs, the controller records the app's upload limit first, holds the app at 1 KiB/s, asks the agent for a test on request, then puts the exact old limit back. Deferred release; a failed hold is undone first; a household change during the test stays; an unreachable app keeps the record; a killed controller's start-up check puts it back; the 50 % rule waits while a record exists. agentapi.LineTestRun (own 2-minute timeout via postSlow); Transmission's RPC shared.
• Tests: 13 new (CHANGELOG lists them), each seen failing: seven hold rules broken one by one, the slow POST, the start-up order, the wiring of both agent calls.
• Live (demo-hp, endpoint level, probes from this commit and agent 1e087bb): a real 10 Mbit/s seed from scratch guest 9202 to DooPlex's qBittorrent. Without the hold the agent refused (not-quiet, 11.1 Mbit/s). With it the uplink fell to 0.02–0.16 Mbit/s, the test read 94.2 Mbit/s, the hold lasted 56.8 s, and qBittorrent was back at 1 249 280 B/s exactly. A kill -9 in the middle left the record and the 1 KiB/s; the start-up check put the limit back. The pinned agent client is unit-tested only (the probes spoke plain HTTP). Evidence: felhom.eu audits/dooplex-alarms-2026-10-24/part4-r1250-live-proof.txt.
• Teardown: the probe and its store removed from 9202's controller container; qBittorrent removed through the product.
• MinAgent: 0.158.1 unchanged (an older agent never reports waiting_for_quiet, so nothing is held).