dsh-mobile-plugin 0.4.0 → 0.4.4

package/lib/mobile/history-derive.js

@@ -6,8 +6,13 @@
  * 本模块只做「事件 → 展示结构」的纯计算，不碰 ctx、不发 RPC，因此可以单独测；
  * 原先这些函数与路由 handler 混在 lib/mobile/sessions.js 里（该文件 1964 行），
  * 拆出来后 handler 层只负责 HTTP 与宿主交互。
+ *
+ * 「什么不下发手机」（推理 / 工具参数 / 工具结果正文与 diff）的唯一规则在 `wire-cut.js`，
+ * 这里只负责把留下的事件折成消息结构 —— 直播间那条路调的是同一份。
  */
 
+const { cutAssistantBlock, cutToolResultEvent, createToolNameIndex } = require('./wire-cut.js');
+
 /**
  * 从 session.list 摘要行取会话标题（与桌面端侧栏同源，不再从 history 窗口猜）：
  *  - 优先读 title 投影（dsh-session-title 在「完整日志」上折叠的最新 session/title
@@ -27,58 +32,6 @@ function listTitle(s) {
   return s.sessionId || '';
 }
 
-/** 单文件一行文本的传输上限：整文件 create/overwrite 的 newText 可能极大，超出即截断并标记。 */
-const DIFF_TEXT_MAX_LINES = 400;
-/** 一次工具调用最多回传的 diff 文件数（对齐桌面「一行一张卡」的粒度，避免畸形 meta 撑爆载荷）。 */
-const DIFF_MAX_FILES = 20;
-
-/** 按行数截断一段 diff 文本；未超限原样返回，超限保留前 MAX 行并标记 truncated。 */
-function capDiffText(text) {
-  if (typeof text !== 'string') return undefined;
-  let lines = 0;
-  for (let i = 0; i < text.length; i += 1) {
-    if (text.charCodeAt(i) === 10) lines += 1;
-    if (lines >= DIFF_TEXT_MAX_LINES) {
-      return { text: text.slice(0, i), truncated: true };
-    }
-  }
-  return { text, truncated: false };
-}
-
-/**
- * 收窄 tool/result 的 `data.meta`（write/edit 的 FsDiffMeta）为可回传的 diff 列表。
- *
- * 桌面 diff 卡的数据源头就是这里：fs 工具把「已应用的分块上下文 diff」挂在
- * `result.meta` 上（dsh-tool-fs 的 computeHunkDiffs，DIFF_CONTEXT=3），
- * agent loop 原样写进 tool/result 事件（dsh-agent-loop/lib/index.js:313
- * `...result.meta !== void 0 ? { meta: result.meta } : {}`），并随会话日志持久化。
- * 此前移动端投影只读 message.content，把 meta 整个丢掉——于是 App 里 write/edit
- * 只剩一坨 JSON 参数，而桌面显示的是真正改了什么。
- *
- * 只接受形状正确的条目（path 非空字符串、newText 字符串、oldText 字符串或 null），
- * 畸形数据返回 undefined 让调用方退回通用卡片，绝不抛错。
- */
-function normalizeResultDiffs(meta) {
-  if (!meta || typeof meta !== 'object' || !Array.isArray(meta.diffs)) return undefined;
-  const out = [];
-  for (const raw of meta.diffs) {
-    if (!raw || typeof raw !== 'object') continue;
-    const path = typeof raw.path === 'string' && raw.path !== '' ? raw.path : undefined;
-    const newText = capDiffText(raw.newText);
-    if (path === undefined || newText === undefined) continue;
-    const oldText = typeof raw.oldText === 'string' ? capDiffText(raw.oldText) : undefined;
-    if (raw.oldText !== null && raw.oldText !== undefined && typeof raw.oldText !== 'string') continue;
-    out.push({
-      path,
-      oldText: oldText === undefined ? null : oldText.text,
-      newText: newText.text,
-      ...newText.truncated || (oldText && oldText.truncated) ? { truncated: true } : {},
-    });
-    if (out.length >= DIFF_MAX_FILES) break;
-  }
-  return out.length > 0 ? out : undefined;
-}
-
 /**
  * tool/result 的可见内容：两种形状都认。
  *
@@ -139,25 +92,32 @@ function toolResultImages(parts) {
   return out;
 }
 
-/** 预扫描 tool/result 事件，构建 callId → {isError, code} 映射（对接桌面 toolRowModel 状态派生）。 */
+/**
+ * 预扫描 tool/result 事件，构建 callId → 状态/图片 映射（对接桌面 toolRowModel 状态派生）。
+ *
+ * 每条结果先过 `wire-cut.js`：正文与结果上的 `meta`（已应用 diff）都不下发，只留状态与图片，
+ * 正文只给定时任务卡要解析的 `schedule_create` 留着。工具名从同一批事件里攒
+ * （`tool/call`、assistant 的 tool-call 块），攒不到就按「不留正文」处理。
+ */
 function buildToolResultMap(events) {
   const map = new Map();
+  const toolNames = createToolNameIndex();
+  toolNames.absorbAll(events);
   for (const entry of events) {
     const e = entry.event || entry;
     if (e.type !== 'tool/result' || !e.data || !e.data.message) continue;
     const msg = e.data.message;
     const src = msg.source;
     if (!src || typeof src.callId !== 'string') continue;
-    const { parts, isError } = toolResultParts(msg);
-    const code = e.data.error && typeof e.data.error.code === 'string' ? e.data.error.code : undefined;
-     const output = parts.map((part) => {
-       if (part && typeof part.text === 'string') return part.text;
-       if (part && typeof part === 'object' && part.type === 'image') return '';
-        try { return JSON.stringify(part); } catch { return ''; }
-     }).filter(Boolean).join('');
-     const images = toolResultImages(parts);
-      const diffs = normalizeResultDiffs(e.data.meta);
-      map.set(src.callId, { isError, code, ...(output ? { output } : {}), ...(images.length ? { images } : {}), ...(diffs ? { diffs } : {}) });
+    const kept = cutToolResultEvent(e, toolNames.nameOf(src.callId));
+    const { parts, isError } = toolResultParts(kept.data.message);
+    const code = kept.data.error && typeof kept.data.error.code === 'string' ? kept.data.error.code : undefined;
+    const output = parts.map((part) => {
+      if (part && typeof part.text === 'string') return part.text;
+      return '';
+    }).filter(Boolean).join('');
+    const images = toolResultImages(parts);
+    map.set(src.callId, { isError, code, ...(output ? { output } : {}), ...(images.length ? { images } : {}) });
   }
   return map;
 }
