dsh-mobile-plugin 0.5.11 → 0.5.12

package/lib/impl.js

@@ -73,7 +73,20 @@ export const name = 'dsh-mobile-plugin'
 //
 // 旧运行时那一支多一个 `apiProxy`：宿主自己提供它（`@deepseek-ai/dsh-host-apiproxy` 装上
 // 了，就一定会被提供），读 `ctx.apiProxy` 必须有 inject，否则 get trap 直接抛。
-export const inject = runtimeProvidesApiProxy() ? ['webServer', 'apiProxy'] : ['webServer']
+//
+// **但「解析得到那个包」不等于「宿主一定会提供这个服务」**（2026-11-02 反馈 #11）：新版宿主
+// 上包名仍然解析得到，服务却已经删了。把 apiProxy 写进 inject 的代价是这一行**永远 pending**
+// —— apply 整个不跑，一条路由都不注册，手机上连「装了但连不上」都看不到。所以 inject 只剩
+// `webServer`，apiProxy 改由 apply 里按「过一小会儿真服务还没来就自己兜」决定，见下面的装配段。
+export const inject = ['webServer']
+
+/**
+ * 解析到包之后，等真服务的宽限期。
+ *
+ * 旧宿主在启动过程中就会 provide 出 apiProxy（本插件通常比它先挂），所以这段时间只用来看
+ * 「服务到底来不来」。等不到就说明这是新版宿主：包在、服务没了，必须自己挂兼容桥。
+ */
+const API_PROXY_GRACE_MS = 3000
 
 export const REMOTE_CONTROL_SETTINGS_NAMESPACE = 'mobile-remote-control'
 export const RemoteControlSettingsSchema = z.object({
@@ -232,10 +245,30 @@ function apply(ctx) {
       return undefined
     }
   }
-  if (!hasHostApiProxy) {
-    // `apiProxy` 是公共名字：另一个兼容旧 API 的插件也可能 provide 它。撞上时用对方那份
-    // （同形状、同语义），不跟它抢 —— 抢的结果是我们自己整块装配失败，手机那边全断。
+  /**
+   * 装兼容桥与两条帧桥（审批 / 提问）。
+   *
+   * 三者都只在「宿主这一代没有真 apiProxy」时才装：旧宿主自带真服务，多 provide 一次会让
+   * 整棵树加载失败（`service "apiProxy" has been registered at <dsh-mobile-plugin>`）。
+   * 而 `apiProxy` 是公共名字：另一个兼容旧 API 的插件也可能 provide 它，撞上时用对方那份。
+   */
+  const installCompatBridges = () => {
     mount('apiProxy 兼容桥', () => ctx.reflect.provide('apiProxy', createApiProxy(ctx)))
+    mount('审批桥', () => ctx.effect(() => installApprovalBridge(ctx), `${name}: host approval bridge`))
+    mount('提问桥', () => ctx.effect(() => installQuestionBridge(ctx), `${name}: host question bridge`))
+  }
+  if (!hasHostApiProxy) installCompatBridges()
+  else {
+    // 解析到包只说明「宿主可能是旧版」：新版宿主上包名还在、`apiProxy` 服务已经没了
+    // （2026-11-02 反馈 #11）。先给它一会儿把真服务 provide 出来（旧宿主在本插件装配
+    // 前后就会挂上），到点还没有就当作新版宿主，自己把兼容桥与两条帧桥装上 —— 否则
+    // 十几个移动端模块读到的是一个永远不来的服务，手机侧全程静默失败。
+    const timer = setTimeout(() => {
+      if (typeof ctx.get === 'function' && ctx.get('apiProxy')) return
+      warn('等不到宿主的 apiProxy，按新版宿主装配兼容桥')
+      installCompatBridges()
+    }, API_PROXY_GRACE_MS)
+    timer.unref?.()
   }
 
   const state = core.loadState()
@@ -310,8 +343,6 @@ function apply(ctx) {
   mount('sidecar', () => ctx.effect(() => sidecarLifecycle.start(), `${name}: facade sidecar`))
   mount('镜像推送', () => ctx.effect(() => mirror.start(), `${name}: mobile mirror sync`))
 
-  if (!hasHostApiProxy) mount('审批桥', () => ctx.effect(() => installApprovalBridge(ctx), `${name}: host approval bridge`))
-  if (!hasHostApiProxy) mount('提问桥', () => ctx.effect(() => installQuestionBridge(ctx), `${name}: host question bridge`))
   ctx.effect(() => {
     // Profiles without the optional tools injection still support core remote control.
     try { installSessionCleanup(ctx) } catch (error) {

package/lib/mobile/model-vendors.js

@@ -102,4 +102,19 @@ function vendorLogoOf(vendor) {
   return entry ? { name: entry.name, icon: entry.icon } : null;
 }
 
-module.exports = { foldText, tokensOf, vendorOfText, identifyVendor, vendorLogoOf, VENDOR_PATTERNS };
+/** 给已清洗的模型目录标厂商，并只返回这份目录实际用到的图标。 */
+function decorateModelGroups(groups) {
+  const vendors = {};
+  for (const group of groups) {
+    for (const model of group.models) {
+      const vendor = identifyVendor({ modelName: model.name, model: model.id, providerName: group.name, provider: group.id });
+      if (!vendor) continue;
+      model.vendor = vendor;
+      const logo = vendorLogoOf(vendor);
+      if (logo) vendors[vendor] = logo;
+    }
+  }
+  return vendors;
+}
+
+module.exports = { foldText, tokensOf, vendorOfText, identifyVendor, vendorLogoOf, decorateModelGroups, VENDOR_PATTERNS };

package/lib/mobile/session-models.js

@@ -1,7 +1,7 @@
 'use strict';
 
 /**
- * 模型目录：会话当前选择 + 可用模型分组 + 各档推理强度，外加「切模型」动作。
+ * 模型目录：会话当前选择 + 可用模型分组 + 厂商标识与图标 + 各档推理强度，外加「切模型」动作。
  *
  * 形状校验（safeModelsValue）与 TTL 缓存是这里的核心，两处都有非平凡的理由：
  *  1. safeModelsValue 不是防御性洁癖——宿主是另一个进程，它给的形状会随版本变，
@@ -15,6 +15,7 @@ const { unwrap } = require('./envelope.js');
 const { callSessions } = require('./rpc.js');
 const { canonicalDeviceKey, sessionModelsStateOf, invalidateSessionModels } = require('./session-cache.js');
 const { readModelOptions, safeModelOptions } = require('./session-model-options.js');
+const { decorateModelGroups } = require('./model-vendors.js');
 
 const SESSION_MODELS_CACHE_MS = 20000; // 模型目录短 TTL；成功后 stale-while-revalidate
 
@@ -91,6 +92,8 @@ function safeModelsValue(value) {
               : {}),
           })),
       }));
+    const vendors = decorateModelGroups(result.groups);
+    if (Object.keys(vendors).length > 0) result.vendors = vendors;
   }
   // 模型之外的附加选项行（速度、输出详略……）：行数与内容都由 session-model-options.js
   // 那张描述表决定，App 只按收到的数组逐行画。空数组不下发（旧宿主没有这个字段）。
@@ -165,7 +168,7 @@ async function buildModelsSnapshot(ctx, sessionId) {
 
 /** GET /api/mobile/v1/session/models?sessionId=…（token）
  * 返回会话当前模型选择与可用模型目录（透传宿主 session.models）。
- * 响应：{ ok, current, defaultModel, routable, groups, options?, failures }。
+ * 响应：{ ok, current, defaultModel, routable, groups, vendors?, options?, failures }。
  * `current` 是这个会话实际会用的，`defaultModel` 是全局默认（新建会话的落点），
  * `options` 是当前渠道的附加选项行，没有就没有这个字段。
  */

package/lib/mobile/uploads.js

@@ -17,6 +17,10 @@
  *
  * 顺序与幂等：chunk 只接受下一片，重复送达同一片按重传处理，跳号直接 409。
  *
+ * 图片走两段：先按上面那套把字节传完拿 uploadId，`session/send` 再把 uploadId 换回内联
+ * base64 交给宿主 prompt。换的时候整份字节要读进内存 —— 宿主只认内联块，这条通道没有流式
+ * 入口。也正因为如此，单张图片的大小上限由桌面端的附件限制定，这里不设体积门槛。
+ *
  * 收件根固定 `~/.dsh/mobile-inbox`，与工作区解耦（工作区被删不影响已收到的文件）；
  * `DSH_MOBILE_INBOX` 可覆盖，只给测试用。
  */
@@ -44,8 +48,13 @@ const CHUNK_MAX_BYTES = 2 * 1024 * 1024;
 const CHUNK_MAX_BODY = Math.ceil(8 * 1024 * 1024 * 4 / 3);
 /** 文件名上限（按字符算，避开各文件系统的字节上限差异）。 */
 const NAME_MAX_CHARS = 120;
-/** 暂存残片的最长寿命：手机上传中断后没人来 abort 的清理依据。 */
-const STAGING_TTL_MS = 24 * 60 * 60 * 1000;
+/**
+ * 暂存残片的最长寿命：手机上传中断后没人来 abort 的清理依据。
+ *
+ * 7 天，跟着手机侧的续传凭据走：凭据活多久，暂存就得留多久，否则手机回来续传的第一片必撞
+ * 404（判据见 `app/src/services/viewmodels/upload-resume.ts` 的 `HOST_STAGING_TTL_MS`）。
+ */
+const STAGING_TTL_MS = 7 * 24 * 60 * 60 * 1000;
 /** 分片必须是标准 base64：Node 的 Buffer.from 会静默丢弃非法字符，光靠解码判不出坏片。 */
 const BASE64_RE = /^[A-Za-z0-9+/]*={0,2}$/;
 
@@ -265,7 +274,7 @@ async function handleUploadBegin(ctx, req, res) {
   if (!body || typeof body.name !== 'string' || !body.name.trim()) {
     return fail(res, 400, 'bad-request', '需要 { name }');
   }
-  // 落点先判：越界 / 不是目录在这一步就回，不先建暂存再报错 —— 残片要躺满 24 小时才清。
+  // 落点先判：越界 / 不是目录在这一步就回，不先建暂存再报错 —— 残片要躺满 7 天才清。
   const destination = await resolveDestDir(ctx, body);
   if (destination.status) return fail(res, destination.status, destination.code, destination.message);
   const stagingDir = path.join(inboxRoot(), '.staging');
@@ -379,9 +388,6 @@ async function handleUploadAbort(_ctx, req, res) {
   sendJson(res, 200, { ok: true });
 }
 
-/** 一张图片的明文上限：超过就按「传太大」拒，而不是把宿主内存撑爆。 */
-const MAX_IMAGE_UPLOAD_BYTES = 10 * 1024 * 1024;
-
 const UPLOAD_EXPIRED_MESSAGE = '这张图片的上传已过期，请重新发送';
 
 /**
@@ -390,6 +396,10 @@ const UPLOAD_EXPIRED_MESSAGE = '这张图片的上传已过期，请重新发送
  * 宿主的 `session.prompt` 只认 `{type:'image', mediaType, data}`，所以这一步要在宿主
  * 那一跳之前完成：手机到宿主这一段只传 uploadId，字节早就在分片上传时落盘了。
  *
+ * 整份读进内存是这条通道的形状决定的 —— 内联块本身就是一个 base64 字符串，没有按流交给宿主
+ * 的入口。也是因此这里不设体积门槛：单张多大由桌面端的附件限制定，真超了由宿主在 prompt 那
+ * 一跳用原话回绝；插件再拦一道，只会把「宿主说附件太大」变成一句假的「上传已过期」。
+ *
  * @returns {Promise<string|null>} 有块补不上就回一句给用户看的话，全补上了回 null。
  */
 async function inlineUploadedImageBlocks(content) {
@@ -400,7 +410,7 @@ async function inlineUploadedImageBlocks(content) {
     if (!record) return UPLOAD_EXPIRED_MESSAGE;
     try {
       const bytes = await fsp.readFile(record.path);
-      if (!bytes.length || bytes.length > MAX_IMAGE_UPLOAD_BYTES) return UPLOAD_EXPIRED_MESSAGE;
+      if (!bytes.length) return UPLOAD_EXPIRED_MESSAGE;
       block.data = bytes.toString('base64');
       if (!block.name) block.name = record.name;
     } catch {