dsh-plugin-rea 2.0.2 → 2.0.4

package/CHANGELOG.md

@@ -2,6 +2,127 @@
 
 本插件遵循语义化版本。版本号变化说明「配置组合」这层的变化，与 REA 自身的版本无关。
 
+## 2.0.4 — 2026-10-17
+
+**两处已核实的缺陷：只读 bundle 目录下 shim 启动即崩；与上游 `rea setup --client dsh` 的同名注册冲突现在会被明确提示。**
+
+### 修复
+
+- **只读 bundle 根目录 + 陈旧 lock → shim 未捕获 EACCES 崩溃**：2.0.3 把删锁移出了 `if (fresh)`，却没包
+  try/catch。目录只读（`chmod 555`、系统级安装目录）且锁已陈旧时，`rmSync(lock)` 抛 `EACCES`，shim 以
+  未捕获异常退出（exit 1 + 堆栈）—— 比原来的静默更吵，但同样起不来。沙箱已复现（WSL `chmod 555`）。
+  现在删锁失败返回 `unwritable`，走既有的「无法写入，请手动跑 setup」路径（exit 78，行不崩）。
+- **与上游 `rea setup --client dsh` 的同名注册冲突**：该命令往 `<DSH_HOME>/cordis.patch.yml` 写入
+  `id: rea-mcp`、`serverName: rea`，而本包是 `id: mcp-rea`、同一个 `serverName`；DSH 对同名条目只保留
+  一个（后加载者报 duplicate server name）。已按上游 6.5.0 实测生成该文件确认。shim 现在启动时检测同
+  文件的 `serverName: rea`（id 不是 `mcp-rea`）并向 stderr 提示「二选一」，`--shim-status` 也会在
+  `duplicateRegistration` 下报告。
+
+### 文档
+
+- 两份 README 新增「只保留一条 REA 注册」小节：与 `rea setup --client dsh` 二选一，并说明两条路线的
+  取舍（零依赖供给 vs 上游官方纯配置注册）。
+- v1 分支 README 顶部加横幅：指向 2.x（`main`，默认推荐）与上游官方注册。
+
+### 验证
+
+- 单测 40 条：Windows 37 过 + 3 平台跳过；WSL 39 过 + 1 跳过（本轮新增 3 条，其中只读目录一条仅 POSIX）。
+- 反向验证：回退删锁的 try/catch → 只读目录测试在 WSL 必红（EACCES/exit 1）；回退冲突检测 → 重复注册
+  测试必红。
+- `verify-branch.ps1` 全绿。
+
+## 2.0.3 — 2026-10-16
+
+**修复 11 处已核实的缺陷（每条都先确认存在、并配了"回退即变红"的回归测试）；上游 REA 钉子从 6.4.0 升到 6.5.0。**
+
+### 上游
+
+- `pins.reaAgents` 与 `components.reaAgents.sources.npm.version` → **6.5.0**：engines 与 bin 入口未变
+  （`^22.19.0 || ^24.11.0 || >=26.0.0`、`scripts/rea.mjs`），工具数 170 → **207**（运行时 `rea doctor --json` 实测；上游源码静态清点为 206，多出的 1 个注册在 contracts 之外。新增：Frida 9、
+  GDB 4、Rizin/Cutter 6、pcap/packet 4、flutter 2、sqlite/rust/go/wasm/electron/harmony/hopper 各 1 等）。
+  新增的 `optionalDependencies.frida` 在 `--ignore-scripts` 下不会执行安装脚本。REA 探针正则收紧为
+  `^6\.5\.0(\s|$)`，审计新增"下一个 patch/minor 不得通过"的断言。
+- Ghidra 12.1.4 / apktool 3.0.3 / jadx-headless-mcp 0.7.1 **经核实仍是当前最新**；Node 24.22.0 虽已发布，
+  但晚于本插件的实测矩阵，故保持 24.21.0（engines 完全满足）。
+
+### 修复
+
+- **`--only` 抹掉其它组件的记录**：bundle.json 由本轮结果整份重写，未点名组件的 `paths.jdk/ghidra` 变
+  `null`，shim 不再导出 `JAVA_HOME`/`GHIDRA_INSTALL_DIR`——原生分析静默失效，下次完整跑还得重新解压
+  750 MB。未点名的组件现在按旧记录结转（且只在记录的路径仍然存在时），缺依赖时优先用旧记录/机器/运行
+  setup 的解释器来满足，而不是整段跳过检查。
+- **完整的 `.part` 不被当作已完成**：只打一行日志，然后发 `Range: bytes=<全长>-`（416；四次重试后把
+  已经下好的文件报成失败）。现在校验通过即改名收下。
+- **Windows 下载主路线没有续传**：PowerShell 路线每轮先删 `.part`；失败后 Node 兜底仍用进本轮前的
+  `have`，以 append 把 200 全量接在半成品后面（长度必然超标，只能重下）。两条路线现在都按盘上实际
+  长度发 Range 续传。
+- **POSIX 的 apktool wrapper 没有执行位**（copyFileSync 落 0644，而 REA 不加 shell 直接 spawn → EACCES）：
+  manifest 里标了 `executable` 的条目落盘时 chmod 0755。
+- **apktool wrapper 钉在 `master` 分支 + 硬校验 sha256**：上游对 wrapper 的任何一次提交都会让全网新装
+  hash mismatch。改钉不可变的 `v3.0.3` tag，哈希按该 tag 重新实测。
+- **`--reuse` 不校验版本**：JDK 只看 `javac` 存在、Ghidra 只看 `analyzeHeadless` 存在（JDK 8/11、Ghidra 11
+  照收）。现在候选必须通过该组件自己的 probe；同时修好"文件型 probe 从不检查 `expect`"（Ghidra 的
+  `application.version=` 断言此前是死配置）。
+- **`bundle.json` 损坏即永久失败**：setup 读不了它、也没人启动 setup，用户只能手删文件。现在 setup 容忍
+  它（并按需重写），shim 对 `malformed` 与 `missing` 一样触发供给。
+- **失败后 shim 谎报 6 小时**：lock 现在记录状态与 pid；失败态如实报告"上一次失败了"，持有者已消失的
+  lock 不再阻塞重试。
+- **成功的 `--json` 轮次从不删 lock**：删除语句原先在非 `--json` 分支里，--json 成功也留下 lock。
+- **shim 兜底 REA 路径少了 `node_modules`**：旧 bundle.json 缺 `paths.reaEntry` 时会把可用安装判成"CLI 丢了"。
+- **`scripts/rea-bundle-bootstrap.ps1`**：`node -v` 输出非数字时 `[int]` 强转在 `$ErrorActionPreference='Stop'`
+  下会炸掉整个 bootstrap（而它存在的意义就是这条路径）；`&` 调用失败时 `$LASTEXITCODE` 可能为 `$null` →
+  `exit $null` = 假成功；engines 改从 manifest 的 `pins.nodeEngines` 读（不再抄第二份）；`-DryRun` 不再创建
+  目录（它承诺"什么都没改"）。
+- **`check-updates.ps1` 的 1.x 残留**：REA 节默认找 npm 全局包（2.x 是 vendored）、Ghidra 节读用户级
+  `GHIDRA_INSTALL_DIR`、`rea doctor` 拿不到 vendored CLI（整段自检被静默跳过）、一体包对账对"未记录版本"
+  的组件静默 `continue` 却打印"全部一致"。现在一律先读 `bundle.json`，并如实报告无法对账的项。
+
+### 审计与 CI
+
+- `audit-manifest.mjs` 新增 4 项：manifest 组件 ⇄ `INSTALL_ORDER` 对账、`pins.nodeEngines` ⇄ `package.json
+  engines`、REA pin 探针不得放行下一个 patch/minor、POSIX wrapper 必须标 `executable`。
+- `validate.yml` 新增 `windows-latest` job：PowerShell 下载路线、zip 解压与 bootstrap 此前是零 CI 覆盖的
+  Windows 专属代码。
+- 单测 33 条（32 过 + 1 条按平台跳过）；`--reuse adopts a compatible node` 在 engines 之外的宿主上改为显式
+  skip（此前在 Node 20 上必红，而 CI 钉 22 看不出来）。
+
+### 第二轮修复（同一份**更新后**的清单，2026-10-16 晚）
+
+- 🔴 **过期 lock 永久卡死自动供给（2.0.0–2.0.2 三版全带）**：`maybeAutoProvision()` 只在 lock 新鲜时
+  处理它，过期的 lock 既不清除也不报告 → 落到独占创建 → `EEXIST` → 返回 `in-flight`，而 `main()` 对
+  `in-flight` **一个字都不打印**。于是「下载被 kill / 断电」这一常态，在 6 小时后再启动就变成**永久不再
+  自动供给且完全静默**。已按清单复现（7 小时死 lock：不启动、lock 原样、无任何提示；5 分钟 lock 对照组
+  正常删锁重启），修法：**不新鲜或持有者已死就一律清锁**（这正是注释里"只在新鲜时尊重它"的本意），
+  并给 `in-flight` / `spawn-failed` / `unwritable` 补上如实提示。
+- 🔴 **`examples/` 两个文件是 1.x 内容，却随 2.x 进了 npm 包**：`cordis.patch.posix.yml` 教人把整行换成
+  `command: rea`、`cordis.patch.with-env.yml` 给的是 `cmd.exe /c rea` 的 1.x 行——对 2.x 全错（2.x 的行是
+  跨平台的 `process.execPath` + bundle shim，照抄会整行绕过 bundle）。两份都已是孤儿（README 不再引用），
+  故从 `main` **删除**，并同步 `package.json files[]` 与 `validate.yml` 的载荷/YAML/机器路径三项检查
+  （v1 分支保留它们，在 1.x 语境里是对的）。npm 载荷由此 21 → 19 个文件。
+- 🟡 **`--offline` 管不住 `reaAgents`**：`provisionReaAgents()` 里 0 处 offline 判断，`npm install` 永远
+  联网——与「`--offline` is a promise, not a hint」直接矛盾。现在 `--offline` 且内置副本不可用时**直接
+  FAIL** 并说明原因（而可用的内置副本仍照常跳过）。
+- 🟡 **npm 那一步没有代理/镜像兜底**：压缩包有 direct→proxy→PowerShell 三路，npm 只读环境变量。失败时
+  现在会打印这句提示，两份 README 的能力/注意里也写明 `HTTPS_PROXY` / `NPM_CONFIG_REGISTRY`。
+- 🟡 **POSIX 缺 `unzip`/`xz` 必现失败**：Ghidra 全平台只有 zip，而 POSIX 解压原先只有 `unzip` 一条路。
+  现在 zip 依次尝试 `unzip` → `python3 -m zipfile` → **已供给 JDK 自带的 `jar`**（JDK 在 Ghidra 之前供给，
+  等于保底），tar 依次 `tar` → `python3`；三者皆无时打印明确的「no zip extractor available」而不是干巴巴的
+  「extraction failed」。
+- 🟡 **manifest 的 arm64 注释是错的**：Google 的 linux/darwin platform-tools 都是 x86_64 二进制，
+  「The same archive serves x86-64 and arm64」不成立。三个条目改成如实描述（macOS 需 Rosetta 2、
+  linux-arm64 上 probe 预期失败并被报为可选组件不可用）。
+- 🟡 **`docs/bundle-design.md` 与实现漂移**：§3 的「row points at `<plugin>/bin/rea-shim.mjs`」改成
+  「按 `DSH_HOME` 算出 `<DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs`（镜像副本）」；§7 的
+  `vendor/rea-agents` 改成 `vendor/node_modules/rea-agents`。
+- 🟢 **`release.yml` 的 `workflow_dispatch` 可绕过 Release 直接发 npm**：publish job 现在先断言
+  `v<package.json version>` 的 tag 在 origin 上存在、且该 Release 挂着版本无关的 `dsh-plugin-rea.tgz`
+  资产，否则拒绝发布（否则 npm 与市场兜底链接会岔开）。
+- 🟢 **数值环境变量会变成 NaN**：`REA_BUNDLE_FETCH_RETRIES=abc` → `Math.max(1, NaN)` → 报
+  「gave up after NaN attempt(s)」；NaN 的 socket 超时等价于 0（立即超时）。现在非正有限值一律回落到默认，
+  且启动日志新增一行 `limits connect=… idle=… retries=…`，让覆盖生效可见。
+- 🟢 注释与整洁：`downloadViaPowerShell` 的文档说自己是 fallback，实际在 Windows 上是主路线（已改口径）；
+  去掉 setup.mjs 里 3 处对已静态导入成员的重复 `await import("node:fs")`（`readdirSync` 补进静态导入）。
+
 ## 2.0.2 — 2026-10-15
 
 **仅文档，无行为变更。**