@@ -165,16 +125,14 @@ function buildToolResultMap(events) {
 /**
  * 把整窗工具结果折成客户端补丁（`/session/messages` 顶层的 `toolResults`）。
  *
- * 补丁本身必须取自整个窗口：调用方游标可能已经越过结果 seq，而工具卡还停在 running，
- * 客户端按 callId 幂等打补丁。但**已经随消息块下发的**那份结果不再重复带正文 ——
- * `items` 里的 tool-call 块本来就是同一张表构出来的，输出/图片/diff 再传一遍等于同一份
- * 工具输出在一条响应里走两趟。客户端打补丁时状态照写、正文只在给了的时候才覆盖，所以
+ * 补丁本身必须取自整个窗口：调用方游标可能已经越过结果 seq，而调用块还停在 running，
+ * 客户端按 callId 幂等打补丁。但**已经随消息块下发的**那份结果不再重复带料 ——
+ * `items` 里的 tool-call 块本来就是同一张表构出来的，图片与定时任务卡要的那份正文再传一遍
+ * 等于同一份内容在一条响应里走两趟。客户端打补丁时状态照写、料只在给了的时候才覆盖，所以
  * 那几格省掉是安全的；消息块不在这份窗口里时才带全。
  *
  * `bodies: false`（增量拉取）连「消息块不在这份窗口里」的那些也只回状态。理由是同一个：
- * 增量拉取的调用方手上已经有一份完整的会话，缺的只是「这几次调用结束了没有」；把整窗的
- * 工具输出再灌一遍，等于每 15 秒把最近两百条消息里的工具输出重发一次（读文件、跑命令的
- * 输出几十到几百 KB 很常见）。要全文的那条路是入口整份拉取（无游标）与展开时重新拉。
+ * 增量拉取的调用方手上已经有一份完整的会话，缺的只是「这几次调用结束了没有」。
  */
 function toolResultPatchesFor(events, items, options = {}) {
   const bodies = options.bodies !== false;
@@ -195,24 +153,20 @@ function toolResultPatchesFor(events, items, options = {}) {
       state,
       ...(result.output ? { output: result.output } : {}),
       ...(result.images && result.images.length ? { images: result.images } : {}),
-      ...(result.diffs && result.diffs.length ? { diffs: result.diffs } : {}),
     };
   });
 }
 
