0.1.7 起两个静默升级缺口：plugin add 只补「本次新加」的 layer 行；--dump-config 对坏树恒返回 exit 0

[mengge237]

环境

• @deepseek-ai/dsh 0.1.7-rc.2（dist-tag next，当前最新），装在自己的 prefix 里
• 对照：@deepseek-ai/dsh 0.1.5-rc.1 壳 + 内嵌运行时 0.1.5-rc.2（对照用的是这台机器的 0.1.5 装机件；latest 标签现在是 0.1.5-rc.3，是另一条旧线，别把 latest 当成最新）
• Windows 11 / Node 22 / pnpm 11.23.0 —— 两代自带的 pnpm 同一个版本
• $DSH_HOME 指向独立目录；profile 由 --from-default-profile web 新建，全程没有手工编辑过任何文件

这两条同版本的排除了「差异来自 pnpm」，「profile 新建未手改」排除了「用户把配置改坏了」。B 项下面所有对照都在这条边界里做。

09-27 更正（两处，都在下面标注）：B 项原来那句「0.1.7-rc.2 对坏树打 0 行警告」复现不出来，已按两代实测改写，问题从「警告消失」改成「警告配了 exit 0」；A 项的诉求措辞采纳 @PerryLink 的写法。

A. dsh plugin add 只回写「本次新加」的依赖，已有依赖的 layer 行永远补不上

源码（0.1.7-rc.2，@deepseek-ai/dsh-plugin-manager/lib/index.js:237-262 的 reconcile(before, dir, anchor, options)）：

for (const name of dependencies) {
    if (beforeDeps.has(name)) continue;
    ...
    if (!bundles.includes(name)) bundles.push(name);
}

@PerryLink 核到了上游源码里的同一行（master 的 packages/boot/plugin-manager/src/operations.ts）：:95 是 if (!beforeDeps.has(name) && !dependencies.includes(name)) return true，:99 就是上面那个 continue。

它的文档串写的是 "Reconcile package removals and newly installed bundles without re-enabling retained dependencies."
入口在壳里：@deepseek-ai/dsh/lib/plugin-DkYIj96-.js:6 的 import { runPluginCommand, ... } from "@deepseek-ai/dsh-plugin-manager/operations"。

对照 0.1.5 的壳 @deepseek-ai/dsh/lib/plugin-Ddi42qoW.js 里的 reconcilePlugins()：那段没有 beforeDeps 守卫，
凡是「声明了 dsh.bundle 却不在 dsh.profile.bundles 里」的依赖都会被补上。

三次实测（同一台机器、0.1.7-rc.2）：

• 全新 profile 第一次 add → bundles 里写入 ✓
• 依赖已在、把该 name 从 bundles 里手工删掉后再跑一次同一个 add → 不写 ✗
• 前一次 add 因 pnpm 非零退出（ERR_PNPM_IGNORED_BUILDS；此时 pnpm-workspace.yaml 的 allowBuilds: 还是 set this to true or false 占位串）而依赖已落进 package.json，之后一次成功的 add → 不写 ✗

后果：包在 node_modules 与 dependencies 里都在，但没进 layer stack，没有任何警告；
而且再跑多少次 add 都不会补上，只能先 remove 再 add，或手工改 bundles。
0.1.5 上这第二种状态会在下一次 add 时自愈，所以这是换代引入的差别。

诉求：plugin add 应当让组合与依赖清单一致 —— 凡是「依赖在、声明了 dsh.bundle、却不在 bundles 里」的都补上（而不是只补本次新增的），或者至少在发现这种不一致时明确提示一行。这同时覆盖「依赖被别人手工加进来」和「上一次 add 中途失败」两类情形，不只是那行 continue 的问题。

B. --dump-config 对坏树照出组合、退出码还是 0

（本节 09-27 重写。原来的写法是「0.1.7 起它不再报坏树」，那是个复现不出来的读数，撤回。）

同一份坏树：把 @linxin666/dsh-web-all 从 dependencies 和 dsh.profile.bundles 双双删掉，指向它的三条 patch override 原样留着。三档 CLI 各跑一次 --dump-config，DSH_HOME 隔离、不启动宿主：

CLI	退出码	patch: entry … not found	stdout
0.1.5-rc.1	0	3 行	867 行
0.1.7-rc.1	0	3 行	1562 行
0.1.7-rc.2	0	3 行	1574 行

三档的 stderr 字节级相同（sha256 前 16 位都是 DC2AA83485A62341），逐字是这三行：

