dsh-market/dsh-market

更正一下上一条：1.16.2 修的是**代理没有透传给 pnpm**（安装走不通的那部分），不是这个 issue 标题说的断点续传。

断点续传仍然做不了——pnpm 本身不支持 Range 续传，市场无法绕过它。这条继续开着。

已在 **1.16.2** 修复，感谢反馈。

```
dsh plugin --profile web add dshmarket
```

根因和改动详见 #239。

导出日志看了，根因是环境问题，不是市场的 bug：这台机器上 `npm`/`corepack` 不在系统 PATH 里（日志里两条报错，Windows 中文系统下的乱码其实是「'corepack' 不是内部或外部命令」「'npm' 不是内部或外部命令」），所以市场没法用它们去装/管理 pnpm，装插件自然装不了。

你在 1.12.1，隔了好几个版本，1.14.0 已经发布，这块的错误提示这期间也改进过（之前是直接甩一堆看不懂的原始报错，现在会明确指出是 npm/corepack 缺失）。建议先升级到最新版重新看一遍提示。

真正要解决还是得让 npm/corepack 能被找到，两个办法选一个：
1. 重装一下 Node.js，安装向导里勾上「Add to PATH」；
2. 或者手动把 Node 的安装目录（装了 npm.cmd/corepack.cmd 那个目录）加进系统环境变量 PATH，加完重启一下 deepseek-harness-studio。

这个不是市场代码能修的东西，暂时不当 bug 处理，你验证一下上面的办法。

确认了根因，跟这个会话里我们另外查到的一个问题是同一件事：**pnpm 装插件时不会走 `HTTPS_PROXY` 环境变量**，它只认 `npm_config_https_proxy` 或 `.npmrc` 里的 `https-proxy`。市场自己发的请求（目录、更新检查）从 1.14.0 起已经改用会读代理的 undici 客户端了，但**装插件这一步是起了个 pnpm 子进程，代理设置不会自动传下去**，这块还没修。

之前 1.12.1 已经把"失败后甩一堆 pnpm 进度日志"这部分改成了可读的错误信息（同一次修复也覆盖了 #161），但没解决你说的"没走代理"本身。

计划是给 pnpm 子进程注入翻译过的 `npm_config_https_proxy` 等环境变量。@fkysly 这个我准备做，你看要不要一起排进去？

在 1.12.1 修复了一半：之前失败时界面直接甩出 pnpm 的 ndjson 进度日志（一堆 `pnpm:fetching-progress` 对象），完全看不出真实原因，这部分已经改成显示可读的错误信息。

但你标题里说的**断点续传本身，仍然没有**——pnpm 下载失败后确实是从头重新拉整个包，这是 pnpm 自己的行为，市场这一层管不到。这个 issue 按断点续传的本意，先留着开。

That encoding is right, and it is the version of the rule I would have written. Nothing further needed from us on the contract.

One heads-up that touches your first gate specifically, since it landed today: **1.12.2 is out**, and what it changes is the path your scenario exercises.