-/** 把 assistant message.content 解析为一个结构块数组（text/reasoning/tool-call/image）。 */
+/** 把 assistant message.content 解析为一个结构块数组（text/tool-call/image）。 */
 function parseBlocks(blocks, toolResults) {
   if (!Array.isArray(blocks)) return [];
   const out = [];
-  for (const b of blocks) {
+  for (const raw of blocks) {
+    // 推理不下发、tool-call 收成骨架（三张轮尾卡的工具留 arguments）—— 与直播间同一条规则。
+    const b = cutAssistantBlock(raw);
     if (!b || typeof b.type !== 'string') continue;
     if (b.type === 'text' && typeof b.text === 'string' && b.text) {
       out.push({ type: 'text', text: b.text });
-    } else if (b.type === 'reasoning') {
-      // Reasoning blocks may be emitted as empty placeholders when the provider
-      // does not expose chain-of-thought. They are known blocks, not unsupported
-      // content; silently omit empty placeholders and avoid leaking their JSON.
-      if (typeof b.text === 'string' && b.text) out.push({ type: 'reasoning', text: b.text });
     } else if (b.type === 'image' && b.dataUnavailable === true) {
       // The image attachment resolver marked this block as unavailable. Keep it out of
       // visible text; pushMessage projects its retry metadata onto unavailableImages.
@@ -223,21 +177,18 @@ function parseBlocks(blocks, toolResults) {
       const entry = imageEntryOf(b);
       if (entry) out.push({ type: 'image', ...entry });
     } else if (b.type === 'tool-call') {
-      // tool-call 块字段为 id/name/arguments（与 harness toAssistantBlock 同口径）。
+      // 块已被上面那条规则收过：非白名单工具只剩 `{ id, name }`，所以 argsRaw 只有三张
+      // 轮尾卡的工具才有（App 从它读计划/扩展/定时任务的料）。
       const callId = b.id != null ? String(b.id) : undefined;
       let state;
-       let output;
-       let images;
-       let diffs;
+      let output;
+      let images;
       if (callId && toolResults) {
         const result = toolResults.get(callId);
         if (result) {
           output = result.output;
-           images = result.images;
-           // write/edit 的已应用分块 diff（桌面 diff 卡的数据源）；结果侧权威，
-           // 有它就替换掉仅凭 arguments 猜出来的调用态。
-           diffs = result.diffs;
-           // 对齐桌面 toolRowModel 状态派生：error.code === 'interrupted' → stopped, isError → error, ok
+          images = result.images;
+          // 对齐桌面 toolRowModel 状态派生：error.code === 'interrupted' → stopped, isError → error, ok
           if (result.isError) {
             state = result.code === 'interrupted' ? 'stopped' : 'error';
           } else {
@@ -251,9 +202,8 @@ function parseBlocks(blocks, toolResults) {
         name: typeof b.name === 'string' ? b.name : undefined,
         argsRaw: typeof b.arguments === 'string' ? b.arguments : (b.arguments != null ? JSON.stringify(b.arguments) : undefined),
         ...state ? { state } : {},
-         ...typeof output === 'string' && output ? { output } : {},
-         ...images && images.length ? { images } : {},
-         ...diffs && diffs.length ? { diffs } : {},
+        ...typeof output === 'string' && output ? { output } : {},
+        ...images && images.length ? { images } : {},
       });
     } else {
       // 桌面端对未知 assistant block 使用 JsonBlock 兜底；移动端没有对应组件，
@@ -264,6 +214,31 @@ function parseBlocks(blocks, toolResults) {
   return out;
 }
 
+/**
+ * 一条消息里 write/edit 成功写过的文件路径。
+ *
+ * 参数不下发手机（见 `wire-cut.js`），但「这一轮动过哪些文件」仍要在本机从**原始**块的
+ * `arguments` 里派生出来：App 拿这份清单解析收尾正文里的行内文件引用。
+ */
+function writtenPaths(content, toolResults) {
+  if (!Array.isArray(content)) return [];
+  const out = [];
+  for (const b of content) {
+    if (!b || typeof b !== 'object' || b.type !== 'tool-call') continue;
+    if (b.name !== 'write' && b.name !== 'edit') continue;
+    const callId = b.id != null ? String(b.id) : undefined;
+    const result = callId && toolResults ? toolResults.get(callId) : undefined;
+    if (!result || result.isError) continue;
+    const raw = typeof b.arguments === 'string' ? b.arguments : (b.arguments != null ? JSON.stringify(b.arguments) : '');
+    try {
+      const args = JSON.parse(raw || '{}');
+      const path = typeof args.path === 'string' ? args.path : typeof args.file_path === 'string' ? args.file_path : null;
+      if (typeof path === 'string' && path) out.push(path);
+    } catch { /* 参数不是 JSON：这条调用不算产出，与「没有参数」同处理 */ }
+  }
+  return out;
+}
+
 /** 从结构块里拼接纯文本（列表预览/标题回退用，仍只取 text 块）。 */
 function blocksToText(blocks) {
   return blocks.filter((b) => b.type === 'text' && typeof b.text === 'string').map((b) => b.text).join('\n');
@@ -328,19 +303,14 @@ function presentedPathsOf(events) {
 
 /**
  * 从 history 事件折叠出消息与「结构化行」（wire v1 扩展，向后兼容）：
- *  - 普通消息维持现状：{ id, seq, time, role, text, blocks?, images?, clientMessageId? }（user/assistant）；
- *  - compaction：{ kind:'compaction', id, seq, time, state:'running'|'done'|'failed', error?, turn?,
- *    summary?, shadowedItemCount?, shadowedTokenCount? }；
- *    压缩检查点 user/message（source.kind==='plugin' && source.plugin==='compact'）绝不渲染成用户气泡，
- *    渲染成 compaction 行（id=compactionId，state='done'），并用同 compactionId 的 compaction/summary 补 counts；
- *    compaction/end 给这次尝试落定（带 error → state='failed' + error 原文，否则 'done'）；
- *    **同一轮里的多次尝试只占一行**（新尝试原地顶替还没落定的那条）—— 宿主一步重试一次，
- *    不并就是几十条「正在压缩…」；
- *  - retry：{ kind:'retry', id: retryId, seq, time, status:'scheduled'|'started', retry, maxRetries, delayMs?, failure? }；
- *  - turn-error / max-tokens：{ kind:'turn-error', id:'turn-<turn>', message, code? } / { kind:'max-tokens', id:'turn-<turn>' }；
- *  - command：{ kind:'command', id:commandId, name, status:'running'|'done', resultKind?, text? }
- *    （command/run 发出行，command/done 原地升级：name 保 run 的，resultKind/text 取 done 的）。
- * 结构化项与消息按事件 seq 升序混排返回；旧载荷字段缺失时跳过对应项，绝不抛错。
+ *  - 普通消息：{ id, seq, time, role, text, blocks?, images?, clientMessageId? }；
+ *  - compaction：渲染成 compaction 行而不是用户气泡，id=compactionId；同 compactionId 的
+ *    compaction/summary 补 counts，compaction/end 落定 state（带 error 即 failed）；
+ *    同一轮的多次尝试只占一行，新尝试原地顶替还没落定的那条；
+ *  - retry：{ kind:'retry', id: retryId, status:'scheduled'|'started', retry, maxRetries, … }；
+ *  - turn-error / max-tokens：id 为 `turn-<turn>`；
+ *  - command：command/run 发出行，command/done 原地升级。
+ * 结构化项与消息按 seq 升序混排；旧载荷字段缺失时跳过对应项，绝不抛错。
  */
 function deriveMessages(events) {
   const out = [];
@@ -357,7 +327,7 @@ function deriveMessages(events) {
   // 交付声明预扫描（`deliverables/presented`）：模型调 `present` 声明「这几份请你收下」时，
   // 宿主的 dsh-tool-present 会往会话日志追一条这个事件。桌面那张「交付文件」卡只认它 ——
   // **不是**「这一轮改过哪些文件」。手机第一版从 write/edit 反推，于是「每改一次都冒卡、
-  // 命令行改的却一张都没有」（2026-10-22 用户报的正是这个）。这里按 **turn** 归并，
+  // 命令行改的却一张都没有」。这里按 **turn** 归并，
   // 同一个路径后声明的覆盖先声明的（桌面 `presentedForClosing` 的 `files.set` 同口径）。
   const presentedByTurn = new Map();
   for (const entry of events) {
@@ -383,8 +353,7 @@ function deriveMessages(events) {
    * 这一轮**被 write / edit 动过**的文件，按轮攒。
    *
    * 为什么按轮而不是按单条消息：一份文件是一轮里某一步写的，而收尾答复那条消息自己一个
-   * 写操作都没有 —— 按消息算的话，正文里提到刚写好的文件时那份清单永远是空的（2026-10-25
-   * 现场：手机上那个文件名一直是灰的，数一遍 54 条消息只有 4 条带得动这份清单）。
+   * 写操作都没有 —— 按消息算的话，正文里提到刚写好的文件时那份清单永远是空的。
    * 桌面 `dsh-client-ui-deliverables` 的 `selectProducedFiles(owner)` 也是按**整轮**取。
    *
    * 攒完在循环之后回填：同一轮里先发的消息也要能看到这一轮后几步才写出来的文件。
@@ -512,15 +481,8 @@ function deriveMessages(events) {
     // 这一轮的轮号（老日志没有）：产出清单与交付声明都按它归并。
     const turn = e.data && typeof e.data.turn === 'number' ? e.data.turn : undefined;
     // 本条消息自己写 / 改过的文件：并进**这一轮**的那一份，不单独挂在它自己头上。
-    const ownWrites = blocks
-      .filter((block) => block.type === 'tool-call' && (block.name === 'write' || block.name === 'edit') && block.state === 'ok')
-      .map((block) => {
-        try {
-          const args = JSON.parse(block.argsRaw || '{}');
-          return typeof args.path === 'string' ? args.path : typeof args.file_path === 'string' ? args.file_path : null;
-        } catch { return null; }
-      })
-      .filter((path) => typeof path === 'string');
+    // 从原始块的 arguments 算（那些参数不下发手机）。
+    const ownWrites = writtenPaths(msg.content, toolResults);
     if (turn !== undefined && ownWrites.length > 0) {
       const bucket = producedByTurn.get(turn) || new Set();
       for (const path of ownWrites) bucket.add(path);
@@ -804,25 +766,16 @@ function deriveMessages(events) {
  * 入口窗口的「内容化」裁剪（`GET /session/messages?thin=1`，只对不带 beforeSeq / afterSeq 的
  * 一次性入口窗口生效；往上翻页与增量补拉保持完整）。
  *
- * 为什么：入口原来按「消息条数」截尾巴，而宿主每跑一个 agent 步就落一条 assistant 消息
- * （推理块 + 工具调用块）。一次长回合几十上百步，最后 40 条可能全是这些过程消息 ——
- * 用户自己那句话被挤出窗口，进对话只剩半轮，看起来像「我说的话凭空消失」。
- *
- * 现在入口按「轮」分组、只留用户看得见的内容：
- *  - 用户消息 / 定时任务唤醒行（原样）；
- *  - 助手正文（中途汇报与最终答复都算）与带图的消息；
- *  - 结构化行（压缩、重试、本轮失败等，体量小，且带着这一轮的状态）。
- * 过程明细（推理块、工具调用块、只有过程没有文字的消息）不下发，开启某一轮时再逐轮补取。
- * 每轮被裁掉多少项、范围到哪，挂在**这一轮开头那条用户消息**的 `turnProcess` 上：App 用它
- * 渲染「还有 N 项处理过程」，点开时按 startSeq / endSeq 回头要那一轮的事件。
+ * 入口原来按「消息条数」截尾巴，而宿主每跑一个 agent 步就落一条 assistant 消息，长回合最后
+ * 几十条可能全是过程消息，用户自己那句话被挤出窗口。现在按「轮」分组，只留用户消息、助手
+ * 正文、带图消息与结构化行；过程明细不下发，每轮裁掉多少项挂在开头那条用户消息的
+ * `turnProcess` 上，点开时按 startSeq / endSeq 回头要那一轮的事件。
  *
- * 窗口最老那一组没有起点（宿主按 maxMessages 截断时正好切在一轮中间）时整组丢掉：
- * 半轮的消息没有用户消息打头，画出来就是「凭空冒出的 AI 发言」；它会被「加载更早」整轮补回。
+ * 窗口最老那一组没有起点（截断正好切在一轮中间）时整组丢掉，否则会画出「凭空冒出的 AI
+ * 发言」，它会被「加载更早」整轮补回。
  *
- * 三种「出卡」工具的调用块要留一条（定时任务 / 计划 / 扩展卡）：轮尾那几张卡是从工具块
- * 现算的（`services/viewmodels/turn-tail-cards` 的 scheduleTailCard / planTailCard /
- * extensionTailCard），整块丢掉会让卡在收口时凭空不见。它们体量很小。
- * **新增一种轮尾卡时要同步这里**，否则那张卡只在「点开过程之后」才出现。
+ * 三种「出卡」工具（定时任务 / 计划 / 扩展卡）的调用块要留一条，轮尾那几张卡是从工具块现算
+ * 的，整块丢掉会让卡凭空不见。新增一种轮尾卡时要同步这里。
  */
 const ENTRY_OUTCOME_TOOLS = new Set(['schedule_create', 'exit_plan_mode', 'extension_present']);
 
@@ -999,8 +952,6 @@ module.exports = {
   errorDetails,
   promptErrorObject,
   MODEL_UNAVAILABLE_ERROR,
-  capDiffText,
-  normalizeResultDiffs,
   buildToolResultMap,
   toolResultPatchesFor,
   parseBlocks,

package/lib/mobile/host-bridge/endpoints.js

@@ -3,12 +3,10 @@
 /**
  * 端点表：旧 `apiProxy.<ns>.<method>` 的键 ⇄ 宿主 wire 名与参数形状。
  *
- * ⚠️ 这张表是人肉对照宿主 descriptor 校验的，**没有任何机器可校验机制**，而它错一次的
- * 后果是静默的：`sessions.projections` 曾少包一层 `request`，宿主每次都回 400，
- * 而 App 侧把 400 catch 掉了，于是整个统计 UI 凭空消失。args 的键名必须**恰好**是
- * descriptor 的 wire 名（多一个少一个都报 gateway/arguments-invalid，dropUnexpectedArgs
- * 只摘多余的键，救不了「少一个」）。改动前请先在 test/host-bridge-endpoints.test.cjs
- * 里补一条参数化用例。
+ * 这张表是人肉对照宿主 descriptor 校验的，没有任何机器校验，错的后果是静默的：少一层
+ * `request` 时宿主只回 400，而 App 把 400 catch 掉，整个页面凭空消失。args 的键名必须恰好
+ * 是 descriptor 的 wire 名，多一个少一个都报 gateway/arguments-invalid。改动前先在
+ * test/host-bridge-endpoints.test.cjs 里补一条参数化用例。
  */
 
 const { invoke, invokeEnvelope, ok, fail, pick, requestId, unsupported, warn } = require('./transport.js');

package/lib/mobile/host-bridge/event-synthesis.js

@@ -52,10 +52,9 @@ function sessionHint(request) {
 /**
  * 这条单会话流该按哪种地址订阅。
  *
- * 子会话必须换成 `{kind:'subagent'}` 的 durable 地址：宿主 `validateAddress` 对
- * `origin === 'subagent'` 的会话拿普通地址一律回 agent-busy，subscribe 直接失败 ——
- * 表现就是「子代理页面打得开，但内容永远不自己更新」。请求体里带上 `parentSessionId`
- * 就是「这是个子会话」的信号（与历史那条同源，见 stream.js 的 handleStream）。
+ * 子会话必须换成 `{kind:'subagent'}` 的 durable 地址：宿主对 `origin === 'subagent'` 的会话
+ * 拿普通地址一律回 agent-busy，subscribe 直接失败，表现是「子代理页面打得开，但内容永远
+ * 不自己更新」。请求体里的 `parentSessionId` 就是「这是个子会话」的信号。
  */
 function sessionAddress(payload) {
   const sessionId = payload && payload.sessionId;
@@ -86,11 +85,9 @@ const BASELINE_DELTA_TYPES = new Set(['text-delta', 'reasoning-delta', 'tool-cal
 /**
  * 展开 follow 首帧里那条「正在跑的那一步已生成的内容」。
  *
- * 宿主的 follow 第一帧是 `{type:'snapshot', cursor, assistantStream:{ revision, activeAttempt }}`，
- * `activeAttempt.stream` 是一份**压缩过的**增量记录（连续同块 delta 被压成
- * `{type:'text-chunks', index, time0, dt, texts}` 这类一条记录多个成员），
- * `nextIndex` 是「下一帧实时增量应有的密排位置」，也就是这条前缀展开后应有的成员数。
- * 中途进入会话的人只有这一份，宿主不会把已发过的实时帧补给他。
+ * 首帧的 `assistantStream.activeAttempt.stream` 是一份压缩过的增量记录（连续同块 delta 被
+ * 压成一条记录多个成员），`nextIndex` 是展开后应有的成员数。中途进入会话的人只有这一份，
+ * 宿主不会把已发过的实时帧补给他。
  *
  * 返回 `[{ time, chunk }]`；形状认不出就跳过那一条记录，绝不让整条流挂掉。
  */
@@ -166,20 +163,15 @@ function coalesceBaselineStream(members) {
 /**
  * follow 流的一帧 → 0..n 个 mux 帧（事件原样转发；实时增量通知合成 assistant/chunk）。
  *
- * 0.2.0 的宿主把逐块流式增量从「会话事件」里拿了出去：正文/推理的每个 delta 只以 follow 流的
- * `assistant-stream` 通知下发，而且**要显式传 `assistantStream: true` 才发**，事件流里只剩
- * 「一步落定」的 `assistant/message`。不订阅通知的话，正文与运行中明细都只能在一步结束时整块
- * 出现（真机故障 2026-10-21：回复整段蹦出来、运行中那一行没有实时明细）。
+ * 0.2.0 把逐块流式增量从会话事件里拿了出去：每个 delta 只以 follow 流的 `assistant-stream`
+ * 通知下发，而且要显式传 `assistantStream: true` 才发，事件流里只剩「一步落定」的
+ * `assistant/message`。不订阅通知的话，正文与运行中明细都只能在一步结束时整块出现。
  *
- * 合成事件用的是移动协议早已认识的 `assistant/chunk` 形状，但**不带 seq** —— 它没有持久化
- * 事件的身份，不该参与客户端的 seq 序门、去重与续传水位（App 侧对无 seq 帧一律放行），
- * turn/step 由最近一次 start 通知补上。设备级推送只看 turn/start、turn/end、session/title
- * （`lib/mobile/events.js` 的 LIST_EVENT_INNER），合成增量到不了那条通道，不会形成推送风暴。
+ * 合成的 `assistant/chunk` 不带 seq：它没有持久化事件的身份，不该参与客户端的 seq 序门、
+ * 去重与续传水位（App 对无 seq 帧一律放行），turn/step 由最近一次 start 通知补上。
  *
- * `state` 是这条流的记账（{ turn, step, streaming }），由调用方持有 —— 一帧的处理要看
- * 「之前收到过什么」。历史正文走 session.history，但首帧 snapshot 里那份
- * `assistantStream.activeAttempt` 不能丢：中途进入会话的人拿不到开跑之前的实时增量，
- * 那一段只存在于这份基线里（见 expandBaselineStream）。
+ * `state` 是这条流的记账（{ turn, step, streaming }），由调用方持有。首帧 snapshot 里那份
+ * `assistantStream.activeAttempt` 不能丢：中途进入会话的人拿不到开跑之前的实时增量。
  */
 function* followFramePayloads(frame, sessionId, state) {
   if (!frame) return;
@@ -293,22 +285,16 @@ function projectionState() {
 }
 
 /**
- * 宿主投影 `inbox` → 移动端 `session/queue` 帧的**平铺 items**。
+ * 宿主投影 `inbox` → 移动端 `session/queue` 帧的平铺 items。
  *
  * 形状差是这条链上唯一的坑：宿主把 inbox 定义成按键分组的对象
- * `{ 'next-turn': Message[], 'next-step': Message[] }`（桌面 bundle 里
- * `@deepseek-ai/dsh-agent-loop/inbox` 的 `key: 'inbox'` + `wire.view: (state) => state`，
- * 桌面 QueueDock 读的也正是 `inbox['next-turn']`），而移动端帧的约定是数组
- * `[{ id, placement, message }]`（`app/src/types/chatStream.ts` 的 QueueItem、
- * `app/src/hooks/streamFrame.ts` 的 `session/queue` 分支）。原样转发对象时 App 的
- * `Array.isArray(items)` 判定失败、整帧被静默丢弃 —— 排队条一次都不显示。
+ * `{ 'next-turn': Message[], 'next-step': Message[] }`，而移动端帧的约定是数组
+ * `[{ id, placement, message }]`。原样转发对象时 App 的 `Array.isArray(items)` 判定失败、
+ * 整帧被静默丢弃，排队条一次都不显示。
  *
- * `next-turn`（等下一轮才开始的消息）→ `placement: 'queued'`，QueueDock 只认这一个值。
- * `next-step`（已收下、等本步末尾注入的插话）→ `placement: 'steering'`：排队条与正文列表都
- * 只认 `queued`，所以它不会多画一行；它的用处是「宿主已经收下了」这条回执 —— 插话从发出去
- * 到真被插进去中间可能隔着好几个工具往返，此前手机上只挂着一颗「发送中…」。页脚那排插话
- * 气泡会把本机自己发的那几条排掉（`steeringForFooter`），不会与待发气泡双画。
- * `message.id` 用宿主行自己的 id，App 靠它与正文去重（chatRenderRows）。
+ * `next-turn` → `placement: 'queued'`（排队条只认这个值）；`next-step` → `'steering'`，
+ * 它只是「宿主已经收下了」的回执，不会多画一行。`message.id` 用宿主行自己的 id，App 靠它
+ * 与正文去重。
  */
 function queueItems(inbox, ctx) {
   const items = [];
@@ -385,7 +371,7 @@ function muxFrames(ctx, request, signal) {
       // **设备级这一支不能跟着宿主那几条流一起结束**：这条 SSE 还捎带着插件自己产的
       // 清单变更、正文水位与 15s 心跳（由 `handleDeviceStream` 直接写这条连接）。
       // 迭代器一返回，SSE 立刻收尾，手机端只会看到「连几秒就断」：信号永远不「活着」，
-      // 兜底轮询降不下去，每次重连还要重放一遍水位（2026-10-24 现场：17 帧后 loopEnded）。
+      // 兜底轮询降不下去，每次重连还要重放一遍水位。
       // 单会话那一支不适用 —— 会话结束了就该收尾。
       if (!signal || signal.aborted) return;
       await new Promise((resolve) => {

package/lib/mobile/host-bridge/shims.js

@@ -72,24 +72,16 @@ async function historyViaPage(ctx, payload, signal) {
 /**
  * `session.models` → `session.modelCatalog` + 会话自己的 `session/projections`。
  *
- * 宿主改成全局目录了（args 为空），字段也换了名：default → current、
- * routableProviders 变成「能不能用这个 provider」。移动端要的 groups 结构两边一致，
- * 原样带过去即可。
+ * 宿主改成全局目录了（args 为空），字段也换了名：default → current；移动端要的 groups 结构
+ * 两边一致，原样带过去即可。
  *
- * 但 `default` 是**全局**默认，不是「这个会话实际用的模型」。会话自己的模型记在
- * `session/projections` 的 `modelSelection` 投影里（`next` 是「下一次请求要用」，
- * 落到 `lastUsed` 是「最近一次真正跑过的」）；只有会话从没选过模型时，投影里才没有
- * 这一项，此时才回落到全局默认。桌面端「切到某个对话显示那个对话的模型」读的正是
- * 这份会话级投影，不是全局默认。移动端这里也要对同一口径，否则 A、B 两个会话各选
- * 了不同模型，手机却都显示同一个「默认模型」。
+ * `default` 是全局默认，不是「这个会话实际用的模型」。会话自己的模型记在
+ * `session/projections` 的 `modelSelection` 投影里（`next` 是下一次请求要用，`lastUsed` 是
+ * 最近一次真正跑过的）；从没选过时才回落到全局默认。读不到投影不是错误，退回全局默认即可，
+ * 别让整个模型面板消失。
  *
- * 读不到投影（会话不存在 / 宿主没挂投影能力）时不升级成错误：退回全局默认即可，
- * 让模型目录照常下发，宁可少一次会话级精修也不让整个模型面板消失。
- *
- * `defaultModel` 单独回一份**全局默认**，与 `current` 分开：宿主的新会话读的就是
- * 「最近一次成功保存的默认值」（`session.create` 不带模型时落这一条），所以 App 要
- * 显示「新对话会用哪个模型」只能看它 —— 拿任何一个会话的 `current` 去顶都是猜，
- * 会话各自选过的模型未必是默认。旧 App 忽略这个字段，行为不变。
+ * `defaultModel` 单独回一份全局默认：宿主的新会话读的就是最近一次成功保存的默认值，所以
+ * App 要显示「新对话会用哪个模型」只能看它，拿任何一个会话的 `current` 去顶都是猜。
  */
 async function modelCatalog(ctx, payload, signal) {
   const sessionId = payload && typeof payload.sessionId === 'string' ? payload.sessionId : '';
@@ -208,13 +200,11 @@ async function projectionBaseline(ctx, signal) {
 /**
  * `subagents.list` → `session.control` 投影基线 + `session.list`。
  *
- * 0.2.0 撤掉了 subagent.list 这个 RPC，但目录数据一条没少：它变成了会话投影里的
- * `subagentCatalog` 键，桌面端 @deepseek-ai/dsh-client-ui-subagent 的 CatalogDropdown
- * 就是读 `state.projectionsBySession` 渲染的。投影基线一次给出**全部**会话的 values，
- * 父子两层的目录在同一帧里 —— hasChildren 因此不需要按子会话再发 N 次投影查询。
+ * 0.2.0 撤掉了 subagent.list，但目录数据没少：它变成会话投影里的 `subagentCatalog` 键。
+ * 投影基线一次给出全部会话的 values，父子两层的目录在同一帧里，hasChildren 不需要再按子
+ * 会话逐个查。
  *
- * 投影里没有的是运行时状态：跑没在跑、父会话在不在线。桌面端也是拿 sessions.list 的
- * summaries 合成 activity 的，这里同口径再取一次会话列表，两边判定完全一致。
+ * 投影里没有运行时状态（跑没在跑、父会话在不在线），所以同口径再取一次会话列表的 summaries。
  */
 async function subagentCatalog(ctx, payload, signal) {
   const parentSessionId = payload && payload.parentSessionId;

package/lib/mobile/host-bridge.js

@@ -3,23 +3,13 @@
 /**
  * 0.2.0 兼容桥：旧 `apiProxy` 调用形状 → 宿主 `typertGateway`。
  *
- * 背景：DSH 0.2.0 删掉了 `apiProxy` 服务（整个 app.asar 里零命中），宿主 RPC 全部改走
- * `ctx.get('typertGateway')` 的 `invoke({namespace, method, args, signal})` / `stream(...)`。
- * 但本插件 17 个移动端模块历史上都是这一套：
+ * 0.2.0 删掉了 `apiProxy` 服务，宿主 RPC 全改走 `ctx.get('typertGateway')` 的 invoke /
+ * stream。本插件十几个移动端模块都按旧形状调用（`ctx.apiProxy.<ns>.<method>(…)`，返回
+ * `{ result: { ok, value|error } }`），这里提供同名同形状的服务，内部翻译成 gateway 调用并
+ * 把结果包回旧信封；将来宿主若恢复真 apiProxy，删掉这个目录即可。
  *
- *   请求：`ctx.apiProxy.<ns>.<method>({ rpcId, method: '<ns>.<method>', payload }, signal)`
- *   返回：`{ result: { ok: true, value } }` 或 `{ result: { ok: false, error } }`
- *
- * 与其逐个改 55 处调用点（每处都要对上宿主的 wire 参数名，而参数名错了只在运行时
- * 报 `gateway/arguments-invalid`），这里提供**同名同形状**的服务，内部翻译成
- * gateway 调用并把结果包回旧信封 —— 17 个文件一行都不用动，将来 DSH 若恢复真
- * `apiProxy`，把这个目录删掉、apply 里那一行 provide 去掉即可。
- *
- * 本文件只剩装配：把端点表铺成 `apiProxy.<ns>.<method>` 的形状。实现分四份：
- *   host-bridge/transport.js       网关传输与信封翻译（唯一知道「宿主怎么调」的地方）
- *   host-bridge/endpoints.js       端点表（键 ⇄ 宿主 wire 名与参数形状）
- *   host-bridge/shims.js           没有 1:1 端点、需要跨端点合成的几处
- *   host-bridge/event-synthesis.js 旧设备级 events.mux ⇄ 0.2.0 拆开的三条流
+ * 本文件只剩装配：实现分四份——transport（网关传输与信封翻译）、endpoints（端点表）、
+ * shims（需要跨端点合成的那几处）、event-synthesis（旧 mux ⇄ 三条新流）。
  */
 
 const { ENDPOINTS } = require('./host-bridge/endpoints.js');
@@ -31,10 +21,8 @@ const { unsupported, UNAVAILABLE } = require('./host-bridge/transport.js');
 /**
  * 把端点表铺成旧的 `apiProxy.<ns>.<method>` 形状。
  *
- * 键表直接从 ENDPOINTS 推，不再手写一份 `<ns>` → 方法名数组：两份表迟早会对不上，
- * 而对不上的后果不是报错，是 `ctx.apiProxy.<ns>.<method> is not a function` 这种在
- * 别的模块、别的请求里炸出来的 TypeError（新增 sessions.projections 时就漏登记过一次，
- * /session/stats 会跟着一起挂）。现在新增端点只改 ENDPOINTS 一处。
+ * 键表直接从 ENDPOINTS 推，不再手写一份：两份表对不上时的症状不是报错，而是别的模块里炸
+ * 出 `ctx.apiProxy.<ns>.<method> is not a function`。新增端点只改 ENDPOINTS 一处。
  */
 function createApiProxy(ctx) {
   const namespaces = {};

package/lib/mobile/host-settings.js

@@ -3,19 +3,12 @@
 /**
  * 移动端「宿主设置」API：只读暴露宿主的模型提供方名单与设置命名空间。
  *
- * 桌面端有完整的设置面板（默认模型、提供方配置、凭据是否已设），手机端此前一点都看不到，
- * 只能看到一个「设置」页里全是 App 自己的偏好项。这里先把「看得到」补齐：
- * settings.describe 与 llm.providers 都是只读接口，且宿主自己已经做了脱敏
- * （secrets 只给出 path 与 set，从不返回值），所以可以原样转给手机。
- *
- * 命名空间里的 schema 字段是序列化后的 zod 树（几百个 uid/refs），对手机没有任何用处，
+ * settings.describe 与 llm.providers 都是只读接口，宿主自己已做脱敏（secrets 只给 path 与
+ * set，从不返回值），可以原样转给手机。命名空间里的 schema 是序列化后的 zod 树，对手机没用，
  * 直接丢掉，只保留 value / base / user / applies / revision 与密钥槽。
  *
- * 写入侧（POST /host-settings/mutate）与桌面端同一口径：只走宿主的 settings.mutate，
- * 用「按路径寻址的 op」（set / unset）+ expectedRevision 做乐观并发，绝不整段 replace。
- * 桌面端就是这么写的：dsh-client-ui-settings/lib/client.js 一次只提交一个 op
- * （`settings.mutate({ ns, ops: [op], expectedRevision })`），失败后重新 describe 再重试。
- * 手机上一般一次改好几个字段，所以这里一次收一组 op，但语义与桌面端逐字段提交完全一致。
+ * 写入侧（POST /host-settings/mutate）与桌面端同一口径：只走宿主的 settings.mutate，用按路径
+ * 寻址的 op（set / unset）+ expectedRevision 做乐观并发，绝不整段 replace。
  */
 
 const { sendJson, readJsonBody } = require('../shared/http-util');
@@ -61,15 +54,12 @@ function boundValue(value, depth = 0) {
 /**
  * 从序列化的 zod 树里读出「这个命名空间的密钥写到哪个凭据引用上」。
  *
- * 宿主把两个标记留在 schema 的 meta 里：`.role('secret')` 标出密钥字段，
- * `.role('credential-ref')` 标出「写着凭据引用名」的那个字段
- * （见 dsh-web-search-deepseek/lib/index.js:240-241 的 apiKey / apiKeyEnv）。
- * settings.describe 的 secrets 槽就是由 role('secret') 生成的，而真正写入时
- * 要用的是 role('credential-ref') 指向字段的值（桌面端也是这么取的：
- * dsh-client-ui-settings-plugins/lib/client.js 的 refOf() 读 snapshot.value.apiKeyEnv）。
+ * 宿主把两个标记留在 schema 的 meta 里：`.role('secret')` 标出密钥字段，`.role('credential-ref')`
+ * 标出「写着凭据引用名」的那个字段。settings.describe 的 secrets 槽由前者生成，而真正写入时
+ * 要用后者指向字段的值。
  *
- * 这里按同一口径从 schema 推导，不写死任何命名空间；推导不出来就返回 null，
- * 于是 App 不会给没有密钥槽的设置项画密码框。
+ * 按同一口径从 schema 推导，不写死任何命名空间；推导不出来就返回 null，于是 App 不会给
+ * 没有密钥槽的设置项画密码框。
  */
 function credentialRefOf(schema, value) {
   const refs = schema && typeof schema === 'object' && !Array.isArray(schema) ? schema.refs : null;