docs: explain the hook count vs the diagnostic check count

docs/diagnostics.md

@@ -224,6 +224,43 @@ already in progress, so the click cannot be absorbed by that run.
   used by diagnostics — the root differential already gives the full 4-way + `hidden`
   without them — and stay only in the Statistics tab.
 
+## 6a. Hook count vs check count — why they differ
+
+Two numbers describe the same backend and they are deliberately not equal, which
+reads as a contradiction if you assume they should match:
+
+- **Statistics → "hooks: N"** counts the *interception points the backend
+  actually installed* — the set bits of its `hooks` mask (protocol §4.3). For a
+  kernel backend on a modern kernel that is 11 (10 below 5.3, where the bind hook
+  is left to CAP_NET_RAW — see §5.1 and the protocol note on the per-kernel
+  requested set); for LSPosed it is the Java hooks that attached.
+- **Detailed diagnostics → the per-check list** counts the *detection vectors the
+  self-test probes* — 15 under the native layer, 13 under the Java layer. Each is
+  a distinct way an app could notice the VPN, run and classified independently
+  (§2, §3).
+
+They are different denominators, not the same one miscounted, because the
+hook↔check relation is many-to-many:
+
+- **One hook covers several checks.** `dev_ioctl` backs both `ioctl_flags`
+  (`SIOCGIFFLAGS`) and `ioctl_mtu` (`SIOCGIFMTU`); one installed hook, two probed
+  vectors.
+- **One check is covered by several hooks, often across backends.** `proc_route`
+  lists `fib_route_seq_show` *and* `zygisk_openat`: whichever active backend
+  closes the vector counts, so a check's `expectedHooks` spans the kernel and
+  Zygisk id spaces even though a given device runs only one of them.
+- **Some checks map to no installed hook and still pass.** `proc_dev` /
+  `proc_if_inet6` have no kernel `seq_show` hook — SELinux or the optional Zygisk
+  `openat` group closes them; and on a pre-5.3 kernel `so_bindtodevice` maps to
+  `socket_bind_interface`, which is intentionally not installed, yet the check
+  passes via the native CAP_NET_RAW gate.
+
+So "KPM OK · hooks: 10" next to "15 KPM checks" is correct: ten interception
+points closing fifteen probed vectors (with SELinux and the kernel's own gates
+carrying the rest). The self-test measures *outcomes per vector*, not one probe
+per hook, which is the whole point of the root-differential (§2) — it asks "is
+this surface hidden", not "did hook N fire".
+
 ## 7. Native check → owning hook, verified on Pixel 4a
 
 The native backend hooks map to the diagnostic checks below. The kernel backends

docs/help/en/kpm-install.md

@@ -42,6 +42,16 @@ KPM validates your kernel family at load time. Supported families are 4.4, 4.9,
 guessed. If the Dashboard shows *"kernel not supported … no validated offset
 table,"* use the [Zygisk backend](zygisk-install.md) instead.
 