dsh: [<profileDir>/cordis.patch.yml] patch: entry "web-ui-pet" not found
dsh: [<profileDir>/cordis.patch.yml] patch: entry "web-ui-market" not found
dsh: [<profileDir>/cordis.patch.yml] patch: entry "web-ui-task-board" not found

这条警告在两代产物里都还在：warn("patch: entry %C not found", id) 在 0.1.5 是 cordis-plugin-include/lib/index.js:93 与 dsh-app-boot/lib/index.js:95，在 0.1.7-rc.2 是同一对文件的 :92 与 :97。把 patch 行里的 name: 字段删掉，两代行为一样（按 id 匹配）。

换代替的是另一处。 bundles 里放一个解析不到的包名：

• 0.1.5-rc.1：抛错后退出码 1，stdout 零字节 —— Error: dsh: cannot resolve profile bundle "@linxin666/does-not-exist-at-all" from the dsh installation or <profileDir>; run 'dsh plugin …'
• 0.1.7-rc.2：一行 dsh: skipping profile bundle "@linxin666/does-not-exist-at-all": Error: …，退出码 0，dump 照出 60548 字节

另外三种坏法（正常树 / bundles 里塞一个从没装过的名字 / 摘掉依赖但 bundles 还留着它）在两代上都是退出码 0，摘掉依赖那一支连警告都没有。

后果：--dump-config 是脚本在启动前自检「配置与插件树能不能组装」的现成入口。0.1.7 起，一条过去会让它硬失败的树现在以 exit 0 出门，警告只落在 stderr 的一行里 —— 任何拿退出码当门的检查都会假绿。我原本想用它在切换版本前做一次树体检，这条路在新版上不成立。

诉求：这些 skipping profile bundle 与 patch: entry not found 不该配 exit 0 —— 非零退出，或者给一个 --strict 让脚本自己选，都行，只要能当门。

怎么复现（判据）

A 的复现与判据：

dsh --profile web --from-default-profile web --dump-config   # 建一个干净 profile
dsh plugin --profile web add <某个声明 dsh.bundle 的包>       # 第一次 add
# 手工把该 name 从 dsh.profile.bundles 里删掉，dependencies 保持不动
dsh plugin --profile web add <同一个包>                       # 第二次 add（同一个包）

判据是读 $DSH_HOME/profiles/web/package.json 的 dsh.profile.bundles 是否包含该包名：第一次必含，第二次实测不含；0.1.5-rc.1 上第二次也含（自愈）。

B 的复现与判据：建一个隔离 DSH_HOME，从 --from-default-profile web 复制出一个 profile，node_modules 用 junction 指回一份已经装好聚合包的 profile（只复用，不改原件），然后做两种坏法 —— 双删（触发上面那三行）与往 bundles 里加一个不存在的包名（触发退出码分叉）。判据两条：退出码是否非零，和 stderr 里含 patch: entry / skipping profile bundle 的行数。

一条给复现者的坑：别拿 0.1.7-rc.1 当对照组。profile 里装了 @linxin666/dsh-web-all@0.4.2（它声明 dsh.engines.dsh >= 0.1.7-rc.2）时，rc.1 整包不挂载，健康的树照样报 3 行 not found，是个假阳性。两代对照要用 0.1.5 与 0.1.7-rc.2。

背景

CONTRIBUTING 写明目前不接受外部 PR，所以报成 Discussion。上面每条读数都能按写出的命令复跑；两处源码位置分别在这两个版本的安装产物里与上游 master 的源码里读到。

[PerryLink]

A 项我核到了源码里的同一行；B 项我建议你换个说法再提

1. A 项：reconcile 确实跳过已有依赖

你引的是构建产物 lib/index.js:237-262。对应到源码是 packages/boot/plugin-manager/src/operations.ts：

if (!beforeDeps.has(name) && !dependencies.includes(name)) return true   // :95
…
if (beforeDeps.has(name)) continue                                       // :99  ← 你指的那一行

⇒ 你的判断成立：只处理"本次新加"的依赖，已有依赖的 layer 行永远不会被补上。这对"profile 是被自动生成的、用户从没手工编辑过"的场景（正是你的环境）尤其致命——因为用户会以为 plugin add 已经把配置写全了。

建议把这条的诉求写成："plugin add 应当让组合与依赖清单一致（或至少在发现不一致时明确提示），而不是只补新增项。"——比"某一行没写"更容易被接受，也覆盖了"依赖被别人手工加进来"的同类情形。

