v1.4.0

模型表随远端目录刷新，并补上 Windows 原生的调用助手

这一版把模型目录重新实测了一遍：新增 Gemma-4-31B-IT，下线已不可用的 DeepSeek-V4-Flash-Vision-Exp，并纠正了两个模型档位表的反向变化——一个扩成七档、一个收缩为三档。同时补了 PowerShell 7 版的 API 调用助手，pnpm probe 在 Windows 上不再需要 Git Bash；顺带把整仓的行尾规则固化进 .gitattributes。

功能变更（DSH 插件口径）

结论：有功能变更——provider 定义与插件行为都有用户可见变化，安装方式与兼容范围未变。

维度	与 v1.3.0 相比
provider 定义（模型、上下文、思考档位）	有变更：新增 Gemma-4-31B-IT（262,144 上下文、收图、七档全接受）；下线 DeepSeek-V4-Flash-Vision-Exp（服务端已返回 400 Requested model ... not supported）；GLM-5.3-Flash 由仅 low/medium/high 扩为七档全接受，重新具备关闭档位；MiniCPM-V-4.7-35B-A3B 反向收缩为仅 low/medium/high。对话模型仍为 10 个
插件行为（安装、启动看护、设置页表现）	有变更：scripts/ 新增 PowerShell 7 版助手 radeon-api.ps1，pnpm probe 在 Windows 上自动改用它；新增 .gitattributes 固化行尾（*.ps1 为 CRLF、其余文本 LF）。安装方式、启动看护与设置页表现未变
安装方式与 DSH 兼容范围	未变：>=0.2.0-rc.1（无上界，三处声明仍逐字一致）；包内新增 scripts/radeon-api.ps1，打包文件 19 → 20

变更

• GLM-5.3-Flash 扩为七档全接受：none/minimal/low/medium/high/xhigh/max 现在全部返回 200，因此重新有了 off（reasoning_effort: "none"）这个关闭档位。对原先被拒的四档各复测两轮，排除限流与上游故障造成的假阴性。
• MiniCPM-V-4.7-35B-A3B 反向收缩：none/minimal/xhigh/max 现在都是 422，只剩 low/medium/high，与 MiniCPM-V-4.7-1B 完全一致。两个 MiniCPM 模型从此同组，原先「同系但档位不同」那条提醒的依据换了对象，文档已按现状改写。
• developer 角色拒收数由 6 个降为 5 个：GLM-5.3-Flash 由拒绝转为接受，其余不变——MiniCPM5-2B、MiniCPM-V-4.7-1B、MiniCPM-V-4.7-35B-A3B 报 422，Qwen 系两个报 400。compat.supportsDeveloperRole: false 仍必须保留。

新增

• 收录 Gemma-4-31B-IT：262,144 上下文、支持图片与 tools，七档全部 200，思考内容经 reasoning 字段返回、reasoning_tokens 正常计数。
• scripts/radeon-api.ps1：与 radeon-api.sh 同一份输出契约的 PowerShell 7 实现——响应体走标准输出、状态码走标准错误的 ---HTTP <code>--- 标记、非 2xx 也照常返回（退出码 0）、RAW=1 逐块输出 SSE。密钥来源、RADEON_KEY_REF/RADEON_BASE/DSH_HOME、默认端点与 bash 版完全一致。实现用 HttpClient 而非 Invoke-WebRequest：后者会把响应整体缓冲，拿不到流式分片，也不能把非 2xx 当正常结果读回来。
• test/ps1-parity.test.mjs：48 项对等性测试。静态层断言两个脚本的环境变量、默认端点、输出标记与用法一致，并钉住 .gitattributes 的行尾规则与两个脚本的实际行尾；行为层在 127.0.0.1 起桩服务把两个脚本各跑一遍，逐字比对 stdout 与 stderr。

修复

