dsh-mobile-plugin 0.4.0 → 0.4.4

package/lib/mobile/inbox-clean.js

@@ -3,31 +3,14 @@
 /**
  * 收件目录（`~/.dsh/mobile-inbox`）的占用统计与按龄清理。
  *
- * 手机分享进来的文件由 `uploads.js` 落到 `<收件根>/<日期>/<消毒名>`，那条通道**只进不出**：
- * 它在盘上只认文件名，不认识会话、也不认识工作区，所以没有任何「删掉这条对话就顺带清掉
- * 它传上来的文件」可言 —— 唯一的引用是会话日志正文里那句 `@路径`，那是文本，宿主不会
- * 跟着它去回收。不设一个出口，这个目录只会按天堆下去。
+ * 手机分享进来的文件由 `uploads.js` 落到 `<收件根>/<日期>/<消毒名>`，那条通道只进不出：盘上
+ * 只认文件名，不认识会话，会话日志里的 `@路径` 也不会触发回收。不设出口，目录只会按天堆。
  *
- * 因此这里的口径是**按龄**：只删 mtime 超过 `keepMs`（24 小时）的文件。
+ * 口径是按龄：只删 mtime 超过 24 小时的文件。按文件而不是按日期目录删，才和「放满一天」这个
+ * 承诺一致；今天传的文件不在范围内，正在跑的那一回合碰不到它。空出来的日期目录顺手删掉。
  *
- * 为什么是文件而不是日期目录：目录按「上传那天的本地日期」分堆，整段删会把昨天 23:50
- * 传的、才过 20 分钟的文件一起带走；按每个文件自己的 mtime 判才和「放满一天」这个承诺
- * 一致。空出来的日期目录顺手删掉。
- *
- * 为什么留着 24 小时而不是立刻删：助手拿到路径之后可能在同一个回合里反复读它，用户也可能
- * 隔一晚上让助手接着看同一份文件。今天传的文件一开始就不在清理范围内，正在跑的那一回合
- * 因此碰不到这里。
- *
- * 与 `session-cleanup.cjs` 的取舍刻意不同：那边进程活着时一条日志都不删（宿主随时可能去
- * 打开，ENOENT 会带走整个进程）；这里删的是收件目录里的普通文件，宿主只在助手明确要读
- * 某个路径时才碰它，而那个路径只有在 24 小时窗口内才可能还有人要。
- *
- * ## 自动清理是开关，默认关（2026-10-21 用户定）
- *
- * 启动时那次自动清理**只有开关打开才跑**；面板上那颗按钮永远可用（那是用户自己按的，
- * 不需要开关授权）。开关落盘在 `<DSH_HOME>/storages/mobile-plugin/inbox-auto-clear.json`，
- * 与自动更新开关同一套写法（读不到 / 读坏了都当关）—— 自动删盘这种事，缺省必须在用户
- * 这一侧，而不是「装了就替你删」。
+ * 自动清理是开关、默认关：启动时那次只有开关打开才跑，面板上的按钮永远可用。开关落盘在
+ * `<DSH_HOME>/storages/mobile-plugin/inbox-auto-clear.json`，读不到或读坏都当关。
  */
 
 const fs = require('node:fs');
@@ -241,7 +224,7 @@ function usageView(scan) {
     keepHours: Math.round(scan.keepMs / (60 * 60 * 1000)),
     /**
      * 自动清理开着没有。两个界面都靠它画那颗开关 —— 不自己猜、也不各自存一份，
-     * 真值只在这台机器的 json 里。**默认 false**（用户 2026-10-21 定）。
+     * 真值只在这台机器的 json 里。**默认 false**。
      */
     autoClear: autoClearEnabled(),
   };

package/lib/mobile/local-images.js