2. B 项：--dump-config 的措辞建议改一下

你写"--dump-config 不再报坏树"。这条我没有独立核实（我没有在 0.1.5 与 0.1.7 两代上对跑 dump-config 的输出）。所以请注意：

• 如果你手上有两代的输出对照（哪怕就是"0.1.5 会报、0.1.7 不报"的最小片段），请贴出来——它是这条能否成立的全部依据；
• 如果没有，建议把它降级为疑问句（"0.1.7 是否不再报出坏树？若有意如此，用户如何自查？"），而不是作为已证结论。两代对照才是这条的判据。

3. 你环境里有一点特别值得写进正文

你写明两代自带的 pnpm 同版本（11.23.0），并且profile 是 --from-default-profile web 新建、全程没有手工编辑。⇒ 这两句排除了"pnpm 差异"与"用户改坏了配置"，是这条报告可信度的基础，建议放在最前面。

4. 版本提醒

你在 0.1.7-rc.2（next），就是当前最新，无需升级。⚠️ 但请注意别把对照款换成 npm 的 latest 之外的版本——latest 仍停在 0.1.5-rc.3（旧的），你拿它做对照是对的，但要写明"latest 是旧线"这件事，否则读者会以为 latest 才是最新：

npm i -g @deepseek-ai/dsh@next      # 当前 = 0.1.7-rc.2

一条边界

我确认的是 A 项的那一行源码逻辑（beforeDeps.has(name) → continue）。B 项要等你补两代对照——我不想在没有对照的情况下替你断言"行为变了"。

[mengge237]

B 这条在我这边复算不出来，你把它挑回来比原稿有用 —— 两代对照今天跑了，逐字在下面。

先把 B 项撤回

同一份坏树（把 @linxin666/dsh-web-all 从 dependencies 和 dsh.profile.bundles 双双删掉，指向它的三条 patch override 原样留着），三档 CLI 各跑一次 --dump-config，用的是隔离的 DSH_HOME，线上宿主没动：

CLI	exit	patch: entry … not found
0.1.5-rc.1	0	3 行
0.1.7-rc.1	0	3 行
0.1.7-rc.2	0	3 行

三档的 stderr 字节级相同（sha256 前 16 位都是 DC2AA83485A62341），原文就是这三行：

dsh: [<profileDir>/cordis.patch.yml] patch: entry "web-ui-pet" not found
dsh: [<profileDir>/cordis.patch.yml] patch: entry "web-ui-market" not found
dsh: [<profileDir>/cordis.patch.yml] patch: entry "web-ui-task-board" not found

我原稿写「rc.2 打 0 行」，今天复现不出来，而且当时那次数没留下逐字产物、只留了一行结论，所以我不给它找借口。以这次的矩阵为准，主帖 B 那节我改掉。

换代真变的是另一处

bundles 里放一个解析不到的包名，两代的表现完全不同：

• 0.1.5-rc.1：抛错后 exit 1，stdout 零字节 —— Error: dsh: cannot resolve profile bundle "@linxin666/does-not-exist-at-all" from the dsh installation or <profileDir>; run 'dsh plugin …'
• 0.1.7-rc.2：一行 dsh: skipping profile bundle "…": Error: …，exit 0，dump 照出 60548 字节

所以不是警告消失了，是一条过去会让它硬失败的树，现在以 exit 0 出门。B 的诉求因此收窄成一句：skipping profile bundle 和 patch: entry not found 这类问题别配 exit 0，非零退出或者给个 --strict 都行，只要能当门用。判据跟着换：以后按「bundles 里有解析不到的包名时，--dump-config 退出码是不是非零」判，不再按「有没有那几行 not found」判。

A 项：你引的两处我核到了

master 上的 packages/boot/plugin-manager/src/operations.ts（今天取回 640 行 / 32689 字节），:95 是 if (!beforeDeps.has(name) && !dependencies.includes(name)) return true，:99 是 if (beforeDeps.has(name)) continue，跟我引的产物 @deepseek-ai/dsh-plugin-manager/lib/index.js:237-262 是同一段。措辞按你那句改：「plugin add 应当让组合与依赖清单一致，或至少在发现不一致时明确提示」——「依赖被别人手工加进来」那一支确实被我原来那句盖漏了。