• 下线 DeepSeek-V4-Flash-Vision-Exp：目录接口里已没有它，直接请求返回 400 Requested model DeepSeek-V4-Flash-Vision-Exp not supported。留在表里只会让选中它的用户拿到硬失败。
• test/merge.test.mjs 不再写死 macOS 应用包路径：src/yaml.js 与 scripts/validate-config.mjs 都支持 DSH_MODULES，唯独这个测试把 /Applications/DSH Desktop.app/… 硬编码进动态 import，于是非 macOS 机器上无论怎么设 DSH_MODULES 都不生效，pnpm test 在这一步直接 ERR_MODULE_NOT_FOUND、后面六个测试一个都跑不到。改成同一套候选顺序：DSH_MODULES 优先，应用包路径兜底，都不行时给一句可操作的错误。

文档

• README 由 585 行压到 179 行，安装方式收敛为「用 dsh plugin 从 npm 装」一条——原文把安装方式、设计理由与实测记录混在一处，「怎么装」有三个答案。设计理由归 AGENTS.md，实测记录归个人记忆库。
• README 模型表、图片输入清单、采集日期（→ 2026-11-09）、已知限制里的 developer 角色计数（6 → 5）全部同步。
• AGENTS.md 补「两个助手脚本遵守同一份输出契约，改一个必须同步改另一个」与行尾规则两项约束；把已过时的档位示例改写成现状。
• docs/market-submission.md 检查项数 123 → 171、打包文件数 19 → 20。

安装与升级

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@latest

npm：@zhz8888/dsh-radeon-cloud-patcher@1.4.0

升级后重启 DSH 即生效，不需要其它动作。这次的变化全在 provider 定义与仓库脚本里，插件运行时行为没有改动。

测试

• pnpm test：189 项全通过（manifest 18 / plugin-meta 11 / merge 15 / patch-text 17 / ownership 23 / apply-guard 14 / patch-sync 11 / client-patch 14 / ps1-parity 48 / verify-reasoning）
• pnpm validate：通过结构校验，并通过 llm-pi-ai 的真实 schema 校验（10 个模型）
• 两版助手真端点对拍：以无效密钥请求 GET /models，bash 版与 pwsh 版的 stdout、stderr 逐字节相同（{"detail":"Invalid bearer token"} / ---HTTP 401---）
• 档位实测：Gemma-4-31B-IT、GLM-5.3-Flash 各两轮七档，MiniCPM-V-4.7-35B-A3B 七档单轮复测；Qwen3.8-27B 传 high 仍返回 400，与既有档位表一致
• 请求构造复核：system 角色、tools + tool_choice、response_format: json_object、temperature + top_p、stream 在 10 个模型上逐一试过，除 MiniCPM-V-4.7-1B 的 tools 遇上游 502 未能定论外均返回 200

发行侧

• 已发布产物与仓库逐字节一致：tarball 20 个文件、39,447 字节、unpacked 111,872 字节，
  sha256 cd05bebc0fc2d7c0c9c1bdd5e8b8d52deafebf50de55f914d70db42c60b424fa
• npm 记录的 gitHead 为 c9ccd49，与 tag v1.4.0 指向的提交相同
• 从 npm 下载的 tarball 解包后与仓库 20 个文件逐一比对，无差异

Full Changelog：v1.3.0...v1.4.0

v1.3.0

模型目录刷新到 10 个，插件在「插件」页显示自己的名字

这一版补齐了远端目录新增的两个模型，并让插件在插件列表里显示 Radeon Cloud，而不是 @zhz8888/dsh-radeon-cloud-patcher。同时修掉了档位实测工具的一处缺陷——它会把「没测到」写成「档位不被接受」，且全程没有任何报错。

功能变更（DSH 插件口径）

结论：有功能变更——provider 定义与插件行为都有用户可见变化，安装方式与兼容范围未变。

维度	与 v1.2.1 相比
provider 定义（模型、上下文、思考档位）	有变更：对话模型 8 → 10 个，新增 MiniCPM-V-4.7-35B-A3B 与 MiniCPM-V-4.7-1B（均 262,144 上下文、支持图片）；原 8 个模型的上下文、模态与档位逐项复测后未变
插件行为（安装、启动看护、设置页表现）	有变更：「插件」页显示名称改由包内 locale/ 提供（英文 Radeon Cloud／中文「Radeon Cloud 提供方」）；安装方式、启动看护与模型设置页行为未变
安装方式与 DSH 兼容范围	未变：>=0.2.0-rc.1（无上界）；包内新增 locale/ 两个文件