@@ -1,25 +1,20 @@
 'use strict';
 
 /**
- * 正文图片内联：把消息文本里指向**本机文件**的图片语法（`![](/abs/path.png)`）换成 data URI，
- * 让手机端能直接把它画出来。
+ * 正文图片内联：把消息文本里指向本机文件的图片语法（`![](/abs/path.png)`）换成 data URI，
+ * 让手机端能直接画出来。
  *
- * 为什么只能在这里换：手机拿到的只是文本，`/Users/…/a.png` 既不是手机上的文件，移动 API 也
- * 没有「按路径读文件」的能力面（见 host-bridge-endpoints 守卫的 forbidden 表），所以地址原样
- * 过去只会显示成一串字面 markdown。会话里用户自己发的图片本来就是内联形状（宿主把附件解成
- * base64，见 attachments.js 与 App 侧 chat.ts 的 images[]），这里只是把「正文里写的本机图片」
- * 拉齐到同一种形状，App 侧因此不需要新增任何通道或依赖。
+ * 手机拿到的只是文本，`/Users/…/a.png` 既不是手机上的文件，移动 API 也没有「按路径读文件」
+ * 的能力面，原样过去只会显示成一串字面 markdown。这里把「正文里写的本机图片」拉齐到附件那种
+ * 内联形状，App 不需要新增通道。
  *
- * 保守取舍（宁可保留原样的字面 markdown，也不给个半截东西）：
- * - 只认能解析成**绝对路径**的地址：`/x/y.png`、`file:///x/y.png`、`~/y.png`；
- *   http(s)、`data:`、`www.`、相对路径一律不碰。
- * - 只认 png/jpg/jpeg/webp/gif（与 app/src/services/viewmodels/image-limits.ts 的 mediaTypes
- *   同白名单），并且**核对魔术字节**：字节不是图片就放弃，绝不按扩展名撒谎。
- * - 三级体积预算（单图 / 单段文本 / 单次响应，见下方常量）：超预算的图保持字面 markdown，
- *   不截断、不缩水成半张图。
- * - 读不到、不是普通文件、读取失败：原样保留 —— 一条图片取不到不能让整段历史或整帧 SSE 挂掉。
- * - 围栏代码块与行内代码里的图片语法一律不碰：那是**写法示例**，不是要画的图；换掉会把
- *   三行代码变成几十万字符的 base64，App 的代码块会铺成很长很长的一块。
+ * 保守取舍——宁可保留字面 markdown，也不给半截东西：
+ * - 本机路径认三种：绝对（`/x/y.png`、`file:///x/y.png`）、`~/y.png`、相对（`deliverables/a.png`，
+ *   按调用方给的工作区目录解析，与桌面端同口径；没给目录就当成不是本机图）；http(s)、`data:` 不碰；
+ * - 只认 png/jpg/jpeg/webp/gif，并核对魔术字节，不按扩展名撒谎；
+ * - 三级体积预算（单图 / 单段 / 单次响应），超预算就保持字面；
+ * - 读不到、不是普通文件、读取失败一律原样保留；
+ * - 围栏代码块与行内代码里的图片语法不碰，那是写法示例。
  */
 
 const fs = require('node:fs/promises');
@@ -69,10 +64,13 @@ function sniffMediaType(buf) {
 }
 
 /**
- * `![](…)` 里的地址 → 本机绝对路径；不是本机图片（远程、data、相对路径、非图片后缀）返回 null。
+ * `![](…)` 里的地址 → 本机路径；不是本机图片（远程、data、非图片后缀）返回 null。
  * 尖括号包裹的目的地（CommonMark 允许 `![](</abs/a.png>)`）在这里一并剥掉。
+ *
+ * 相对地址（`deliverables/a.png`、`./a.png`）按 `cwd` 解析——那是会话的工作区目录，也是
+ * 桌面端画正文图的基准；没给 `cwd` 时相对地址照样返回 null（老口径：保持字面 markdown）。
  */