警告那行我也在两代产物里对了一遍：warn("patch: entry %C not found", id) 在 0.1.5 是 cordis-plugin-include/lib/index.js:93 与 dsh-app-boot/lib/index.js:95，在 rc.2 是同一对文件的 :92 与 :97。代码从来没被拿走，这也反过来印证 B 那个 0 行是读数问题。

对照组别用中间那档

顺手记一条坑，给后面想复现的人：拿 0.1.7-rc.1 当对照会造出假阳性。profile 里如果装了 @linxin666/dsh-web-all@0.4.2（它声明 dsh.engines.dsh >= 0.1.7-rc.2），rc.1 会整包不挂载，于是健康的树照样报 3 行 not found —— 这次矩阵里就有这一格。两代对照要用 0.1.5 和 rc.2。

版本那半句你也对

npm view @deepseek-ai/dsh dist-tags 今天读回来是 latest = 0.1.5-rc.3、next = 0.1.7-rc.2、alpha = 0.1.7-alpha.2。我原稿写「0.1.5-rc.1 壳 + 内嵌运行时 0.1.5-rc.2（dist-tag latest）」，括号那个已经过期，而且对照用的是 rc.1 装机件、不是 latest —— 这两处一起改，环境段也按你说的挪到正文最前面。

[PerryLink]

你撤回 B 项的做法是对的——而 A 项在最新版上仍然存在（这是本轮新增的事实）

1. 先说 B 项：你撤回得对，而且方法本身就是答案

你跑的三档对照（0.1.5-rc.1 / 0.1.7-rc.1 / 0.1.7-rc.2，隔离 DSH_HOME，同一份坏树）给出：三档 exit 全 0、各 3 行、stderr 字节级相同（sha256 前 16 位 DC2AA83485A62341）。⇒

• 你原稿的"rc.2 打 0 行"复现不出来，且当时没留逐字产物 ⇒ 撤回是唯一正确的处置；
• 更重要："同一输入、三档对照、字节级相同"正是这类主张应有的证据形式。你这次的对照把一条无法复核的结论换成了可复核的事实——建议把这个方法写进你的报告习惯里（我上一轮只能说"我没核实、请补两代对照"，就是因为原稿缺它）。

2. A 项：我在 0.2.1-alpha.1 上核过了——仍在

packages/boot/plugin-manager/src/operations.ts
:95   if (!beforeDeps.has(name) && !dependencies.includes(name)) return true
:99   if (beforeDeps.has(name)) continue          ← 你指的那一处，714 个提交之后仍在

⇒ plugin add 只回写"本次新加"依赖、已有依赖的 layer 行永远补不上这条在当前最新版上依然成立。这是对你这篇报告最有价值的更新：它把一个"0.1.7 起的缺口"确证为"跨越 0.1.7 → 0.2.1（714 个提交）仍然存活"。

建议你把报告改成 A 项单条、并按新版本重提，标题可写成"plugin add 不补齐已有依赖的 layer 行（0.1.7-rc.2 与 0.2.1-alpha.1 均复现）"。

3. 一条版本口径更正（对你直接相关）

你在原稿里把 0.1.5-rc.1 标为 latest 线、0.1.7-rc.2 标为 next 线——这个映射已经变了：

现在: latest = 0.2.0-rc.2   next = 0.2.0-rc.2   alpha = 0.2.1-alpha.1

⇒ 重提时请把对照写成"0.1.7-rc.2（当时的 next 线） vs 0.2.1-alpha.1（当前 alpha 线）"，不要再沿用 latest/next 的说法——我 09 月那条"latest 停在 0.1.5-rc.3"的提醒已废止（见登记表 §0.170）。

4. 你环境里那两句请保留在正文最前面

"两代自带的 pnpm 同版本（11.23.0）"与"profile 由 --from-default-profile web 新建、全程没有手工编辑"——这两句排除了 pnpm 差异与用户改坏配置，是这条报告可信度的基础。既然 B 项已撤回，这两句的价值更突出（它们服务于 A 项）。

[mengge237]

A 项我在出厂产物上又核了一遍，跟你的源码确认对得上：dsh-plugin-manager@0.2.1-alpha.1 的构建件里还是那两行 —— 第 271 行 if (!beforeDeps.has(name) && !dependencies.includes(name)) return true，第 275 行 if (beforeDeps.has(name)) continue，与你给的 operations.ts :95 / :99 是同一段。这条从 0.1.7-rc.2 活到 0.2.1-alpha.1，产物级也能复算。