A Windows desktop host was launching dsh without the Node install directory on PATH. Node was running; `npm` and `corepack` were not reachable; one-click pnpm setup could not succeed, and with no pnpm the market installs nothing (#167). The fix looks for the toolchain beside `process.execPath` — the one directory the process cannot be wrong about, since it is executing out of it.

This matters to you because "install the artifact into a fresh profile" is exactly the step that needs a package manager present. If your disposable host is a clean Windows image, that step could have failed on 1.12.0 for an environment reason rather than a plugin one — and a first gate that red-lights on its own harness is worse...

重新打开——合并 PR 时被 `Fixes #167` 自动关掉了，不是我判定它已经解决。

修复已随 1.12.2 发布，但你那台机器上会不会真的好，取决于 `deepseek-harness-studio` 内置的 Node 运行时带不带 npm；这一点只有你复测才知道。等你的结果，确认好了我再关。

是真 bug，已修复并发布 **1.12.2**。感谢你带了导出日志——这个问题只有日志能看出来，你贴的那份直接定位了。

## 日志里说了两件事

```
platform: win32 x64
node: v24.18.1 ← Node 在跑
[error] setup-pnpm: npm -g: exit=1 'npm' 不是内部或外部命令… ← npm 却找不到
```

Node **正在运行**，`npm` 和 `corepack` 却找不到。`deepseek-harness-studio` 启动 dsh 时没有把 Node 的安装目录放进 PATH，所以「一键准备 pnpm」这个按钮不可能成功；而没有 pnpm，市场什么插件都装不了——你看到的正是这个。

## 修了两处

1. **我们压根没去 npm 真正在的地方找。** 官方 Node 发行版都把 `npm` / `npm.cmd` / `corepack` 装在 node 可执行文件旁边。这个目录是唯一不可能搞错的——当前进程就是从那里跑起来的——但之前 Windows 上我们一个候选目录都没加。现在会去那里找。

2. **本该给你的提示，在 Windows 上永远不会出现。** 我们靠匹配 `ENOENT`（Node 的措辞）来判断「工具链缺失」，而 cmd.exe 用的是控制台的 ANSI 代码页；那串报错到我们这里既不是 `ENOENT` 也不是合法 UTF-8——你日志里那堆乱码就是我们解码解坏了，不是你那边的问题。于是没有任何分支命中，你只拿到一句「自动准备没成功」，没有任何可操作的信息。现在改成直接在磁盘上找可执行文件，**跟系统语言无关**。

顺带把措辞也改了：以前那句说的是「找不到 Node」，但你这台机器 Node 好好跑着，缺的是 npm——照那句话去重装 Node 是白费功夫。

## 请你复测

```sh
dsh plugin --profile web add dshmarket@1.12.2
```

重启后再点一次那个按钮。两种结果，都请回报：

- **装上了** → 第 1 条修复生效，问题解决。
- **仍然失败** → 那说明 `deepseek-harness-studio` 内置的 Node 运行时**...

Thanks for the refinement. We will encode the `1.11.2` threshold in the route scenario rather than assuming `version` exists on every historical artifact:

- `>=1.11.2`: assert `version` equals the immutable artifact version;
- older artifacts: assert HTTP 200, the stable status fields, and the exact loader row without treating a missing `version` as a failure.

That gives us a narrow, reproducible first gate while preserving useful historical comparisons. I will update the Testkit issue and use this contract when the route assertion surface is implemented.

Agreed on all of it, and keeping the first gate narrow is the right call.

One implementation detail that would otherwise cost you a confusing failure: **`version` in `/dsh-market/status` only exists from 1.11.2 onward.** It was added so a screenshot of a bug report carries the version, and the status route inherited it.

So the assertion "`version` matches the artifact under test" is correct for 1.11.2 and newer, and will fail on anything older for a reason that has nothing to do with the plugin working. If you ever pin an older artifact for comparison, fall back to the loader row and a 200 from the route.

The other fields you named are older and safe across the whole supported range: `pnpm`, `boot`, `restart`, `installed`.

Nothing else from us — go ahead and rerun against the digest when the assertion surface is ready. If a scenario fails against a released artifact, an issue here with the machine-readable report is exactly the right channel, and we will treat it as a real report r...

Thank you — this is exactly the level of contract detail we needed, and I confirm the partnership.

I recorded the supported floor (`0.1.0-rc.6`), the loader/package name distinction (`dsh-market` / `dshmarket`), the host-route surface, and the smallest scenario in [DSH Testkit #18](https://github.com/iiwish/dsh-testkit/issues/18).

The first follow-up will stay deliberately narrow: pinned published artifact → boot → `GET /dsh-market/status` with HTTP 200 and artifact-matching `version` → exact loader row → uninstall/reboot/residue check. I will keep update/rollback and CRLF patch cases as later opt-in scenarios rather than expanding the first gate.

I will also treat the route response as evidence only, not a certification or ranking, and keep the route probe restricted to the disposable host. Once the route assertion surface is implemented, I will rerun `dshmarket@1.12.0` against the exact digest already verified here and attach the machine-readable report.

Thanks for the careful wa...

Happy to participate. Thank you for running it against the real artifact rather than a checkout — I verified the digest you published:

```
claimed 8d3bb4a346182175a21d879bd7bed17a396e013f11de3017cd0187f7d9012647
actual 8d3bb4a346182175a21d879bd7bed17a396e013f11de3017cd0187f7d9012647
```

That is the tarball npm serves for `dshmarket@1.12.0`. Starting from a published artifact is the part that makes this worth reading.

Answers to your four points, in the order you raised them.

## 1. Supported DSH release train

**0.1.0-rc.6 and newer.** rc.6 is a hard floor, not a preference: below it the client primitives the market renders with do not exist, and it disables itself deliberately rather than throwing mid-render.

Both rc.6 and rc.7 are supported and both are verified — we ran our own layer-3 lane against each yesterday, not just the newer one. Your run used rc.6, which is the floor, so it is the more interesting of the two to keep pinned.

One rc.7-only surface exists (a settings c...

**当然可以，认领了。** 而且你的诊断是对的，我核对了代码：

`depIdentities()`（`src/client/market-data.ts:298`）从依赖里提取身份时，只有 `github:` 规格会带上仓库标识：

```ts
const match = /github:([A-Za-z0-9_.-]+\/[A-Za-z0-9_.-]+)…/i.exec(spec)
```

`link:` 和 `file:` 装的插件走不到这个分支，身份集合里就只剩一个小写包名——于是**目录里所有同名条目都会匹配上**，全都显示「已安装」。你说的「退化为按包名匹配」，准确。

## 动手前想跟你对齐一下方向

难点在于：`link:../foo` 这种规格**本身确实不含仓库信息**，所以不是「解析得更用力一点」就能解决的，得决定拿不到身份时怎么办。两条路：

1. **本地安装只匹配精确同名的那一个条目**，同名的其余不显示已安装 —— 简单，但如果用户 link 的正是某个条目的本地检出，可能匹配到错的那个
2. **读一下 `node_modules//package.json` 的 `repository` 字段**来补身份 —— 更准，但市场客户端拿不到这个，得让 `/dsh-market/installed` 多返回一点数据

我倾向 **2**，因为它把「不知道」变成「知道」，而 1 只是把错误摊薄。但 2 要动服务端，工作量大一些。你怎么看？选 1 也行，比现状好。

## 提 PR 时麻烦带上

- **红→绿的测试**：`tests/market-data.spec.ts` 里有现成的 `matchInstalledName` 用例可以照着加。先确认新测试对**现在的代码是红的**，否则容易写出一个怎么改都通过的测试（我自己踩过好几次）
- `npm test` 和 `npm run check` 都过

涉及 UI 判定的改动我这边会真机验证一遍再合。

顺带说一句：这个 bug 的形态挺典型的——**当身份无法确定时，代码选择了「宽松匹配」而不是「承认不知道」**，结果错误被放大到所有同名条目。你能从「多个卡片都显示已安装」反推到匹配逻辑，排查得很扎实。

补充一个可复现情况：当 profile 通过 `link:` 安装本地插件，且市场存在多个同名插件（如 `dsh-vision-bridge`）时，实际只安装了其中一个，但多个同名卡片都会显示“已安装”。看起来当前在无法从 `link:` 解析仓库身份时，会退化为按包名匹配。

如果这个方向目前还没人处理，我想认领并提交 PR，可以吗？

**1.12.1 已发布**，其中包含前面说的那个修复：失败时不再把 pnpm 的原始进度日志当错误信息展示。

```sh
dsh plugin --profile web add dshmarket@1.12.1
```

断点续传本身还是没有——那是 pnpm 的行为，市场改不了。

不过前面请你确认的那件事仍然有效，那才是关键区别：**「同一个包反复重下」是 pnpm 固有行为，「每次装新插件都重下已有依赖」才是真 bug**。升级后如果还觉得频繁，麻烦点「导出日志」贴上来，我看 `storeDir` 那行就能判断。