package/README.md

@@ -82,6 +82,10 @@ Both lines ship the **same patch shape** — one `insert` row of `@deepseek-ai/d
 same `mcp__rea__*` surface; they differ in who prepares the runtime. Moving from 1.x to 2.x takes two
 commands: see [Upgrading from 1.x](#upgrading-from-1x).
 
+Upstream also registers itself with dsh now (`rea setup --client dsh`); that route is essentially the
+1.x model maintained upstream — configuration only, your own Node/REA/Ghidra. This bundle is the
+zero-dependency route. Pick one of the three, and never keep two `serverName: rea` rows at once.
+
 ## Install
 
 **Nothing to install first.** On a bare Windows x64 machine:
@@ -110,6 +114,10 @@ If Node is already installed, you can skip the bootstrap and run provisioning di
 node scripts/setup.mjs --reuse      # or --dry-run to see the plan first
 ```
 
+Node, when you provide it instead of letting setup fetch one, must satisfy REA's engines —
+`^22.19.0 || ^24.11.0 || >=26.0.0` (check with `node -v`). A lower Node does not fail at install
+time; the MCP row fails later, which reads as silence.
+
 Installing the plugin **first** also works, but it takes two steps. The row resolves to
 `<DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs`, and that file is created by setup — so until the first
 provisioning run the row exits with `MODULE_NOT_FOUND`, and nothing is there to start a background
