[Bug Report] dsh plugin add 对 git 源安装失败的诊断不分类：仓库不存在时误报 allowBuilds 提示，且提示引用的"pnpm 打印的 key"根本不存在

[DRAG0NM]

摘要

dsh plugin add github:<owner>/<repo> 失败时，DSH 在任何 pnpm 非零退出后都会打印一条固定的 allowBuilds 提示（"git-hosted plugins build on install via their prepare script, which pnpm blocks until allowed — add the exact key pnpm printed above under allowBuilds in pnpm-workspace.yaml"）。该提示不区分失败原因：当失败是 git 解析阶段仓库不存在（git ls-remote 返回 "Repository not found"）时，构建从未开始，allowBuilds 完全不适用；提示里"pnpm printed above"的 key 在输出中也并不存在。同时 DSH 用 stdio: "inherit" 把 pnpm 的 stderr 直通终端，自身看不到错误文本，因此无法做任何分类——这正是 #871 的现象（添加 tui plugin 报错后，用户得到两条矛盾信息：真实的"仓库不存在"与一条误导性的构建白名单提示）。

复现步骤

1. 执行（仓库名故意写错或不存在，模拟 有bug, 还是说文档描述不准确? 添加tui plugin失败了 #871 的 org 写错场景）：

   dsh plugin --profile tui add github:deepseek-harness/turtle-ui

2. 结果：pnpm 报 git ls-remote git+ssh://git@github.com/deepseek-harness/turtle-ui.git →
   remote: Repository not found.，随后 DSH 追加打印 allowBuilds 提示。
3. 提示内容与实际失败无关：没有发生任何构建，也没有任何 pnpm 构建拦截消息可引用。

根因（源码定位，rc.6）

apps/cli 的 lib/plugin-9h8shc4d.js（编译产物 @deepseek-ai/dsh/lib/plugin-9h8shc4d.js）：

1. L108-112：spawnSync("pnpm", args, { cwd: dir, stdio: "inherit", ... })——
   pnpm 的 stderr 直通终端，DSH 进程从不读取，因此后续只能依据退出码 + argv 猜测。
2. L120-126：

   const exitCode = result.status ?? 1;
   if (exitCode === 0) reconcilePlugins(before, dir);
   else {
     process.stderr.write(`${NAME}: pnpm failed in profile directory ${dir}\n`);
     if (args.some((argument) => /^git\+|^github:|\.git(?:#|$)/.test(argument)))
       process.stderr.write(`${NAME}: git-hosted plugins build on install via their prepare script, ...\n`);
   }

   只要参数形似 git 源，无论 pnpm 因何失败（仓库不存在、网络、认证、build 被拦、依赖冲突……）
   都打印同一条 allowBuilds 提示。该提示只对"pnpm 已成功解析并安装、但 prepare 脚本被
   allowBuilds 拦截"这一种失败成立；对解析期失败（仓库 404）是错误诊断。

建议修复

方案 A（推荐）· 捕获并分类 pnpm stderr：把 stdio: "inherit" 改为捕获 stderr
（stdio: ["inherit","inherit","pipe"]），按特征串分类输出：

• 含 Repository not found / remote: Repository not found → 提示"插件仓库不存在——
  检查 owner/repo 拼写、是否为公开仓库、是否正确使用了社区仓库的完整地址"；
• 含 was blocked / ignored build scripts / allowBuilds → 保留现有 allowBuilds 提示；
• 其余 → 只报 pnpm failed，并把捕获的 stderr 尾部附在提示后（用户至少能看到原因）。

方案 B（轻量）· 提示语加前提：不捕获输出，仅把提示改为"如果失败原因是
pnpm 拦截了 git 插件的 prepare 脚本，请 …"，不再宣称"pnpm printed above"存在 key。

方案 C（增强）· add 前预检仓库：对 github: 形式参数，先
GET https://api.github.com/repos/<owner>/<repo> 探测存在性与可见性，404 时直接
给出明确错误并停止，避免把用户推进 pnpm 的 ssh 解析深渊。

影响

• 用户被引导执行无效操作：按提示去 pnpm-workspace.yaml 加 allowBuilds（有bug, 还是说文档描述不准确? 添加tui plugin失败了 #871 场景下
  无效且无 key 可加），浪费时间并加深困惑
• 真实原因（仓库名/组织写错）被淹没在误导提示中；社区仓库（非官方 org 下）尤其
  容易踩中——github:deepseek-harness/<x> 的组织名写错即触发
• 同类：任何 git 源解析期失败（私有仓库未认证、网络不通）都会收到同一条
  不相关的 allowBuilds 提示

环境

• 源码定位：0.1.0-rc.6（npx 缓存安装包，Node v24.16.0，Windows 11）
• 原报告：有bug, 还是说文档描述不准确? 添加tui plugin失败了 #871（0 评论，此前无人分析）

验证材料

• 根因节代码行号与关键片段（L108-112 的 inherit、L120-126 的无条件提示）
• 复现步骤即 有bug, 还是说文档描述不准确? 添加tui plugin失败了 #871 原命令，失败输出与提示并存可直接观察
• 逻辑验证：/^git\+|^github:|\.git(?:#|$)/ 匹配任何 git 参数 → 任何失败都触发
  同一条提示，与失败阶段无关

---

First analysis of discussion #871. Happy to open a PR with fix option A.