dsh-mobile-plugin 0.4.0 → 0.4.1

package/lib/mobile/session-snapshot.js

@@ -77,12 +77,10 @@ async function buildStatsSnapshot(ctx, sessionId) {
 /**
  * 统计投影快照（handleStats 与 buildStatsSnapshot 共用）。
  *
- * 0.2.0 把整帧投影从 session.history/page 的返回值里拆走了（page 只回
- * events/hasMore/cursor），所以「拉 1 条历史顺带取投影」这条路已经断了；改走
- * host-bridge 翻译出来的 `apiProxy.sessions.projections({ request: { sessionId } })`，
- * 返回值是 `{ asOfSeq, values }`。顺带把 plan 归一化成 planMode（plan.active 加可选的
- * pending），排队条与计划条读的是 planMode。历史轮询是每 5 秒一次的热路径，多背一次
- * 投影 RPC 划不来，所以宁可让统计单独走投影端点。
+ * 0.2.0 把整帧投影从 history/page 的返回值里拆走了，「拉一条历史顺带取投影」这条路断了；
+ * 改走 `apiProxy.sessions.projections({ request: { sessionId } })`，返回值是
+ * `{ asOfSeq, values }`。顺带把 plan 归一化成 planMode（排队条与计划条读它）。
+ * 历史轮询是每 5 秒一次的热路径，多背一次投影 RPC 划不来，所以统计单独走投影端点。
  */
 async function statsProjections(ctx, sessionId) {
   // 显式给 signal：宿主部分方法内部直接读 signal.aborted，不做 undefined 兜底。

package/lib/mobile/sessions.js

@@ -1,32 +1,16 @@
 'use strict';
 
 /**
- * 移动端会话 API 的**会话列表**与**新建会话**。
+ * 移动端会话 API 的会话列表与新建会话。
  *
- * 本文件一度是 1964 行的单体，HTTP 路由、宿主 RPC、缓存、事件派生全混在一起；而且
- * 它是 lib/mobile 下被引用最多的模块——stream / credentials / skills / subagents /
- * workspaces / host-settings 全都从它取 unwrap、callSessions、缓存访问器，于是它成了
- * 事实上的公共工具库，谁都不好动。现在按域拆开：
- *
- *   envelope.js        信封拆解（unwrap / envelopeValue），唯一的实现
- *   rpc.js             对宿主 apiProxy 的窄接口封装（callSessions / callAgentPresets）
- *   session-cache.js   按 ctx 隔离的状态表，全部 WeakMap 集中在这里
- *   attachments.js     图片附件还原
- *   completion.js      完成提醒状态机
- *   session-models.js  模型目录与切模型
- *   session-search.js  正文检索
- *   session-send.js    发消息 / slash 命令 / 读 / 附件重取 / 停 / 改名 / 分叉
- *   session-snapshot.js 消息与统计快照（镜像与分页共用）
- *   session-mirror.js  镜像整帧构建
- *   session-goal.js    目标条动作
- *   session-presets.js Agent 预设目录
- *   session-preview.js 列表行的 lastMessage 预览（按会话指纹复用 + 运行中会话的节流）
- *   session-list-shortcut.js `?rev=` 条件刷新记住的那份清单是谁
+ * 这个文件一度是一千九百多行的单体，HTTP 路由、宿主 RPC、缓存、事件派生全混在一起；现在
+ * 按域拆开：envelope（信封拆解）、rpc（窄接口封装）、session-cache（按 ctx 隔离的状态表）、
+ * attachments、completion、session-models、session-search、session-send、session-snapshot、
+ * session-mirror、session-goal、session-presets、session-preview、session-list-shortcut。
  *
  * 剩下的就是列表：GET /sessions（10 秒缓存 + fresh 绕过 + 完成态确认 + `?rev=` 条件刷新）、
- * GET /session（单会话摘要）、GET /session/head（正文水位探针）、GET /session/stats、
- * 新建会话、排队消息动作。**本文件继续从各子模块转出导出**，
- * 所以 lib/mobile 下所有 import 路径一行都不用改。
+ * 单会话摘要、正文水位探针、统计、新建会话、排队消息动作。本文件继续转出各子模块的导出，
+ * 所以 lib/mobile 下的 import 路径一行都不用改。
  */
 
 const { sendJson, readJsonBody } = require('../shared/http-util');

package/lib/mobile/stats-collect.cjs

@@ -3,26 +3,14 @@
 /**
  * 统计采集：把宿主每条会话的累计用量读出来，和水位一比，增量记进账本。
  *
- * 为什么不重放会话事件：那是 dsh-context 在桌面上干的事（它让宿主注册一份投影，
- * 每个事件折一次）。手机这边要的是「按天看个大概」，重放整条日志在宿主上是一笔
- * 每秒都在烧的开销，而我们每轮只需要一个数 —— 会话的累计用量。
+ * 不重放会话事件：手机要的是「按天看个大概」，重放整条日志是每秒都在烧的开销。所以走水位差
+ * （宿主累计值 − 账本水位 = 这次入账的量），零依赖，代价是入账日期取「插件看到增量的那一天」，
+ * 跨零点的一轮会落在后一天。首采会把历史全量入账，日期取它最后一次活动的日期，算一次性回填。
  *
- * 所以走水位差：
- *   宿主累计值 − 账本记下的水位 = 这次该入账的量。
- * 好处是零依赖（只用现有的会话投影接口，不需要宿主新能力，也不用装别家插件），
- * 代价如实说：入账日期取「插件看到增量的那一天」，跨零点的一轮会落在后一天。
- * 这是刻意的近似 —— 为一个几十分钟的边界去重放事件流不值得。
+ * 采集是按需的（打开统计页 / 下拉刷新 / 清理已归档前补一刀），没有后台定时器。
  *
- * 首采（账本里没有这条会话）会把它的历史全量入账，日期取它最后一次活动的日期：
- * 这是一次性回填，用户装上这个版本之后第一次打开统计页就会看见过去的用量，
- * 而不是从今天零点重新计数。
- *
- * 采集是**按需**的（打开统计页 / 下拉刷新 / 清理已归档前补一刀），没有后台定时器：
- * 手机上没人看统计的时候不该让宿主一直读盘。
- *
- * 清理前那次补采（`skipPreview`）刻意不读「最后一句」：那一步要读会话日志，是整轮里
- * 最重的一趟，而删除不可恢复、时间又卡在手机那条请求的预算里。为了多把几十上百条会话的
- * 数字记进账本，宁可让首次见到的会话卡片少一行摘要 —— 标题与项目名还认得出来。
+ * 清理前那次补采（`skipPreview`）不读「最后一句」：那一步要读会话日志，是整轮最重的一趟，
+ * 而删除不可恢复、时间又卡在请求预算里。宁可让首次见到的会话卡片少一行摘要。
  */
 
 const { unwrap } = require('./envelope.js');
@@ -39,11 +27,9 @@ const CONCURRENCY = 4;
 /**
  * 这一轮先扫「最近还在动」的会话，再按「最久没采过」补老账。
  *
- * 之前每一轮都只按最后活动时间倒序扫、1.5 秒到点就停，于是最老的那批永远排在队尾、
- * 永远采不到（实测七十多条会话从没进过账本，其中大多是子代理）。现在把队列分成两段：
- * 近 7 天有动作的照旧优先（它们才是数字在变的那批），其余的按 `collectedAt` 升序 ——
- * 采过的会顺手把时间推到当下、自动排到队尾，于是每一轮的预算都接着上一轮的地方往下走，
- * 不需要额外持久化一个游标。
+ * 只按最后活动时间倒序扫会让最老的那批永远排在队尾、永远采不到。所以队列分两段：近 7 天有
+ * 动作的优先（它们才是数字在变的那批），其余按 `collectedAt` 升序 —— 采过的会把时间推到当下、
+ * 自动排到队尾，每一轮的预算接着上一轮往下走，不需要额外持久化游标。
  */
 const RECENT_WINDOW_MS = 7 * 86400_000;
 
@@ -51,7 +37,7 @@ const RECENT_WINDOW_MS = 7 * 86400_000;
  * 一次采集的时间预算。
  *
  * 手机上点开统计页时，插件会当场把每条会话的累计用量读一遍；一百多条会话串起来能拖到
- * 十几秒（每条两趟宿主调用），用户看到的就是「点统计，转好久」（2026-10-22 真机）。
+ * 十几秒（每条两趟宿主调用），用户看到的就是「点统计，转好久」。
  * 所以给这一趟设上限：到点就停，把**已经采到的**那部分记进账本先回给手机，剩下的等
  * 下一次打开 / 下拉刷新接着采 —— 水位差是累积的，采一半不会算错，只是数字暂时偏小。
  */

package/lib/mobile/stats-ledger.cjs

@@ -3,21 +3,15 @@
 /**
  * 统计账本：按天累计的用量 + 每条会话的累计与身份（`$DSH_HOME/mobile-stats.json`）。
  *
- * 为什么要有这一份、以及它为什么不寄在会话日志上：用户会归档会话、也会清理已归档的
- * 会话，清理删的是日志本身。统计如果每次现算，清理之后那部分用量就凭空消失（还常常
- * 表现为「今天的使用量突然掉了一半」）。所以采集一旦读到增量就落进这个文件，之后会话
- * 在不在都不影响历史数字 —— 那张会话卡片只会被标成「已清理」。
+ * 它不寄在会话日志上：用户会清理已归档的会话，删的就是日志本身；统计每次现算的话，清理之后
+ * 那部分用量会凭空消失。一旦读到增量就落进这个文件，之后会话在不在都不影响历史数字。
  *
- * 口径（与桌面插件 dsh-context 的每日账本一致，但只保留手机用得着的部分）：
- * - 一天的账落在那**一天完成观测**的日期上（宿主本地日期，`YYYY-MM-DD`）；
- * - 计费 token = 未命中输入 + 缓存读 + 缓存写 + 输出，四个桶分开存，合并多台设备时
- *   才可能按同一口径重算计费量与命中率；
- * - 会话卡片保留最近 `MAX_SESSIONS` 条（按最后活动时间），更老的会话从卡片里消失，
- *   但它们的量**仍然留在按天的账上**（总量不会因为裁剪而缩水）。卡片退场只是不再展示
- *   （`retired`），水位留着 —— 水位一丢，这条会话下次再有动作就会被当成首采、把整段
- *   历史重记一遍，按天的账凭空多出一截。
+ * 口径（与桌面 dsh-context 的每日账本一致，只保留手机用得着的部分）：一天的账落在「观测到
+ * 增量」的宿主本地日期上；计费 token = 未命中输入 + 缓存读 + 缓存写 + 输出，四个桶分开存；
+ * 会话卡片只留最近 `MAX_SESSIONS` 条，更老的退场（`retired`）但量仍留在按天账上，水位也留着
+ * —— 水位一丢，那条会话下次有动作会被当成首采、把整段历史重记一遍。
  *
- * 这个文件只做纯数据（读写 + 折算），不碰网络；采集在 stats-collect.cjs，路由在 stats.js。
+ * 只做纯数据（读写 + 折算），不碰网络；采集在 stats-collect.cjs，路由在 stats.js。
  */
 
 const fs = require('node:fs');
@@ -170,8 +164,8 @@ function sanitizeLedger(raw) {
         }
       }
       const billed = sanitizeUsage(value.billed);
-      // 老账本（2026-10-24 之前）没有每条会话的按天用量：把它的历史量记在它最后一次
-      // 活动那天。这跟「首采回填」是同一条近似，也是一次性回填 —— 之后就只记增量。
+      // 更早的账本没有每条会话的按天用量：把它的历史量记在它最后一次活动那天。
+      // 这跟「首采回填」是同一条近似，也是一次性回填 —— 之后就只记增量。
       if (Object.keys(daily).length === 0 && billedOf(billed) > 0) {
         daily[dayKeyOf(num(value.lastAt) || Date.now())] = { ...billed };
       }
@@ -364,12 +358,11 @@ function usageInRange(record, startDay, today) {
 /**
  * 按范围折算成 App 要的总览（纯函数）。
  *
- * 逐日序列会把范围内**每一天都列出来**（没有活动的补 0）：柱状图靠它保持等距，
- * 由页面决定怎么省略日期标签。
+ * 逐日序列会把范围内每一天都列出来（没有活动的补 0），柱状图靠它保持等距。
  *
- * 三块口径必须对得上（2026-10-24 改）：`kpi` 是范围内总量，`sessions` 里的每张卡片是
- * **这条会话在同一个范围里**的用量，`retired` / `untracked` 把不在卡片上的那部分明说出来 ——
- * 卡片加起来永远解释不了总量，是这个页面被读成「数据对不上」的根源。
+ * 三块口径必须对得上：`kpi` 是范围内总量，`sessions` 里的每张卡片是这条会话在同一个范围里
+ * 的用量，`retired` / `untracked` 把不在卡片上的那部分明说出来 —— 卡片加起来解释不了总量，
+ * 是页面被读成「数据对不上」的根源。
  */
 function summarize(ledger, range, now) {
   const today = dayKeyOf(now);

package/lib/mobile/stream.js

@@ -3,32 +3,21 @@
 /**
  * dsh-mobile 流式：SSE 转发目标会话的增量事件。
  *
- * 订阅宿主事件流，仅转发目标会话的 session/event 帧（增量事件），
- * 每 15s 发一行注释 + 一帧 `session/heartbeat` 数据帧；客户端断开即取消订阅。
+ * 订阅宿主事件流，只转发目标会话的 session/event 帧，每 15s 发一行注释加一帧
+ * `session/heartbeat`；客户端断开即取消订阅。心跳那帧不能省：注释行只是保活，客户端一个
+ * 事件都收不到，而「流被正常收尾」在 App 那边看起来和「还开着」一样，它需要一个自己数得到
+ * 的活口。心跳不带 seq、不进消息模型、不写缓存。
  *
- * 为什么要那帧心跳：注释行只是保活，客户端一个事件都收不到。而「流被正常收尾」
- * （中转重启、隧道掉了、宿主自己结束响应）在 App 那边看起来和「这条流还开着」一模一样
- * —— react-native-sse 在 readyState 走到 DONE 时既不派发 error 也不派发 close。所以
- * App 需要一个**自己数得到**的活口，两拍没到就主动断开重连（见 app 侧
- * services/viewmodels/stream-liveness.ts）。这帧不带 seq、不进消息模型、不写缓存。
+ * 断线恢复：客户端重连带 `Last-Event-ID: <sessionId>:<seq>`（或 `lastSeq`），服务端先回放
+ * `seq > lastSeq` 的事件再接入实时流，并用 seq 去重。回放受窗口与字节数上限约束，超出的
+ * 缺口让客户端去拉权威快照。
  *
- * 断线恢复：SSE 客户端重连时携带 `Last-Event-ID: <sessionId>:<seq>`（或查询参数
- * `lastSeq=<seq>`）。服务端先在 history 中回放 `seq > lastSeq` 的事件（收敛状态），
- * 再无缝接入实时流，并用 seq 去重避免回放/实时交界处重复交付。由于宿主 history
- * 只支持窗口回放，若断线窗口超过回放上限，客户端仍应在其 SSRD 重连补偿刷新
- * 权威快照（/session/messages、/workspaces）兜底。
+ * 生命周期：所有失败路径都必须经 logStream 留痕（守卫逐条钉着字面量），收尾一定给客户端一帧
+ * `session/resync-required`；keepAlive 定时器要 unref。
  *
- * 生命周期：所有失败路径都必须经 logStream 留痕（守卫 test/stream-liveness.test.cjs
- * 逐条钉着字面量），收尾一定给客户端一帧 `session/resync-required`；keepAlive 定时器
- * 要 unref —— 它只是保活，不该把进程退出按在 15s 一拍上。
- *
- * 出流量的三个口子（2026-10-25，都在这一层收）：
- *  - 草稿增量按 200ms 合并成一帧（`DRAFT_FLUSH_MS`）：一帧固定成本两三百字节，而一个
- *    token 只有十几字节，逐帧发等于按帧收费；
- *  - 草稿的填充窗口 250ms（`DRAFT_PAD_INTERVAL_MS`）：填充是按时间补的，120ms 就是
- *    16KB/s 的底线，与正文多少无关；
- *  - 推理只推每一步的开头 600 字、工具结果只推前 2000 字：运行中用户不读它们，完整内容
- *    仍在 `assistant/message` 与 `/session/messages` 里，一个字都不丢。
+ * 出流量收在三处：草稿增量按 200ms 合并成一帧（一帧固定成本两三百字节，token 才十几字节）；
+ * 草稿填充窗口 250ms；推理只推每一步开头 600 字、工具结果只推前 2000 字，完整内容仍在
+ * `assistant/message` 与 `/session/messages` 里。
  */
 
 const { sendJson } = require('../shared/http-util');

package/lib/mobile/subagents.js

@@ -3,25 +3,12 @@
 /**
  * 移动端「子代理」API：把某个会话派出去的子代理目录转给手机。
  *
- * 桌面端会话标题栏里挂着一个「N 个子代理」下拉（@deepseek-ai/dsh-client-ui-subagent
- * 的 SubagentHeaderLineage）：父会话头部按 `origin === "subagent" && parentId ===
- * 当前会话` 把子代理收成一棵树，点进去能读子会话的完整记录。手机端此前把
- * `origin === 'subagent'` 的行在侧栏里直接 continue 掉（app/src/drawerGroups.ts:122），
- * 于是用户既不知道这个会话派过子代理，也没有任何入口能打开它 —— 子代理在手机上
- * 等于不存在。
+ * 手机侧栏把 `origin === 'subagent'` 的行直接跳过，于是用户既不知道会话派过子代理，也没有
+ * 入口打开它。子会话在普通消息接口里只有带 durable parent address（parentSessionId + mode）
+ * 才能读，而 /sessions 只给 origin/parentSessionId，mode 来自这里的子代理目录。
  *
- * 子会话在普通消息接口中只有携带 durable parent address 才能读取（parentSessionId + mode）；
- * /sessions 只给 origin/parentSessionId，mode 则来自这里的子代理目录。缺的只是
- * 「这个会话有哪些子代理」——
- * 那正是 subagent.list 的返回值（entries + parentAvailable），这里只做形状收敛、
- * 限长与限条数，避免异常宿主把手机端列表撑爆。
- *
- * 宿主 subagent.list 的第二个形参是取消信号（内部 listChildren 会读 signal），
- * 故与 session.search 一样显式传一个 AbortController 的 signal，不裸传 undefined。
- *
- * DSH 0.2.0 没有 subagent.list 这个 RPC 了，目录改由 host-bridge.js 从会话投影的
- * subagentCatalog 重建（形状仍是 entries + parentAvailable），本文件对它的形状收敛、
- * 限长与限条数一字未动。
+ * 0.2.0 没有 subagent.list 这个 RPC，目录由 host-bridge.js 从会话投影的 subagentCatalog
+ * 重建（形状仍是 entries + parentAvailable）；本文件只做形状收敛、限长与限条数。
  */
 
 const { sendJson, readJsonBody } = require('../shared/http-util');

package/lib/mobile/uploads.js

@@ -3,26 +3,17 @@
 /**
  * 移动端文件分片上传：把手机分享进来的文件落到宿主机固定收件目录。
  *
- * 四步：begin（登记文件名，拿 uploadId 与片大小）→ chunk（按 index 顺序追加）→
- * finish（落盘成 `<收件根>/<日期>/<文件名>`，重名自动加后缀）→ abort（放弃）。
+ * 四步：begin（登记文件名，拿 uploadId 与片大小）→ chunk（按 index 顺序追加）→ finish
+ * （落盘成 `<收件根>/<日期>/<文件名>`，重名自动加后缀）→ abort（放弃）。
  *
- * 为什么分片，而不是一次 POST 传完：
- *   - 一次传完会把「能传多大的文件」变成一条运维配置 —— 中转的
- *     `MAX_BODY_BYTES`（dsh-mobile-server/lib/config.js）默认 50MB，插件自己的
- *     readJsonBody 默认只有 256KB。分片后单请求最大只有 2MB，与这些上限无关。
- *   - 手机侧网络不稳，分片能只重传坏掉的那一片，而不是整个文件。
+ * 分片而不是一次传完：单请求因此与中转的 `MAX_BODY_BYTES`、readJsonBody 的 256KB 上限无关，
+ * 手机网络不稳时也能只重传坏掉的那一片。片内容走 base64 而不是原始字节：App 侧没有发二进制
+ * body 的先例，图片通道本来就以 base64 走 JSON；代价是 33% 膨胀，仍远低于各层上限。
  *
- * 为什么片内容走 base64 而不是原始字节：隧道协议本身支持原始字节
- * （lib/relay/protocol.js 的 httpBody 帧），但 App 侧没有任何「发二进制 body」的
- * 先例，RN 的 fetch 对 ArrayBuffer body 的支持也随版本变；图片通道本来就以 base64
- * 走 JSON，这里沿用同一条确定能用的路。代价是 33% 膨胀（单片 2MB → 约 2.73MB），
- * 仍远低于任何一层上限。
+ * 顺序与幂等：chunk 只接受下一片，重复送达同一片按重传处理，跳号直接 409。
  *
- * 顺序与幂等：chunk 只接受「下一片」，重复送达同一片按重传处理（回当前 received，
- * 不再追加），跳号直接 409 —— 客户端因此不需要在重试前先问进度。
- *
- * 落盘根目录固定 `~/.dsh/mobile-inbox`（收件专目录，与工作区解耦，工作区被删也不
- * 影响已收到的文件）。`DSH_MOBILE_INBOX` 可覆盖，只给测试用。
+ * 收件根固定 `~/.dsh/mobile-inbox`，与工作区解耦（工作区被删不影响已收到的文件）；
+ * `DSH_MOBILE_INBOX` 可覆盖，只给测试用。
  */
 
 const fsp = require('node:fs/promises');

package/lib/mobile/workspaces.js

@@ -3,15 +3,12 @@
 /**
  * dsh-mobile 工作区/目录浏览：透传宿主 apiProxy 的目录浏览与工作区采纳 RPC。
  *
- * 移动端是**远程遥控器**——它不能像桌面端那样弹被控端的原生目录对话框。
+ * 移动端是远程遥控器，不能像桌面端那样弹被控端的原生目录对话框。
  *
- * 这里曾经写着一个**错的**前提：以为 directory-picker-auto 会在「宿主绑定局域网（非
- * 127.0.0.1）」时自动启用 `browse` 能力，于是 `apiProxy.host.listDirectory` /
- * `host.createDirectory` 在任何被控端都可用。实际不是：auto 只在「web 服务绑到非回环」
- * 或「平台不是 darwin/win32」时挂 browse，而**桌面 profile 宿主**（手机经 sidecar/中转
- * 连上的那种）两者都不满足，于是恒解析成 native —— 手机端一个条目都列不出来，只能登记
- * 一个恰好已存在的目录。现在这两个动词在宿主不服务 browse 时由插件自带实现兜底，见
- * lib/mobile/directory-browse.js。本模块仍只做与 sessions.js 相同的透传包装。
+ * directory-picker-auto 只在「web 服务绑到非回环」或「平台不是 darwin/win32」时挂 browse，
+ * 桌面 profile 宿主两者都不满足、恒解析成 native。所以宿主不服务 browse 时，两个目录动词由
+ * 插件自带实现兜底（见 lib/mobile/directory-browse.js）；本模块只做与 sessions.js 相同的
+ * 透传包装。
  */
 
 const { sendJson, readJsonBody } = require('../shared/http-util');
@@ -27,6 +24,7 @@ const { withIdempotency, requestIdOf } = require('./idempotency.js');
 const { canonicalDeviceKey } = require('./session-cache.js');
 const { unwrap } = require('./envelope.js');
 const { describeProjectGit } = require('./git-repos.js');
+const { listRoots } = require('./drive-roots.js');
 
 /** 调宿主 apiProxy.host.*（directory-picker 的 browse 能力）。 */
 function callHost(ctx, method, payload) {
@@ -167,6 +165,19 @@ async function handleListDirectory(ctx, req, res) {
   sendJson(res, 200, { ok: true, listing: value });
 }
 
+/**
+ * GET /api/mobile/v1/directory/roots（token）
+ * 「添加工作区」的盘符层：宿主 browse 后端只列某一层目录的内容、从不枚举盘符，而手机端的
+ * 目录浏览器一打开就落在被控端主目录 —— Windows 上它永远在 C 盘，别的盘没有任何入口。
+ * Windows 回真实存在的盘符，其余平台回文件系统根；只有一项时 App 不显示这一层。
+ *
+ * 不走宿主：host.listDirectory 只认路径、给不出一份根清单，而枚举本身与目录选择器的部署
+ * 形态无关（browse / native 两种宿主下答案一样）。
+ */
+async function handleDirectoryRoots(_ctx, _req, res) {
+  sendJson(res, 200, { ok: true, roots: await listRoots() });
+}
+
 /**
  * POST /api/mobile/v1/directory/create（token）{ path, name }
  * 透传宿主 host.createDirectory：在被控端 `path` 下新建名为 `name` 的文件夹。
@@ -339,6 +350,7 @@ module.exports = {
   handleMoveWorkspace,
   handleWorkspaces,
   handleListDirectory,
+  handleDirectoryRoots,
   handleCreateDirectory,
   handleCreateWorkspace,
   handleRenameWorkspace,