@@ -168,6 +176,27 @@ To pin a different launch command on this machine (for example your own globally
 the row from the profile's own `cordis.patch.yml` — that file is machine-local and never published. Only one
 row may use `serverName: rea` in a profile.
 
+### One REA registration only
+
+Upstream REA 6.5.0 can register itself with DSH:
+
+```
+rea setup --client dsh
+```
+
+That writes a row with `id: rea-mcp` and `serverName: rea` into `<DSH_HOME>/cordis.patch.yml`. This
+bundle's row is `id: mcp-rea` with the same `serverName`, and DSH rejects the later of two entries
+that share a server name — so which REA row survives depends on load order. **Use one, not both.**
+
+Which one? Upstream's is the configuration-only route: it expects Node on REA's engines,
+`rea-agents` reachable, and a Ghidra/JDK you provisioned yourself. This bundle is the
+zero-dependency route: it fetches Node, REA, JDK and Ghidra on first run. The patch shape and the
+`mcp__rea__*` surface are the same either way.
+
+The shim reports the conflict on startup when it can see that file — a custom `DSH_HOME` is hidden
+from an MCP child, so it falls back to `~/.dsh` there — and `node bin/rea-shim.mjs --shim-status`
+lists it under `duplicateRegistration`.
+
 ## Verify
 
 Ask for a `mcp__rea__*` call — `binary_session` reports the engine checks
@@ -179,11 +208,11 @@ exact shim launch the MCP row will use.
 
 ## Verified against
 
-Author's machine, 2026-10-13 / 14:
+Author's machine, 2026-10-13 / 14 / 16:
 
 | Component | Version |
 |---|---|
-| REA (`rea-agents`) | **6.4.0** (170 tools) |
+| REA (`rea-agents`) | **6.5.0** (207 tools) |
 | DeepSeek Harness | desktop runtime **0.2.0-rc.2**, with its bundled dsh CLI 0.1.7-rc.2 |
 | `@deepseek-ai/dsh-mcp-client` (row provider) | bundled by the harness |
 | Ghidra | 12.1.4 |
@@ -192,7 +221,7 @@ Author's machine, 2026-10-13 / 14:
 | Host | Windows 11 x64 (build 26200) |
 
 Exercised live: a clean `setup.mjs --reuse` run reached `setup complete`; an MCP `initialize` handshake
-**through the shim with no `rea` on PATH** answered `serverInfo {name: rea, version: 6.4.0}`; and the whole
+**through the shim with no `rea` on PATH** answered `serverInfo {name: rea, version: 6.5.0}`; and the whole
 chain ran under the real desktop host — its own Electron binary launched
 `<DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs mcp`, the shim started the **vendored** REA, and a live tool
 call reported `path_source: environment` for a path only that machine's `bundle.json` knows.
@@ -203,19 +232,33 @@ macOS/Linux.
 
 ## Scope and caveats
 
-- REA exposes 170 tools at 6.4.0, so every session's tool list grows.
+- REA exposes 207 tools at 6.5.0, so every session's tool list grows.
 - Provisioning is honest about checksums: where a vendor publishes one it is pinned and verified; where none
   exists (jadx-headless-mcp, the apktool wrapper, Android platform-tools, the rolling "latest" URLs) the
   hash is **measured once and recorded**, and later drift is reported rather than silently accepted.
   `bundle.json` lists which components are in that state under `unverifiedChecksums`.
 - Downloads are slow on some networks (measured 0.35–0.54 MiB/s from the GitHub release CDN here, so Ghidra
-  alone takes ~25–45 min). Fetching is resumable: the cache is kept and re-verified, and a killed run
-  continues instead of restarting.
+  alone takes ~25–45 min). Fetching is resumable on both routes: a partial `.part` is continued with a Range
+  request, and a `.part` that already holds the whole file is verified and kept instead of re-fetched.
 - Some REA tools launch processes, write files and access the network — DSH's permission policy applies.
   Analyse only artifacts you are authorized to inspect.
