Upload watch: spike, design (08 section 9, proposed), live proofs on 9202; rows R-1244..R-1248 (register 189 -> 194); STATUS D41/D42 + the Monday list

Spike: per-app normal levels on three boxes (19-31 days), the off-site push as a line measure (a lower bound),
qBittorrent/Transmission/Plex explainers measured on 9202, a tc ceiling measured (not built). Live on 9202 with
0.342.0-rc.1: limit set; real seed explained; CPU burner and the hidden flood alarmed once each and cleared once;
the household's limit left alone. Teardown: apps removed, 9202 back on 0.341.0, receiver 9471 destroyed.

documentation/architecture/08-alarm-ladder.md

@@ -531,3 +531,37 @@ list is shown as custom and saved back unchanged; the default list maps to group
    multi-day backup fault reads as „nobody noticed" if the household ever finds out.
 2. **The cooldown field („hány óránként legfeljebb"):** keep it on the page or move it under „Részletek"? Pick:
    **under Részletek** — it is an engineering choice, which is what this redesign removes.
+
+## 9. The upload and CPU watch — „does the app explain its own traffic?" [DESIGN — proposed; built in controller v0.342.0 + hub v0.169.0, NOT released]
+
+**Why** (operator ruling 2026-10-23 19:22, `CONTEXT.md`): DooPlex's hacked Plex sent ~474 GB in a day with no viewer and
+used ~10 cores with no film being converted (`audits/plex2shell-felhom-impact-2026-10-23/`). Nothing on a Felhom box
+would have noticed: the health check sees whole-box CPU at one instant, and nothing looks at upload at all. **The idea:**
+when an app sends a lot (or burns CPU) for a long time, ask the APP whether that is its work. Work the app explains is
+normal use; work it does not explain is the sign of a hacked app. Numbers and measurements:
+`audits/SPIKE-upload-watch-2026-10-23.md`; the code: controller `internal/upwatch` (README §8e).
+
+1. **The line.** Learnt from what the box already does: while its off-site push runs, 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`); a
+   night counts when that window moved ≥ 10 MB; the line is the highest counting night. A **lower bound**, shown so
+   („legalább N Mbit/s", system settings). An active test is not built (R-1247).
+2. **Trigger, per app** (its compose project's containers summed; exact counters from the Docker Engine API, once a
+   minute): upload ≥ max(5 Mbit/s, 25 % of the line) for 15 minutes; CPU ≥ max(150 %, 50 % × cores) of one core for 30
+   minutes. Infrastructure (the controller — its own push is the line measure —, traefik, cloudflared, Samba) is never
+   judged; the box's own work on an app (a backup run, an update, a deploy) is never judged.
+3. **The explanation.** qBittorrent (`up_info_data`) and Transmission (`uploadedBytes`): explained when the container
+   sent ≤ 1.25 × what the app counted + 1 Mbit/s. Plex: any viewer explains upload; any transcode explains CPU. An app
+   that does not answer gives no number (a hacked app may refuse its own API). No explainer: upload alarms only at ≥ 10 ×
+   its own p95 for 60 minutes after ~20 h of history; CPU at ≥ max(200 %, 75 % × cores) for 60 minutes.
+4. **Who is told** (the R-388 rule, §8.1): **`app_unexplained_upload` / `app_unexplained_cpu`** (warning) and their
+   `_cleared` (info, recorded) are **operator-only** (hub `operatorOnlyEvents`), one per episode, per-app cooldown. The
+   household is told only about the qBittorrent limit, because they can change it (R-1246 asks the operator).
+5. **qBittorrent's default upload limit:** 50 % of the line (R-1245), every 15 minutes, re-set when the line moves
+   > 20 %; never over a limit the household set (one there first, or any change from the value qBittorrent stored for
+   the box — it keeps KiB/s). No line → none set. While the box owns it, qBittorrent's page says: „A qBittorrent
+   feltöltése legfeljebb N Mbit/s, hogy a családi internet gyors maradjon. A qBittorrentben átállíthatod."
+6. **Limits, stated:** an attacker who knows the check can make the app's API lie — a per-container ceiling (`tc` from
+   a helper in the app's network namespace, measured to work in an unprivileged guest; spike §5) would cap the flood
+   whatever the API says; not built. The box cannot tell LAN from internet bytes per app; a host-network container
+   (Samba) has no counter; the line is a lower bound.
+7. **Release:** not released; the operator's yes (R-1244).

documentation/architecture/13-threat-model.md

@@ -76,7 +76,7 @@ OS packages (exact versions, apt-signed), the installer script (by tag, R-980).
 | **added:** LAN ↔ box | partly | root password SSH on the host from the LAN (R-982) |
 | **added:** hub ↔ box (inbound) | **does not hold** | `01` §4 says the box exposes no control endpoint; a hub-key route can replace the box's settings (R-970) |
 | **added:** catalog ↔ every box | **design gap** | a catalog push reaches every box with no check on the box (R-971) |
-| **added 2026-10-23 (R-1241):** a hacked app pod on DooPlex ↔ Felhom's secrets | **does not hold**; not used in the Plex2Shell window | two no-login doors: the Longhorn NFS export (the hub's unencrypted nightly copies with the unsealed tokens of R-975; by a published file-handle escape the whole sda1 disk, the operator signing keys included — not exercised) and the Longhorn API (backup a volume to any target). Plex2Shell, 2026-10-17 → 10-23: **NOT REACHED** — 0 new NFS connections in the window, no off-schedule backup or volume; the hub, the k8s API and the kubelet refuse a caller with no credential (measured). The export was narrowed to the pod network on 2026-10-23; the pod side stays open (`audits/plex2shell-felhom-impact-2026-10-23/`) |
+| **added 2026-10-23 (R-1241):** a hacked app pod on DooPlex ↔ Felhom's secrets | **does not hold**; not used in the Plex2Shell window | two no-login doors: the Longhorn NFS export (the hub's unencrypted nightly copies with the unsealed tokens of R-975; by a published file-handle escape the whole sda1 disk, the operator signing keys included — not exercised) and the Longhorn API (backup a volume to any target). Plex2Shell, 2026-10-17 → 10-23: **NOT REACHED** — 0 new NFS connections in the window, no off-schedule backup or volume; the hub, the k8s API and the kubelet refuse a caller with no credential (measured). The export was narrowed to the pod network on 2026-10-23; the pod side stays open (`audits/plex2shell-felhom-impact-2026-10-23/`). **Felhom half, 2026-10-23 night:** the last plain tokens sealed in hub 0.168.0 (built, deploy pending — `audits/hub-token-seal-2026-10-23/`); the two plain Longhorn copies of the hub volume already in the folder are R-1243's decision. A household box's version of this attacker (a hacked app sending or mining) is what the upload watch (R-1244, not released) detects |
 
 ## 6. What we accept (do not re-report)