+## Why it shows 10 hooks on some kernels
+
+On kernels older than 5.3 the Native backend installs 10 hooks, not 11, and reads
+**OK** — this is a complete install, not a missing hook. The one hook it skips
+guards binding a socket to the VPN interface, and on those kernels the kernel
+already blocks that itself (it needs a privilege an ordinary app doesn't have),
+so VPN Hide leaves it to the kernel. From 5.3 up all 11 are installed. (The hook
+count is separate from the number of Diagnostics checks — see
+[What the self-test checks](what-the-check-proves.md).)
+
 ## If it's installed but inactive
 
 The Dashboard names the cause:

docs/help/en/what-the-check-proves.md

@@ -40,3 +40,12 @@ A steady-state callback probe also cannot certify every Wi-Fi/mobile/offline
 transition or every combination of callback registrations. Those require separate
 transition tests. For current, retained and interrupted results, see
 [Result meanings](check-result-meanings.md).
+
+## Why the check count isn't the hook count
+
+The Diagnostics list has more entries than the backend has hooks (for example
+15 native checks against 10–11 kernel hooks). That's expected: a check is a *way
+an app could detect the VPN*, and one hook often covers several of them, while
+some checks are covered by the kernel or SELinux with no hook at all. The
+self-test measures each vector's outcome, not one probe per hook. The hook count
+lives on the [Statistics](statistics.md) screen.

docs/help/ru/kpm-install.md

@@ -41,6 +41,16 @@ KPM проверяет семейство вашего ядра при загр
 угадываются. Если Дашборд пишет *«ядро не поддерживается… нет проверенной
 таблицы смещений»*, используйте [бэкенд Zygisk](zygisk-install.md).
 
+## Почему на некоторых ядрах показывается 10 хуков
+
+На ядрах старше 5.3 нативный бэкенд ставит 10 хуков, а не 11, и отображается как
+**OK** — это полная установка, а не пропущенный хук. Единственный хук, который он
+не ставит, защищает привязку сокета к VPN-интерфейсу, а на таких ядрах само ядро
+уже это блокирует (для этого нужно право, которого у обычного приложения нет),
+поэтому VPN Hide оставляет его ядру. Начиная с 5.3 ставятся все 11. (Число хуков —
+это не то же самое, что число проверок в диагностике, см.
+[Что проверяет самотест](what-the-check-proves.md).)
+
 ## Если установлен, но неактивен
 
 Дашборд называет причину:

docs/help/ru/what-the-check-proves.md

@@ -41,3 +41,12 @@ VPN](tester-finds-vpn.md).
 Wi-Fi/мобильная сеть/офлайн и все сочетания регистраций. Для этого нужны отдельные
 проверки переходов. О текущих, сохранённых и прерванных результатах см.
 [Значения результатов](check-result-meanings.md).
+
+## Почему число проверок не равно числу хуков
+
+В списке диагностики пунктов больше, чем у бэкенда хуков (например, 15 нативных
+проверок против 10–11 хуков ядра). Так и должно быть: проверка — это *способ,
+которым приложение могло бы обнаружить VPN*, и один хук часто закрывает сразу
+несколько таких способов, а часть проверок закрывает само ядро или SELinux вообще
+без хука. Самотест измеряет исход каждого вектора, а не «одна проба на хук». Число
+хуков показано на экране [Статистики](statistics.md).

docs/help/zh/kpm-install.md

@@ -34,6 +34,14 @@ KPM 在加载时校验你的内核家族。受支持的家族为 4.4、4.9、4.1
 6.1、6.6、6.12。其他家族会被拒绝而非猜测。若仪表盘显示*“内核不受支持……没有已
 验证的偏移表”*，请改用 [Zygisk 后端](zygisk-install.md)。
 
+## 为什么某些内核上显示 10 个钩子
+
+在低于 5.3 的内核上，原生后端安装 10 个而非 11 个钩子，并显示为 **OK**——这是完整
+安装，而非缺少钩子。它跳过的那个钩子用于防护把套接字绑定到 VPN 接口，而在这些内核
+上，内核本身已经阻止了这一点（这需要普通应用没有的权限），所以 VPN Hide 把它交给内
+核。从 5.3 起，11 个钩子全部安装。（钩子数量与诊断中的检查数量不是一回事，参见
+[自检检查了什么](what-the-check-proves.md)。）
+
 ## 如果已安装但未生效
 
 仪表盘会说明原因：

docs/help/zh/what-the-check-proves.md

@@ -31,3 +31,10 @@
 
 稳定状态的回调探测也不能证明全部 Wi-Fi/移动网络/离线切换或所有回调注册组合。
 这些需要单独的切换测试。当前、保留及中断结果见[结果说明](check-result-meanings.md)。
+
+## 为什么检查数量不等于钩子数量
+
+诊断列表中的条目比后端的钩子多（例如 15 项原生检查对应 10–11 个内核钩子）。这是
+正常的：一项检查是*应用可能借以发现 VPN 的一种方式*，一个钩子往往能覆盖其中好几
+种，而有些检查由内核或 SELinux 本身（无需钩子）覆盖。自检衡量的是每个向量的结
+果，而非“每个钩子一次探测”。钩子数量显示在[统计](statistics.md)界面。