admin/dsh_shenxian
1
0 Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
59 Commits 1 Branch 0 Tags
master
Commit Graph
18 Commits
Author SHA1 Message Date
admin e6207aa691 chore(仓库对齐): 文档库结构治理 + IM/插件线落地
build / build-and-scan (push) Waiting to run
Details 
文档库：目录改为编号制（01-规范/02-架构设计/03-数据库/04-调整方案/
05-交接单/06-ops/07-scripts/08-skills/09-archive），顶层散文件归入 01-规范/；
INDEX.md 与 docs-manifest.json 重刷（档案 146 篇）；旧目录名引用全量对齐。

IM 线：src/im/**（SDK / hub / store / presence / ws / gateway-token）、
src/web/routes/im.ts、src/db/plugin-data/**、src/supervisor/plugin-assembly.ts
及对应 test/**。

插件线：poc/{im-agent-bridge,im-connection-gateway,im-conversation-tabs,
business-plugins-im,carbon-mcp-probe}、src/web/routes/{sessions,overlay-device}.ts、
src/net/relay/{device-grant,instance-credential}.ts。

仓库卫生：清出 40 个历史误入库 / 已改名文件（34 个交接单归档 + 6 个旧结构，
本地均有副本）；dsh-server-docs/.gitignore 补 tmp/；交接单不入库（政策）。
 2026-09-24 07:25:16 +08:00
admin 20fb8dcbb5 fix(实例代理): 客户端断连主动中止上游，根治 relay per-port 额度泄漏导致的 503 
- 判据落在响应流 reply.raw 上（不可用 request.raw：GET 无请求体，
  请求头读完即 close，会误判为客户端断开而掐死正常请求）
- clientGone 后丢弃上游响应、不再重试、不写已关闭的 reply
- 隧道 'close' 双向 destroy（'close' 不是 'error'，正常断开只发 close）
- 档案 146
 2026-09-21 17:22:04 +08:00
admin 1242d07db0 fix(实例代理): 冷启动窗口转发失败改为 503，消除实例子域 502（档案 141） 
根因：proxyHttp() 在转发两次失败后 reply.raw.destroy()，不写任何响应头与 body，边缘 nginx 只能回 502。
现象：admin 首次用 admin.ai1net.com 进场即 502 —— /api/dsh/enter 拉起实例后 12 秒访问，实例进程已在、端口已分配但 dsh 尚未监听。
改法：新增 replyUpstreamUnavailable()，响应头未发出时回 503 + Retry-After（导航请求给会自动重试的极简 HTML），仅 headersSent/writableEnded 才允许 destroy。
实测：门户 200 / admin.ai1net.com 401 / 实例端口 401 / 启动日志 0 error / verify-inject 全绿。
 2026-09-19 16:18:41 +08:00
admin 452924d89c feat(config): 涉密内容外置到配置目录（档案 140） 
把散落在代码里的真实部署值统一收进 config/，代码改为引用配置，
使仓库副本/开源导出不再带出生产域名、IP、内网路径与凭据。

新增 config/：platform.env.example（模板）· load.sh（shell 加载器）·
index.cjs（node 加载器）· README.md（键一览与优先级）。
真实值放 config/platform.env —— 已 .gitignore 排除，不入库、不进导出。

TS 侧新增 src/platform-paths.ts 作部署路径的唯一解析处（零副作用）：
platformDir/stateDir/backupDir/artifactDir/installDir/scriptPath。
config.ts 接入这些字段；内置中继种子由生产 URL 改为空（改由
DSHS_OVERLAY_BOOTSTRAP_SEEDS 提供）。修掉 5 处硬编码绝对路径，
src/** 注释中性化 116 行/53 文件。

scripts/** 36 个内部运维脚本：真令牌/PG 口令/隧道目标/主机号/路径
一律改从配置取；web/wake.html 的注册域白名单改为运行时从
location.hostname 推导；test/** 夹具 119 行/13 文件改 RFC 2606/5737
保留值，并把「内置种子必须为空」固化为回归断言。

取证：tsc 0 错；npm test 373/375（唯一失败 lease 属既有）；
全仓扫描（大小写不敏感）代码面涉密标识 = 0；已部署 47 并零回归
（/opt/dsh/* 未搬家，/var/lib/dshs/platform 未被误建）。
 2026-09-19 15:12:19 +08:00
admin d2ef362a98 feat(overlay): 覆盖网络线 序㊾ —— 探针观测面改「两台中继并集」（附 序㊽ 源码/文档补提交） 
序㊾（本棒）：
- scripts/overlay-probe.cjs：OBS-01 / OBS-08 / OBS-09 的数据源由「只读 47 中继」
  改为「按两台中继取并集」，消除 worker 归属漂移时的假红 / 假 SKIP
  · endpoints 以 network:hostId:port 为键合并，online 取「或」、localPort 取在线那一侧
  · used 按 network/hostId 去重计数（不求和，避免凭空放大在册数）
  · localPort 属中继机回环落点 ⇒ 按归属分机探活（106 侧落点由 106 机上探）
  · derived（OBS-11）保持 47 视角；阈值与判据一律未放宽
  · OBS-16 计数约束：对 47 /status 的读取仍为三次、Δ 只取 47 的 counters；
    对端 106 的采样为独立一次，落在第三次采样之后，不进 (status2, status3] 门窗口
  · 新增 --peer-status-fixture（并集的对端那一半）与「并集不可取证」强制留痕
- 交接单《覆盖网络-序45-低熵块治理-测熵与实现》§16 全节（§8 前前缀逐字未变）
- 参数表 §11.16 补记（§10 现算指纹未变，值格未动）

附（前几棒已完成并已部署、但尚未入仓的源码 / 文档）：
- src/net/relay/content/*.ts、src/net/relay/index.ts、main.ts：块级寻址 C 域分离
- src/supervisor/orchestrator.ts、src/worker/agent.ts：日志采集与巡检（方案 C）
- test/overlay-content.test.mjs：随附用例（npm test = 200 pass / 0 fail / 1 skipped，Node 22）
- scripts/dshlog.mjs（跨机日志取证）、scripts/overlay-entropy.cjs（熵探针）
- dsh-server-docs/04-调整方案/129、133；INDEX.md / docs-manifest.json / 交接单 README 登记
 2026-09-19 05:35:35 +08:00
admin 09ce76f3af feat(overlay): 内容块级寻址 + 实例逐步拉起 + 骨干选路 + 组密钥加密（序24–㉛ 累积同步） 
代码
- 内容分发块级寻址：新增 src/net/relay/content/{chunker,store,runtime,source,peer,crypto}.ts
- 组密钥（C 档）确定性加密：AES-256-GCM，块 id β′ = sha256(密文) 前 32 hex；双 epoch 过渡窗口
- 实例生命周期：三处 teardown() 不再杀实例（local/remote/leased-spawner）；启动认领 + TCP 探活判孤儿
- 骨干选路：jitter 选路 + endpoint-target；relay client/server/wire/identity/directory/rendezvous/switcher 调整
- 工作台 src/web/server.ts、src/worker/relay-tunnel.ts 装配与候选链观测

脚本与测试
- scripts/overlay-{probe,keyring,jitter}.cjs 更新
- 探针新增 OBS-21（每连接候选数）/ OBS-22（teardown 静态守卫 + 认领面）/ OBS-23（组密钥加密）
- 新增 test/{orchestrator-teardown,orchestrator-rehydrate,overlay-content,overlay-jitter}.test.mjs；relay 两例更新

文档
- 新增交接单：覆盖网络-序24-内容分发块级寻址 / 序25-实例逐步拉起 / 序26-骨干稳定选路与加密
- INDEX.md、交接单/README.md、skills/dsh-auto-handoff-chain/SKILL.md 同步

验收（零回归，2026-09-18 08:0x 复核）
- npm test           201 tests / 200 pass / 0 fail / 1 skipped
- overlay-failover-drill --scene all --table   12 PASS / 0 SKIP / 0 FAIL
- overlay-probe --table                        23 PASS / 0 SKIP / 0 FAIL (rc=0)
 2026-09-18 08:08:51 +08:00
admin 146c3d25ef feat(overlay): 覆盖网络线序①–⑮ 代码与测试产物入库 
覆盖网络线累积产物（此前只在工作区、未入版本库）：
- 新增 relay 子系统 src/net/relay/**（wire/duplex/server/client/dialer/switcher/directory/identity/keys/placement/network/addr-override/main/index）
- 新增 src/worker/relay-tunnel.ts、src/web/routes/overlay.ts
- 新增观测/演练脚本 overlay-probe、overlay-failover-drill、overlay-keyring、overlay-holepunch、overlay-jitter、overlay-wan、overlay-relaykey-add、relay-mem-calibrate
- 新增测试 12 个（relay / relay-failover / remote-spawner / instance-port / overlay-{network,auth,bootstrap,identity} / remote-user-fs 等）

验收基线：npm test = 162 pass / 0 fail / 1 skip；--scene all = 12 PASS / 0 SKIP / 0 FAIL；overlay-probe = 12/12
 2026-09-17 17:03:27 +08:00
admin 640813e84e 覆盖网络线 S0+S1 落地：可达性单一入口 + 会合地址出 env 
S0（本机）：新增 src/net/reachability.ts（Reachability 描述 + agentBaseUrlOf 唯一取值入口）、src/net/rendezvous.ts、docs/architecture.md（四层划分 + 依赖方向 + R1-R4 判据）、scripts/check-layering.mjs + layering-baseline.json、test/reachability.test.mjs；src/supervisor/remote-spawner.ts 与 src/web/server.ts 改为统一走 agentBaseUrlOf()，agentUrl 降级为可选旧字段（向后兼容）。

S1（本机 + 106）：新增 DSHS_RENDEZVOUS_URL 出 env（src/config.ts 解析 clusterRendezvousUrl，优先级 overrides > 新变量 > DSHS_TUNNEL_TARGET 兜底 > 空），src/worker/tunnel.ts 新增 normalizeTunnelTarget()、src/worker/agent.ts 改读新配置 ⇒ 双路径并存、可零代码回滚（删掉新 env 即走旧路径）。106 已上线，健康检查 tunnel.ready=true。

package.json 增加 check:layering 脚本并接入 verify；README 登记分层文档。

验收：npm run build 通过；npm test 44/44；check:layering 无新增违规（基线 5 条）。
 2026-09-16 15:02:52 +08:00
admin c70d5d860e feat(cluster): 集群化落地 —— Manager/Worker 拆分 + 归属租约 + 跨机验证（T08） 
背景：把平台从「单机单进程」改造成「1 组 Manager + N 台 Worker + 共享归属状态」，
硬约束 = 全程兼容单例模式（deployMode 默认 local；生产切换前 47 一行未动）。

主要改动
1) 数据模型 v7（SQLite 与 PG 两方言同步）：新增 dsh_hosts 注册表 +
   dsh_instances.{host_id,epoch,heartbeat_at,lease_until}；claimInstance 原子抢占
   （UPDATE … WHERE host_id IS NULL OR lease_until < now）+ pinInstanceHost 钉住归属。
2) 租约与 fencing：src/supervisor/lease.ts（acquire/renew/release + stillHolder 判据 +
   ttl > 2×renew 硬校验）；心跳里续租，失权即向 worker 下发更高 epoch（self-fencing）。
   ⚠️ release 只清租约（lease_until），**保留 host_id** —— host_id 是「用户数据在哪台」的锚点。
3) Worker agent（src/worker/agent.ts，子命令 dshs worker）：实例生命周期 + 文件面 /fs/*
   + 幂等键（operationId）+ 鉴权（timingSafeEqual）；Worker 不写控制面数据
   （apiKey/uid 由 Manager 随 launch 投递，R5 收窄）。
4) 远端 Spawner + LeasedSpawner：按 host 路由（**粘性优先**：有历史归属且那台 up 就留在原地，
   否则按容量选最空的）+ 容量准入 + deployMode=cluster 装配（systemd drop-in，可回滚）。
5) bwrap 修正：**所有挂载点的中间目录统一前置 + 去重 + 由外到内**（「就近创建」会在嵌套前缀下
   遮掉已绑挂载点 ⇒ bwrap: Can't chdir）；且**只能用 --tmpfs**，用 --perms 会让 47 的
   bwrap 0.4.0 直接拒启动（沙箱全挂）。
6) 跨机隧道 src/worker/tunnel.ts：SSH ControlMaster + 动态 -R 转发；**自愈由 agent 本地
   20s 定时器驱动**（不能只放 /healthz —— 心跳本身经隧道进来，断了就没人触发它）。
7) 文件面按归属路由（RemoteUserFs）：实例与文件必须落在同一台机器，否则实例看不到自己的文件。
8) 观测面：dshs doctor / dshs cluster status。

验证（本次均已实跑）
- test/lease.test.mjs：SQLite 10/10 == PG 10/10
- 组件级端到端 5 个：verify-cluster-{agent,lease,fs,migrate,live}.mjs
- 真跨机（47 Manager / 106 Worker，跨云 + 反向隧道）verify-cluster-cross.mjs 九步全绿
- 域名形态访问 verify-cluster-domain.mjs（<user>.域名 → Manager → 远端实例；越权 403）
- 冒烟 scripts/smoke-*：6/8，失败项与改动前基线完全相同（无回归）
- 生产切换与回滚剧本见 dsh-server-docs/交接单/T08-集群化落地-兼容单例模式.md §16
 2026-09-15 18:47:02 +08:00
admin 68c0a320ed refactor(k8s): 删除 K8s 命名的死接口 LivePod；修正 K8s 文档横幅重复 
1) src/supervisor/spawner.ts：LivePod —— 注释此前已中性化，但**类型名来自 K8s 的
   Pod**；全仓只有声明那一处出现（0 引用 = 死代码）⇒ 整块删除。属 cf8b7b1 的漏项。

2) docs/k8s-deploy.md · docs/k8s-deployment.md：cf8b7b1 里那行状态横幅被**重复
   插入 2 次并挤在同一行**（生成脚本当时不幂等，每跑一次多插一条）⇒ 收敛为 1 条。
   脚本已补「H1 后已有横幅就不再插」的负向断言 + 一条把重复收敛成 1 条的自愈规则。

验证：tsc --noEmit exit 0；npm test 36 测试 / 35 通过 / 0 失败 / 1 跳过；
LivePod 全仓（含 lib/）0 命中；两份文档横幅各 1 条。
 2026-09-15 06:51:48 +08:00
admin cf8b7b1f5c chore(k8s): 下线 K8s 后端形态，移除依赖 @kubernetes/client-node 
生产形态是单机 local（DEFAULT_DEPLOY_MODE=local，env 未覆盖）⇒ K8s 分支
在 local 下本来不可达；且该形态与官方 dsh 基座、插件体系均无关
=> 整体下线，并移除该形态唯一的第三方依赖。

移除（备份在 D:/github/_dsh_shenxian_K8s后端备份_20260915/，含还原命令与
「集群化方案要复用的模板清单」）：
  src/supervisor/{k8s-spawner,leader,reconcile}.ts
  src/fs/k8s-user-fs.ts · src/tcp-bridge.ts · src/web/file-service.ts
  test/{k8s-spawner,leader}.test.mjs · scripts/smoke-file-service.mjs

改写调用方：cli.ts（5 条 import / 选主块 / file-service 与 tcp-bridge 两个
子命令 / dispatch / HELP）、web/server.ts（改为 fail-loud 守卫 + 恒用
LocalSpawner）、fs/provider.ts（只留 LocalUserFs）、package.json（测试与
smoke 入口），外加 3 处指向已删类型的悬空 JSDoc。

保留（集群化方案列为未来可选）：deploy/ · poc/01-04 · Dockerfile.dsh ·
docs/k8s*.md（已加「代码已下线」状态横幅）· config.ts 的 K8s 配置字段与
DeployMode 联合类型。

验证：tsc --noEmit exit 0；npm test 36 测试 / 35 通过 / 0 失败 / 1 跳过；
npm run verify exit 0；依赖与被删符号全仓 0 命中。
 2026-09-15 06:36:20 +08:00
admin ed0c3c0ad5 fix(proxy): 治本 —— 陈旧 dsh-auth cookie 回写清理（档案 98，修 431 → Failed to load plugins） 
根因（2026-09-14 实测）：dsh **每次实例 (重)启动都换** `dsh-auth-<随机后缀>` 的 **cookie 名**；平台此前
只在**转发给实例时**丢弃旧的（`mergeCookieHeader`），**从不回写浏览器** ⇒ 浏览器 cookie jar **只增不减**
⇒ `Cookie` 请求头越涨越长 ⇒ 实测 **12.8 KB 放行 / 19.1 KB 就被 431**（且 19 KB 时连 `/` 也 431）
⇒ 被 Cloudflare / 本机 nginx 直接拒掉，**请求根本到不了平台** ⇒ 那条 11 MB 合并脚本取不到
⇒ 客户端报 `bundle script … failed to load` ⇒ 界面「Failed to load plugins」。
（旁证全对：平台日志无该请求 ✓／无痕正常=空 cookie 罐 ✓／服务器侧一切正常 ✓）

修法（只动 proxy.ts 一处）：在响应头块里对**陈旧名字**回写 `Set-Cookie: <name>=; Path=/; Max-Age=0`。
· **只在「本次响应确实下发了 dsh-auth-*」时才动手** —— 那时才确知当前有效名字，绝不误删在用的那个；
· 其余情形什么都不做；不带 `Domain=`（dsh 下发的是 host-only cookie）；
· 即使判断有误，档案 51 的「401 → 取新 cookie 透明重放」也会自愈。

验证：
· 本机 `npm run verify` EXIT=0；服务器 `ci.sh` CI OK（48 pass / 0 fail）；
· `scripts/verify-inject.cjs` 新增防回退断言「会清理陈旧 dsh-auth cookie」；
· **端到端实测**：带 2 个假 `dsh-auth-*` 请求 `/?token=…` → 303 响应含 **3 条 Set-Cookie，其中 2 条 Max-Age=0**
  正是那两个假名字 ✅

⚠️ 它**救不了已经 431 的当下**（那时请求在 CF/nginx 就被拒、到不了平台）⇒ 用户需**先手动清一次**
（只删 `dsh-auth-*`、保留 `sid`），此后由本机制维持小 jar。⚠️ 根因仍在（官方每重启换名）⇒ **少重启**仍是要点。
 2026-09-14 23:01:04 +08:00
admin cc1dc5c9a8 fix(proxy): /plugins/ 合并脚本补 ETag + 304 短路 —— 省掉每次 11 MB 重下（档案 97） 
问题（实测 2026-09-14）：官方 `@deepseek-ai/dsh-client-modules` 把全部客户端插件拼成**一条
11,172,365 字节的脚本**（combo URL `/plugins/??<模块列表>&rev=<revision>`）；我们给它下发
`no-cache`（档案 95，为"改了 UI 就能看到"），而实例**既不给 ETag 也不给 Last-Modified**
⇒ 浏览器"回源校验"退化成**每次全量重下 11 MB** —— 经 Cloudflare 实测 **114.87 秒**
（弱网/手机上直接表现为页面加载不出来）。

修法（只动 proxy.ts 一处，不改官方、不动 rev）：
· 按 URL 派生强校验器 `ETag = sha1(targetPath)`，**只对 GET/HEAD + /plugins/ 且 URL 含 `rev=` 生效**
  （无 rev 一律跳过）。依据是官方契约：「**已公告响应不可变；未知组合或 revision 返回 404**」
  ⇒ (模块组合, rev) 唯一决定内容 ⇒ 同 URL 必同字节，故按 URL 派生 ETag 是安全的。
· 命中 `If-None-Match` 时 **直接回 304、完全不回源**（省的正是那 11 MB）。
· 未命中时行为与原先一致，只在既有缓存头区块多透出一个 `ETag`。

验证：
· 本机 `npm run verify` EXIT=0；服务器 `ci.sh` CI OK（48 pass / 0 fail）；
· `scripts/verify-inject.cjs` 新增防回退断言「proxy.ts 有 /plugins/ ETag + 304 短路」；
· **端到端实测**：① 首次 200 / 11,172,365 B + `ETag="034a459a92…"`；② 带 If-None-Match → **304 / 0 B** ✅

⚠️ 顺带记录：本仓库 `core.autocrlf` 会在 git 触碰后把工作区文件改成 CRLF ⇒ 脚本化改文件必须
**行尾自适应**（本轮 `proxy.ts` 的多行匹配因此失配过一次）。
 2026-09-14 22:46:40 +08:00
admin 53b8eff870 fix(mem): 实例内存改为「基础 MIN → 最多 MAX」，与插件开关解耦（档案 96） 
用户原话两段：①「改为 实例内存不要受插件开关影响，只受 min 和 max 值影响」
②「改成基础 min 最大可以浮动到 max」。

实现（cgroup 两个参数表达这个区间）：
· src/supervisor/orchestrator.ts：instanceMemMb() 拆成 instanceBaseMb()（=MIN_MEM_MB）与
  instanceMaxMb()（= max(base, MAX)）；sdArgs 改为 -p MemoryHigh=<base>M ＋ -p MemoryMax=<max>M；
  **删除** PLUGIN_MEM_MB 与 BASE_MEM_MB（不再读 profile 的 budsles）；quotaInfo() 返回 {baseMb,memMb,heapMb}。
· src/supervisor/spawner.ts：quotaInfo?() 返回类型同步加 baseMb。
· poc/business-plugins/lib/client.js：quotaOf() 兜底值改为硬顶上界（进度条 100% 基准与「超限」判据同它）；
  事实行改为「基础 448 MiB → 最多 1024 MiB · V8 堆 256」（新增 i18n mem.base）；插件表保留但**仅用于预估**。
· scripts/verify-mem-model.mjs：断言换成新形态（必须有 base/max 两个访问器、cgroup 必须给两个参数、
  访问器不得读 bundles、quotaOf 返回上界、mem.base 存在）。
· 取值沿用用户裁定值：MIN 448（base）/ MAX 1024 —— **我没有自行改数**。

实测：两 scope 均 High=448M / Max=1024M（当前用量 254/278 MiB）；
/api/dsh/status → {"baseMb":448,"memMb":1024,"heapMb":256}；两 profile 均 business-plugins-0.3.19.tgz。
本机 npm run verify EXIT=0；服务器 ci.sh CI OK。

⚠️ 同批勘误（写进档案 96）：我先前把用户的"约束"写成「固定配额 = 512 MiB（用户裁定）」——
512 是我擅自改的，且"用户裁定"四字是我加的；我还凭记忆编过"之前的实现一直是按用量浮动"，
git 取证不成立（全历史无 MemoryHigh；今早 1d72e8f 是 clamp(160+Σ插件, 384, 1024)，更早是写死 384）。

⚠️ 未提交：BRIEF.md / DEPLOY-本部署.md 的配额口径同步（那两个文件本就有别人未提交的改动）。
 2026-09-14 22:26:06 +08:00
admin e18eaa2b64 fix(proxy): HTML 外壳也下发 no-cache —— 修「Failed to load plugins」根因（档案 95） 
症状：用户页面报
  client-modules: bundle script /plugins/??…&rev=… failed to load  ⇒ 界面「Failed to load plugins」

根因（实测三条对照）：
· `GET /`（外壳 HTML）**没有任何缓存头**（无 Cache-Control/ETag/Last-Modified/Expires）⇒ 浏览器启发式缓存
· 外壳内嵌带**内容哈希 `rev`** 的插件 bundle URL；`rev`/模块列表与实例当前状态**必须完全一致**：
  原样 200（11.17 MB）｜只改 rev → **404**｜rev 对但少一个模块 → **404**
· 于是「改了插件 / 重启了实例」之后，旧外壳永远去请求**已不存在的 rev** ⇒ 404 ⇒ 报错，
  且**普通刷新会命中缓存的外壳 ⇒ 复现不消失**（2026-09-14 事故：当天连铺 4 次插件 + 3 次重启 dshs）

修法：把既有的 `no-cache` 治理（2026-09-12 只覆盖 `/plugins/`、`/assets/`）**扩到 HTML 外壳**——
`String(headers['content-type']).includes('text/html')` 也下发 `Cache-Control: no-cache`。
实例端仍是唯一事实源，平台只加缓存头，不改 rev（R2）。

验证：
· 服务器 `bash scripts/ci.sh` → CI OK（48 pass / 0 fail）
· `scripts/verify-inject.cjs` 新增防回退断言「/plugins/ 与 text/html 都必须 no-cache」
· 经 nginx 公网路径实测 `GET /` → **cache-control: no-cache**（改前为空）
· 端到端：取各用户页面里**自身**的 bundle URL 回拉 → admin/guest 均 200（11.69 / 11.13 MB）

⚠️ 本提交不能回溯治愈「已经坏在用户浏览器里的那份旧外壳」——用户需**强刷一次**
（Ctrl/Cmd+Shift+R，或 DevTools 勾 Disable cache，或无痕窗口）。

⚠️ 同批未提交（属别人 lane，见档案 95 §六）：`BRIEF.md` / `DEPLOY-本部署.md` 的配额口径同步
（我改了它们的配额数字，但那两个文件本就有别人未提交的改动 ⇒ 不跟提，宁可保持 dirty）。
 2026-09-14 21:50:28 +08:00
admin 683c4cdeff fix(mem): 内存口径定案 —— BASE 448 / MIN 448 / MAX 1024（用户裁定） 
用户裁定：「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（客户端常量随之更新）。
 2026-09-14 21:38:57 +08:00
admin f6d4ad9b15 fix(mem): 统一实例内存配额口径 + status 暴露真值（消灭「388 MiB」误报） 
用户问「实例内存大小是不是调整过了，为什么功能设置中还是显示 388 多」。
实测：guest 真实 MemoryMax = 672 MiB、admin = 384 MiB（都真调整过）；
而「功能管理」显示的是插件**自建的第二套模型**（基线 285 / univer 64 / mcn 39，
且把 clamp 下限 384 当硬上限）⇒ 全勾显示 388 并报「⚠ 将超出上限」，纯误报。
根因：档案 81 R1 把「写死 384」改为「按插件集合推导」时**只改了编排器**，
插件那份副本原地漂移，此后 univer 384→512、mcn-suite 128 都没同步。

平台侧（把已算好的真值透出来，零新增计算）：
- spawner.ts 新增可选 quotaInfo?(userId)（照 breakerInfo 模式）
- orchestrator.ts 实现 quotaInfo()，走**同一个** instanceMemMb()/heapMbFor()
- /api/dsh/status 返回 quota: {memMb, heapMb}

防漂（根因是「同一事实两处副本」，必须让它不可能再漂）：
- 新增 scripts/verify-mem-model.mjs，逐项交叉断言常量/成本表/clamp 算式/接线点，
  接进 npm run verify —— 任一处漂移即构建失败（已做反向验证：改回 285 即 exit 1）

验证：build 零报错；verify 全绿（含新增 15 项断言）；服务端 md5 与本机编译产物一致；
GET /api/dsh/status → quota {memMb:384,heapMb:256} 与实测 402653184 吻合。

注：poc/business-plugins/**（0.3.6）与其 package.json 未在此提交 —— 该文件被并行会话
连续改过两轮（0.3.4/0.3.5，0.3.5 已上线但未 commit），刻意留给他们一起提交。
 2026-09-13 21:38:04 +08:00
admin 43976fea6a 初始提交：DSH 多租户平台（dshs） 2026-09-13 16:18:10 +08:00