@mrrisega/dsh-remote 0.7.0-beta.7 → 0.7.0

package/packages/dsh-remote-web/lib/index.js

@@ -15,7 +15,7 @@
 //     （no_account/no_runtime/installing/starting/connecting/online/error），并在返回前自动补装运行环境、
 //     拉起 bridge、清理卡死标记（带退避）；区分「bridge 进程在跑」与「设备已在中继注册成功（online）」。
 //     面板用 2~3s 短轮询自动推进到 online（无需点按钮/刷新页面），error 才给重试与诊断信息；
-//     另 POST /dsh-remote/connect/retry 手动重试、POST <api>/api/install-report 上报安装口径
+//     另 POST /dsh-remote/connect/retry 手动重试、POST <api>/api/install-report 上报安装约定
 //     （install_source/version + host_os/arch，详见 installSourceOf）。
 //   - 0.1.2+ ?token 浏览器鉴权会话代持（0.4.1 起）
 //
@@ -90,14 +90,14 @@ const DEFAULT_RELAY_DIR = process.env.DSH_RELAY_DIR || join(homedir(), ".dsh-rem
 // 默认云端服务地址（SaaS 入口；自建用户在设置页/面板切换）。
 // DSH_RELAY_DEFAULT_API 只改「配置里根本没写 api_url」时的兜底：测试脚本把它指向本地死端口，
 // 这样任何**在临时目录被拆掉之后**才跑到的后台请求（如装机上报的重试）都不会打生产。
-// 真实事故形态见 test/wechat-bind-telemetry.test.mjs 的注释：用例拆目录 → 读到空配置 → 回落生产。
+// 真实故障形态见 test/wechat-bind-telemetry.test.mjs 的注释：用例拆目录 → 读到空配置 → 回落生产。
 const DEFAULT_API = String(process.env.DSH_RELAY_DEFAULT_API || "").trim()
   || "https://n.risegao.cn:13443/relay-api";
 const DEFAULT_APP_URL = "https://n.risegao.cn:13443/app/";
 
 // ---------- 上游 dsh web 地址（bridge/watcher 都要连它，绝不写死 3080） ----------
 //
-// 【2026-09-23 用户实测事故】这里（以及运行时的 checkUpstream）原本把上游**写死**
+// 【2026-09-23 用户实测故障】这里（以及运行时的 checkUpstream）原本把上游**写死**
 // `http://127.0.0.1:3080`：只要用户的 dsh web 不在默认端口（`dsh web --port 8090`、
 // profile 里配了 port、或 `--port 0` 让系统分配空闲端口），watcher 的「dsh web 在线吗」
 // 探测就永远失败 → **bridge 永远不启动**，而面板只会说「正在启动 Bridge…」（错误为空）
@@ -491,7 +491,7 @@ function npxInvocation() {
 /** 子进程环境：把 node 目录补进 PATH（npx 及其 shebang 需要），可附加额外变量。 */
 function spawnEnv(extra) {
   // ⚠️ 这里刻意用 **process.execPath**，不是 NODE_BIN：PATH 首位的用途是让 npx 的
-  // `#!/usr/bin/env node` 解析到**正在跑本插件的那个 node**（与 npxInvocation 同口径）。
+  // `#!/usr/bin/env node` 解析到**正在跑本插件的那个 node**（与 npxInvocation 同约定）。
   // NODE_BIN 回答的是另一个问题——"自启动服务里该登记哪个解释器"（真实 node 优先）。
   // 两者语义不同，混用会悄悄改掉 web 版上 npx 用哪个 node。
   const nodeDir = dirname(process.execPath);
@@ -759,9 +759,9 @@ function fetchFailReason(e) {
 }
 
 /**
- * Cookie 按 **authority 分文件**(0.7.0-beta.2 起,2026-10-09 事故根治)。
+ * Cookie 按 **authority 分文件**(0.7.0-beta.2 起,2026-10-09 故障根治)。
  *
- * 【事故】`~/.dsh-remote/` 只有一份 `.harness-cookie.json`,而 Web 端(3080)与桌面端(每次启动
+ * 【故障】`~/.dsh-remote/` 只有一份 `.harness-cookie.json`,而 Web 端(3080)与桌面端(每次启动
  *   随机端口)是**两个宿主进程**,各自的插件都往里写"自己 authority 的 Cookie" → 互相覆盖。
  *   桥撞 401 后重读磁盘,拿到的是另一个宿主刚写的 Cookie → 重试 → 还是 401 → 再读 → 又被
  *   覆盖回去……**乒乓,永不自愈**,手机端持续白页(现象与"自愈坏了"一模一样,极易误判)。
@@ -782,7 +782,7 @@ function harnessCookieFileFor(authority) {
 function harnessCookieRevokedFileFor(authority) {
   return `${HARNESS_COOKIE_REVOKED_FILE}.${authoritySlug(authority)}`;
 }
-/** 由本进程 webServer 端口推出 authority(与 bridge 的 Host 口径一致)。 */
+/** 由本进程 webServer 端口推出 authority(与 bridge 的 Host 约定一致)。 */
 function harnessAuthorityOfPort(port) {
   return port ? `127.0.0.1:${port}` : "";
 }
@@ -832,7 +832,7 @@ async function mintHarnessCookie(ctx, relayDir) {
     if (UNINSTALLED_DIRS.has(relayDir)) return false;
     const out = { authority: `127.0.0.1:${port}`, cookie, mintedAt: Date.now() };
     mkdirSync(dirname(configPathOf(relayDir)), { recursive: true });
-    // ① 本宿主专属文件(权威,两个宿主互不覆盖 —— 事故根治点)
+    // ① 本宿主专属文件(权威,两个宿主互不覆盖 —— 故障根治点)
     const ownPath = join(relayDir, harnessCookieFileFor(out.authority));
     writeFileSync(ownPath, JSON.stringify(out, null, 2), { mode: 0o600 });
     hardenFile(ownPath); // 会话 Cookie ≈ dsh web 的完整访问权，同样要收紧
@@ -1003,7 +1003,7 @@ function runtimeManifest(relayDir) {
 /**
  * 桌面运行环境缺失/不完整的文件清单（空 = 就绪）。
  *
- * 【2026-09-23 用户实测事故】判据原本是「`dsh-setup.mjs` 存在即就绪」——**存在 ≠ 能加载**。
+ * 【2026-09-23 用户实测故障】判据原本是「`dsh-setup.mjs` 存在即就绪」——**存在 ≠ 能加载**。
  * npx 补装是「先拷入口脚本、再递归拷 clients/」，中途被打断（用户关窗口 / 杀软锁文件 /
  * 机器休眠 / 看门狗判超时结束进程）就会留下一个**只有入口脚本的半装运行时**。此后：
  *   · runtimeReady() 恒为 true → 插件再也不补装（自愈彻底停摆）；
@@ -1049,7 +1049,7 @@ function launchAgentPath() {
 /**
  * ★ 这份自启动 plist 是否**确实是为本 relayDir 装的**（内容里写着 `<relayDir>/dsh-setup.mjs`）。
  *
- * 🔴 2026-10-10 事故（两次，同一根因）：`reapBrokenAutostart()` 用**当前 relayDir** 判断
+ * 🔴 2026-10-10 故障（两次，同一根因）：`reapBrokenAutostart()` 用**当前 relayDir** 判断
  *   "入口脚本缺失"（测试的临时 relayDir 当然没有 dsh-setup.mjs → 判 true），
  *   但删除的却是 `launchAgentPath()` = **真实 HOME 下那份 plist** → 把开发者本机的自启动
  *   连 bootout 带删文件一起干掉了（远程访问中断，且日志里看不出异常）。
@@ -1136,7 +1136,7 @@ WantedBy=default.target
 /**
  * Linux：拉起 bridge 的阶梯（**与 macOS 同构：可自愈优先，可用兜底**）。
  *
- * 【0.6.15 事故根因】0.6.14 及更早，`startBridge` 只认 macOS 的 launchd，Linux 直接返回
+ * 【0.6.15 故障根因】0.6.14 及更早，`startBridge` 只认 macOS 的 launchd，Linux 直接返回
  * `unsupported: 当前平台（linux）暂不支持自启动服务`。于是：
  *   · 自愈轮次每轮都调用它、每轮都拿到 unsupported、**bridge 永远起不来**；
  *   · 用户面板上的表现是永远停在「正在启动 Bridge…」+「bridge 进程: 未运行」；
@@ -1188,7 +1188,7 @@ function startBridgeLinux(relayDir) {
 /**
  * launchd 域名阶梯（**必须与 dsh-setup.mjs 一致**）。
  *
- * 事故（2026-09-19 实测）：安装器按 macOS 26 的修复把作业装在 **`user/<uid>`** 域
+ * 故障（2026-09-19 实测）：安装器按 macOS 26 的修复把作业装在 **`user/<uid>`** 域
  * （gui 域会被系统置为 on-demand-only，RunAtLoad/KeepAlive 失效），
  * 但插件这边只认 `gui/<uid>` → 切换账号时那次"重启 bridge"实际执行的是
  *   launchctl bootout gui/501/com.dshremote.bridge   → 找不到
@@ -1449,7 +1449,7 @@ function appendLogLine(relayDir, name, line) {
  * 注意：默认优先官方源——镜像(npmmirror)可能滞后于刚发布的版本，装到旧版会把
  * 已被 0.4.5 移除的“用户 include”重新写回 profile（历史上造成 dsh web 重复 ID 崩溃）。 */
 /**
- * 补装失败退避（2026-09-15 生产事故）。
+ * 补装失败退避（2026-09-15 生产故障）。
  *
  * 背景：Windows 用户补装 `npx @mrrisega/dsh-remote` 持续失败时，自愈调度每轮都重试，
  * 生产遥测里看到单机 12 秒一次、累计 606 次的失败风暴（1659 次 install_failed 全在 Windows）。
@@ -1673,7 +1673,7 @@ function ensureRuntime(relayDir) {
 /**
  * 生成 plist（与 dsh-setup.mjs 的 writeAutostartFile **必须同构**），返回路径。
  *
- * ⚠️ 两份模板历史上漂移过、并因此各造成一个真机事故（插件每次自愈/启动都会重写 plist，
+ * ⚠️ 两份模板历史上漂移过、并因此各造成一个真机故障（插件每次自愈/启动都会重写 plist，
  *    所以**插件这份谁写谁说了算**，漂移等于把安装器那份正确的覆盖掉）：
  *   · 漏 `/usr/sbin`、`/sbin`（SERVICE_PATH）→ bridge 找不到 `ioreg` → 机器指纹静默退化成
  *     hostname 哈希（改一次主机名就被当成新设备）；
@@ -2007,7 +2007,7 @@ function stopBridge(relayDir) {
   }
   const targets = launchTargets();
   if (!targets.length) return { ok: false, status: "unsupported", detail: `当前平台（${osPlatform()}）没有 launchd 服务可停，请手动结束 \`dsh-remote run\` 进程` };
-  // 两个域都要停：作业可能由安装器装在 user/<uid>，而旧版插件只会去 gui/<uid> 找不到（实测事故）
+  // 两个域都要停：作业可能由安装器装在 user/<uid>，而旧版插件只会去 gui/<uid> 找不到（实测故障）
   let lastErr = "";
   for (const target of targets) {
     const r = sh(`launchctl bootout ${target}`);
@@ -2065,7 +2065,7 @@ function uninstallRuntime(relayDir, protectedPath) {
     // a) 停服务 + 移除自启动文件
     try {
       if (isDarwin()) {
-        /* 🔴 2026-10-10 事故护栏：**relayDir 不在当前 HOME 之下时，绝不碰真实自启动**。
+        /* 🔴 2026-10-10 故障护栏：**relayDir 不在当前 HOME 之下时，绝不碰真实自启动**。
            当天某个用例用「真 HOME + 临时 relayDir」调到了这里：plist 路径解析到真实的
            ~/Library/LaunchAgents/com.dshremote.bridge.plist → 先 bootout 真桥、再把 plist 删了
            → **开发者本机的远程访问被测试整个卸掉**（job 消失、桥停摆）。
@@ -2085,7 +2085,7 @@ function uninstallRuntime(relayDir, protectedPath) {
         // 只处理「plist 位于当前 HOME」的服务：本插件/dsh-setup.mjs 安装的服务一定在此
         const plistPath = launchAgentPath();
         if (plistPath && existsSync(plistPath)) {
-          /* ★★ 归属校验（2026-10-10 事故的最终护栏）：
+          /* ★★ 归属校验（2026-10-10 故障的最终护栏）：
              这份 plist 必须**确实是为本 relayDir 装的**（内容里写着 <relayDir>/dsh-setup.mjs）。
              不校验的话，只要有用例拿「真 HOME + 临时 relayDir」走到这里，就会把开发者本机
              真实的服务**先 bootout 再删文件**（当天实测发生：桥停摆、远程访问中断）。
@@ -3240,7 +3240,7 @@ async function proxyFeedback(relayDir, req, res, pathname) {
 
 /**
  * 把 `/dsh-remote/announcements*` 代理到云端公告 API（契约冻结见
- * dsh-relay-enterprise/docs/announcements-contract.md §3）：
+ * 服务端公告契约文档（冻结 v1） §3）：
  *   · GET  /dsh-remote/announcements       → 上游 GET  {api}/api/announcements?client=desktop[&install_id=…]
  *   · POST /dsh-remote/announcements/click → 上游 POST {api}/api/announcements/click  {id[, install_id]}
  *
@@ -3251,7 +3251,7 @@ async function proxyFeedback(relayDir, req, res, pathname) {
  *    两者**同时**带上会让唯一索引 (announcement_id, user_id, install_id) 把"同一人两台机器"
  *    算成两行 —— UV 直接翻倍。所以下面是有 Bearer 就不带 install_id，反之亦然。
  * ② **install_id 复用本机既有的 device_id，绝不新造 ID**：服务端那个维度就是"这台电脑"，
- *    再生成一个 ID 只会让同一台机器在统计里变成两台（且新 ID 与反馈/设备列表的口径对不上）。
+ *    再生成一个 ID 只会让同一台机器在统计里变成两台（且新 ID 与反馈/设备列表的约定对不上）。
  *    注意 `cfg.device_id` 是**本机设备标识**，与遥测的 `.telemetry-install-id` 不是一回事：
  *    后者在 DSH_REMOTE_TELEMETRY=0 时根本不生成，公告不该被遥测开关牵连。
  * ③ **失败一律软着陆**：上游 404（老服务端）/ 不可达 / 超时都只回一个 JSON，**绝不抛**。
@@ -3271,7 +3271,7 @@ async function proxyAnnouncements(relayDir, req, res, pathname) {
     }
 
     const headers = { "x-dsh-client": `dsh-remote-web/${PLUGIN_VERSION}` };
-    // 浏览器已带的 Bearer 优先透传（与 proxyFeedback 同口径：那是请求方自己的身份）；
+    // 浏览器已带的 Bearer 优先透传（与 proxyFeedback 同约定：那是请求方自己的身份）；
     // 否则由 node 半附当前账号 JWT —— 只有"确实配了账号"才值得为此跑一次 device-login。
     const auth = req.headers.authorization;
     let bearer = "";
@@ -3497,7 +3497,7 @@ async function fetchDistTags() {
   return {};
 }
 
-/** 在「当前通道」与 latest 之间取更高者（**更新与"检查更新"必须用同一口径**，否则面板会说"已是最新"而更新却装新版）。 */
+/** 在「当前通道」与 latest 之间取更高者（**更新与"检查更新"必须用同一约定**，否则面板会说"已是最新"而更新却装新版）。 */
 function pickBestTag(tags) {
   const t = tags || {};
   const channelVer = typeof t[UPDATE_TAG] === "string" ? t[UPDATE_TAG] : "";
@@ -3511,7 +3511,7 @@ function pickBestTag(tags) {
   return { tag: UPDATE_TAG, version: channelVer, why: `当前通道 ${UPDATE_TAG}(${channelVer}) 不低于 latest(${latestVer})` };
 }
 
-/** 查询"对我而言"的最新版本号（口径同 pickBestTag）。 */
+/** 查询"对我而言"的最新版本号（约定同 pickBestTag）。 */
 async function npmLatestVersion() {
   return pickBestTag(await fetchDistTags()).version;
 }
@@ -3607,7 +3607,7 @@ function spawnUpdater(relayDir, extraEnv, onError, spec = UPDATE_SPEC) {
     // Windows 上跑 npx.cmd 必须经 shell（Node ≥20.12 起否则 EINVAL）；走 node+npx-cli.js 时不需要。
     shell: npx.shell,
     windowsHide: true, // Windows：不弹控制台窗口（POSIX 上该选项被忽略）
-    // PATH 补 node 目录：App 最小 PATH 下也能跑 npx；同时保持本机既有的安装来源口径
+    // PATH 补 node 目录：App 最小 PATH 下也能跑 npx；同时保持本机既有的安装来源约定
     // （在线更新会重跑安装器并重写 plist，若不带来源就会把 plugin_market 误记成 npx）。
     env: spawnEnv({
       DSH_BRIDGE_INSTALL_SOURCE: installSourceOf(relayDir),
@@ -3877,7 +3877,7 @@ function rotateUpdateLog(relayDir) {
 /**
  * 判断 patch 文本是否是「合法的顶层 YAML 数组文档」。
  *
- * 为什么必须判（2026-09-18 Windows 用户实测的致命事故）：dsh 解析 cordis.patch.yml 时
+ * 为什么必须判（2026-09-18 Windows 用户实测的致命故障）：dsh 解析 cordis.patch.yml 时
  * **要求顶层是数组**，而**纯注释文档的 YAML 解析结果是 `null` 而不是空数组**，于是 dsh 直接：
  *   `Error: dsh: overlay …/cordis.patch.yml must be a top-level YAML array of loader patch entries`
  * 官方空 profile 模板是「注释 + `[]`」——`[]` 这个占位符不能省。
@@ -3907,7 +3907,7 @@ function stripOwnEntriesFromPatch(patch) {
   // ① 管理标记块（dsh-setup 写入的形式）
   // 结尾标记后面可能还有残留文字（历史变体），用 [^\n]* 吃掉整行，避免留下半截内容
   const out = String(patch ?? "").replace(/\n?# >>> dsh-remote-(?:web|ui)[^\n]*\n[\s\S]*?# <<< dsh-remote-(?:web|ui)[^\n]*\n?/g, "\n");
-  // ② 无标记的 insert 块（旧版 / 其它工具写入的形式，历史事故里出现过）。
+  // ② 无标记的 insert 块（旧版 / 其它工具写入的形式，历史故障里出现过）。
   //    只摘标记块是不够的：目录已删而 patch 仍引用 → dsh 插件树加载失败 → 整个 dsh web 起不来。
   const lines = out.split("\n");
   const kept = [];
@@ -3949,7 +3949,7 @@ function writePatchDocument(patchFile, text) {
 /**
  * 「运行时清理助手」源码（卸载用；由插件生成、detached 执行）。
  *
- * 为什么必须是独立进程（2026-09-18 用户实测的僵死事故）：
+ * 为什么必须是独立进程（2026-09-18 用户实测的僵死故障）：
  *   uninstallRuntime() 里有 spawnSync("schtasks"/"powershell"/"taskkill")，同步子进程调用会把
  *   **dsh web 的事件循环整个钉死** —— 不只是这一个请求不返回，手机端隧道、其它页面、所有 API
  *   一起停摆，表现为「端口在听、连接建立、但永不响应」。而 spawnSync 的 timeout 在 Windows 上
@@ -3959,7 +3959,7 @@ function writePatchDocument(patchFile, text) {
  * 助手做的是「宁可少做也不卡住」的有界清理：杀残留进程 → 删自启动 → 清配置目录，每步独立 try/catch。
  */
 function buildRuntimeCleanupHelper(relayDir, protectedPath) {
-  /* ★ 归属校验（2026-10-10 事故第三条路径）：计划里的 plistPath 用的是**当前 homedir**，
+  /* ★ 归属校验（2026-10-10 故障第三条路径）：计划里的 plistPath 用的是**当前 homedir**，
      而 relayDir 来自调用方 —— 两者不必是同一个目录。曾有测试用「真 HOME + 临时 relayDir」
      走到这里，于是这个 detached 助手把**开发者本机真实的自启动 plist 删了**（异步删，
      所以在进程内插桩根本抓不到）。现在：plist 里没写着本 relayDir 的入口脚本 → **不给路径**，
@@ -3986,7 +3986,7 @@ import { dirname, join, sep } from "node:path";
 
 const PLAN = ${plan};
 // 与主进程一致的测试隔离开关：置位时**绝不做任何真实系统操作**（不碰 launchctl/systemctl/schtasks/taskkill），
-// 但仍清空配置目录 —— 否则用例会去动开发者本机真实的自启动服务（历史事故，见 setup-output 用例的护栏）。
+// 但仍清空配置目录 —— 否则用例会去动开发者本机真实的自启动服务（历史故障，见 setup-output 用例的护栏）。
 const SKIP_SYSTEM_OPS = process.env.DSH_RELAY_SKIP_SERVICE === "1";
 function log(m) { try { appendFileSync(PLAN.log, "\\n[" + new Date().toISOString() + "] " + m + "\\n"); } catch (e) { /* 日志失败不阻断清理 */ } }
 function run(cmd, args, timeout) {
@@ -4086,7 +4086,7 @@ function accountFingerprintOf(cfg) {
 /**
  * 账号（或模式/设备身份）变化后，**必须让 bridge 用新凭据重新登记**。
  *
- * 事故（2026-09-19 实测）：从 A 账号切到 B 账号后，配置已经改了、device_id 也清了，
+ * 故障（2026-09-19 实测）：从 A 账号切到 B 账号后，配置已经改了、device_id 也清了，
  * 但**正在运行的 bridge 是启动时把账号/密码固化在环境变量里的**，它不会自己换账号；
  * 而那次"重启 bridge"又因 launchd 域名不一致（插件只认 gui/<uid>，安装器装在 user/<uid>）静默失败
  * → 设备继续留在 A 账号，B 账号的设备列表里永远看不到这台机器。
@@ -4477,7 +4477,7 @@ async function composeConnect(relayDir, opts = {}) {
   // ── 中继注册证据（只有 bridge 进程在跑时才算「现在能用」） ──
   // ⚠️ 先判「这个 bridge 是不是当前账号的」：账号切换后进程不会自己换凭据，
   // 旧账号留下的状态文件（phase=online + 旧 device_id）会让面板谎报「已连接」，
-  // 自愈也就永远不会去重启它（2026-09-19 实测事故）。
+  // 自愈也就永远不会去重启它（2026-09-19 实测故障）。
   const accountCurrent = bridgeMatchesCurrentAccount(relayDir, cfg);
   let registered = false;
   let registerSource = "";
@@ -4815,7 +4815,7 @@ async function submitFeedback(relayDir, payload) {
     "content-type": "application/json",
     "x-dsh-device": cfg.device_id || "",
     "x-dsh-client": `dsh-remote-web/${PLUGIN_VERSION}`,
-    // 与 proxyFeedback 同一口径：结构化平台字段 + 真实 UA（此处没有浏览器请求可转发，
+    // 与 proxyFeedback 同一约定：结构化平台字段 + 真实 UA（此处没有浏览器请求可转发，
     // 就如实写本机平台，绝不冒充浏览器 UA）。
     "user-agent": `dsh-remote-web/${PLUGIN_VERSION} (${process.platform}; ${process.arch})`,
     "x-dsh-platform": process.platform,
@@ -4890,7 +4890,7 @@ function ensureConnection(relayDir, opts = {}) {
   const watcherRunning = Boolean(launchd.running || watcherProcs.length);
   if (bridgeProcs.length || watcherRunning) {
     // 进程在跑 ≠ 跑对了账号：切换账号后旧 bridge 会一直用旧凭据，
-    // 只看"有没有进程"会让自愈永久停摆（实测事故）。这里多判一次账号归属。
+    // 只看"有没有进程"会让自愈永久停摆（实测故障）。这里多判一次账号归属。
     if (bridgeProcs.length && !bridgeMatchesCurrentAccount(relayDir, cfg)) {
       book.lastAttemptAt = now;
       book.attempts += 1;
@@ -5473,7 +5473,7 @@ function telemetryRuntimeReady(relayDir) {
 }
 
 /**
- * 运行环境探针（在补装 watcher 与面板轮询里顺手调用，不额外起定时器）：
+ * 运行环境探测（在补装 watcher 与面板轮询里顺手调用，不额外起定时器）：
  *   - 现在缺运行环境 → 记下「本进程见过缺失」，并在超过 INSTALL_STALE_MS 仍缺时归因为
  *     install_failed(runtime_install_timeout)（每进程一次）；
  *   - 之前见过缺失、现在已就绪 → runtime_ready（每进程一次）。
@@ -5729,7 +5729,7 @@ export const __telemetryInternals = {
 
 /**
  * 安装信息上报（插件侧通道）：登录后把本机安装信息发给企业端，供「已登录用户升级插件后刷新版本号」
- * 之类的口径统计。无账号凭据不上报；失败静默（绝不阻塞面板、不弹错误）。
+ * 之类的约定统计。无账号凭据不上报；失败静默（绝不阻塞面板、不弹错误）。
  * 契约：POST <api_url>/api/install-report，头 `authorization: Bearer <device-login JWT>`，
  * body { device_id?, install_source, install_version, harness_version, host_os, host_arch }，成功 200 {ok:true}；
  * 404/400 一律忽略（老服务端没有该接口时不能报错）。
@@ -6218,7 +6218,7 @@ function registerRoutes(ctx, relayDir) {
       handler: async (_req, res) => {
         // 彻底卸载 = ① 插件 profile 清理（快、纯 fs、可预期）② 运行时/bridge 清理（慢、要调外部命令）
         //
-        // ⚠️ 顺序是刻意的，别改回去（2026-09-18 用户实测的僵死事故）：
+        // ⚠️ 顺序是刻意的，别改回去（2026-09-18 用户实测的僵死故障）：
         //   旧实现把**慢的** uninstallRuntime 排在最前、uninstallSelf 排在其后，于是
         //   uninstallRuntime 里任何一次 spawnSync 卡住（Windows 沙箱拦 schtasks，而 spawnSync 的
         //   timeout 在 Windows 上并不可靠，实测 18s+ 未返回），uninstallSelf 就**永远不执行**
@@ -6596,7 +6596,7 @@ function registerRoutes(ctx, relayDir) {
         invalidateRelayToken(relayDir); // 账号可能变了：丢弃旧 token 缓存，立即用新账号认证
         if (accountFingerprintOf(cfg) !== accountFpBefore) resetBridgeForAccountChange(relayDir, "账号/模式已变更");
         const bridgeRestart = startBridge(relayDir);
-        // 登录成功即上报本机安装信息（企业端用于「升级插件后刷新版本号」口径）；失败静默。
+        // 登录成功即上报本机安装信息（企业端用于「升级插件后刷新版本号」约定）；失败静默。
         maybeReportInstall(relayDir, { force: true });
         sendJson(res, 200, { ok: true, bridgeRestart, ...(await composeStatus(relayDir)) });
       },
@@ -6627,7 +6627,7 @@ function registerRoutes(ctx, relayDir) {
         // 首次安装/在线更新后重启 DeepSeek harness：插件本体与浏览器半在进程启动时装载，
         // 不重启则面板入口与 /dsh-remote/* 路由都不会出现。只重启承载本插件的进程。
         //
-        // 🔴 2026-10-11 业主口径：**桌面端绝不代为重启**。
+        // 🔴 2026-10-11 用户约定：**桌面端绝不代为重启**。
         //   "自动重启会很突兀地把窗口给关掉，关没了……我们应该提示用户自己重启，不要由我们来重启。"
         //   桌面端 Host 由 Electron 托管，重启 = 强杀承载窗口的进程（还会弹原生致命错误）。
         //   这里做成**硬拒绝**（不只是前端藏按钮）：任何调用方都拿不到"被重启"的结果，
@@ -6754,7 +6754,7 @@ function registerRoutes(ctx, relayDir) {
         const password = String(body.password ?? "");
         if (!phone || !smsCode || !password) return sendJson(res, 400, { ok: false, error: "手机号、短信验证码与密码必填" });
         // 全量透传 body（不挑字段）：注册来源 reg_source（面板=panel_register／手机端网页=remoteweb_register）
-        // 等扩展字段必须原样进企业端，否则「用户从哪注册的」这类增长口径会全部丢失。
+        // 等扩展字段必须原样进企业端，否则「用户从哪注册的」这类增长约定会全部丢失。
         const payload = { ...body, phone, sms_code: smsCode, password };
         delete payload.__parseError;
         const captchaId = body.captcha_id ?? body.captchaId;
@@ -6904,7 +6904,7 @@ function registerRoutes(ctx, relayDir) {
 // 自己持有 webserver 配置（实测监听 43120 / 回环），我们的 LAN 绑定补丁并不生效，于是它一直
 // 用的是原生那条路。**不能把"手机能不能选工作区"押在宿主的绑定地址上。**
 //
-// 【0.6.15 事故修正 —— 0.6.14 的"先建 browse、后摘 auto"在 DSH Desktop 上必然失败】
+// 【0.6.15 故障修正 —— 0.6.14 的"先建 browse、后摘 auto"在 DSH Desktop 上必然失败】
 //
 // 现场（用户诊断日志）：
 //   error: service "directoryPicker" has been registered at .dLateDirectoryPicker3
@@ -7064,9 +7064,9 @@ const PICKER_PIN_PROBE_WAIT_MS = 30_000;  // 等服务挂出来的上限（只
 const PICKER_PIN_PROBE_GAP_MS = 3_000;    // 上面那段轮询间隔
 
 /**
- * 目录选择器的**延后**接线 —— 这是 2026-09-26 启动事故的直接修复。
+ * 目录选择器的**延后**接线 —— 这是 2026-09-26 启动故障的直接修复。
  *
- * 🔴 事故：旧实现在 `apply()` 里**立刻**调 `pinBrowseDirectoryPicker(ctx)`（最多 6 次 × 700ms 轮询）。
+ * 🔴 故障：旧实现在 `apply()` 里**立刻**调 `pinBrowseDirectoryPicker(ctx)`（最多 6 次 × 700ms 轮询）。
  *    `loader.remove()` / `loader.create()` 会触发 dsh 的 `internal/plugin` 事件，而
  *    `@deepseek-ai/dsh-client-modules` 收到事件就**重新 compose 整张前端插件图**
  *    （`ClientModuleRegistry.flush() → buildCombo() → newlineCount()/identitySectionMap()`）。
@@ -7184,7 +7184,7 @@ export function apply(ctx, config = {}) {
   // 0.1.2-rc.1+ 浏览器会话代持：换取 Harness 会话 Cookie 供 bridge 上游携带（手机点设备不再 401 白页）
   ctx.effect(() => scheduleHarnessMint(ctx, relayDir), "dsh-remote-web: harness browser-session mint");
   // 目录选择器:远程控制下必须用浏览器内实现(否则手机点「添加工作区」像没反应) —— 见上方长注释
-  // ⚠️ **必须延后**：绝不能在 apply() 里直接切 Loader —— 会把宿主启动拖成假死（2026-09-26 事故，
+  // ⚠️ **必须延后**：绝不能在 apply() 里直接切 Loader —— 会把宿主启动拖成假死（2026-09-26 故障，
   //    见 schedulePickerPin 上方长注释）。schedulePickerPin 自己等"宿主已 listen + 静置"再动手。
   ctx.effect(() => schedulePickerPin(ctx), "dsh-remote-web: pin browser directory picker");
   // 插件市场一键全功能:缺桌面运行环境则自动安装,登录后自动拉起 bridge(不依赖用户跑 npx)
@@ -7200,7 +7200,7 @@ export function apply(ctx, config = {}) {
     telemetryRuntimeProbe(relayDir); // 匿名遥测：记下「本进程见过运行环境缺失」（装好后发 runtime_ready）
   }
   // 插件启动即上报本机安装信息（install_source/version + 主机 OS/架构；仅有账号凭据时上报，失败静默）。
-  // 面板登录成功（POST /dsh-remote/config）时会再上报一次，覆盖「已登录用户升级插件」的口径。
+  // 面板登录成功（POST /dsh-remote/config）时会再上报一次，覆盖「已登录用户升级插件」的约定。
   maybeReportInstall(relayDir);
   ctx.logger?.info?.(`dsh-remote-web: /dsh-remote routes ready (relayDir=${relayDir})`);
 }

package/packages/dsh-remote-web/lib/tarball-update.js

@@ -1,7 +1,7 @@
 /**
  * 零依赖更新通道：直接从 npm registry 取 tarball，用 Node 内置 zlib + 自解析 tar 落到 staging 目录。
  *
- * 为什么必须有这条通道（真实事故，生产遥测近 14 天）：
+ * 为什么必须有这条通道（真实故障，生产遥测近 14 天）：
  *   插件面板的「一键更新」过去一律走 `npx @mrrisega/dsh-remote@<tag>`。在 Windows 上，
  *   Node ≥20.12（CVE-2024-27980 的修复）起 `spawn("npx.cmd")` 不带 shell 会**同步抛 EINVAL**，
  *   0.6.6 及更早正是这么写的 —— 于是**升级通道本身坏掉**：427 台 Windows 里 157 台装机失败

package/packages/dsh-remote-web/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-remote-web",
-  "version": "0.7.0-beta.7",
+  "version": "0.7.0",
   "description": "公网远程控制 DeepSeek Harness（dsh web）：安装即得专属加密地址，人在外面也能用手机访问电脑上的 dsh——无需同一局域网/WiFi、无需公网 IP 与内网穿透，全程加密；手机端 100% 还原电脑体验（对话/工具/审批/设置）。技术用户可选自建服务，流量走自己的服务器。Remote control DeepSeek Harness (dsh web) from anywhere over the public internet — install, get an encrypted URL, use it from your phone on any network (dual-half cordis plugin: Settings panel + same-origin /dsh-remote routes). (2026-09 由 dsh-remote-ui 更名 / renamed from dsh-remote-ui; dsh-remote 的 dsh web 插件半，不是纯 UI/皮肤插件)",
   "type": "module",
   "main": "lib/index.js",

package/packages/dsh-remote-web/runtime/clients/dsh-remote/dsh-bridge.mjs

@@ -55,8 +55,8 @@
  *   - 帧体带信封标记(content-type: application/vnd.dsh.e2ee-v2 或 x-dsh-e2ee)= 已加密:
  *     HTTP 解封→转发上游→响应封回;WS 逐消息封/解。任何解封失败显式
  *     502 + x-dsh-e2ee-error / ws-close 1008,绝不静默降级。
- *   - 控制通道 /_e2ee/ctrl(device/channel 形态)不连上游,跑 §5.2 握手(hello/ack/探针);
- *     数据流 ws-open 携带 &e2ee=<sessId>&w=<8B hex>,探针通过前不转发任何数据。
+ *   - 控制通道 /_e2ee/ctrl(device/channel 形态)不连上游,跑 §5.2 握手(hello/ack/探测);
+ *     数据流 ws-open 携带 &e2ee=<sessId>&w=<8B hex>,探测通过前不转发任何数据。
  *
  * E2EE Phase-4(镜像页 shim,见 e2ee-shim.mjs / e2ee-shim-script.js):
  *   - doHttp 在 text/html 注入 mobile-adapter 之后、压缩/封包之前,对「e2ee.enabled ∧
@@ -237,7 +237,7 @@ function persistBridgeState(patch, opts = {}) {
   } catch { /* 非关键:面板侧还有日志/账号兜底判据 */ }
 }
 
-// ---------- 安装来源 / 版本(服务端设备行统计口径) ----------
+// ---------- 安装来源 / 版本(服务端设备行统计约定) ----------
 // DSH_BRIDGE_INSTALL_SOURCE 由一键安装器(dsh-setup.mjs)注入 = npx;未设置表示这台电脑走的是
 // 「插件市场装面板插件 + 插件自愈补装运行环境」那条路径 = plugin_market;白名单外一律 unknown。
 const INSTALL_SOURCE_VALUES = new Set(["npx", "plugin_market"]);
@@ -339,9 +339,9 @@ const HARNESS_UNAUTHORIZED_TEXT = "dsh web authentication required";
 const HARNESS_COOKIE_REVOKED_FILE = ".harness-cookie-revoked";
 
 /**
- * Cookie 按 **authority 分文件**(0.7.0-beta.2 起,2026-10-09 事故根治)。
+ * Cookie 按 **authority 分文件**(0.7.0-beta.2 起,2026-10-09 故障根治)。
  *
- * 【事故】`~/.dsh-remote/` 只有一份 `.harness-cookie.json`,而 Web 端(3080)与桌面端(每次启动
+ * 【故障】`~/.dsh-remote/` 只有一份 `.harness-cookie.json`,而 Web 端(3080)与桌面端(每次启动
  *   随机端口)是**两个宿主、两个进程**,各自的插件都会往里写"自己 authority 的 Cookie" →
  *   互相覆盖。桥撞 401 后重读磁盘,拿到的是**另一个宿主刚写的** Cookie(与失败的不是同一个)
  *   → 重试 → 还是 401 → 再读 → 又被覆盖回去……**乒乓,永不自愈**。手机端持续白页。
@@ -905,7 +905,7 @@ async function doHttp(method, path, reqHeaders, body, isB64) {
  * 【0.6.15】这里曾经是 `body: Buffer.from(JSON.stringify(respEnv)).toString("base64")`
  * + `bodyBase64: true` —— 也就是把整个信封 JSON 再 base64 一次。中继拿到它做的第一件事
  * 就是解回 UTF-8 再写给手机，所以这一层**纯属白花 33% 流量**，而且正好落在按流量计量的
- * bridge→中继 那条 WS 上（业主实测那条聚合包：12.69 MiB vs 直接发 UTF-8 的 9.5 MiB）。
+ * bridge→中继 那条 WS 上（用户实测那条聚合包：12.69 MiB vs 直接发 UTF-8 的 9.5 MiB）。
  * 中继对两种形态都支持（`frame.bodyBase64` 真假之分），所以直接发 UTF-8 明文即可。
  *
  * @param {string|number} id 帧 id
@@ -931,7 +931,7 @@ export function e2eeHttpResponseFrame(id, sessId, respEnv) {
  * 「镜像页交付了、但页面再也没回来」的看门狗（2026-09-25）。
  *
  * 【为什么需要】首屏提示层被整块删除后，页面上不再有任何东西能告诉用户"没加载完"
- * （那正是业主的要求：不许再有会盖住界面的层）。但**服务端能看见一个更硬的信号**：
+ * （那正是用户的要求：不许再有会盖住界面的层）。但**服务端能看见一个更硬的信号**：
  * 我们把镜像页 HTML 交付给手机后，官方前端一定会在几秒内发一串请求（模块、会话、mux…）。
  * 若 60 秒内一个都没有，那这个页面几乎必然没起来 —— 这时在**日志**里留一条带时间戳的结论，
  * 用户「复制诊断信息」或 `dsh-remote doctor` 时就能看到，不用再靠猜。
@@ -1109,7 +1109,7 @@ function sendCtrlError(send, id, code, extra = "") {
   sendCtrlMsg(send, id, { v: 2, type: "e2ee-error", code, ...(extra ? { message: extra } : {}) });
 }
 
-/** 控制通道 ws-open:不连上游,应答 ok 后按 §5.2 跑握手(hello/ack → 探针)。 */
+/** 控制通道 ws-open:不连上游,应答 ok 后按 §5.2 跑握手(hello/ack → 探测)。 */
 function openControlWs(send, id) {
   if (!e2ee.enabled) {
     console.log(`[bridge] e2ee ctrl 被拒(桥端未启用): id=${id}`);
@@ -1122,7 +1122,7 @@ function openControlWs(send, id) {
   console.log(`[bridge] e2ee ctrl 通道已开 (id=${id}),等待 hello`);
 }
 
-/** 控制通道消息:明文 hello / AEAD 探针信封(§5.2)。 */
+/** 控制通道消息:明文 hello / AEAD 探测信封(§5.2)。 */
 function handleCtrlMessage(send, id, rawText) {
   const conn = ctrlConns.get(id);
   if (!conn) return;
@@ -1145,9 +1145,9 @@ function handleCtrlMessage(send, id, rawText) {
     return;
   }
   if (obj.v === 2 && obj.k === "ctrl") {
-    // AEAD 探针(密文信封);失败 → bad_key 提示手机“密码/密钥不一致”,绝不静默
+    // AEAD 探测(密文信封);失败 → bad_key 提示手机“密码/密钥不一致”,绝不静默
     if (!conn.sessId) {
-      sendCtrlError(send, id, "unknown_session", "探针先于 hello");
+      sendCtrlError(send, id, "unknown_session", "探测先于 hello");
       return;
     }
     try {
@@ -1155,7 +1155,7 @@ function handleCtrlMessage(send, id, rawText) {
       sendCtrlMsg(send, id, reply);
     } catch (e) {
       const code = e2eeCodeOf(e);
-      // 探针解密失败对手机语义统一为 bad_key(§5.2;密码不一致/改密未更新)
+      // 探测解密失败对手机语义统一为 bad_key(§5.2;密码不一致/改密未更新)
       sendCtrlError(send, id, code === "auth_failed" || code === "bad_key" ? "bad_key" : code, e?.message || "");
     }
     return;
@@ -1183,7 +1183,7 @@ export async function handleWsOpen(dchOrSend, frame) {
       send({ id, type: "ws-open", ok: false, code: 1008, reason: "e2ee_session_locked:请先解锁完成握手(检查密码)" });
       return;
     }
-    // 探测前不转发任何数据(§4.6/§5.2:探针通过后数据流才可建);此时已验证 → 安全
+    // 探测前不转发任何数据(§4.6/§5.2:探测通过后数据流才可建);此时已验证 → 安全
   }
   if (wsSessions.has(id)) { try { wsSessions.get(id).ws.terminate(); } catch {} wsSessions.delete(id); }
   const safe = safePath(tagged ? tagged.upstreamPath : path);
@@ -1412,7 +1412,7 @@ async function registerDeviceInAccount(token) {
         device_name: os.hostname() || "dsh-bridge",
         pub_key: pubKey,
         machine_fp: MACHINE_FP, // v6 同机识别:服务端据此自动顶替旧设备(重装不再被设备数卡死)
-        // 安装口径(服务端存到设备行,用于区分「市场安装/自愈补装」与「安装器 npx」):
+        // 安装约定(服务端存到设备行,用于区分「市场安装/自愈补装」与「安装器 npx」):
         //   install_source: npx(安装器注入) | plugin_market(插件拉起/自愈,默认) | unknown(白名单外)
         install_source: INSTALL_SOURCE,
         install_version: INSTALL_VERSION,
@@ -1659,7 +1659,7 @@ async function resolveWechatTier() {
 
 /**
  * App 入口(免费用户越界时给的转化链接)。
- * 由账号 API 地址推导:去掉 `/relay-api` 再加 `/app/` —— 与插件半的 DEFAULT_APP_URL 同一口径
+ * 由账号 API 地址推导:去掉 `/relay-api` 再加 `/app/` —— 与插件半的 DEFAULT_APP_URL 同一约定
  * (https://host:port/relay-api → https://host:port/app/)。
  */
 function wechatAppUrl() {
@@ -1691,7 +1691,7 @@ function startWeChat() {
       relayDir,
       // 传**取值器**而不是当次的值（0.7.0-beta.2 修复）。
       //
-      // 【2026-10-09 真机事故】这里以前传的是 `UPSTREAM` 这个**当次快照**：bridge 起来时宿主还在
+      // 【2026-10-09 真机故障】这里以前传的是 `UPSTREAM` 这个**当次快照**：bridge 起来时宿主还在
       //   3080，随后宿主换了端口（Desktop 每次启动随机），隧道转发侧因为每次读最新 UPSTREAM 而
       //   一切正常，**唯独微信事件通道抱着 3080 死循环重连** —— 现象极具迷惑性：手机能开页面、
       //   bridge-status 显示 online，但任务跑完**一条推送都没有**，日志里只有刷屏的
@@ -1770,7 +1770,7 @@ async function runTunnel() {
 /**
  * 给 stdout/stderr 的每一行加 ISO 时间戳。
  *
- * 【2026-09-25 事故】bridge 日志**没有任何时间戳**，于是排查
+ * 【2026-09-25 故障】bridge 日志**没有任何时间戳**，于是排查
  * 「任务跑完没收到微信推送」时完全无法把日志和事件对上时间：
  * 不知道最后一条 `sendmessage 失败` 发生在用户的回话之前还是之后，
  * 最后只能靠"数行数 ÷ 每分钟行数"去估时间（估出来的结论还差点搞反方向）。

package/packages/dsh-remote-web/runtime/clients/dsh-remote/dsh-events.mjs

@@ -45,7 +45,7 @@
  *     （裸 id → `session/agent-busy`，说明找到了；`session-<uuid>` → `session/not-found`，说明不存在）。
  *     规格 §4 那句「必须用持久 session-<uuid>，裸 uuid 会 not-found」只在根会话上成立。
  *     本模块主形式原样发送，另一种形式只在 `session/not-found` 时兜底各试一次（见 `sessionIdCandidates`）。
- *   - `api-session/*` 的口径（真机逐帧核对）：`status` = `[sessionId, running]`（**边沿**事件）、
+ *   - `api-session/*` 的约定（真机逐帧核对）：`status` = `[sessionId, running]`（**边沿**事件）、
  *     `error` = `[id, message]`、`activity` = `[sessionId, epochMs]`、`removed` = `[sessionId]`、
  *     `added` = `[summary]`，summary 字段 `sessionId/updatedAt/running/blank/parentSessionId/origin/cwd/projections`。
  *   - `turn/end.reason.kind` 闭集：completed|aborted|blocked|error|max-tokens|interrupted
@@ -88,7 +88,7 @@
  *     缓存只用于「list 失败」时兜底）；两处都拿不到就**显式失败** `through-seq-unavailable`，
  *     绝不猜一个魔法数字。
  *     ⚠️ 不用描述符允许的 `throughSeq: -1`：history.js `paginate()` 会把它算成
- *        `end = min(-1+1, …) = 0` → 返回**空页**（不是「最新一页」）。口径为负，故不采用。
+ *        `end = min(-1+1, …) = 0` → 返回**空页**（不是「最新一页」）。约定为负，故不采用。
  *
  *   助手结论文本的真实形状（`session/page` → `value.records[]`）
  *     `record = {type:'event', event:{type,seq,time,data}}`；助手消息是 `event.type === 'assistant/message'`，
@@ -1012,7 +1012,7 @@ class EventSubscriber extends EventEmitter {
         //   旧行为是失败即 `#followBlocked.add()`，此后**本代**（直到 mux 重连）再也不订阅它 ——
         //   而「这一轮又跑起来了」（status:true）恰恰是重新订阅的正当理由。
         //   不清掉的话：一次 `session/agent-busy`/`session/not-found` 抖动 = 该会话这一整轮的
-        //   turn/end 全部丢失 = 完成推送静默消失（与上面定时任务那个自我关停是同一类事故）。
+        //   turn/end 全部丢失 = 完成推送静默消失（与上面定时任务那个自我关停是同一类故障）。
         //   重试天然有界：一次 running 边沿最多触发一次重新订阅，不会打转。
         this.#followBlocked.delete(sessionId);
         this.#ensureFollow(sessionId);
@@ -1156,14 +1156,14 @@ class EventSubscriber extends EventEmitter {
     const timer = setTimeout(() => {
       this.#discoverTimer = null;
       if (this.#closed || this.#state !== "ready") return;
-      // ★ 2026-09-25 事故修复：这里原本写成 `if (this.#follows.size > 0)`，注释是
+      // ★ 2026-09-25 故障修复：这里原本写成 `if (this.#follows.size > 0)`，注释是
       //   「没有 follow 流就没有可对账的东西（每代至少发现过一次）」。
       //   它漏掉了这条定时任务的**另一半职责：发现**。丢一次边沿事件（mux 重连、status:true
       //   早于我们订阅、帧被丢）就会让 `#follows` 长期为 0，而这条任务又因为「0 个流」把自己关掉
       //   → **从此再也不发现任何会话** → 该会话的 turn/end 永远收不到 → 完成推送**静默消失**。
       //
-      //   真机现场（业主本人，2026-09-25）：任务跑完一条微信都没收到，bridge 日志里也
-      //   **没有任何报错**（因为确实什么都没发生）。活体探针（以微信通道同款方式订阅本机）显示：
+      //   真机现场（用户本人，2026-09-25）：任务跑完一条微信都没收到，bridge 日志里也
+      //   **没有任何报错**（因为确实什么都没发生）。活体探测（以微信通道同款方式订阅本机）显示：
       //     · 新起的订阅器 **163ms** 就发现并 follow 了正在跑的会话 —— 机制本身是好的；
       //     · 而当时在跑的 bridge 进程到 3080 只有 **2 条** WS（mux + control）、**没有 follow 流**，
       //       可它明明有一个正在跑长任务的会话 —— 正是这里的自我关停把发现能力锁死了。

package/packages/dsh-remote-web/runtime/clients/dsh-remote/e2ee-client.mjs

@@ -22,7 +22,7 @@
  *        http 请求   "dsh-e2ee/v1\0http\0<reqNonceB64>\0p2b"(reqNonce=请求信封 n)
  *        http 响应   "…\0http\0<reqNonceB64>\0b2p"(响应信封 n 回显请求 n)
  *        ws 流       "…\0ws\0<wsLabel>\0p2b|b2p"(wsLabel 见 parseWsE2eeParams)
- *        ctrl 探针   "…\0ctrl\0p2b|b2p"
+ *        ctrl 探测   "…\0ctrl\0p2b|b2p"
  *   4. AAD = UTF8("dsh-e2ee/v1\0<kind>\0<sessId>\0<dir>\0<counter>")。
  *      [偏差] 评审稿 §4.3 建议把路径摘要也放进 AAD,但因解密方在打开前并不知道
  *      明文里的路径(循环依赖),v1 规范化 AAD 不含路径;模块保留 extra 参数供后续绑定。
@@ -247,7 +247,7 @@ export class E2eeSession {
     this.saltH = saltH;
     this.profile = profile;
     this.epoch = epoch;
-    this.verified = false; // 探针通过前不接受任何数据流/请求
+    this.verified = false; // 探测通过前不接受任何数据流/请求
     this.createdAt = Date.now();
     this.usedAt = this.createdAt;
   }
@@ -681,7 +681,7 @@ export class E2eeService {
    * dsh_token cookie 完成「同账号」授权(device/channel 形态都只到本设备)——
    * 信任模型见 docs/e2ee-protocol.md §5.4 [DECISION]:引导瞬间以「持有效扫码会话=账号本人」
    * 为准,存在被中继主动冒充的理论窗口(与扫码登录产品一致);引导后数据面照常走
-   * hello/probe 探针(双方已同持 MK)与 AEAD 信封。
+   * hello/probe 探测(双方已同持 MK)与 AEAD 信封。
    * @returns {{mk:string, profile:string, epoch:number}}
    */
   introGrant() {
@@ -765,15 +765,15 @@ export class E2eeService {
   handleProbe(sessId, env) {
     const session = this.sessionOf(sessId);
     if (!session) throw new E2eeError("unknown_session", "e2ee: 会话不存在或已过期(请重新解锁)");
-    // 先解密成功再推进计数:失败的尝试(密钥不符)不得消耗合法探针的计数
+    // 先解密成功再推进计数:失败的尝试(密钥不符)不得消耗合法探测的计数
     const opened = session.open({ kind: "ctrl", dir: DIR_P2B, env, counter: env?.c ?? 0, reqNonceB64: env?.n });
     let pt;
     try {
       pt = JSON.parse(opened.data.toString("utf8"));
     } catch {
-      throw new E2eeError("bad_key", "e2ee: 探针明文非法(密钥不一致?)");
+      throw new E2eeError("bad_key", "e2ee: 探测明文非法(密钥不一致?)");
     }
-    if (pt?.p !== "dsh-e2ee-probe-v1") throw new E2eeError("bad_key", "e2ee: 探针载荷不符");
+    if (pt?.p !== "dsh-e2ee-probe-v1") throw new E2eeError("bad_key", "e2ee: 探测载荷不符");
     const guards = this.ctrlCounters.get(sessId) || { p2b: new SequenceGuard(), b2p: new SequenceGuard() };
     guards.p2b.check(Number(env?.c) || 0); // 成功后推进,后续重放被拒
     session.verified = true;
@@ -791,7 +791,7 @@ export class E2eeService {
   guardHttpRequest(sessId, env) {
     const session = this.sessionOf(sessId);
     if (!session) throw new E2eeError("unknown_session", "e2ee: 会话不存在或已过期(请重新解锁)");
-    if (!session.verified) throw new E2eeError("not_verified", "e2ee: 会话未完成探针校验");
+    if (!session.verified) throw new E2eeError("not_verified", "e2ee: 会话未完成探测校验");
     if (!this.httpNonces.check(sessId, env.n)) throw new E2eeError("replay", "e2ee: HTTP 信封 nonce 重放");
     return session;
   }