+- The MCP child and the engines it launches are ordinary processes running as **you**. DSH's tool
+  approvals govern what the model asks for, not what that child may read, write or send on its own;
+  treat the plugin like any third-party code you install.
+- On Linux, upstream's process-ownership checks need a **procps-compatible `ps`** on PATH; the
+  Ghidra/JADX and firmware paths use it. A minimal image without it fails those tools, not the install.
 - `scripts/setup.mjs` runs `npm install` for the REA CLI with `--ignore-scripts`: the published tarball
   carries no `node_modules`, so a dependency closure must be resolved, and package lifecycle scripts are
-  skipped on purpose during provisioning.
+  skipped on purpose during provisioning. That step is also the **only** one that cannot use this bundle's
+  own route/proxy resolution — npm reads `HTTPS_PROXY`/`HTTP_PROXY` and `NPM_CONFIG_REGISTRY` from the
+  environment, so on a network that needs a mirror, set one of those before provisioning
+  (`NPM_CONFIG_REGISTRY=https://registry.npmmirror.com`). With `--offline` the step is refused outright
+  instead of quietly going online.
+- On POSIX, extraction falls back when the usual tools are missing: a zip is opened with `unzip`, then
+  `python3 -m zipfile`, then the provisioned JDK's `jar`; a tarball with `tar`, then `python3`. A minimal
+  image that has none of them fails with an explicit "no zip extractor available" line rather than a bare
+  "extraction failed". This matters because Ghidra is a zip on every platform and `unzip` is not installed
+  everywhere by default.
 
 ## Updating — three independent things
 

package/README.zh-CN.md

