v0.342.0 (unreleased): the upload and CPU watch — an app that sends or burns far more than its own numbers explain is one operator-only alarm; the line learnt from the off-site push; qBittorrent's default upload limit (never over the household's)

internal/upwatch: exact per-container counters from the Docker Engine API, per-app judging (upload >= max(5 Mbit/s,
25% of the line) for 15 min; CPU >= max(150%, 50% x cores) for 30 min), explainers qBittorrent / Transmission / Plex,
app_unexplained_upload / app_unexplained_cpu + _cleared (hub 0.169.0). The off-site push is sampled once a second
for the line (a lower bound). qBittorrent limit = 50% of the line, the household's limit always wins. 20 red-proofs.
Spike + design: felhom.eu audits/SPIKE-upload-watch-2026-10-23.md, architecture/08 section 9. Not released.

CHANGELOG.md

@@ -1,3 +1,43 @@
+## v0.342.0 (unreleased — committed 2026-10-23 night, NOT released; a test image `0.342.0-rc.1` for scratch 9202 only) — the upload and CPU watch (operator ruling 2026-10-23 19:22)
+
+**MinAgent: 0.158.1** (unchanged). **Hub dependency:** the four new event types need hub 0.169.0 (committed the same
+night, not built); an older hub answers 400 and the event is dropped (logged), nothing else breaks. Task: the weekend-
+night brief, Part 2 (spike → design → build, commit only). Design: felhom.eu `architecture/08-alarm-ladder.md` §9
+[DESIGN — proposed]; spike numbers: felhom.eu `audits/SPIKE-upload-watch-2026-10-23.md`.
+
+- **`internal/upwatch` — the watch.** Once a minute it reads every app container's EXACT sent bytes and CPU time from the
+  Docker Engine API on the socket (`DockerAPI`; `docker stats`' text has three significant digits — ~1.3 Mbit/s steps at a
+  one-minute sample), adds them up per app (the compose project) and judges each app: **upload** at ≥ max(5 Mbit/s, 25 % of
+  the measured line) for 15 minutes; **CPU** at ≥ max(150 %, 50 % × cores) of one core for 30 minutes. Then it ASKS THE APP
+  (`Explainer`): qBittorrent's `up_info_data`, Transmission's `current-stats.uploadedBytes` (bytes it counted — explained
+  when the container sent ≤ 1.25 × that + 1 Mbit/s; measured overhead 3–7 % and 0.1–2 %), Plex's `/status/sessions` (any
+  viewer explains upload; no viewer and a big upload is the Plex2Shell signature) and `/transcode/sessions` (any
+  transcode explains CPU). Not explained → **`app_unexplained_upload` / `app_unexplained_cpu`** (warning, operator-only on
+  the hub), ONE per episode, and a `_cleared` (info) after 15 quiet minutes. An app the box cannot ask is judged only once
+  it has ~20 hours of history, at ≥ 10 × its own p95 for an hour, worded „no app number to compare". The box's own work
+  on the app (a backup run, an update, a deploy) is never judged. Infrastructure (the controller, traefik, cloudflared,
+  Samba) is never judged. Passwords and tokens are read at use (the mediawire seams, `09` §3 decision 248), never stored.
+- **The upload line, learnt from the off-site push** (`line.go`, `backup.SetOffboxPushObserver`): during the push the
+  controller samples its OWN sent bytes once a second; the best 10-second rate is kept per night (14 nights,
+  settings.json `upwatch.line`) and the line is the highest night whose best 10 seconds moved ≥ 10 MB — a lower bound,
+  shown as „legalább N Mbit/s" on the system settings page („még mérjük" until then).
+- **qBittorrent's default upload limit** (`qblimit.go`): 50 % of the measured line (CC's pick; decide row in felhom.eu
+  STATUS), checked every 15 minutes, set through its Web API, re-set when the line moves > 20 %, and NEVER over a limit the
+  household set — a limit that was there first, or any change from the value qBittorrent stored for the box (it keeps
+  KiB/s; the stored value is compared), makes the limit the household's for good. No line yet → nothing is set. While the
+  box owns the limit, qBittorrent's page says one line: „A qBittorrent feltöltése legfeljebb N Mbit/s, hogy a családi
+  internet gyors maradjon. A qBittorrentben átállíthatod."
+- `metrics.StackTxP95Mbps` (the per-app baseline), `settings.Upwatch` (one opaque block), `notify.NotifyUnexplained`.
+- Tests, each red-proved (20 mutations, each seen failing): `TestUpwatch_SeedingQBittorrentIsExplained`,
+  `…_HackedQBittorrentAlarmsOnceAndClears`, `…_PlexWithNoViewerAlarmsWithAViewerDoesNot`,
+  `…_NoExplainerLearnsThenNeedsTenTimesItsP95ForAnHour`, `…_CPUBurnerAlarmsTranscodeAndBoxWorkDoNot`,
+  `…_RestartAndInfrastructureAreNotJudged`, `…_AnAppThatDoesNotAnswerIsNotAnExplanation`, `…_TriggerFollowsTheLine`,
+  `TestLine_SummarizePeakAndCounts`, `TestQBLimit_TheHouseholdAlwaysWins`, `TestQBittorrent_AskKeepsTheSessionAndReLogsInOn403`,
+  `TestTransmission_AskFollowsTheSessionID`, `TestPlex_AskReadsSessionsWithTheTokenOnlyWhenClaimed`,
+  `TestStackTxP95Mbps_SumsContainersPerMinute`, `TestNotifyUnexplained_TypesSentencesAndDetails`,
+  `TestUpwatch_QBLimitLineOnQBittorrentsPageOnly`, `TestUpwatchIsWiredAtStartup`, `TestNewUpwatch_ExplainersAndEmit`;
+  the system page's four frozen Hungarian renders gained the one new row (diffed: nothing else moved).
+
 ## v0.341.0 (2026-10-23) — the night update takes a security-fix step (D39 = B, `09` §3 decision 255, R-1239)
 
 **Released 2026-10-23: global floor 11:24:47 UTC (the operator's yes in chat), MinAgent 0.158.1; image `sha256:8aa4ce60…c0bc`