新增

• 收录 MiniCPM-V-4.7-35B-A3B 与 MiniCPM-V-4.7-1B，对话模型由 8 个增至 10 个。档位只能实测（目录接口不返回该信息）：
  • MiniCPM-V-4.7-35B-A3B 七档全接受，none 可关闭思考；
  • MiniCPM-V-4.7-1B 只接受 low/medium/high，不接受 none，因此不提供关闭档位；
  • 两者同属 MiniCPM 系却档位不同，实测确认都返回分离的思考内容，按推理模型声明。MiniCPM5-2B 复测 reasoning 仍恒为空、reasoning_tokens 为 0，维持 reasoningEfforts: false。
• 「插件」页显示名称改由包内 locale/en.json 与 locale/zh.json 提供，走 DSH 自带的读取机制（readPluginMeta → meta.title）。此前读不到元信息时会静默回落成完整 npm 包名。新增 test/plugin-meta.test.mjs 钉住三条硬要求：locale/en.json 必须存在（只在 en 能解析时才会去读同目录的其它语言文件）、exports 必须有 ./locale/*.json 模式、files 必须包含 locale——三者缺一都只在界面上表现为「名字不好看」。

修复

• 档位实测不再把非结论写成结论（scripts/probe-efforts.mjs）：429（限流）冷却 65 秒、5xx（上游偶发故障）等 5 秒后各重测最多两次。本轮的实测依据是：MiniCPM-V-4.7-35B-A3B 的 low/medium/high/xhigh 四个组合返回 500 并被记为不可用，手工复测后确认四个档位全部可用——差一点就从选择器里凭空删掉四个档位，而且不会有任何报错。
• 请求间隔由 3100 毫秒放宽到 4500 毫秒：网关限流为每分钟 20 次（响应头 x-ratelimit-limit-user-rpm），而 3.1 秒的节流判据会让第 21 次请求落进第 1 次所在的滚动窗口，实测必踩 429。另新增 --interval 便于按需调整。
• 更正 developer 角色的实测结论：拒绝数由「8 个中 5 个」更正为「10 个中 6 个」，且报错文本分两种——GLM-5.3-Flash、MiniCPM5-2B、MiniCPM-V-4.7-1B 报 422 unknown role: developer，Qwen 系两个与 MiniCPM-V-4.7-35B-A3B 报 400 Unexpected message role.。

文档

• README 同步模型表、图片输入清单、采集日期与 developer 角色说明。
• AGENTS.md 补两条实测结论（429/5xx 不是档位结论；同一厂商、名字相近的模型档位不可互推）与插件页显示名称的三条硬要求。
• docs/market-submission.md 同步检查项数（112 → 123）与打包文件数（17 → 19）。
• 两条更早已进入 main 的文档提交一并纳入本版：刷新发布文档的版本锚点、把 Release 说明的栏目结构固化进「发版」一节。

安装与升级

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@latest

npm：@zhz8888/dsh-radeon-cloud-patcher@1.3.0

升级不需要额外动作：定义由插件层声明，装上新版本重启即生效。插件页那一行的名称同样要等装到 1.3.0 之后才会变化——它来自包内的 locale/，旧包里没有这两个文件。

测试

• pnpm test：8 组 123 项全通过
• pnpm validate：通过结构校验与 llm-pi-ai 真实 schema 校验（10 个模型，其中 9 个声明了思考档位）
• pnpm test:meta：11 项通过（并已按 6 种变异逐一确认会红灯）
• pnpm test:manifest：18 项通过（三处 DSH 版本声明一致、files 白名单覆盖齐全）
• 全量档位实测覆盖 10 个模型 × 7 个档位共 70 个组合；两个新模型另外做过真实 API 调用，核对过「档位被接受」与「返回分离思考内容」两件事

发行侧

• 已发布产物与仓库逐字节一致：tarball 19 个文件、41.9 kB、unpacked 120.9 kB，
  sha256 f17943b6df9cfcdbe531c736991f69a01308fd1b385e4486f7ff6d84bb37c2f6
• npm 记录的 gitHead 为 a4777f6，与 tag v1.3.0 指向的提交相同
• 从 npm 拉取安装后实测：locale/en.json、locale/zh.json 可经 exports 解析，
  插件页标题表为 {"en":"Radeon Cloud","zh":"Radeon Cloud 提供方"}，未回落成包名

Full Changelog：v1.2.1...v1.3.0

v1.2.1

文档与元数据修正：仓库不再充当经验数据库

这一版没有任何功能变更，改的全是「说给人听的部分」——而且是照着代码与 DSH 源码逐条核对之后改的。

功能变更（DSH 插件口径）

结论：无功能变更——provider 定义、插件行为与安装方式都与 v1.2.0 一致，改的是文档与 package.json 的元数据。

维度	与 v1.2.0 相比
provider 定义（模型、上下文、思考档位）	未变：8 个模型、上下文长度与档位表逐字相同
插件行为	未变：定义交付、启动看护与客户端补丁均未改动（src/ 仅注释修正）
安装方式与 DSH 兼容范围	未变：>=0.2.0-rc.1（无上界）

为什么发这一版

仓库里积了 5 份过程与决策文档（可行性评估、实施计划、真机实测记录、参考实现分析、使用方式差异评估，合计 1821 行）。它们记录的是「当时为什么这么判断」，属于决策与排错的留档；这类内容会随代码演进而失效，却每改一次代码就多一份要同步的叙述，读者也分不清哪句描述的是现状、哪句是当时。本版把它们移出仓库，只保留「照做就能用」的三份：README.md、AGENTS.md、docs/market-submission.md。

同时做了一次文档审计：把三份文档里可核对的声明逐条拉出来对代码与本机 DSH 安装（模型表用脚本与 provider/radeon-cloud.yml 逐行比对；界面文案、DOM 类名、schema 默认值、CLI 开关都在 @deepseek-ai/* 里查到出处），修正了六处与实际不符的描述：

• Qwen 系的思考档位：定义里 Qwen 有 off: none（none 正是它关闭思考的方式），而 README 与 AGENTS 写成「GLM 与 Qwen 系不支持 none」，还与 README 自己的档位表自相矛盾
• 归属结局的数量：src/ownership.js 是四种归属结局外加哨兵 dynamic（config 是 !!js 表达式、或本次运行读不到 profile 目录时跳过判定，只告警），README 的判定表漏了这一种
• 客户端补丁的 CSS：文档里少了 !important，与 client/client.js 不一致
• 发布产物的成分：文档说 tarball 里「只有 JSON / YAML / JS」，实际还有 radeon-api.sh、README.md 与 LICENSE
• 安装后为什么要重启：原文把机制说成「热挂载只支持纯 insert 行」并引用了一句并不存在的界面文案，已改为只陈述可验证的行为——插件管理器对这类变更给出 restart-required，重启后生效
• package.json 的 description：还写着「把 provider 定义按键合并进 profile」，那是 1.2.0 之前的行为，而 npm 页面与插件市场展示的正是这句话

发行侧

• 历史版本 1.1.0 与 1.1.1 已补发到 npm（此前 registry 上只有 1.2.0），两者与各自的 git tag 逐文件一致
• 本版已核对：已发布产物与仓库逐字节一致（tarball shasum dfaac767…，17 个文件、unpacked 114.6 kB）
• pnpm test、pnpm validate、pnpm test:manifest 均通过

安装与升级

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@latest

npm：@zhz8888/dsh-radeon-cloud-patcher@1.2.1

Full Changelog：v1.2.0...v1.2.1

v1.2.0

设置页不再有「删除」按钮：provider 定义改由插件自带

这一版的主题是一件事：radeon-cloud 这个 id 现在由插件独占。

此前 provider 定义要按键合并进 profile 的 cordis.patch.yml，于是「设置 → 模型」里那一行永远带着「删除」按钮——点一下就把插件装出来的 provider 删了；卸载插件后 profile 里还会留一份副本。现在定义写在插件自带的补丁层里：那一行不再出现删除按钮，卸载插件就等于删除供应商，profile 里不留任何副本，插件也不再改写你的 profile。

功能变更（DSH 插件口径）

结论：有功能变更——provider 定义与 v1.1.1 完全一致，变的是定义的交付方式、设置页表现与兼容范围。

维度	与 v1.1.1 相比
provider 定义（模型、上下文、思考档位）	未变：8 个模型、上下文长度与档位表逐字相同
插件行为	有变：定义改由插件的补丁层声明，不再写入 profile；启动时判定 id 归属，冲突即失败；新增隐藏「自定义」标签的客户端补丁
安装方式	有变：装完不需要任何手工步骤（不必再跑 pnpm install:profile）
DSH 兼容范围	有变：改为只有下界 >=0.2.0-rc.1（@deepseek-ai/cordis 同理 >=4.0.2）

变更

定义归属

• provider 定义由插件的 cordis.plugin.patch.yml 声明；真源仍是 provider/radeon-cloud.yml，由 pnpm sync:patch 渲染进补丁，测试断言两者逐字符一致
• 安装后不需要任何手工步骤（不必再跑 pnpm install:profile），重启 DSH 即生效
• pnpm install:profile 保留为补救路径：profile 里已有 llm-pi-ai 的其它 provider 时，用它把定义按键合并进 profile——保留你写下的注释、缩进与同级键，合并前演练、写前断言、自动备份；已存在不一致的同 id 定义时拒绝覆盖，确认要覆盖再加 --force

启动看护

插件启动时静态读 profile / home / 命令行 overlay 三层，判定这个 id 现在由谁说了算：

情况	结果
没人碰过 llm-pi-ai 的 config	插件层的定义生效，正常启动
profile 里有一份与插件一致的声明	放行（通常是设置页保存时物化出的副本）
同 id 但定义不一致	启动失败：报「provider id 冲突」并指名第一处差异
profile 覆盖了 llm-pi-ai 却没有本 provider	启动失败：报「定义未生效」并给出合并命令

后两种是失败 + 原因，而不是静默接管、也不是静默消失——这是本项目的取舍：id 冲突要响亮。判定取「与本插件一致即放行」而不是「有声明就失败」，因为设置页每保存一次都会把有效配置物化进用户层（录入 API 密钥也会），严格判定会让插件在你正常操作之后起不来。

设置页的「自定义」标签被隐藏

DSH 对任何不在内置模型目录中的 provider 硬编码了这个标记，配置层面无从去掉。本版随包带了一个极小的客户端补丁（一条 CSS，零依赖、免构建），只隐藏本 provider 那一行。代价说明：它依赖 DSH 的 DOM 结构与类名片段，DSH 改版后可能静默失效——标签重新出现，功能不受影响。删除按钮不由这个补丁负责，它由定义落在补丁层这件事本身永久消除。

兼容范围改为只有下界

• @deepseek-ai/dsh-llm、dsh-llm-pi-ai、dsh-settings：>=0.2.0-rc.1
• @deepseek-ai/cordis：>=4.0.2

去掉上界后，DSH 或 cordis 升大版本都不必为放宽范围重发插件。代价是失去「未来版本被挡住」这层保护，改由上面的启动看护兜底；低于下界的运行时仍会被安装器直接拒绝。一个已知边界：0.2.1-alpha.1 这类新元组的预发布不被 npm/pnpm 的默认规则放行（DSH 闸门因为带 includePrerelease 会放行），届时用 --config.strict-peer-dependencies=false 安装，或给该元组补一条范围分支。

安装与升级

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@latest

npm：@zhz8888/dsh-radeon-cloud-patcher@1.2.0

升级后重启 DSH：定义属于补丁层，只在启动时组装。若你此前用 pnpm install:profile 把定义合并进过 profile，那份副本会盖住插件层的新定义——重跑一次该命令，或删掉那份副本，让插件独占管理。

测试

pnpm test 112 项检查全绿（清单不变式 18、合并语义 15、文本级编辑 17、所有权判定 23、启动看护 14、补丁一致性 11、客户端补丁 14）；pnpm validate 通过——后者用 llm-pi-ai 的真实 schema 校验 provider 定义，是发现「上游把字段改了名」的那道防线。

Full Changelog：v1.1.1...v1.2.0

v1.1.1

修正版：启动失败的排查指引指向了错误的字段

一处会影响排错方向的缺陷：provider 定义失效时，插件给出的排查指引让用户去核对 engines.dsh，而 DSH 的安装闸门只读 peerDependencies——照原文排查会转向一个不生效的字段。本版修正它并同步文档与实际行为，另新增 AGENTS.md 协作指引。

功能变更（DSH 插件口径）

结论：无功能变更——provider 定义与插件逻辑都未变，改的是失败时的诊断文案与文档。

维度	与 v1.1.0 相比
provider 定义（模型、上下文、思考档位）	未变：8 个模型、上下文长度与档位表逐字相同
插件行为	未变；仅诊断文案变化：排查指向从 engines.dsh 改为 peerDependencies 声明的兼容范围
安装方式与 DSH 兼容范围	未变

修复

• 启动失败时的排查指引指向了错误的字段：原文提示「核对 package.json 的 engines.dsh」，但闸门只读 peerDependencies，两者在 1.1.0 之后取值已不相同。现指向 peer 声明的兼容范围，并说明 engines.dsh 是同样的声明但不参与判定。
  这条修复的意义在于：本插件的核心卖点就是「让失效响亮地失败」，而诊断信息本身指错方向会削弱这一设计。
• README 目录树补全：此前漏列 pnpm-workspace.yaml（承载仓库自身的安装期构建授权）与 docs/market-submission.md，读者按旧图操作会遗漏前者。
• 文档中的版本闸门描述同步：此前把闸门机制说成读 engines.dsh，且多处写死 0.2.0-rc.2，与 1.1.0 放宽后的声明不一致。
• README 的 Node.js 要求更正：原写 ^22.19.0 或 >=24.0.0，与包内 engines.node（>=22）不符。

新增

AGENTS.md —— 供智能体与协作者使用的项目指引，内容取自实测结论，含几处不写下来必然踩坑的地方：补丁行的 id 与 name 故意不同、@deepseek-ai/cordis 不参与版本闸门、测试用手写 runner 而非 node:test。

安装与升级

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@latest

npm：@zhz8888/dsh-radeon-cloud-patcher@1.1.1（本版于 2026-10-06 补发到 npm）

测试

pnpm test 32 项检查全通过（合并语义 15 项 + 文本级编辑 17 项），思考字段取回的回归脚本同样通过。

Full Changelog：v1.1.0...v1.1.1

v1.1.0

安装形态变更：包名加作用域，DSH 兼容范围放宽到整个 0.2.x

这一版有两处会影响安装的变更：包名改为作用域包 @zhz8888/dsh-radeon-cloud-patcher（安装命令必须带 @zhz8888/），DSH 兼容范围从锁死的 0.2.0-rc.2 放宽到 0.2.x 的全部预发布与正式版。此外仓库从 npm 迁到 pnpm，并补齐了插件市场投稿所需的元数据。

功能变更（DSH 插件口径）

结论：有功能变更——变更集中在安装行为；provider 定义（模型、上下文、思考档位表）与 v1.0.0 完全一致。

维度	与 v1.0.0 相比
provider 定义（模型、上下文、思考档位）	未变：8 个模型、上下文长度与档位表逐字相同
插件行为	未变：仍是按键合并进 profile；src/ 除插件注册名与提示文案外无逻辑变更
安装方式	有变：包名加作用域，安装命令改为 @zhz8888/dsh-radeon-cloud-patcher
DSH 兼容范围	有变：从 0.2.0-rc.2 放宽为 >=0.2.0-rc.1 <0.2.1-0 || >=0.2.1-0 <0.3.0-0

变更

包名改为作用域包

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher

DSH 兼容范围放宽到整个 0.2.x

此前锁死 0.2.0-rc.2，装到 0.2.1-alpha.1 会被安装器拒绝。范围写成双分支是必要的：node-semver 只在范围里某个比较符与该版本的 major.minor.patch 元组一致、且自身带预发布标签时才放行预发布；单写 >=0.2.0-rc.1 <0.3.0-0 会把 0.2.1-alpha.1 这类不同元组的预发布静默排除，用户会撞上 ERESOLVE。

包管理器迁移：npm → pnpm

• 新增 pnpm-lock.yaml 与 pnpm-workspace.yaml，文档与源码提示中的命令相应改为 pnpm test / pnpm validate / pnpm install:profile
• pnpm-workspace.yaml 显式拒绝 @google/genai 与 protobufjs 的安装期构建：它们是 dsh-llm-pi-ai 的传递依赖，且发布 tarball 未携带构建脚本。此项声明让 pnpm install 不再因 ERR_PNPM_IGNORED_BUILDS 非零退出
• 面向使用者的插件安装路径不受影响：profile 的构建授权由 DSH 自行管理

插件市场投稿准备

按 awesome-dsh-plugin 贡献指南补齐包元数据：repository / homepage / bugs 指向仓库、声明 dsh.manifestVersion、官方 @deepseek-ai/* 包保持 peerDependencies；新增 docs/market-submission.md 说明投稿流程。

修复与文档

• 修复 README 里 DSH 版本徽章显示为 404 的问题（shields.io 静态路径的连字符分段导致解析失败）
• 精简 .gitignore 注释

安装与升级

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@latest

npm：@zhz8888/dsh-radeon-cloud-patcher@1.1.0（本版于 2026-10-06 补发到 npm）

测试

pnpm test 32 项检查全通过（合并语义 15 项 + 文本级编辑 17 项）；思考字段取回的回归脚本读取真实抓取的 SSE 流，同样通过。

Full Changelog：v1.0.0...v1.1.0

v1.0.0

首个版本：把 AMD Radeon Cloud 接入 DeepSeek Harness

装好插件后在「设置 → 模型」录入密钥即可使用：8 个对话模型全部可选，其中 7 个能逐档设置思考强度（reasoning effort），并正确取回分离的思考文本。插件不实现任何 provider 逻辑——传输、思考字段解析、多轮回传与用量计量全部由 DSH 自带的 dsh-llm-pi-ai 承担。

功能变更（DSH 插件口径）

结论：首个版本，无对比基线。

维度	本版状态
provider 定义（模型、上下文、思考档位）	交付 8 个对话模型；7 个支持思考档位，MiniCPM5-2B 不返回分离思考，故不提供档位
插件行为	把 provider 定义按键合并进 profile 的 cordis.patch.yml：只新增或覆盖 providers.radeon-cloud 这一个键，你自行添加的其它 provider、注释、缩进风格与键序原样保留
安装与兼容	可由 dsh plugin add 装载；仅支持 DSH 0.2.0-rc.2，其它版本由安装器直接拒绝

能力

• 档位实测：模型目录接口不返回档位信息，provider/radeon-cloud.yml 里的档位表逐模型实测得出（采集日期 2026-10-04）
• 启动校验：定义失效时让插件启动失败并给出可操作的诊断，而不是让思考功能无声坏掉
• 版本闸门：DSH 版本不匹配时直接拒绝安装，不会出现「装上了但思考功能失效」

安装

本版未发布到 npm：当时的包名还是无作用域的 dsh-radeon-cloud-patcher，而该名字需要另行占用；正式发布从 v1.1.0（作用域包名）开始。要使用请安装 v1.1.0 或更新版本：

dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher

已知边界

• 插件不实现任何 provider 逻辑：传输、思考字段解析、多轮回传、用量计量全部由 DSH 自带的 dsh-llm-pi-ai 承担
• 仅支持 DSH 0.2.0-rc.2，其它版本会被安装器拒绝
• 包管理使用 npm

全部提交：https://github.com/zhz8888/dsh-radeon-cloud-patcher/commits/v1.0.0