@@ -77,6 +77,9 @@ patch 里不含任何机器路径**。
 `mcp__rea__*` 工具面；区别只在"谁准备运行时"。从 1.x 到 2.x 只要两条命令，见
 [从 1.x 升级](#从-1x-升级)。
 
+上游现在也能自己注册进 dsh（`rea setup --client dsh`）：那基本就是上游维护的 1.x 模式 —— 只写配置，
+Node/REA/Ghidra 由你准备。本包是零依赖路线。三条路选一条，不要同时留两行 `serverName: rea`。
+
 ## 安装
 
 **前置什么都不用装。** 在干净的 Windows x64 机器上：
@@ -104,6 +107,10 @@ dsh plugin --profile <profile> add github:czcdr/dsh-plugin-rea#v2.0.0
 node scripts/setup.mjs --reuse      # 或先 --dry-run 看计划
 ```
 
+如果 Node 由你自备（而不是让 setup 去取），它必须满足 REA 的 engines：
+`^22.19.0 || ^24.11.0 || >=26.0.0`（用 `node -v` 核对）。版本偏低不会在安装时失败，而是到 MCP 行
+启动时才失败 —— 表现就是"没有反应"。
+
 反过来**先装插件**也可以，但要分两步：发布的行指向 `<DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs`，
 而那个文件**只有 setup 会创建**——所以在第一次供给之前，该行会以 `MODULE_NOT_FOUND` 退出，也就没有
 任何东西能去启动后台供给（harness 本身不受影响：`failOnStartupError: false` 是刻意的）。先手动跑一次
@@ -159,6 +166,25 @@ node bin/rea-shim.mjs --shim-print-env   # MCP 子进程将看到的环境变量
 `cordis.patch.yml` 按 id 覆盖即可 —— 那个文件是机器本地的，永不发布。一个 profile 里只允许一行使用
 `serverName: rea`。
 
+### 只保留一条 REA 注册
+
+上游 REA 6.5.0 起可以自己注册进 DSH：
+
+```
+rea setup --client dsh
+```
+
+它会把一行 `id: rea-mcp`、`serverName: rea` 写进 `<DSH_HOME>/cordis.patch.yml`。本包的行是
+`id: mcp-rea`、同样 `serverName: rea`，而 DSH 对同名条目只保留一个：后加载的那行会以
+duplicate server name 报错并加载失败，最终留下哪一行取决于加载顺序。**二选一，不要同时用。**
+
+选哪个？上游那条是纯配置路线：需要 Node 满足 REA engines、`rea-agents` 可达，Ghidra/JDK 由你
+自己准备。本包是零依赖路线：首次运行自动取 Node、REA、JDK、Ghidra。两者的 patch 形态与
+`mcp__rea__*` 工具面相同。
+
+shim 在能看到该文件时会在启动时提示冲突 —— MCP 子进程里拿不到自定义 `DSH_HOME`，那种情况下它会
+退回 `~/.dsh`；`node bin/rea-shim.mjs --shim-status` 会把冲突列在 `duplicateRegistration` 下。
+
 ## 验证
 
 随便发一个 `mcp__rea__*` 调用 —— `binary_session` 会报引擎各项检查
@@ -170,11 +196,11 @@ shim 启动**。
 
 ## 实测环境
 
-作者机器，2026-10-13 / 14：
+作者机器，2026-10-13 / 14 / 16：
 
 | 组件 | 版本 |
 |---|---|
-| REA（`rea-agents`） | **6.4.0**（170 个工具） |
+| REA（`rea-agents`） | **6.5.0**（207 个工具） |
 | DeepSeek Harness | desktop runtime **0.2.0-rc.2**，内含 dsh CLI 0.1.7-rc.2 |
 | `@deepseek-ai/dsh-mcp-client`（行 provider） | 随 harness 打包 |
 | Ghidra | 12.1.4 |
@@ -183,7 +209,7 @@ shim 启动**。
 | 宿主 | Windows 11 x64（build 26200） |
 
 实测跑过：一次干净的 `setup.mjs --reuse` 走到 `setup complete`；一次**不经 PATH 上的 `rea`、完全经由
-shim** 的 MCP `initialize` 握手返回 `serverInfo {name: rea, version: 6.4.0}`；以及**真实桌面宿主下的完整链路** ——
+shim** 的 MCP `initialize` 握手返回 `serverInfo {name: rea, version: 6.5.0}`；以及**真实桌面宿主下的完整链路** ——
 宿主自己的 Electron 二进制启动 `<DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs mcp`，shim 拉起 **bundle 内置**
 的 REA，随后一次真实工具调用报出 `path_source: environment`，而那个路径只有该机的 `bundle.json` 知道。
 
@@ -192,18 +218,31 @@ shim** 的 MCP `initialize` 握手返回 `serverInfo {name: rea, version: 6.4.0}
 
 ## 边界与注意事项
 
-- REA 在 6.4.0 有 170 个工具，每个会话的工具列表都会变长。
+- REA 在 6.5.0 有 207 个工具，每个会话的工具列表都会变长。
 - 校验和对得起良心：厂商发布了的就固定并验证；没发布的（jadx-headless-mcp、apktool 包装脚本、
   Android platform-tools、滚动的 `latest` 地址）则**实测一次并记录**，之后若漂移是**报告**而不是默默接受。
   `bundle.json` 的 `unverifiedChecksums` 会列出处于该状态的组件。
 - 某些网络下很慢（这里实测 GitHub release CDN 只有 0.35–0.54 MiB/s，光 Ghidra 就要 25–45 分钟）。
-  下载是**可续传**的：缓存保留并重新校验，被中断的一轮会继续而不是从头再来。
+  下载是**可续传**的：两条路线都按盘上已有的字节发 Range 继续；若 `.part` 恰好已经完整，会校验后直接收下
+  而不是重下。
 - **代理**：Node 的全局 `fetch` 不读系统代理，而 .NET/PowerShell 会读。在开着 WinINET 代理的机器上，
   同一个地址 `Invoke-WebRequest` 通、Node 却 `ECONNRESET`/超时。setup 自己解析代理
   （环境变量优先，Windows 上回退读注册表）并用 CONNECT 隧道，`NO_PROXY` 也照常生效。
 - REA 的部分工具会启动进程、写文件、访问网络 —— DSH 的权限策略照常适用。只分析你有权检视的样本。
+- MCP 子进程与它拉起的引擎都是以**你的身份**运行的普通进程。DSH 的工具审批管的是模型发起的调用，
+  管不到这个子进程自己去读、写或发送什么；请把插件当作你安装的第三方代码来对待。
+- Linux 上，上游的进程归属检查依赖 PATH 上**兼容 procps 的 `ps`**；Ghidra/JADX 与固件工具会用到它。
+  极简镜像里缺它只会让这些工具失败，不影响整体安装。
 - `scripts/setup.mjs` 为 REA CLI 跑的是带 `--ignore-scripts` 的 `npm install`：官方 tarball 不带
-  `node_modules`，必须解析依赖闭包；而供给过程中**刻意跳过包的 lifecycle 脚本**。
+  `node_modules`，必须解析依赖闭包；而供给过程中**刻意跳过包的 lifecycle 脚本**。这一步也是**唯一**用不上
+  本插件自己的路由/代理回退的环节 —— npm 只从环境读 `HTTPS_PROXY`/`HTTP_PROXY` 与
+  `NPM_CONFIG_REGISTRY`，所以网络需要镜像时请先设其中一个（例如
+  `NPM_CONFIG_REGISTRY=https://registry.npmmirror.com`）。带 `--offline` 时这一步会被**直接拒绝**，
+  而不是悄悄联网。
+- POSIX 上解压有兜底：zip 依次尝试 `unzip` → `python3 -m zipfile` → 已供给 JDK 自带的 `jar`；tar 包依次
+  尝试 `tar` → `python3`。三者都没有的最小镜像会得到一句明确的「no zip extractor available」，而不是
+  干巴巴的「extraction failed」。Ghidra 在所有平台都只有 zip，而 `unzip` 并非每个发行版默认安装，
+  所以这条不是理论问题。
 
 ## 更新 —— 三件互相独立的事
 

package/assets/make-screenshots.ps1

@@ -84,7 +84,7 @@ Draw-Text $g '第三方适配 · 自身不做逆向分析 · 自供给 Node/REA/
 $rowY = 180; $boxH = 158; $boxW = 250
 Draw-Box $g 60 $rowY $boxW $boxH $([System.Drawing.Color]::White) $line
 Draw-Text $g 'DeepSeek Harness 会话' $fBox $ink 80 ($rowY + 18)
-Draw-Text $g "mcp__rea__* 工具`n（6.4.0 暴露 170+）`n工具随会话注入`n按 DSH 权限策略执行" $fBody $muted 80 ($rowY + 50)
+Draw-Text $g "mcp__rea__* 工具`n（6.5.0 暴露 207）`n工具随会话注入`n按 DSH 权限策略执行" $fBody $muted 80 ($rowY + 50)
 
 Draw-Box $g 360 $rowY $boxW $boxH $([System.Drawing.Color]::FromArgb(255,239,246,255)) $accent
 Draw-Text $g '官方 MCP 客户端行' $fBox $accent 380 ($rowY + 18)
@@ -112,7 +112,7 @@ Draw-Line  $g 358 446 150 446 $muted
 Draw-Arrow $g 150 446 150 342 $muted
 
 Draw-Text $g '上游 REA（MIT）：github.com/morluto/rea      本插件：github.com/czcdr/dsh-plugin-rea' $fSmall $muted 60 620
-Draw-Text $g '实测 REA 6.4.0 + DSH 桌面运行时 0.2.0-rc.2 + Ghidra 12.1.4 + Node 24.21.0（Windows 11 x64，2026-10-14）' $fSmall $muted 60 646
+Draw-Text $g '实测 REA 6.5.0 + DSH 桌面运行时 0.2.0-rc.2 + Ghidra 12.1.4 + Node 24.21.0（Windows 11 x64，2026-10-16）' $fSmall $muted 60 646
 Draw-Text $g 'Ghidra 为 Apache-2.0（NSA）；REA 为 MIT。本仓库不分发上游代码。' $fSmall $muted 60 672
 Save-Png $bmp $g (Join-Path $OutDir 'screenshot-1.png')
 

package/bin/rea-shim.mjs

@@ -15,7 +15,7 @@
  *                            and the message is the operator's remediation.
  */
 import { spawn } from "node:child_process";
-import { existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { existsSync, mkdirSync, readFileSync, rmSync, writeFileSync } from "node:fs";
 import { homedir } from "node:os";
 import path from "node:path";
 import process from "node:process";
@@ -93,6 +93,77 @@ function provisioningScript(root) {
   return usableSetup(PLUGIN_ROOT);
 }
 
+/**
+ * Upstream REA 6.5.0 can add a second registration for the same MCP server:
+ * `rea setup --client dsh` writes a row with id "rea-mcp" and serverName "rea"
+ * into `<DSH_HOME>/cordis.patch.yml`, while this bundle ships id "mcp-rea" with
+ * the same serverName. DSH does not dedupe those rows: it rejects the later entry
+ * with a duplicate-server-name error, so which REA row survives depends on load
+ * order. The shim cannot prevent that, but it can name the conflict instead of
+ * leaving a missing row to be diagnosed from "the tools are gone".
+ *
+ * The parse is deliberately small: the two files it cares about are block
+ * mappings with one id/serverName per row, and anything it cannot attribute is
+ * ignored — a missed hint is acceptable, a false alarm is not. The mirrored shim
+ * cannot see a custom DSH_HOME (the harness strips DSH_* from an MCP child), so
+ * this falls back to `~/.dsh` like the rest of the bundle; the row has the same
+ * limitation.
+ */
+function foreignReaRegistration() {
+  const patch = path.join(dshHome(), "cordis.patch.yml");
+  let text;
+  try {
+    text = readFileSync(patch, "utf8");
+  } catch {
+    return null;
+  }
+  const unquote = (value) => value.replace(/^(['"])(.*)\1$/, "$2").trim();
+  // A row starts at `- id:`; the block runs to the next row, so a serverName can
+  // never be attributed to a row that does not contain it.
+  for (const block of text.split(/\r?\n(?=\s*-\s+id:\s*)/)) {
+    const id = /^\s*-\s+id:\s*(.+?)\s*$/m.exec(block);
+    const server = /^\s+serverName:\s*(.+?)\s*$/m.exec(block);
+    if (!id || !server || unquote(server[1]) !== "rea") continue;
+    const rowId = unquote(id[1]);
+    if (rowId !== "mcp-rea") return { patch, id: rowId };
+  }
+  return null;
+}
+
+/**
+ * The provisioning lock is a small JSON record: { state, pid, at, exit? }.
+ * `state: "running"` is written when a run is started (setup's own pid once it
+ * exists), and the failing run rewrites it as `state: "failed"` — it is kept on
+ * purpose so a broken setup cannot be re-downloaded in a loop. A legacy
+ * plain-number lock is still honoured as "running".
+ */
+const STALE_LOCK_MS = 6 * 60 * 60 * 1000;
+
+function readLock(lock) {
+  try {
+    const raw = readFileSync(lock, "utf8").trim();
+    if (raw.startsWith("{")) {
+      const parsed = JSON.parse(raw);
+      if (parsed && typeof parsed === "object") return parsed;
+    }
+    const at = Number(raw);
+    return Number.isFinite(at) ? { state: "running", at } : null;
+  } catch {
+    return null;
+  }
+}
+
+/** Is the process recorded in the lock still alive? null means "cannot tell". */
+function pidAlive(pid) {
+  if (!Number.isInteger(pid) || pid <= 0) return null;
+  try {
+    process.kill(pid, 0);
+    return true;
+  } catch (error) {
+    return error?.code === "ESRCH" ? false : null;
+  }
+}
+
 /**
  * On first run there is nothing to launch. Provisioning is a long download, so
  * it is started detached: the harness may kill this row (or the whole session)
@@ -100,34 +171,67 @@ function provisioningScript(root) {
  * a killed attempt is simply continued on the next start.
  *
  * Set REA_BUNDLE_AUTO_PROVISION=0 to require an explicit `setup.mjs` run.
- * Returns the log path when a run was started, otherwise null.
+ * Returns { started, reason, logPath } — the caller words its message from
+ * `reason`, because "provisioning started in the background" was also printed
+ * for a lock left behind by a run that had already failed, and for one whose
+ * process was long gone.
  */
 function maybeAutoProvision(root) {
-  if (process.env.REA_BUNDLE_AUTO_PROVISION === "0") return null;
+  if (process.env.REA_BUNDLE_AUTO_PROVISION === "0") return { started: false, reason: "disabled" };
   const setupScript = provisioningScript(root);
-  if (!setupScript) return null;
+  if (!setupScript) return { started: false, reason: "no-setup" };
   const lock = path.join(root, "setup.lock");
   const logPath = path.join(root, "logs", "setup.log");
   if (existsSync(lock)) {
     // A crashed run must not wedge provisioning forever: honour the lock only
     // while it is fresh; setup removes it itself when it finishes cleanly.
-    let age = Infinity;
+    const record = readLock(lock);
+    const age = record && Number.isFinite(record.at) ? Date.now() - record.at : Infinity;
+    const fresh = Number.isFinite(age) && age < STALE_LOCK_MS;
+    if (fresh && record?.state === "failed") {
+      // The run gave up and left the lock behind so it would not be retried in a
+      // loop. Claiming it is still provisioning was a six-hour lie: nothing runs,
+      // and every restart repeated the sentence.
+      return {
+        started: false,
+        reason: "last-run-failed",
+        exit: record.exit,
+        failedAt: record.at,
+        ageMs: age,
+        logPath,
+      };
+    }
+    if (fresh) {
+      const alive = pidAlive(record?.pid);
+      if (alive !== false) return { started: false, reason: "in-flight", logPath, ageMs: age };
+    }
+    // Reached when the lock is older than the freshness window, or its holder is
+    // gone and never wrote an outcome (harness restart, power loss, a kill): what
+    // it records is not happening any more. This removal is the whole point of the
+    // freshness rule — without it the exclusive create below failed with EEXIST
+    // *forever*, auto-provisioning never ran again, and main() printed nothing at
+    // all for that outcome. The lock's own "honour it only while it is fresh"
+    // comment described behaviour the code did not have.
     try {
-      age = Date.now() - Number(readFileSync(lock, "utf8").trim() || 0);
+      rmSync(lock, { force: true });
     } catch {
-      age = Infinity;
+      // A read-only bundle root (system-wide install, chmod 555) cannot drop the
+      // stale lock either. Returning the same "cannot write here" outcome as the
+      // exclusive create below keeps the row alive: an uncaught EACCES killed the
+      // shim with a stack trace, which is louder than the old silence but just as
+      // unable to start REA.
+      return { started: false, reason: "unwritable", logPath };
     }
-    if (Number.isFinite(age) && age < 6 * 60 * 60 * 1000) return logPath;
   }
   try {
     mkdirSync(path.join(root, "logs"), { recursive: true });
     // Exclusive create: check-then-write is not atomic, so two rows starting at
     // once could both decide to provision. EEXIST means another run owns it.
-    writeFileSync(lock, String(Date.now()), { flag: "wx" });
+    writeFileSync(lock, JSON.stringify({ state: "running", pid: process.pid, at: Date.now() }), { flag: "wx" });
   } catch (error) {
-    if (error?.code === "EEXIST") return logPath;
+    if (error?.code === "EEXIST") return { started: false, reason: "in-flight", logPath };
     /* a read-only bundle root must never break the harness */
-    return null;
+    return { started: false, reason: "unwritable" };
   }
   try {
     const child = spawn(process.execPath, [setupScript, "--root", root], {
@@ -136,9 +240,18 @@ function maybeAutoProvision(root) {
       windowsHide: true,
     });
     child.unref();
-    return logPath;
+    // Hand the lock to the detached downloader, so a later start that finds this
+    // row dead still sees the run that is actually doing the work as alive.
+    if (Number.isInteger(child.pid)) {
+      try {
+        writeFileSync(lock, JSON.stringify({ state: "running", pid: child.pid, at: Date.now(), supervisor: process.pid }));
+      } catch {
+        /* the lock is advisory: the row keeps working without it */
+      }
+    }
+    return { started: true, reason: "started", logPath };
   } catch {
-    return null;
+    return { started: false, reason: "spawn-failed", logPath };
   }
 }
 
@@ -195,8 +308,13 @@ function readBundleConfig(root) {
 function resolveRea(config, root) {
   const paths = config.paths ?? {};
   const node = paths.node;
+  // The fallback has to match where setup actually installs the package:
+  // `npm install --prefix <root>/vendor` resolves into vendor/node_modules, so a
+  // fallback without that segment named a directory that never exists. It only
+  // fires when an older bundle.json has no paths.reaEntry — which is exactly when
+  // a wrong fallback turns a usable install into "the vendored REA CLI is gone".
   const reaEntry = paths.reaEntry
-    ?? path.join(root, "vendor", "rea-agents", "scripts", "rea.mjs");
+    ?? path.join(root, "vendor", "node_modules", "rea-agents", "scripts", "rea.mjs");
 
   if (typeof node !== "string" || node.trim() === "") {
     return { ok: false, reason: "bundle.json has no paths.node" };
@@ -279,6 +397,18 @@ function main() {
 
   const root = bundleRoot();
   const loaded = readBundleConfig(root);
+  // Upstream can add a second row for the same serverName; the shim cannot stop
+  // DSH from loading both rows, but saying so is better than doubled tools with
+  // no stated cause. The status report carries the same fact for diagnostics.
+  const duplicate = foreignReaRegistration();
+  if (duplicate && !argv.includes("--shim-status")) {
+    process.stderr.write(
+      `\n  dsh-plugin-rea (bundle): duplicate REA registration.\n` +
+        `  ${duplicate.patch} also registers serverName "rea" (id "${duplicate.id}").\n` +
+        `  This bundle's row is id "mcp-rea" with the same serverName; DSH rejects the later\n` +
+        `  entry as a duplicate server name, so only one survives. Keep exactly one of them.\n`,
+    );
+  }
 
   if (argv.includes("--shim-status")) {
     const report = {
@@ -288,6 +418,7 @@ function main() {
       reason: loaded.ok ? undefined : loaded.code,
       autoProvision: process.env.REA_BUNDLE_AUTO_PROVISION ?? "(default)",
     };
+    if (duplicate) report.duplicateRegistration = duplicate;
     if (loaded.ok) {
       report.paths = loaded.config.paths ?? {};
       report.versions = loaded.config.versions ?? {};
@@ -302,10 +433,31 @@ function main() {
       loaded.code === "missing"
         ? `No bundle state at ${loaded.file}.`
         : `Bundle state at ${loaded.file} could not be parsed.`;
-    const logPath = loaded.code === "missing" ? maybeAutoProvision(root) : null;
-    if (logPath) {
+    // Both "missing" and "malformed" start a run. A malformed file used to fail
+    // permanently: setup overwrites a bundle.json it cannot parse, but nothing
+    // ever started setup, so every restart reported the same EX_CONFIG until the
+    // operator deleted the file by hand. The lock stops a provisioning loop when
+    // writing keeps failing.
+    const provisioning = maybeAutoProvision(root);
+    if (provisioning.started) {
+      process.stderr.write(
+        `\n  dsh-plugin-rea (bundle): first run — provisioning started in the background.\n  progress: ${provisioning.logPath}\n`,
+      );
+    } else if (provisioning.reason === "last-run-failed") {
+      process.stderr.write(
+        `\n  dsh-plugin-rea (bundle): the last provisioning attempt failed (exit ${provisioning.exit ?? "?"}).\n` +
+          `  Nothing is running right now — read the log, then re-run setup.\n  log: ${provisioning.logPath}\n`,
+      );
+    } else if (provisioning.reason === "in-flight") {
+      // A live run owns the lock. Saying nothing here is what made a wedged
+      // provisioning attempt look like a machine that simply has no bundle.
+      process.stderr.write(
+        `\n  dsh-plugin-rea (bundle): provisioning is already running in the background.\n  progress: ${provisioning.logPath}\n`,
+      );
+    } else if (provisioning.reason === "spawn-failed" || provisioning.reason === "unwritable") {
       process.stderr.write(
-        `\n  dsh-plugin-rea (bundle): first run — provisioning started in the background.\n  progress: ${logPath}\n`,
+        `\n  dsh-plugin-rea (bundle): provisioning could not be started (${provisioning.reason}).\n` +
+          `  Run it by hand:\n    node "${path.join(root, "scripts", "setup.mjs")}"\n`,
       );
     }
     return fail(message, loaded.detail);