@mars-sea/dsh-commandcode-provider 0.14.0 → 0.14.2

package/CHANGELOG.md

@@ -4,6 +4,45 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.14.2] - 2026-10-18
+
+### Changed
+
+- 同步 Command Code CLI `1.82.5` → `1.84.0`：请求版本标识（`x-command-code-version`）随之上调。这是**纯请求头同步**，不伴随运行时行为变更。官方日志两版共 8 条：`1.83.0`（2026-10-16）7 条**全部为 FEAT（新功能）**，集中在 CLI 的 mods 扩展体系——`panes`／`widgets`／`toasts`、mods 热重载、权限应答、会话记录脱敏、按请求路由模型、注入面 `{cmd.state,cmd.store,cmd.clock,cmd.model,cmd.prompt}` 与子代理类型、`/mods` 命令与 `cmd mods inspect`、`--safe-mode`（安全模式）、`hooks.transformTextDelta`、`cmd.process.spawn`、`cmd.ui.override`，另有一条「Planning and Implementation models follow the live model catalog」；`1.84.0` 仅 1 条，新增 `/statusline`。**四类关切（推理强度／ZDR／套餐与定价／协议）在官方条目中零命中**，且新增的 `/mods` 与 `/statusline` 都是本地 TUI（终端界面）命令而不是 API 路径，因此插件侧的协议面与数据面本身没有跟着变化。
+
+- **产物级对照：`1.82.5` 与 `1.84.0` 的能力数据逐项相等。**两版 CLI 产物的模型注册表 100 条、efforts（推理档位）66 条、subscriptions（订阅表）9 条、ZDR 例外 24 条逐项相同，内嵌 `catalogVersion` 两版同为 `d6177bab…`；端点主机集合与自定义请求头集合零差异，因此版本号之外没有任何需要跟随的改动——`1.82.4` → `1.82.5` 那一轮把实时目录结果折回内嵌快照之后，`1.84.0` 没有再动这份快照。该结论来自产物级静态比对：官方日志的 8 条覆盖不到数据面，只有逐项比对才能排除"日志没写但数据动了"。
+
+- 实时目录漂移与快照同步（`?view=client` 101 条，`catalogVersion` `e6fe850d…`；默认视图 93 条）：`KNOWN_PLANS` 92 → 93、`KNOWN_EFFORTS` 64 → 65，两处新增的都是 `reflection/beam:free`（免费预览、Go 档、仅文本、五档 `low`／`medium`／`high`／`xhigh`／`max`）；`KNOWN_NON_ZDR_MODELS` 24 → 25，撤出 `meituan/LongCat-2.0:free`、补入 `meituan/LongCat-2.0` 与 `reflection/beam:free`（目录对付费 id 判 `zdr:false`、对被撤下的 `:free` 行改判 `zdr:true`，属同一位置的改名而非覆盖变化）；`KNOWN_DEALS` 6 → 7，新增 `reflection/beam:free` 免费促销。`KNOWN_IMAGE_MODELS` 保持 70 条不变——新模型只支持文本输入。目录 `catalogVersion` 由 `d6177bab…` 推进到 `e6fe850d…`，与产物内嵌快照之间的差距继续拉大，再次印证第七章第 9 条：内嵌快照发布后约两天即过期，同步一律以实时目录为准。
+
+- 三张 id 表与 ZDR 例外表的收录口径本轮写进[《决策记录》第七章第 12 条](docs/决策记录.md#七上游快照同步边界)：`KNOWN_PLANS`／`KNOWN_EFFORTS`／`KNOWN_IMAGE_MODELS` 只收**默认目录视图**（`GET /provider/v1/models`，本轮 93 个 id）里的 id，该视图不返回 `hidden` 字段、也没有隐藏行，8 个 `hidden:true` 行只存在于 `?view=client`，故天然不进入这三张表；`KNOWN_NON_ZDR_MODELS` 收 **artifact 排除集与 `?view=client` 目录 `zdr:false` 行的并集**（单源不完整，`reflection/beam:free` 就是只有目录侧提名的一例）。本轮 `reflection/beam:free` 在默认视图可见，因此 92 → 93 与口径自洽，不需要任何"CLI 注册表未认的行例外收录"式说明。
+
+- 价格表与输出上限表重新生成：`deepseek-v4.1-flash` 与 `glm-5.3-flash` 两行的每月额度由 Go $10／GOAT $100／Pro $100 下调为 **Go $10／GOAT $80／Pro $90**，两行的费率不变（前者 $0.15／$0.6／$0.003，后者 $0.15／$0.5／$0.03）。`MODEL_OUTPUT_TOKEN_LIMITS` 新增 3 行（`deepseek/deepseek-v4-flash-fast` 384 000、`Qwen/Qwen3.8-Max-0902` 131 072、`tencent/hy3-paid` 128 000），写入数 75 → **78**。`reflection/beam:free` 按页面发布的字面零价，不进价格表。
+
+- 复核**无变化**的项：峰谷计价仍是 5 个 DeepSeek 模型、窗口 `01–04 & 06–10 UTC, Mon–Fri` 与本地常量逐值一致；订阅条目与每月额度零变化；`reflection/beam:free` 支持图像输入这一点未被目录宣告，图像能力表保持 70 条；effort 词汇表仍是 `off｜low｜medium｜high｜xhigh｜max`。
+
+- **证据边界**：本轮 `scripts/` 巡检工具的状态为 `incomplete`、`readyToApply=false`、`protocol=not-verified`；唯一一条 error 是 `reflection/beam:free: absent from CLI registry`——该模型只出现在两个目录视图里，`1.84.0` 产物注册表完全不认它，因此 `KNOWN_EFFORTS` 与 `KNOWN_NON_ZDR_MODELS` 里这一行属**目录侧单源证据**（与 `1.82.4` 时 `stealth/cat-jam:free` 的处境相同）。16 个数据源全部返回 HTTP 200。**未做**：真实账号登录、付费生成、浏览器渲染验证，也没有在真实账号上验证价格与订阅额度的页面读数；`?view=client` 与定价页均为公开数据采集。
+- **设置页「模型与上下文」分组改为可折叠，默认收起（issue #94）。**该分组是页面上最长的一组（套餐过滤开关 → 可见模型白名单 → 自定义上下文长度 → 按模型覆盖行），折起后「隐私与安全」与「集成与显示」两个分组不必翻过白名单即可到达。折叠头与「高级设置」共用同一实现（`DisclosureHead`／`CollapsibleGroup`），三条行为两边逐字一致：整行可点、箭头在行尾、状态不跨刷新记忆（组件内 `useState`，既不进配置文档也不进 localStorage——折叠是呈现偏好，不该由设置文档承载）。**「高级设置」呈现与交互零变化**，只是换成共用实现；`cc-groupHead`／`cc-disclosure`／`cc-chevron`／`cc-badgeWarn` 四个既有类原样复用，样式表零改动。**边界：纯呈现层开关**——`filterModelsByPlan`／`visibleModels`／`contextWindow`／`maxOutputTokens`／`contextWindowOverrides` 五个字段的暂存、校验、整批提交与写入所有权一律不变（沿用[《决策记录》第六章第1、2条](docs/决策记录.md#六设置写入所有权)），收起只决定组内 DOM 是否渲染，已暂存的编辑不会丢。**连带处理**：默认收起会把组内的无效数字一并藏起，而保存按钮会因此禁用，故折叠时在标题行显示警告徽标（新 locale 键 `modelsInvalid`，与「高级设置」的既有徽标同形）；不新增「已选 N 个模型」式摘要徽标——诉求只是可收起，「非默认」口径需要另行定义。**已知取舍**：折叠头的标题仍是 `span` 而非 `h3`（该分组在标题导航里不再是一个 heading），沿用「高级设置」的既有写法（`button` 内不能放 heading），以换取与它逐字一致的 DOM 与零 CSS 布局风险。新增 `tests/section.test.ts` 12 项 React-free 用例固定两个分组「组内是否有未填好的数字」的判定（含按模型覆盖行分支）；检查集与保存守卫走的**同一份 staged plan** 对齐——连 UI 上填不错的 `filterModelsByPlan` 开关也纳入，免得呈现判定比保存条件窄。两组变异对照（删 rows 分支、删 `filterModelsByPlan`）各自精准命中对应用例、恢复后 12／12 全通过，证明用例有判别力。
+
+- **设置页「自定义上下文长度」与「单轮输出上限」的界面说明精简约一半。**两段 hint 只留「填什么 → 会怎样」：中文 124 → 61 字、240 → 98 字，英文 325 → 228、686 → 223 字符；删掉的是机制叙述（为何影响压缩与选择器标注、`0` 的动机、二进制换算示例、宿主限定预算的辅助调用），这些在 README 的对应段落里原样保留（**用户选定：README 保持不动**）。**两个信息点不可删**——「影响上下文计量与自动压缩」与「`0` 只在 CLI 与 OpenAI 传输生效，Claude 的 Messages 端点必填该字段」；后者由 `tests/settings.test.ts` 的既有文案护栏守着：首轮精简把它删掉后护栏立即失败（`zh hint names the route that requires the field`），遂以精简措辞加回，同组英文断言随之从 `/sends no such field/` 改为 `/omits the field/`（断言语义不变：文案必须说明 `0` 不发送该字段）。顺带去掉 hint 里的反引号——它经 `.cc-rowDesc` 纯文本渲染，反引号会在界面上原样显示。
+
+## [0.14.1] - 2026-10-18
+
+### Changed
+
+- **DSH 兼容矩阵反转为两引擎向下兼容 `0.2.0-rc.2 || 0.2.1-rc.2`**，撤销 `[0.14.0]` 的单一引擎收敛。官方 npm `latest` 至今仍指向 `0.2.0-rc.2`（2026-10-18 复核），`0.2.1-rc.2` 挂在 `next` 上，而宿主准入判定只读 `engines.dsh`——只声明 rc.2 会让走官方默认安装路径的用户被直接拒绝（插件行被预检禁用、作为 bundle 被静默跳过、`dsh plugin add` 在 pnpm 之前就拒绝，机制见[《决策记录》第八章第12条](docs/决策记录.md#八dsh-引擎兼容范围与验证边界)）。`engines.dsh`、`dsh.compatibility.dsh`、15 个 `@deepseek-ai/dsh-*` 对等依赖与 19 个开发依赖同批回到析取式，`dsh.compatibility.dshReleases` 回到**两条记录**；两条记录**都是 RC**，alpha（早期测试版）通道不保留——自 `0.2.1-alpha.5` 之后没有新的已验证版本。每个分支仍必须是裸版本号，`0.2.0-rc.1`／`0.2.1-rc.1`／`0.3.0-alpha.1` 等相邻未验证版本继续被拒。`react ^18.2.0` 不变；`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 由 rc.2 轮次的单分支 `~4.0.5`／`~3.18.5` 恢复为**按引擎配对的析取式** `~4.0.4 || ~4.0.5`／`~3.18.4 || ~3.18.5`——两代引擎的配对不同（`0.2.0-rc.2` 随 cordis `~4.0.4`／schemastery `~3.18.4` 发布，`0.2.1-rc.2` 随正式版 `4.0.5`／`3.18.5` 发布），单分支解析不到旧引擎的配对，只适用于单引擎矩阵。反转理由、判据与 PR #93 的评审结论见[《决策记录》第八章第14条](docs/决策记录.md#八dsh-引擎兼容范围与验证边界)。
+
+- **网页搜索的选择写入同时支持两种引擎形状。**rc.2 继续走官方易变写入面（`ctx.settings.update()`／`replace()`，写入 profile 的易变字段由 loader 原地提交，且不夺取他人显式选择、写后读回校验）；pre-rc.2 引擎（含 `0.2.0-rc.2`）既没有该易变引用也没有 `web` 的设置行，选择是实例自有字段 `searchProviderId`，改为直写该字段，沿用既有「记住被顶掉的后端、只归还自己拿走的」语义——该值只存在于内存，随实例结束失效，且看不到用户层的他人显式选择。形状按每次观察解析，一个构建同时服务两个引擎；`tests/web-search.test.ts` 新增旧形状用例。
+
+- **升级审计工具同步双引擎。**`.agents/skills/dsh-release-upgrade/` 的 `SKILL.md` 维护策略改为「官方默认安装版本（npm `latest`）必须可用 + 通道最新，不保留 alpha 通道」，与声明面口径一致；`scripts/collect.py` 的隐式 baseline 由「`package.json` 必须恰好一条 `dshReleases`」改为取其中 **semver 最大**者（升级审计总是从最新已验证引擎出发），并把实际选用值打到 stderr，`--baseline` 显式覆盖优先、空记录仍退出 2。技能单测 5/5 通过（新增 4 项：单条/两条取值、semver 排序、空记录报错、CLI 空清单退出 2）。
+
+- 文档同步：两份 README、[对接说明](docs/对接说明.md)、[引擎兼容](docs/agent-reference/engine-compatibility.md)、[账号与重试](docs/agent-reference/accounts-and-retry.md)、[模型成本与性能分析](docs/模型成本与性能分析.md)、[决策记录](docs/决策记录.md)与[提交历史](docs/提交历史.md)。**验证**（本机静态与合成依赖）：`npm run test:engine` 退出码 0，矩阵 **2/2**——关键行 `host compatibility preflight admits this plugin on dsh 0.2.0-rc.2` 与 `... on dsh 0.2.1-rc.2`，末行 `engine-load smoke passed on all 2 declared-compatible engines (0.2.0-rc.2, 0.2.1-rc.2)`；`npm run test:install` 退出码 0（pnpm `10.34.5`），输出 `isolated install passed with pnpm 10.34.5 (dsh 0.2.0-rc.2)` 与 `(dsh 0.2.1-rc.2)`。Cordis／Schemastery 改回析取式后**已重跑**，两次矩阵同为 **2/2**——一个引擎全绿不算通过，沿[《决策记录》第八章第2条](docs/决策记录.md#八dsh-引擎兼容范围与验证边界)。**未做**：真实浏览器渲染、真实账号登录、付费生成、跨平台与长期稳定性；真实引擎内的网络响应与凭据为合成依赖。**真实旧引擎（`0.2.0-rc.2`）上的端到端搜索选择写入未验证**——`test:engine` 只证明插件在该引擎上加载并通过宿主准入，不驱动 `webSearch` 开关，旧形状由单元级替身覆盖。
+
+### Fixed
+
+- 修掉 `[0.14.0]` 引入的「按官方默认方式安装 dsh 的用户装不上本插件」：`0.2.0-rc.2` 仍是 npm `latest`（官方默认安装路径会跑的版本），本版本重新声明它。
+
+- 补齐 `[0.14.0]` 漏改的两处引擎记录表述：[客户端与设置](docs/agent-reference/client-and-settings.md)与[仓库地图](docs/agent-reference/repository-map.md)此前写的 `dshReleases` 条数与当时的单引擎声明不一致，现按两条 RC 记录写明。
+
 ## [0.14.0] - 2026-10-18
 
 ### Added

package/README.md

@@ -37,17 +37,19 @@ See [Screenshots](#screenshots) below for what the UI looks like.
 
 ## Install
 
-This release supports **dsh 0.2.1-rc.2**. The compatibility matrix is now a
-single verified engine: the RC channel moved from `0.2.0-rc.2` to `0.2.1-rc.2`
-on 2026-10-17, and no alpha release is retained because none has been verified
-since `0.2.1-alpha.5`. The peer range and compatibility records name only that
-exact version, and `@deepseek-ai/cordis` / `@deepseek-ai/schemastery` are pinned
-to the stable releases paired with it (`~4.0.5` / `~3.18.5`). Note that
-**dsh 0.2.1-rc.2 reads `engines.dsh` alone** when it decides whether a plugin is
-compatible; the dsh peer ranges are consulted only when that field is absent, so
-a build that declares the wrong `engines.dsh` is refused outright. A profile on
-`0.2.0-rc.2`, `0.2.1-alpha.5` or any earlier release must upgrade its engine
-before installing this build:
+This release supports **dsh 0.2.0-rc.2 and 0.2.1-rc.2** — two verified engines, both on the RC
+(release-candidate) channel. `0.2.0-rc.2` is what npm `latest` still points at (re-checked
+2026-10-18), so it is the engine an official default install runs; `0.2.1-rc.2` ships on the `next`
+tag. The peer range and the compatibility records name both as exact versions, and no alpha release
+is retained: nothing has been verified since `0.2.1-alpha.5`. `@deepseek-ai/cordis` /
+`@deepseek-ai/schemastery` carry the paired disjunction `~4.0.4 || ~4.0.5` / `~3.18.4 || ~3.18.5`,
+because the two engines pair differently (`0.2.0-rc.2` needs cordis `~4.0.4` and schemastery
+`~3.18.4`, `0.2.1-rc.2` ships `4.0.5` / `3.18.5`) and one branch cannot resolve both. Note that
+**dsh 0.2.1-rc.2 reads
+`engines.dsh` alone** when it decides whether a plugin is compatible; the dsh peer ranges are
+consulted only when that field is absent, so a build that declares the wrong `engines.dsh` is refused
+outright there — while on `0.2.0-rc.2` the peer ranges are what decides. A profile on
+`0.2.1-alpha.5` or any earlier release must upgrade its engine before installing this build:
 
 ```sh
 dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@latest
@@ -74,14 +76,14 @@ dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@0.11.15
 
 The same applies to every profile you install into, including the terminal UI below.
 
-Fresh pnpm 10 marketplace generations are supported directly. Every Harness package is declared by the plugin as a Host peer, so the active dsh profile remains their owner; do not add a separate dependency for any of them. The `@deepseek-ai/dsh-*` packages all declare one exact version; `@deepseek-ai/cordis` and `@deepseek-ai/schemastery` carry the ranges `~4.0.5` and `~3.18.5` paired with that engine instead, because publishing an engine rewrites both to the version that shipped alongside it. Upstream removed the `@deepseek-ai/dsh-invariants` package in `0.2.1-alpha.1`, so the plugin no longer declares it.
+Fresh pnpm 10 marketplace generations are supported directly. Every Harness package is declared by the plugin as a Host peer, so the active dsh profile remains their owner; do not add a separate dependency for any of them. The `@deepseek-ai/dsh-*` packages all declare the same exact-version disjunction `0.2.0-rc.2 || 0.2.1-rc.2`; `@deepseek-ai/cordis` and `@deepseek-ai/schemastery` carry the paired disjunctions `~4.0.4 || ~4.0.5` and `~3.18.4 || ~3.18.5` instead, because publishing an engine rewrites both to the version that shipped alongside it and the two retained engines were published against different pairs. Upstream removed the `@deepseek-ai/dsh-invariants` package in `0.2.1-alpha.1`, so the plugin no longer declares it.
 
 ## Updating
 
 Update with the same tag you installed with:
 
 ```sh
-dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest     # dsh 0.2.1-rc.2
+dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest     # dsh 0.2.0-rc.2 / 0.2.1-rc.2
 dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@0.9.1      # older dsh (0.5.0 line, unmaintained)
 ```
 
@@ -160,7 +162,7 @@ cmd login                               # writes ~/.commandcode/auth.json
         cwd: !!js process.cwd()
 ```
 
-**Engine version.** The plugin is maintained against **one verified engine: dsh 0.2.1-rc.2**. Its `@deepseek-ai/dsh-*` peers use the exact version `0.2.1-rc.2`, while `@deepseek-ai/cordis` and `@deepseek-ai/schemastery` use the stable ranges paired with that engine release, `~4.0.5` and `~3.18.5` (both were prereleases in the alpha era and became stable with this batch). Compatibility records contain exactly this one engine. Each channel upgrade replaces its previous version after verification; it does not accumulate supported releases or admit unverified neighbours, and a channel with no newly verified release simply leaves the matrix. Both `npm run test:engine` and `npm run test:install` check the retained engine, and `test:engine` also calls that engine's own `evaluatePluginCompatibility` on the published manifest — from alpha.4 on, that verdict reads `engines.dsh` alone, so a wrong engine declaration fails there instead of only at install time. See [Install](#install) for older engines.
+**Engine version.** The plugin is maintained against **two verified engines: dsh `0.2.0-rc.2` and dsh `0.2.1-rc.2`**. Its `@deepseek-ai/dsh-*` peers use the exact-version disjunction `0.2.0-rc.2 || 0.2.1-rc.2`, while `@deepseek-ai/cordis` and `@deepseek-ai/schemastery` use the paired disjunctions `~4.0.4 || ~4.0.5` and `~3.18.4 || ~3.18.5` — one branch per engine, because `0.2.0-rc.2` was published against cordis `~4.0.4` / schemastery `~3.18.4` and `0.2.1-rc.2` against the stable `4.0.5` / `3.18.5`. Compatibility records contain exactly these two engines — both RC, with no alpha channel, because nothing has been verified since `0.2.1-alpha.5`. `0.2.0-rc.2` is retained deliberately even though it is the older of the two: it is still what npm `latest` resolves to, so a build that dropped it would be refused by the host's `engines.dsh` admission on every default install. Every declared branch must stay a bare version, so unverified neighbours (`0.2.0-rc.1`, `0.2.1-rc.1`, `0.3.0-alpha.1`) are still rejected. Both `npm run test:engine` and `npm run test:install` verify every declared engine in turn rather than one of them, and `test:engine` also calls that engine's own `evaluatePluginCompatibility` on the published manifest — from alpha.4 on, that verdict reads `engines.dsh` alone, so a wrong engine declaration fails there instead of only at install time. See [Install](#install) for older engines.
 
 ## Usage dashboard
 
@@ -208,7 +210,7 @@ llm-commandcode:
 
 ## Configure
 
-**Settings → Command Code** is organized as **Accounts** (keys, sign-in, live quota, pinning, dedicated models), **Models & context** (hide out-of-plan models, visible models, then the **Custom context length** field and the **Per-model overrides** rows right after the allowlist — global and per model, see below), **Privacy & security** (zero data retention, off by default, see below), **Integrations & display** (serve web search with Command Code, show the quota card in the sidebar, off by default), and a collapsed **Advanced** section (API base URL, request/stream timeouts, transport retries, cache-aware image offload). The working directory is no longer on the page; `workingDir` in config still works.
+**Settings → Command Code** is organized as **Accounts** (keys, sign-in, live quota, pinning, dedicated models), a collapsed **Models & context** group (click its heading to unfold: hide out-of-plan models, visible models, then the **Custom context length** field and the **Per-model overrides** rows right after the allowlist — global and per model, see below), **Privacy & security** (zero data retention, off by default, see below), **Integrations & display** (serve web search with Command Code, show the quota card in the sidebar, off by default), and a collapsed **Advanced** section (API base URL, request/stream timeouts, transport retries, cache-aware image offload). Both foldable groups toggle from their whole heading row, and neither remembers its expanded state across visits. The working directory is no longer on the page; `workingDir` in config still works.
 
 The same options live in `$DSH_HOME/settings.yaml` (changes apply immediately, no restart):
 
@@ -258,10 +260,10 @@ On the CLI transport (`/alpha/generate`), a new image can make Command Code's re
 
 When your deployment's dsh shell mounts the web capability (`@deepseek-ai/dsh-web` + `@deepseek-ai/dsh-tool-web`), the model's `web_search` tool is served by this plugin's `commandcode` search provider — it calls the Command Code Provider API's `/alpha/web-search` endpoint with the **same API key and base URL** as chat. You do not configure a separate search key, endpoint, or model.
 
-**On by default.** The plugin's **Settings → Command Code** page has a *"Serve dsh web search with Command Code"* toggle (`webSearch`, default on). When on, the plugin selects `commandcode` as the active search backend automatically; turn it off to hand the selection back to whichever backend was there before (a sibling search plugin such as modsearch keeps working — it is never forced back to dsh's shipped DeepSeek search). The toggle takes effect on the next search — no restart needed. On dsh 0.2.1-rc.2 this uses the official volatile-settings write path, so the change is committed into the running `web` entry in place rather than by remounting it. **When the official Web search settings already pin another backend, this toggle has no effect** — that explicit choice wins.
+**On by default.** The plugin's **Settings → Command Code** page has a *"Serve dsh web search with Command Code"* toggle (`webSearch`, default on). When on, the plugin selects `commandcode` as the active search backend automatically; turn it off to hand the selection back to whichever backend was there before (a sibling search plugin such as modsearch keeps working — it is never forced back to dsh's shipped DeepSeek search). The toggle takes effect on the next search — no restart needed. On dsh 0.2.1-rc.2 this uses the official volatile-settings write path, so the change is committed into the running `web` entry in place rather than by remounting it; on 0.2.0-rc.2 the engine instead keeps its selection in an instance field with no settings surface, which the plugin assigns directly (memory-only, gone with the instance). **When the official Web search settings already pin another backend, this toggle has no effect** — that explicit choice wins; on 0.2.0-rc.2 there is no such settings row, so no pin can be seen and the toggle always takes over.
 
 - The provider registers as `commandcode` on `ctx.web` only when the web service is present; without it this stays a chat-only plugin.
-- The toggle selects `commandcode` through the engine's volatile-settings write path — the same `web.searchProvider` field the official **Web search** card's *Use the new Web Search API* switch writes (that switch also writes `fetchProvider`). The plugin **defers to an explicit choice already present in the user layer**: when the Web search settings pin another backend, it keeps `commandcode` registered but unselected and reports that state (the toggle's hint, plus a host log line) instead of overwriting it; it takes over only while nothing else pins the field, remembers the backend it displaced, and restores it when the toggle goes off or the plugin unloads. If you would rather pin the choice durably, set `searchProvider: commandcode` (or `$DSH_WEB_SEARCH_PROVIDER=commandcode`); that keeps working even if the runtime selection cannot be committed.
+- The toggle selects `commandcode` through the engine's volatile-settings write path on `0.2.1-rc.2` — the same `web.searchProvider` field the official **Web search** card's *Use the new Web Search API* switch writes (that switch also writes `fetchProvider`). The plugin **defers to an explicit choice already present in the user layer**: when the Web search settings pin another backend, it keeps `commandcode` registered but unselected and reports that state (the toggle's hint, plus a host log line) instead of overwriting it; it takes over only while nothing else pins the field, remembers the backend it displaced, and restores it when the toggle goes off or the plugin unloads. On `0.2.0-rc.2` (and the alphas) the engine has neither that reference nor a `web` settings row, so the selection is its own `searchProviderId` field: the plugin assigns it in memory under the same "remember what we displaced, hand back only what we took" rule, and no other writer's pin is observable there. If you would rather pin the choice durably, set `searchProvider: commandcode` (or `$DSH_WEB_SEARCH_PROVIDER=commandcode`); that keeps working even if the runtime selection cannot be committed.
 - `numResults` from the dsh tool is clamped to the Command Code range (1–10, default 5); results map to the dsh `WebSearchSource` shape (`url`/`title`/`snippet`).
 
 > This reuses the Command Code Provider API directly (like the official CLI's built-in `web_search`), so it is distinct from a DeepSeek-native search backend.

package/README.zh-CN.md

@@ -35,7 +35,7 @@
 
 ## 安装
 
-本版本**只支持 dsh 0.2.1-rc.2**。兼容矩阵已收敛为单一已验证引擎：RC（候选发布版）通道于 2026-10-17 由 `0.2.0-rc.2` 替换为 `0.2.1-rc.2`，alpha（早期测试版）通道自 `0.2.1-alpha.5` 之后没有新的已验证版本，本轮退出支持矩阵。peer（对等依赖）范围和兼容记录只列这一个精确版本；`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 固定为该引擎配对的正式版范围 `~4.0.5`／`~3.18.5`。注意 **dsh 0.2.1-rc.2 判定插件兼容性时只读 `engines.dsh`**，dsh 对等依赖范围仅在该字段缺失时才被参考，因此 `engines.dsh` 声明错误会被直接拒绝。使用 `0.2.0-rc.2`、`0.2.1-alpha.5` 或更早版本的配置需先升级引擎，再安装本构建：
+本版本支持 **dsh 0.2.0-rc.2 与 0.2.1-rc.2 两个已验证引擎**，两者都在 RC（候选发布版）通道上。`0.2.0-rc.2` 至今仍是 npm `latest` 指向的版本（2026-10-18 复核），也就是官方默认安装会跑的那一版；`0.2.1-rc.2` 挂在 `next` 标签上。peer（对等依赖）范围与兼容记录把两者都写成精确版本；alpha（早期测试版）通道不保留——自 `0.2.1-alpha.5` 之后没有新的已验证版本。`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 写成按引擎配对的析取式 `~4.0.4 || ~4.0.5`／`~3.18.4 || ~3.18.5`——两代引擎的配对不同（`0.2.0-rc.2` 需要 cordis `~4.0.4` 与 schemastery `~3.18.4`，`0.2.1-rc.2` 随 `4.0.5`／`3.18.5` 发布），单分支覆盖不了两代。注意 **dsh 0.2.1-rc.2 判定插件兼容性时只读 `engines.dsh`**，dsh 对等依赖范围仅在该字段缺失时才被参考，因此 `engines.dsh` 声明错误会被它直接拒绝；而在 `0.2.0-rc.2` 上起作用的正是对等依赖范围。使用 `0.2.1-alpha.5` 或更早版本的配置需先升级引擎，再安装本构建：
 
 ```sh
 dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@latest
@@ -57,14 +57,14 @@ dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@0.11.15
 
 这一点对每个 profile 都成立，包括下面的终端界面。
 
-插件可直接在 pnpm 10 的全新插件市场 generation 中安装。所有 Harness 包都由插件声明为 Host peer，由当前 dsh profile 统一管理，不要另行添加 dependency。其中 `@deepseek-ai/dsh-*` 全部声明同一个精确版本；`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 则写成该引擎配对的范围 `~4.0.5` 与 `~3.18.5`——上游每次发引擎都会把这两个包重写成随引擎发布的版本。上游曾在 `0.2.1-alpha.1` 删除 `@deepseek-ai/dsh-invariants` 这个包，因此插件不再声明它。
+插件可直接在 pnpm 10 的全新插件市场 generation 中安装。所有 Harness 包都由插件声明为 Host peer，由当前 dsh profile 统一管理，不要另行添加 dependency。其中 `@deepseek-ai/dsh-*` 全部声明同一个精确版本析取式 `0.2.0-rc.2 || 0.2.1-rc.2`；`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 则写成按引擎配对的析取式 `~4.0.4 || ~4.0.5` 与 `~3.18.4 || ~3.18.5`——上游每次发引擎都会把这两个包重写成随引擎发布的版本，而两个保留引擎发布时的配对不同，单分支覆盖不了两代。上游曾在 `0.2.1-alpha.1` 删除 `@deepseek-ai/dsh-invariants` 这个包，因此插件不再声明它。
 
 ## 更新
 
 用与安装时相同的 tag 更新：
 
 ```sh
-dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest     # dsh 0.2.1-rc.2
+dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest     # dsh 0.2.0-rc.2 / 0.2.1-rc.2
 dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@0.9.1      # 更早的 dsh（0.5.0 线，不再维护）
 ```
 
@@ -143,7 +143,7 @@ cmd login                               # 写入 ~/.commandcode/auth.json
         cwd: !!js process.cwd()
 ```
 
-**引擎版本要求。** 插件只维护**一个已验证引擎：dsh 0.2.1-rc.2**。`@deepseek-ai/dsh-*` 的 peer（对等依赖）为精确版本 `0.2.1-rc.2`；`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 使用该引擎配对的正式版范围 `~4.0.5` 与 `~3.18.5`（两者在 alpha 时期是预发布，随本批次转为正式版）。兼容记录恰好包含这一个版本，同通道升级验证后替换旧版，不累加已支持版本、不放行未验证的邻近版本；某条通道没有新的已验证版本时，直接退出矩阵而不保留。`npm run test:engine` 与 `npm run test:install` 对保留的引擎执行验证，前者还会用该引擎自己的 `evaluatePluginCompatibility` 对发布清单求值——自 alpha.4 起该判定只读 `engines.dsh`，因此引擎声明写错会在这一步失败，而不是拖到安装时才暴露。旧引擎安装说明见[安装](#安装)。
+**引擎版本要求。** 插件维护**两个已验证引擎：dsh `0.2.0-rc.2` 与 dsh `0.2.1-rc.2`**。`@deepseek-ai/dsh-*` 的 peer（对等依赖）为精确版本析取式 `0.2.0-rc.2 || 0.2.1-rc.2`；`@deepseek-ai/cordis` 与 `@deepseek-ai/schemastery` 使用按引擎配对的析取式 `~4.0.4 || ~4.0.5` 与 `~3.18.4 || ~3.18.5`——每个分支对应一代引擎的配对：`0.2.0-rc.2` 随 cordis `~4.0.4`／schemastery `~3.18.4` 发布，`0.2.1-rc.2` 随正式版 `4.0.5`／`3.18.5` 发布。兼容记录恰好包含这两个引擎——**两条都是 RC，不含 alpha 通道**，因为自 `0.2.1-alpha.5` 之后没有新的已验证版本。`0.2.0-rc.2` 虽然更旧，但被有意保留：它仍是 npm `latest` 解析到的版本，去掉它会让跑默认安装的宿主用 `engines.dsh` 准入直接拒绝本插件。每个分支仍必须是裸版本号，`0.2.0-rc.1`、`0.2.1-rc.1`、`0.3.0-alpha.1` 等未验证的邻近版本继续被拒。`npm run test:engine` 与 `npm run test:install` 对每个已声明引擎各跑一遍而不是只跑其中一个，前者还会用该引擎自己的 `evaluatePluginCompatibility` 对发布清单求值——自 alpha.4 起该判定只读 `engines.dsh`，因此引擎声明写错会在这一步失败，而不是拖到安装时才暴露。旧引擎安装说明见[安装](#安装)。
 
 ## 用量面板
 
@@ -191,7 +191,7 @@ llm-commandcode:
 
 ## 配置
 
-**设置 → Command Code** 分为：**账户**（密钥、网页登录、实时额度、固定账户、专用模型）、**模型与上下文**（隐藏套餐外模型、可见模型，以及紧随白名单之后的**自定义上下文长度**字段与**按模型覆盖**列表，全局与按模型，见下）、**隐私与安全**（零数据保留 ZDR，默认关闭，见下）、**集成与显示**（用 Command Code 承载联网搜索、在侧边栏显示额度卡片，默认关闭），以及默认折叠的**高级设置**（API 地址、请求/流超时、传输重试次数、历史图片缓存优化）。工作目录已不在页面上显示，配置中的 `workingDir` 仍然有效。
+**设置 → Command Code** 分为：**账户**（密钥、网页登录、实时额度、固定账户、专用模型）、**模型与上下文**（默认折叠，点标题展开：隐藏套餐外模型、可见模型，以及紧随白名单之后的**自定义上下文长度**字段与**按模型覆盖**列表，全局与按模型，见下）、**隐私与安全**（零数据保留 ZDR，默认关闭，见下）、**集成与显示**（用 Command Code 承载联网搜索、在侧边栏显示额度卡片，默认关闭），以及默认折叠的**高级设置**（API 地址、请求/流超时、传输重试次数、历史图片缓存优化）。两个可折叠分组都点标题整行展开/收起，展开状态不跨刷新记忆。工作目录已不在页面上显示，配置中的 `workingDir` 仍然有效。
 
 同一组选项也位于 `$DSH_HOME/settings.yaml`（修改即刻生效，无需重启）：
 
@@ -241,10 +241,10 @@ llm-commandcode:
 
 当你的 dsh 部署加载了 web 能力（`@deepseek-ai/dsh-web` + `@deepseek-ai/dsh-tool-web`）时，模型所用的 `web_search` 工具会由本插件的 `commandcode` 搜索 provider 承载——它用**与聊天相同的 API key 与 base URL** 调用 Command Code Provider API 的 `/alpha/web-search` 端点。你无需另外配置搜索 key、端点或模型。
 
-**默认开启。** 插件的 **设置 → Command Code** 页里有一个「用 Command Code 承载联网搜索」开关（`webSearch`，默认开）。开启时插件会自动把 `commandcode` 选为当前搜索后端；关闭则把选择权交还给之前的后端（比如 modsearch 等其他搜索插件可继续工作——不会被强制回退到 dsh 自带的 DeepSeek 搜索）。该开关在**下一次搜索时生效**，无需重启；在 dsh 0.2.1-rc.2 上它走官方易变设置写入路径，改动原地提交进运行中的 `web` 条目，而不是重挂载该条目。**若官方「网页搜索」设置里已显式选择其他后端，本开关不生效**——那个显式选择优先。
+**默认开启。** 插件的 **设置 → Command Code** 页里有一个「用 Command Code 承载联网搜索」开关（`webSearch`，默认开）。开启时插件会自动把 `commandcode` 选为当前搜索后端；关闭则把选择权交还给之前的后端（比如 modsearch 等其他搜索插件可继续工作——不会被强制回退到 dsh 自带的 DeepSeek 搜索）。该开关在**下一次搜索时生效**，无需重启；在 dsh 0.2.1-rc.2 上它走官方易变设置写入路径，改动原地提交进运行中的 `web` 条目，而不是重挂载该条目；在 0.2.0-rc.2 上引擎把选择放在一个没有设置面的实例字段里，插件直接赋值（只存在于内存，随实例结束失效）。**若官方「网页搜索」设置里已显式选择其他后端，本开关不生效**——那个显式选择优先；0.2.0-rc.2 上没有这一设置行，看不到他人的 pin，因此开关总是接管。
 
 - 该 provider 仅在 web 服务存在时以 `commandcode` 注册进 `ctx.web`；没有它，本插件仍是纯聊天插件。
-- 开关通过引擎的易变设置写入路径选中 `commandcode`（写的就是官方「Web 搜索」卡片里「启用新版 Web 搜索 API」开关所用的同一个 `web.searchProvider` 字段，该开关还会一并写 `fetchProvider`）。插件**尊重用户层已有的显式选择**：当「网页搜索」设置已 pin 其他后端时，它让 `commandcode` 保持已注册但未被选中，并把这一状态报出来（开关的提示文案，外加一行宿主日志），而不是覆盖对方；只有在没人 pin 该字段时才接管，并记住被顶掉的后端，在关闭开关或卸载插件时恢复。若你想更稳妥地固定，可设置 `searchProvider: commandcode`（或 `$DSH_WEB_SEARCH_PROVIDER=commandcode`）；即使运行时选择无法提交，该配置仍然生效。
+- 开关在 `0.2.1-rc.2` 上通过引擎的易变设置写入路径选中 `commandcode`（写的就是官方「Web 搜索」卡片里「启用新版 Web 搜索 API」开关所用的同一个 `web.searchProvider` 字段，该开关还会一并写 `fetchProvider`）。插件**尊重用户层已有的显式选择**：当「网页搜索」设置已 pin 其他后端时，它让 `commandcode` 保持已注册但未被选中，并把这一状态报出来（开关的提示文案，外加一行宿主日志），而不是覆盖对方；只有在没人 pin 该字段时才接管，并记住被顶掉的后端，在关闭开关或卸载插件时恢复。`0.2.0-rc.2`（以及各 alpha）既没有该易变引用也没有 `web` 的设置行，选择是引擎自己的 `searchProviderId` 实例字段：插件按同一套「记住被顶掉的后端、只归还自己拿走的」规则直写内存，也看不到其他写者的 pin。若你想更稳妥地固定，可设置 `searchProvider: commandcode`（或 `$DSH_WEB_SEARCH_PROVIDER=commandcode`）；即使运行时选择无法提交，该配置仍然生效。
 - dsh 工具的 `numResults` 会被收敛到 Command Code 的取值范围（1–10，默认 5）；结果映射为 dsh 的 `WebSearchSource` 结构（`url`/`title`/`snippet`）。
 
 > 这里直接使用 Command Code Provider API（与官方 CLI 内置的 `web_search` 相同），因此与 DeepSeek 原生搜索后端不同。