-function localImagePathOf(url) {
+function localImagePathOf(url, cwd) {
   if (typeof url !== 'string') return null;
   let value = url.trim();
   if (!value) return null;
@@ -88,12 +86,39 @@ function localImagePathOf(url) {
   } else if (value === '~' || value.startsWith('~/')) {
     value = path.join(os.homedir(), value.slice(1));
   }
-  if (!path.isAbsolute(value)) return null;
+  if (!path.isAbsolute(value)) {
+    if (!cwd) return null;
+    value = path.resolve(cwd, value);
+  }
   if (!mediaTypeFor(value)) return null;
   return path.normalize(value);
 }
 
-/** 一次响应共用的内联预算；不给就按单次调用算一份。 */
+/**
+ * 正文里有没有「相对地址」的本机图片语法。
+ *
+ * 只有这种文本才值得去取会话的工作区目录（`sessions.list` 要扫一遍全部会话），
+ * 其余情况一条会话列表都不查：绝对路径照常内联，相对地址原样留着。
+ */
+function hasRelativeImage(text) {
+  if (typeof text !== 'string' || text.indexOf('![') < 0) return false;
+  for (const m of text.matchAll(IMAGE_RE)) {
+    let dest = m[2].trim();
+    if (dest.startsWith('<') && dest.endsWith('>')) dest = dest.slice(1, -1).trim();
+    if (!dest || path.isAbsolute(dest)) continue;
+    if (dest === '~' || dest.startsWith('~/')) continue;
+    if (/^[a-z][a-z0-9+.-]*:/i.test(dest)) continue;
+    if (mediaTypeFor(dest)) return true;
+  }
+  return false;
+}
+
+/**
+ * 一次响应共用的内联预算；不给就按单次调用算一份。
+ *
+ * `cwd` 由调用方按需补上（相对地址的解析基准，见 localImagePathOf）：`undefined` 表示
+ * 「还没查过工作区目录」，空串表示「查过了，这条会话没有」。
+ */
 function createTextImageBudget(limit = MAX_RESPONSE_CHARS) {
   return { remaining: limit };
 }
@@ -221,7 +246,7 @@ async function inlineTextImages(text, budget) {
   let cursor = 0;
   for (const m of matches) {
     if (textBudget <= 0 || pool.remaining <= 0) break;
-    const filePath = localImagePathOf(m[2]);
+    const filePath = localImagePathOf(m[2], pool.cwd);
     if (!filePath) continue;
     const uri = await dataUriFor(filePath);
     if (!uri || uri.length > textBudget || uri.length > pool.remaining) continue;
@@ -233,4 +258,4 @@ async function inlineTextImages(text, budget) {
   return cursor === 0 ? text : out + text.slice(cursor);
 }
 
-module.exports = { inlineTextImages, createTextImageBudget, localImagePathOf };
+module.exports = { inlineTextImages, createTextImageBudget, localImagePathOf, hasRelativeImage };

package/lib/mobile/model-vendors.js

@@ -0,0 +1,105 @@
+'use strict';
+
+/**
+ * 模型 → 厂商的识别，以及厂商图标（`vendor-logos.cjs` 那张表）的取用。
+ *
+ * 为什么需要猜：宿主只给「渠道 id + 模型 id」，没有厂商这一栏，而同一个模型在不同渠道下写法
+ * 各不相同 —— `deepseek-v4.1-flash`、`DeepSeek V4.1 flash`、`deepseek_v4_1_flash` 都是同一个
+ * 东西；有些渠道还把模型名整个改掉（`route-model-a`）。所以先规范化（小写、去掉所有分隔符），
+ * 再按关键词认；模型名认不出时再看渠道名（`anthropic`、`moonshotai` 这类渠道 id 往往就是厂商）。
+ *
+ * 认不出来的就**不猜**：宁可那一行退回首字母徽标，也不要给一个错的品牌 —— 厂商名是用户用来
+ * 认模型的，猜错比空着更糟。这条与「取不到就整块不出」是同一个口径。
+ *
+ * 纯函数、不碰网络也不碰文件，守卫直接跑真实现。
+ */
+
+const { VENDOR_LOGOS } = require('./vendor-logos.cjs');
+
+/**
+ * 规范化：小写、只留字母与数字（汉字保留 —— 国产模型的别名经常是中文）。
+ *
+ * 去掉分隔符是关键：`v4.1` / `v4-1` / `v4_1` 都应该落到同一个串上，否则每种写法都要单独列一条。
+ */
+function foldText(value) {
+  return typeof value === 'string' ? value.toLowerCase().replace(/[^\p{L}\p{N}]+/gu, '') : '';
+}
+
+/** 按非字母数字切开的小写片段：给「o3」「phi」这种两三个字符的短词用（它们不能按子串认）。 */
+function tokensOf(value) {
+  return typeof value === 'string'
+    ? value.toLowerCase().split(/[^\p{L}\p{N}]+/u).filter(Boolean)
+    : [];
+}
+
+/**
+ * 认法表。匹配顺序就是优先级，长关键词在前。
+ *
+ * `terms` 在规范化后的串上按子串认（`deepseekv41flash` 里含 `deepseek`）；
+ * `tokens` 按切开后的整段认（`o3-mini` 的 `o3`、`phi-4` 的 `phi`）—— 短词按子串认会把
+ * 一堆无关模型认成同一家。
+ */
+const VENDOR_PATTERNS = [
+  ['deepseek', { terms: ['deepseek', '深度求索', '深度探索'] }],
+  ['anthropic', { terms: ['claude', 'anthropic', 'sonnet', 'opus', 'haiku'] }],
+  ['openai', { terms: ['openai', 'chatgpt', 'gpt', 'codex', 'davinci', 'omni'], tokens: ['o1', 'o3', 'o4'] }],
+  ['google', { terms: ['gemini', 'gemma', 'google', 'vertex', 'bard'] }],
+  ['alibaba', { terms: ['qwen', 'qwq', 'tongyi', 'alibaba', '通义', '千问', '阿里'] }],
+  ['moonshot', { terms: ['kimi', 'moonshot', '月之暗面'] }],
+  ['zhipu', { terms: ['glm', 'chatglm', 'zhipu', '智谱', '清言'] }],
+  ['meta', { terms: ['llama', 'meta'] }],
+  ['mistral', { terms: ['mistral', 'mixtral', 'codestral', 'devstral', 'magistral'] }],
+  ['xai', { terms: ['grok', 'xai'] }],
+  ['cohere', { terms: ['cohere', 'commandr'] }],
+  ['bytedance', { terms: ['doubao', 'bytedance', 'seed', '豆包', '火山'] }],
+  ['baidu', { terms: ['ernie', 'wenxin', 'baidu', '文心', '百度'] }],
+  ['tencent', { terms: ['hunyuan', 'tencent', '混元', '腾讯'] }],
+  ['minimax', { terms: ['minimax', 'abab', '海螺'] }],
+  ['nvidia', { terms: ['nemotron', 'nvidia', '英伟达'] }],
+  ['microsoft', { terms: ['microsoft', 'azure'], tokens: ['phi', 'phi3', 'phi4', 'phi35'] }],
+];
+
+/** 一段文字认哪家；认不出返回空串。 */
+function vendorOfText(value) {
+  const folded = foldText(value);
+  if (!folded) return '';
+  for (const [vendor, rule] of VENDOR_PATTERNS) {
+    if (rule.terms && rule.terms.some((term) => folded.includes(term))) return vendor;
+  }
+  const tokens = tokensOf(value);
+  if (tokens.length > 0) {
+    for (const [vendor, rule] of VENDOR_PATTERNS) {
+      if (rule.tokens && rule.tokens.some((token) => tokens.includes(token))) return vendor;
+    }
+  }
+  return '';
+}
+
+/**
+ * 一条模型用量认哪家：先看模型名 / 模型 id，再看渠道名 / 渠道 id。
+ *
+ * 顺序有意如此 —— 渠道可以挂着任何模型（自建渠道尤其如此），名字写对了就以名字为准；
+ * 只有名字认不出来时才用渠道兜底，这也是很多网关渠道的实际情况（渠道叫 `anthropic`、
+ * 模型名是它自己起的别名）。
+ *
+ * 返回的是**认出来的那一家**，跟它有没有图标无关：有一家（比如 GLM / Grok）暂时没有图标，
+ * 这一行就该退回首字母徽标，而不是接着往下试渠道名 —— 那样「模型名认出 A、渠道名像 B」时会
+ * 认成 B，摆上别家的 logo。认错厂商比不认更糟，这一条是硬规矩。
+ */
+function identifyVendor(entry) {
+  if (!entry || typeof entry !== 'object') return '';
+  const candidates = [entry.modelName, entry.model, entry.providerName, entry.provider];
+  for (const candidate of candidates) {
+    const vendor = vendorOfText(candidate);
+    if (vendor) return vendor;
+  }
+  return '';
+}
+
+/** 厂商的展示名与图标标记；不在表里返回 null。 */
+function vendorLogoOf(vendor) {
+  const entry = VENDOR_LOGOS[vendor];
+  return entry ? { name: entry.name, icon: entry.icon } : null;
+}
+
+module.exports = { foldText, tokensOf, vendorOfText, identifyVendor, vendorLogoOf, VENDOR_PATTERNS };

package/lib/mobile/monitor.js

@@ -3,22 +3,14 @@
 /**
  * GET /api/mobile/v1/monitor —— 安卓后台提醒服务专用的「状态位」视图（只读）。
  *
- * 为什么单开一条：那条前台服务活在 JS 之外（App 退到后台、进程被系统回收，只有它还在），
- * 所以「这一轮跑完了 / 跑挂了 / 停下来等你回话」只能由它自己定时去问。它此前问的是完整
- * 会话清单（`?fresh=1`），而那份清单为了画侧栏还捎着**最后一条消息预览** —— 预览要为最近
- * 20 个会话各读一次 history。后台每 8 秒白读 20 次日志，只为判断「completed 翻没翻」。
+ * 那条前台服务活在 JS 之外，只能自己定时来问「这一轮跑完了 / 跑挂了 / 停下来等你回话」。
+ * 它此前问完整清单，而清单为了画侧栏还捎着最后一条消息预览，后台每 8 秒白读 20 次 history。
  *
- * 这条只回监控需要的那几格：在不在跑、刚完成没有、在等谁回话、上一轮是不是跑挂的、标题。
- * 并支持 `?rev=` 条件刷新：状态位与上次一模一样时回一句 `unchanged`，连 items 都不带
- * （稳态下这一发是几十字节）。再带上 `?wait=秒` 时，条件刷新的那一发**先挂住**，等状态位
- * 真的变了才回 —— 安卓后台服务靠它把「定时去问」变成「一有变化立刻送到」。
+ * 这条只回监控需要的那几格，支持 `?rev=` 条件刷新（状态位没变就回 unchanged）与 `?wait=秒`
+ * （条件不满足时先挂住，真变了才回），让安卓服务不必轮询。完成态仍以 completion 状态机为准，
+ * 常态下不读 history，只有「跑过、不在跑、结局还没定」的那几条才读一次。
  *
- * 完成态仍以 completion 状态机为准，与 `/sessions` 用同一本账：常态下这里**不读 history**，
- * 只有「跑过、现在不在跑、结局还没定」的那几条才读一次 —— 那是唯一能把 failedTurn 折出来
- * 的地方（事件流漏帧时全靠它，见 completion.js 的坑）。
- *
- * 刻意不进 `/sessions`：那边一旦按调用方分叉视图，镜像推送与 App 的写后刷新也会跟着
- * 受影响，而这两条都要求「一份完整清单」。分路由比加参数安全。
+ * 刻意不进 `/sessions`：那边一旦按调用方分叉视图，镜像推送与写后刷新都会受影响。
  */
 
 const { sendJson } = require('../shared/http-util');
@@ -50,8 +42,7 @@ function monitorItem(summary, state, fact) {
   // 为什么：那个按设备记账的完成态要靠「这一次真的读回了 history」才折得出来，而
   // 「刚跑完」那一刻宿主的镜像推送早把同一份预览按新指纹写进缓存了 —— 监控这一侧
   // 拿到的是缓存命中（events 为空）、永远折不出来，`completed` 就一直 false，后台
-  // 一条提醒都不会响（2026-10-25 真机：宿主日志里全是「preview cache-hit」）。
-  // 事实那本账由 turn/end 事件当场记下，不依赖预览缓存，所以拿它判完成。
+  // 一条提醒都不会响。事实那本账由 turn/end 事件当场记下，不依赖预览缓存。
   //
   // 已读水位仍然生效：这一轮结束在「这台手机读过」之前就不算提醒。
   const clearedAt = typeof state?.clearedAt === 'number' ? state.clearedAt : null;
@@ -103,7 +94,7 @@ async function buildMonitorState(ctx, deviceKey) {
   const deleted = deletedSessionIdsOf(ctx);
   const { archived } = await workspaceSessionFlags(ctx);
   // 子代理会话不参与后台提醒：它们是主轮内部的执行单元，App 侧栏也不列；把它们算进来
-  // 会在后台弹一堆「子代理跑完了」（2026-10-26 真机日志里四十多个 UUID 会话都是这种）。
+  // 会在后台弹一堆「子代理跑完了」。
   const live = summaries.filter((s) => s && typeof s.sessionId === 'string' && s.sessionId
     && s.origin !== 'subagent'
     && !deleted.has(s.sessionId) && !archived.has(s.sessionId));

package/lib/mobile/pairing.js

@@ -3,27 +3,15 @@
 /**
  * 移动端配对：手机在中转上用自己的配对码换到 token 与设备凭据。
  *
- * **这条路由归宿主，不归中转。**「谁可以进这台机器」是宿主自己的判断，配对码本来就存在
- * 宿主的 `state` 里；中转只按实例标识把请求转过来。早先这套判断长在独立的中转进程里
- * （`dsh-mobile-server/server.js` 的 `/pair`），换成 Rust 中转时整块没搬过去，于是手机
- * 按老地址 POST `/pair`、请求被中转原样转给宿主、宿主没有这条路由，只能回 405。
+ * 这条路由归宿主、不归中转：「谁可以进这台机器」是宿主自己的判断，配对码存在宿主的 state
+ * 里，中转只按实例标识把请求转过来。
  *
- * 与局域网那条（`lib/relay/lan-proxy.js` 的 `/__lan_pair`）是**同一件事的两个入口**：
- * 都是「配对码 / 票据 → 签发凭据」，差别只在网络路径。凭据本身两条路签发的是同一种 HMAC
- * （都用宿主 lanSecret 签名），所以经中转配对拿到的 token 可以直接用于局域网请求。
+ * 与局域网那条（`lib/relay/lan-proxy.js` 的 `/__lan_pair`）是同一件事的两个入口，签发的
+ * 是同一种 HMAC（都用宿主 lanSecret 签名），所以经中转配对拿到的 token 也能用于局域网请求。
  *
- * 请求体**两种形状都认**：
- *   老形状  `{ instanceId?, code, device }`   —— 旧 App，明文，一字不改地照旧处理；
- *   新形状  `{ instanceId, sealed }`          —— 协议 v2，`sealed` 是用二维码票据派生的
- *                                                密钥封的，解出来是设备主密钥与设备信息。
- * 新形状里**没有配对码**：票据本身就是资格证明。回包同样是密文 —— 里面是 token / cookie /
- * 设备凭据，明文回包等于让中转顺手拿到这台设备未来一年的通行证。
- *
- * 故意**不**在这里做的事：
- *  - 不问宿主再确认一次。宿主的配对策略（pairingPolicy）已经决定了它接不接受新设备，
- *    `deny` 时中转根本连不上；而这条路由本身就跑在宿主进程里。
- *  - 不做「多台机器撞同一个配对码」的处理。那是中转的职责（它才看得见全部实例），
- *    在这台宿主上，配对码要么对上要么对不上。
+ * 请求体两种形状都认：老 App 的 `{ instanceId?, code, device }` 明文照旧；协议 v2 的
+ * `{ instanceId, sealed }` 没有配对码，票据本身就是资格证明，回包同样是密文 —— 里面是
+ * token / cookie / 设备凭据，明文回包等于让中转拿到这台设备的长期通行证。
  */
 
 const { sendJson } = require('../shared/http-util');