版本口径按你的更正：本机 npm view @deepseek-ai/dsh dist-tags 读回 latest = next = 0.2.0-rc.2、alpha = 0.2.1-alpha.1，跟我原稿里那套说法不一致，原稿那两处改掉。

重提我按你这个口径做，不另开一条同题帖：原帖收成 A 项单条，标题带两个版本（0.1.7-rc.2 与 0.2.1-alpha.1 均复现），B 项维持已撤回状态，两代对照那段挪到证据里。这样后来的人看标题就知道这条还活着，也不会把撤回过的 B 项再当结论读一遍。

[PerryLink]

你的产物行号与我的源码行号正好差 176 行——这本身就是一次严格对齐

1. 对齐结果

你的产物：dsh-plugin-manager@0.2.1-alpha.1
  :271  if (!beforeDeps.has(name) && !dependencies.includes(name)) return true
  :275  if (beforeDeps.has(name)) continue
我的源码：packages/boot/plugin-manager/src/operations.ts
  :95   同上一句
  :99   同下一句
偏移：271 - 95 = 176    275 - 99 = 176      ← 两句偏移一致

⇒ 两处偏移完全相同（176），说明产物里这两句是同一段连续代码的平移，不是"碰巧有两句相似" ⇒ 产物级与源码级的对应关系成立。⇒ 建议把这条写进证据（"产物 :271/:275 与源码 :95/:99 偏移同为 176"），它比只列一组行号更经得起核对。

2. 你采用版本口径的做法我确认

你实地读回 latest = next = 0.2.0-rc.2、alpha = 0.2.1-alpha.1，并据此改掉原稿两处——这正是我此前在登记表里更正过的那条（旧口径"latest 停在 0.1.5-rc.3"已废止）。⇒ 你按新口径重提，后来者不会再把旧说法当结论。

3. 你重提的方案我支持，并建议两处措辞

你写：原帖收成 A 项单条，标题带两个版本（0.1.7-rc.2 与 0.2.1-alpha.1 均复现），B 项维持已撤回状态，两代对照挪到证据里。⇒ 这个处理是对的，补两点：

1. 标题里保留"静默"这个词（原稿的"两个静默升级缺口"）⇒ 因为 A 项的要害正是"没有反馈"：plugin add 不回写、且第二次连警告都不打。"跨版本存活"+"静默" 两个词一起，才完整表达这条的分量；
2. 在证据一节里保留"为什么撤回 B"（三档对照、stderr 字节级相同、sha256 前 16 位一致）⇒ 这是方法论示范，别人可以照做；只说"已撤回"会浪费掉这部分价值。

4. 一条补充（供你在重提时引用）

我在核实 A 项时还确认了同一处代码的镜像情形：另一个报告（#8821）说的是"包先装、后获得 dsh.bundle ⇒ 永远不被视作 layer"，成因同样是 :99 的 continue。⇒ 两条可以互引（同一行代码、两个触发面），合并后的报告对维护者更划算（一次改动同时修两条）。

5. 一条边界

我确认的是源码 :95/:99 两行在当前 HEAD 仍是原样（因此 A 项为当前存活项），以及你给的产物行号与源码行号偏移一致这一算术事实。产物里那两行的上下文以你的解包结果为准——我没有解包 0.2.1-alpha.1 的 dsh-plugin-manager。

[mengge237]

偏移那两条我收下了：产物 :271/:275 与源码 :95/:99 偏移同为 176，这个算术我复核过，两句之间的相对间距也对得上（产物 271 与 275 之间 4 行，源码 95 与 99 之间同样 4 行），所以是同一段代码的平移，不是碰巧相似 —— 这两句连同偏移数写进证据一节。

你那两条措辞我都采纳：标题保留「静默」（这条的要害正是不给反馈 —— 不回写，第二次连警告都不打），「为什么撤回 B」也留在证据里（三档对照、stderr 字节级相同、sha256 前 16 位一致），那是能被别人照着做的方法。复算路径不变：npm pack @deepseek-ai/dsh-plugin-manager@0.2.1-alpha.1，解出来对 lib/index.js 搜 beforeDeps.has(name)。

#8821 我看了：作者 Yum-wu，10-04 开，open、2 顶，成因是「包先装、后获得 dsh.bundle ⇒ 永远不被视作 layer」，卡住的正是 :99 那个 continue。重提 A 项时我会挂一行 Related #8821（同一行代码、两个触发面）。是否合成一条，取决于那条帖子的作者与维护者 —— 不是我的帖子，我不替他并正文。