From 683c4cdeff25aef40140ae6396177d003824c2a3 Mon Sep 17 00:00:00 2001 From: maogeigei Date: Mon, 14 Sep 2026 21:38:57 +0800 Subject: [PATCH] =?UTF-8?q?fix(mem):=20=E5=86=85=E5=AD=98=E5=8F=A3?= =?UTF-8?q?=E5=BE=84=E5=AE=9A=E6=A1=88=20=E2=80=94=E2=80=94=20BASE=20448?= =?UTF-8?q?=20/=20MIN=20448=20/=20MAX=201024=EF=BC=88=E7=94=A8=E6=88=B7?= =?UTF-8?q?=E8=A3=81=E5=AE=9A=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 用户裁定：「base 448 没问题 max 就是 1024」。据此把两侧常量收成一份事实 （编排器 instanceMemMb() 与插件客户端 MEM_* 必须逐值一致，verify-mem-model 会守着）： · BASE 160 → 448：0.1.5 基座**实测 312 MiB**，旧值按 0.1.2 的 106~145 估的、严重低估 ⇒ 384 的上限里只剩 72 MiB 给插件，这正是宿主 swap 被吃掉（452 MiB）的原因 · MIN 384 → 448：**MIN 必须 ≥ BASE**，否则 clamp(raw, MIN, MAX) 的下限失去意义 （旧 384 在 BASE=160 时满足该不变量，抬 BASE 后必须跟着抬） · MAX 1536 → 1024：不是偏好，而是编排器头部既有的不变量 「上限 1024M 是单实例硬顶（宿主 1870M）」；在途草稿的 1536 与宿主容量前提自相矛盾 · mcn 成本表保持 128（驳回草稿的 256）：无可支撑抬高的实测，反向有证据 —— 装了它的用户在旧 384 上限下一直跑得住 ⇒ 需求 ≤384；而抬高会直接吃宿主余量 实测（铺发+重启后经 /api/dsh/status 核对）：admin 384→576、guest 384→448， 均在 [448,1024] 内；heapMb 256；两实例 restarts:0。宿主可用 761→1267 MiB。 本机 verify-mem-model 与 npm run verify 均**首次全绿**。 插件 business-plugins 0.3.16 → 0.3.17（客户端常量随之更新）。 --- poc/business-plugins/lib/client.js | 9 +++++---- poc/business-plugins/package.json | 4 ++-- src/supervisor/orchestrator.ts | 14 ++++++++++++-- 3 files changed, 19 insertions(+), 8 deletions(-) diff --git a/poc/business-plugins/lib/client.js b/poc/business-plugins/lib/client.js index 494525d..93582ed 100644 --- a/poc/business-plugins/lib/client.js +++ b/poc/business-plugins/lib/client.js @@ -94,10 +94,11 @@ window.__ModuleLoader__.load({ // 而平台真实配额是 672（guest）/ 384（admin），**384 早已只是下限** ⇒ 纯属误报。 // 修法：① 常量与规则对齐平台；② 优先读 `/api/dsh/status` 的 `quota.memMb/heapMb` // （平台**实际使用**的值）直接显示；③「超限」改为判断是否顶到硬顶 MAX。 - /** 与编排器 `BASE_MEM_MB` 一致。 */ - var MEM_BASE_MIB = 160; - /** 与编排器 `MIN_MEM_MB` 一致 —— ⚠️ 这是**下限**，不是上限。 */ - var MEM_MIN_MIB = 384; + // 2026-09-14 定案（BASE 448 / MIN 448 / MAX 1024）：与编排器 instanceMemMb() 是**同一份事实**，两处必须逐值一致； scripts/verify-mem-model.mjs 会逐键比对。 + /** 与编排器 `BASE_MEM_MB` 一致。0.1.5 基座实测 312 MiB ⇒ 抬到 448（旧值 160 按 0.1.2 的 106~145，严重低估）。 */ + var MEM_BASE_MIB = 448; + /** 与编排器 `MIN_MEM_MB` 一致 —— ⚠️ 这是**下限**，不是上限；**必须 ≥ BASE**，否则下限失去意义。 */ + var MEM_MIN_MIB = 448; /** 与编排器 `MAX_MEM_MB` 一致 —— 单实例硬顶。 */ var MEM_MAX_MIB = 1024; /** 与编排器 `PLUGIN_MEM_MB` 一致；未识别的插件平台按 0 计。 */ diff --git a/poc/business-plugins/package.json b/poc/business-plugins/package.json index 7ed1bc6..8ec28f9 100644 --- a/poc/business-plugins/package.json +++ b/poc/business-plugins/package.json @@ -1,7 +1,7 @@ { "name": "@dsh-local/business-plugins", - "version": "0.3.16", - "description": "功能管理（原「功能插件」）section for dsh web profile — v0.3.16（2026-09-14）：**官方推荐插件列表按 dsh 版本过滤**（用户：「插件管理中的官方推荐插件列表 只能显示匹配当前dsh版本 和 超过当前版本的插件（超过的要明确标注）」）。① 官方目录（`awesome-dsh-plugin.com/plugins.json`）**不带 dsh 版本字段** ⇒ 平台侧逐包查 npm 精简 packument 的 `peerDependencies / engines` 与**平台真实版本**比对，分类 `match / none / newer / older / unknown`（判定在 `src/web/plugin-dsh-compat.ts`）；② **默认隐藏 `older`**（只声明了更旧版本），`newer`（要求更高的 dsh）**橙色显著标注**并在 tooltip 给出「需 ≥ X，当前 Y」；③ 说明行给出「已按 dsh X 过滤，隐藏 N 个…」且**勾选框「含仅兼容更旧版本的」是显式逃生口** —— 绝不让条目静默消失；④ 判定结果按 `@<版本>` 落盘缓存 7 天，首次进页后台预热全量，请求内只给 6s 预算、超预算判 `unknown` 并**照常显示**（网络抖动不该等同「不兼容」）；⑤ ⚠️ 语义：判 `satisfies` **必须带 `includePrerelease: true`** —— 平台版本是 prerelease，默认语义下 `^0.1.2` 甚至 `*` 都不满足，实测 TOP300 会把 `dsh-univer-office`/`dshmarket` 这类**在跑的**插件误判为 older（`match 97/older 139` → 容忍后 `match 214/older 22`）；且**伞包 `@deepseek-ai/dsh` 必须单独解析**（它不在自己的 node_modules 里，而那 3 条 `newer` 全部只写在伞包上）。｜v0.3.15（2026-09-14）：**删除条目补二次确认**（官方 `deleteDialog` 的等价物）。原「删除」紧挨着「停用」且**无任何确认** ⇒ 一次误点就连已存储的 API 密钥一起删掉（`DELETE /api/me/keys/:id` 不可撤销，用户只能重新粘贴密钥）；现改为弹窗**点名该提供方**（`ms.delTitle` / `ms.delDesc` / `ms.delConfirm`）后才执行，遮罩点击或「取消」可关。｜v0.3.14（2026-09-14）：**「模型设置」页按官方 `dsh-client-ui-settings-models` 复刻交互**（用户：「admin模型设置和状态 一个名称换行了，另一个两个按钮换行了，交互体验需要优化…新增模型的操作交互和官方原始新增模型的交互差距很大，建议仔细参考 复刻官方的交互」）。① **换行根因**：原「我已添加的厂家」是 4 列表格（`pa-tbl` 自动列宽）⇒「内置 DeepSeek」与「停用/删除」被挤到换行；改为**官方卡片行**（`ms-rowCard`/`ms-rowHead`/`ms-rowIdentity`/`ms-rowActions`，名称与按钮两侧均 `nowrap`）⇒ **结构上不可能换行**，状态文字下沉到独占一行的副标题。② **新增流程改为官方的两步式**：默认只露**两个虚线按钮**（「+ 添加提供方」/「+ 添加自定义提供方」，`flex:1 1 0;min-width:180px;height:44px`），点击才展开卡片 —— 旧版是「常开表单 + 厂家下拉里混一项『自定义厂家…』」。③ 新增卡片**主字段是单独一个「API 密钥」输入框**（官方原文：页面从不问环境变量名），显示名挪进收起的「自定义设置」`
`；自定义卡片按官方字段序（Provider ID → 显示名称 → API 地址 → API 协议 → API 密钥 → 模型目录），模型目录由**一行一个的文本框**改成官方的**行式编辑器**（`+ 添加模型` / 行尾 ✕ 删除）。④ CSS 数值**逐值照抄**官方 CSS 模块（圆角 16/18/14/12/10/8/6/4、字号 14/12/11、行高 22/18/16、按钮高 36/28/44px），颜色走同一批 `--dsw-*` token。⑤ 顺带修两处文案缺陷：admin 自己看共享模型卡片时原写「由 admin 配置」（后端早已给 `ownerIsMe`）⇒ 改「由你配置」；「内置 DeepSeek 密钥留空则回落平台共享密钥」是**错的**（`keyAddSchema` 里 `apiKey` 是 `required + minLength:1`，留空必得 400）⇒ 改为「输入你的 DeepSeek API 密钥」。⑥ 新增 `scripts/verify-models-dict.mjs` 断言 zh/en 键集一致 + 代码引用的键都已声明（本轮就是靠它抓到 `ms.needUrl`/`ms.needModels` 被引用未声明）。｜v0.3.10（2026-09-13）：① **「服务管理」改名「实例管理」**、**「密钥管理」改名「模型管理」**（用户要求；门户导航/卡片同步改名）；② **「实例管理」页可管任意用户**（用户要求「admin 要能管所有用户的服务」）—— 工具条新增「用户」下拉，切换后文件树/启停/打开全部针对所选用户，走新开的 `/api/admin/users/:id/{fs,dsh}`（requireAdmin）｜v0.3.8（2026-09-13）：**撤掉「我的密钥」分区** —— 模型配置统一走**官方「设置 → 模型」页**（用户要求「界面交互和官方一模一样」⇒ 不仿制、直接放开官方页，见档案 86）。平台侧同步两处：① `ensure-role-profile-patch.cjs` 不再禁用 `ui-settings-models`（实测官方页在本环境可用：`/api/session/modelCatalog` 返回 200）；② `src/web/server.ts` 的 `resolveApiKey()` 改为「用户已自配 ⇒ **不注入共享 env**」——因为 dsh 凭据解析里 `inherited process environment` **优先级最高**，不这样做用户配的 key 会被静默盖掉。｜v0.3.7（2026-09-13 · 原拟 0.3.6，因并行会话已用同号 0.3.6 铺发过「内存条」版本 ⇒ 提升为 0.3.7）：① ~~新增「我的密钥」分区~~（**已于 0.3.8 撤除**，原因是两套入口会互相干扰） —— 用户自助配置自己的模型密钥（自配自用），不配置就用「平台共享密钥」（管理员配置）；页面分两段：我的密钥（添加 / 启用 / 删除）+ 当前生效（明示在用谁的 key，并提示改 key 只重启自己的实例、不影响他人）。配套后端：`/api/me/keys` 由 requireAdmin 放开为 requireAuth，`resolveApiKey(userId)` 改为「先取自己的 → 取不到回落管理员的共享 key」两级；门户「密钥管理」文案同步改为「平台共享密钥」。② **内存条改读平台真实配额，消灭「388 MiB 误报」**（用户问「实例内存大小是不是调整过了，为什么功能设置中还是显示 388 多」）。根因：本插件自建了**第二套**内存模型（基线 285 / univer 64 / mcn 39，并把 clamp 下限 384 当硬上限判超限），而平台编排器自 R1 起为「按插件集合推导」（base 160 / univer 512 / mcn 128 / clamp 384–1024），两处从未对齐 ⇒ 全勾显示 388 并报「⚠ 将超出上限」，真值却是 672（guest）/ 384（admin）。本轮：① 常量与规则逐项对齐编排器，并新增 `scripts/verify-mem-model.mjs` 在 `npm run verify` 里交叉断言（漂了就构建失败）；② 优先读 `/api/dsh/status` 新增的 `quota{memMb,heapMb}`（平台**实际使用**的值，与 spawn 同源）直接显示「实际配额 · V8 堆」；③ 超限判断改为「原始需求 > 硬顶 1024」；④ 未进成本表的插件不再显示 ≈0 MiB 徽章。｜v0.3.5（2026-09-13）：**插件管理 →「官方推荐插件」列表高度拉高**（用户要求「高度可以增加，距离底部 100px 就行」）—— 该表 max-height 由固定 420px 改为 `max(280px, min(calc(92vh - 470px), 580px))`（类 `.pa-plist`），按弹窗高度反推、使列表底部**距弹窗底部约 100px**；下限 280px 防小屏压扁，上限 580px 对应弹窗触顶 1040px。｜v0.3.4（2026-09-13）：**「系统管理」全面对齐门户 web/portal.html 的 6 个功能页**（用户要求「点开弹窗里面展示的内容，要和 portal 点击功能后那种详细的表格和功能一致」）—— 分区首页 = 门户 renderHome（「服务」「管理」两组 + .nav-card 三行卡片）；点开每一项 = 门户**那一页的完整页面**：服务管理（文件树 + 启动/停止/打开 DSH + 新建文件夹/上传）、密钥管理（全局 API 密钥增删启用）、用户管理（审批/禁用/恢复/删除，需输入用户名二次确认）、技能管理（.zip 上传/替换/删除）、插件管理（官方推荐插件 + 手动添加/管理双页签、搜索/分类/只看可导入/重新拉取/批量导入、.tgz 投放含 P0 扫描与显式信任）、运行环境（版本表 + 漂移提示 + 目录/体积 + 折叠说明）；表格列 / 按钮 / 文案逐字一致（`PA_PAGES` 逐函数移植 portal 的 renderXxx/initXxx，只改 3 处：局部 `$` 查询器、跨子域 `paReq`、去掉 hash 路由）；弹窗宽度对齐门户功能页 min(1440px,96vw)、高 92vh。写操作就地调平台 admin API（跨子域 + credentials:include，CORS 白名单已含 GET/POST/DELETE）。**已删除**旧版自造的 5 项只读摘要（用户管理 / 候选池 / 运行时 / 存储 / 当前实例）。⚠️ 顺带修掉门户 `readAsBase64()` 缺 await 导致上传恒传空数据的缺陷（弹窗侧已修正，门户侧待同修）。｜v0.3.3（2026-09-13）：「系统管理」视觉层照抄门户组件（.nav-card / .pg-cnt / .table-wrap + table.tbl / .badge / .btn-sm / .page-title）。｜v0.2.8（2026-09-13）：所有弹窗改页内弹窗（弃用 window.confirm）。｜v0.2.7（档案 75）：卡片加内存预估徽章 + 列表上方内存预估状态条。｜v0.2.4（档案 67）：对齐 06-工作台UI规范（信息层次反转 / 字号阶梯 / 行 hover）。｜v0.2.2：分区名由「功能插件」改为「功能管理」。｜v0.2.0：配色改用官方 --dsw-* design token（跟随 dsh 主题）；文案走官方 locale（zh/en）。", + "version": "0.3.17", + "description": "功能管理（原「功能插件」）section for dsh web profile — v0.3.17（2026-09-14）：**内存口径定案**（BASE 448 / MIN 448 / MAX 1024，插件成本表 univer 512、mcn 128）—— 与编排器 `instanceMemMb()` 逐值对齐（`verify-mem-model.mjs` 会红着提醒）。① BASE 160→448：0.1.5 基座**实测 312 MiB**，旧值按 0.1.2 的 106~145 估的，严重低估 ⇒ 384 的上限里只剩 72 MiB 给插件，这正是宿主 swap 被吃掉的原因；② **MIN 必须 ≥ BASE**（否则 `clamp(raw, MIN, MAX)` 的下限失去意义）⇒ MIN 384→448；③ **MAX 保持 1024**（不是偏好：编排器头部已写「上限 1024M 是单实例硬顶（宿主 1870M）」这一不变量，在途草稿的 1536 与宿主容量前提自相矛盾，已驳回）；④ mcn 套件**保持 128**：无可支撑抬高的实测，反向有证据（装了它的用户在旧 384 上限下一直跑得住 ⇒ 需求 ≤384），而抬高会直接吃宿主余量（1870M / 可用 ≈761M / swap 已用 452M）。｜v0.3.16（2026-09-14）：**官方推荐插件列表按 dsh 版本过滤**（用户：「插件管理中的官方推荐插件列表 只能显示匹配当前dsh版本 和 超过当前版本的插件（超过的要明确标注）」）。① 官方目录（`awesome-dsh-plugin.com/plugins.json`）**不带 dsh 版本字段** ⇒ 平台侧逐包查 npm 精简 packument 的 `peerDependencies / engines` 与**平台真实版本**比对，分类 `match / none / newer / older / unknown`（判定在 `src/web/plugin-dsh-compat.ts`）；② **默认隐藏 `older`**（只声明了更旧版本），`newer`（要求更高的 dsh）**橙色显著标注**并在 tooltip 给出「需 ≥ X，当前 Y」；③ 说明行给出「已按 dsh X 过滤，隐藏 N 个…」且**勾选框「含仅兼容更旧版本的」是显式逃生口** —— 绝不让条目静默消失；④ 判定结果按 `@<版本>` 落盘缓存 7 天，首次进页后台预热全量，请求内只给 6s 预算、超预算判 `unknown` 并**照常显示**（网络抖动不该等同「不兼容」）；⑤ ⚠️ 语义：判 `satisfies` **必须带 `includePrerelease: true`** —— 平台版本是 prerelease，默认语义下 `^0.1.2` 甚至 `*` 都不满足，实测 TOP300 会把 `dsh-univer-office`/`dshmarket` 这类**在跑的**插件误判为 older（`match 97/older 139` → 容忍后 `match 214/older 22`）；且**伞包 `@deepseek-ai/dsh` 必须单独解析**（它不在自己的 node_modules 里，而那 3 条 `newer` 全部只写在伞包上）。｜v0.3.15（2026-09-14）：**删除条目补二次确认**（官方 `deleteDialog` 的等价物）。原「删除」紧挨着「停用」且**无任何确认** ⇒ 一次误点就连已存储的 API 密钥一起删掉（`DELETE /api/me/keys/:id` 不可撤销，用户只能重新粘贴密钥）；现改为弹窗**点名该提供方**（`ms.delTitle` / `ms.delDesc` / `ms.delConfirm`）后才执行，遮罩点击或「取消」可关。｜v0.3.14（2026-09-14）：**「模型设置」页按官方 `dsh-client-ui-settings-models` 复刻交互**（用户：「admin模型设置和状态 一个名称换行了，另一个两个按钮换行了，交互体验需要优化…新增模型的操作交互和官方原始新增模型的交互差距很大，建议仔细参考 复刻官方的交互」）。① **换行根因**：原「我已添加的厂家」是 4 列表格（`pa-tbl` 自动列宽）⇒「内置 DeepSeek」与「停用/删除」被挤到换行；改为**官方卡片行**（`ms-rowCard`/`ms-rowHead`/`ms-rowIdentity`/`ms-rowActions`，名称与按钮两侧均 `nowrap`）⇒ **结构上不可能换行**，状态文字下沉到独占一行的副标题。② **新增流程改为官方的两步式**：默认只露**两个虚线按钮**（「+ 添加提供方」/「+ 添加自定义提供方」，`flex:1 1 0;min-width:180px;height:44px`），点击才展开卡片 —— 旧版是「常开表单 + 厂家下拉里混一项『自定义厂家…』」。③ 新增卡片**主字段是单独一个「API 密钥」输入框**（官方原文：页面从不问环境变量名），显示名挪进收起的「自定义设置」`
`；自定义卡片按官方字段序（Provider ID → 显示名称 → API 地址 → API 协议 → API 密钥 → 模型目录），模型目录由**一行一个的文本框**改成官方的**行式编辑器**（`+ 添加模型` / 行尾 ✕ 删除）。④ CSS 数值**逐值照抄**官方 CSS 模块（圆角 16/18/14/12/10/8/6/4、字号 14/12/11、行高 22/18/16、按钮高 36/28/44px），颜色走同一批 `--dsw-*` token。⑤ 顺带修两处文案缺陷：admin 自己看共享模型卡片时原写「由 admin 配置」（后端早已给 `ownerIsMe`）⇒ 改「由你配置」；「内置 DeepSeek 密钥留空则回落平台共享密钥」是**错的**（`keyAddSchema` 里 `apiKey` 是 `required + minLength:1`，留空必得 400）⇒ 改为「输入你的 DeepSeek API 密钥」。⑥ 新增 `scripts/verify-models-dict.mjs` 断言 zh/en 键集一致 + 代码引用的键都已声明（本轮就是靠它抓到 `ms.needUrl`/`ms.needModels` 被引用未声明）。｜v0.3.10（2026-09-13）：① **「服务管理」改名「实例管理」**、**「密钥管理」改名「模型管理」**（用户要求；门户导航/卡片同步改名）；② **「实例管理」页可管任意用户**（用户要求「admin 要能管所有用户的服务」）—— 工具条新增「用户」下拉，切换后文件树/启停/打开全部针对所选用户，走新开的 `/api/admin/users/:id/{fs,dsh}`（requireAdmin）｜v0.3.8（2026-09-13）：**撤掉「我的密钥」分区** —— 模型配置统一走**官方「设置 → 模型」页**（用户要求「界面交互和官方一模一样」⇒ 不仿制、直接放开官方页，见档案 86）。平台侧同步两处：① `ensure-role-profile-patch.cjs` 不再禁用 `ui-settings-models`（实测官方页在本环境可用：`/api/session/modelCatalog` 返回 200）；② `src/web/server.ts` 的 `resolveApiKey()` 改为「用户已自配 ⇒ **不注入共享 env**」——因为 dsh 凭据解析里 `inherited process environment` **优先级最高**，不这样做用户配的 key 会被静默盖掉。｜v0.3.7（2026-09-13 · 原拟 0.3.6，因并行会话已用同号 0.3.6 铺发过「内存条」版本 ⇒ 提升为 0.3.7）：① ~~新增「我的密钥」分区~~（**已于 0.3.8 撤除**，原因是两套入口会互相干扰） —— 用户自助配置自己的模型密钥（自配自用），不配置就用「平台共享密钥」（管理员配置）；页面分两段：我的密钥（添加 / 启用 / 删除）+ 当前生效（明示在用谁的 key，并提示改 key 只重启自己的实例、不影响他人）。配套后端：`/api/me/keys` 由 requireAdmin 放开为 requireAuth，`resolveApiKey(userId)` 改为「先取自己的 → 取不到回落管理员的共享 key」两级；门户「密钥管理」文案同步改为「平台共享密钥」。② **内存条改读平台真实配额，消灭「388 MiB 误报」**（用户问「实例内存大小是不是调整过了，为什么功能设置中还是显示 388 多」）。根因：本插件自建了**第二套**内存模型（基线 285 / univer 64 / mcn 39，并把 clamp 下限 384 当硬上限判超限），而平台编排器自 R1 起为「按插件集合推导」（base 160 / univer 512 / mcn 128 / clamp 384–1024），两处从未对齐 ⇒ 全勾显示 388 并报「⚠ 将超出上限」，真值却是 672（guest）/ 384（admin）。本轮：① 常量与规则逐项对齐编排器，并新增 `scripts/verify-mem-model.mjs` 在 `npm run verify` 里交叉断言（漂了就构建失败）；② 优先读 `/api/dsh/status` 新增的 `quota{memMb,heapMb}`（平台**实际使用**的值，与 spawn 同源）直接显示「实际配额 · V8 堆」；③ 超限判断改为「原始需求 > 硬顶 1024」；④ 未进成本表的插件不再显示 ≈0 MiB 徽章。｜v0.3.5（2026-09-13）：**插件管理 →「官方推荐插件」列表高度拉高**（用户要求「高度可以增加，距离底部 100px 就行」）—— 该表 max-height 由固定 420px 改为 `max(280px, min(calc(92vh - 470px), 580px))`（类 `.pa-plist`），按弹窗高度反推、使列表底部**距弹窗底部约 100px**；下限 280px 防小屏压扁，上限 580px 对应弹窗触顶 1040px。｜v0.3.4（2026-09-13）：**「系统管理」全面对齐门户 web/portal.html 的 6 个功能页**（用户要求「点开弹窗里面展示的内容，要和 portal 点击功能后那种详细的表格和功能一致」）—— 分区首页 = 门户 renderHome（「服务」「管理」两组 + .nav-card 三行卡片）；点开每一项 = 门户**那一页的完整页面**：服务管理（文件树 + 启动/停止/打开 DSH + 新建文件夹/上传）、密钥管理（全局 API 密钥增删启用）、用户管理（审批/禁用/恢复/删除，需输入用户名二次确认）、技能管理（.zip 上传/替换/删除）、插件管理（官方推荐插件 + 手动添加/管理双页签、搜索/分类/只看可导入/重新拉取/批量导入、.tgz 投放含 P0 扫描与显式信任）、运行环境（版本表 + 漂移提示 + 目录/体积 + 折叠说明）；表格列 / 按钮 / 文案逐字一致（`PA_PAGES` 逐函数移植 portal 的 renderXxx/initXxx，只改 3 处：局部 `$` 查询器、跨子域 `paReq`、去掉 hash 路由）；弹窗宽度对齐门户功能页 min(1440px,96vw)、高 92vh。写操作就地调平台 admin API（跨子域 + credentials:include，CORS 白名单已含 GET/POST/DELETE）。**已删除**旧版自造的 5 项只读摘要（用户管理 / 候选池 / 运行时 / 存储 / 当前实例）。⚠️ 顺带修掉门户 `readAsBase64()` 缺 await 导致上传恒传空数据的缺陷（弹窗侧已修正，门户侧待同修）。｜v0.3.3（2026-09-13）：「系统管理」视觉层照抄门户组件（.nav-card / .pg-cnt / .table-wrap + table.tbl / .badge / .btn-sm / .page-title）。｜v0.2.8（2026-09-13）：所有弹窗改页内弹窗（弃用 window.confirm）。｜v0.2.7（档案 75）：卡片加内存预估徽章 + 列表上方内存预估状态条。｜v0.2.4（档案 67）：对齐 06-工作台UI规范（信息层次反转 / 字号阶梯 / 行 hover）。｜v0.2.2：分区名由「功能插件」改为「功能管理」。｜v0.2.0：配色改用官方 --dsw-* design token（跟随 dsh 主题）；文案走官方 locale（zh/en）。", "type": "module", "main": "lib/index.js", "exports": { diff --git a/src/supervisor/orchestrator.ts b/src/supervisor/orchestrator.ts index 02b0356..8d979f6 100644 --- a/src/supervisor/orchestrator.ts +++ b/src/supervisor/orchestrator.ts @@ -78,10 +78,20 @@ const WATCHDOG_TASK = 'Read DSHS_HANDOFF_PATH. If it contains a JSON {"command": * ──────────────────────────────────────────────────────────────────────────── */ const PLUGIN_MEM_MB: Record = { 'dsh-univer-office': 512, // 实测其 gateway 单进程 ≈390 MB（2026-09-13 14:44 384→512：544 仍欠 ~50-120 MiB，实测 gateway 起不来；512 ⇒ 配额 672） + // ⚠️ mcn 套件**保持 128**（2026-09-14 定案）：没有实测依据支撑抬高 —— 反而有反向证据： + // 装了它的那个用户在**旧 384 上限**下一直跑得住 ⇒ 需求 ≤384。上限抬升会直接吃宿主机余量 + // （宿主 1870M / 可用 ≈761M / swap 已用 452M），等有实测再抬。 'dsh-plugin-mcn-suite': 128, // 7 插件整合包（含 xlsx 等重型依赖） } -const BASE_MEM_MB = 160 // dsh 基座（实测稳态 106~117、峰值约 145） -const MIN_MEM_MB = 384 // 不低于原写死值（等于零回归） +// BASE 448（2026-09-14 用户裁定）：0.1.5 基座**实测 312 MiB**，旧值 160（按 0.1.2 的 106~145）严重低估 +// —— 384 的上限里只剩 72 MiB 给插件，正是宿主 swap 被吃掉的原因；抬高 BASE 是**修正低估**。 +const BASE_MEM_MB = 448 +// MIN 必须 ≥ BASE，否则 `clamp(mb, MIN, MAX)` 里的 MIN 失去意义（永远不会低于 BASE）。 +// 故取 MIN = BASE = 448（旧值 384 在 BASE=160 时满足该不变量，抬 BASE 后必须跟着抬）。 +const MIN_MEM_MB = 448 +// MAX 保持 1024 —— 这不是偏好，而是**本文档头部已写明的不变量**： +// 「上限 1024M 是单实例硬顶（宿主 1870M）」。2026-09-14 用户裁定「max 就是 1024」； +// 在途草稿里的 1536 与宿主机容量前提**自相矛盾**，已驳回。 const MAX_MEM_MB = 1024 const HEAP_HEADROOM_MB = 96 // 配额里留给非堆部分（native/栈/共享）