DSH 的 safe provider：把本机 ZCode CLI（zcode.cjs，ZCode 0.17.0）作为一个 zcode 路由接进 DSH 的 LLM 层。一个 LlmAdapter，无运行时依赖（dependencies 为空），Node ≥ 22。
这个插件的三件事（三件全部成立，第三件分两步走）：
- 完全合规 ✓ —— 插件自己从不向上游发一个网络请求：所有流量由官方二进制自带 ed25519 签名发起；不碰 ZCode 的账号密码，不伪造客户端特征。零风控、零封号面。
- 吃到 ZCode 账号的官方额度 ✓ —— 付费套餐走官方签名通道；免费起步套餐经 app-server 账号注入，且注入层已端到端激活（对照官方桌面客户端的投递载荷修复了 canonical revision、connectionKey 与 runtime 上报的 builtin tag，实测模型可在免费套餐上跑完整轮次）。消耗与官方客户端同池同规则，不需要任何 API Key。
- 抛弃 ZCode 的 harness 换 DSH 的：MCP 工具桥已落地 ✓ —— 实测（probe5，2026-10-26）：免费套餐上的模型可以经 MCP 桥调用工具。v0.3.0 起插件内建 HTTP MCP 桥（loopback + bearer token 随机路径），把 DSH 的工具 schema 投影给模型、把工具调用交回 DSH 工具管线执行；
toolPolicy非dsh-owned或桥起不来时自动退回 CLI 主导形态。审批走 DSH 现役审批面（桥的执行带 Agent 句柄）；toolAllowlist/toolDenylist为配置透传，语义未在本机实测验证。
DSH 生态里接第三方模型的插件，本质差异只有一个问题：谁来当 harness。harness 指「工具怎么执行、多步循环怎么走、上下文怎么管」这三件事。三类插件正好站在光谱两端：
| 本插件（当前版本） | 自建 harness 类第三方 provider 插件 | 抽 token 反代类插件 | |
|---|---|---|---|
| 模型额度来源 | ZCode CLI 官方二进制 | 各自的官方 CLI 二进制 | 逆向出的私token |
| harness 归属 | v0.3.0 起工具执行归 DSH（MCP 桥；整轮编排仍由 ZCode 驱动） | DSH 主导 | 插件自建 |
| 工具执行 | DSH 工具管线（MCP 桥回传；dsh-owned 时生效） |
DSH 工具管线（审批/沙箱全生效） | 插件自实现 |
| 网络请求 | 官方二进制签发 | 官方二进制签发 | 插件伪造客户端直连 |
| 风控/封号面 | 无 | 无 | 有（如 ZCode 通道 405 [3012] 惩罚阶梯） |
| DSH harness 增强（审批、沙箱、子代理、压缩） | 审批生效（MCP 桥带 Agent 句柄走 DSH 审批面）；沙箱/子代理/压缩仍未接 | 全部生效 | 部分自实现 |
为什么曾经是「CLI 主导」——旧判断与它的实测推翻。 本插件最初判断「ZCode 不卖裸模型接口」：它只卖「跑一轮任务」（-p 一次性 / app-server 会话），额度又绑定官方签名通道，看起来没有把 DSH 工具 schema 投进去的通道。这个判断已被实测推翻（2026-10-26 probe5：免费套餐上的模型经 MCP 桥成功调用工具）。v0.3.0 起 MCP 工具桥已产品化：插件把桥挂在自己的 loopback 路由上，经 session/create 的 mcpServers 参数注册给 ZCode（协议取自 zcode.cjs schema 取证，stdio/http 两形 union），DSH 工具经 HTTP 桥回传执行。toolPolicy 非 dsh-owned、或桥启动失败时，自动退回「整轮委托给 ZCode、DSH 只做壳层」的旧形态——桥的任何失败都是降级，不是报错。
DSH 市场里已有两条同走官方 CLI 委托路线的 ZCode 插件，都是认真维护的作品，收录本插件前先说清它们为什么不同：
dsh-zcode-cli-proxy/dsh-zcode-plan-bridge：单路线常驻 app-server（Start Plan 账号注入），真流式，跟进 ZCode CLI 新版（3.16.x）与 DSH 0.2.1 更激进。适合想让 ZCode 会话常驻、跟进新 CLI 的用户。- 本插件锚定已实测的 ZCode 0.17.0 + DSH 0.2.0-rc.2，做的是另一件事：付费（
-p一次性）与免费（app-server 注入）双路线，且把两条路线的行为逐一对齐（resume 语义、死会话自愈、准入检查、错误码），以 194 例 node --test 测试和三处计数的门禁锁死，每条行为有契约文档（docs/dsh-provider-contract.md）背书。适合要付费/免费可切、看重可测契约与 fail-closed 语义的用户。
- 零风控：只走官方 CLI 的签名通道，不触碰任何可被识别为「非官方客户端」的行为。
- 多路由并存：
zcode只是 DSH 模型列表里的一行——同一会话随时切回 DSH 原生 provider，ZCode 留作纯文本任务的额度补充。 - 双通道：付费（及默认）走一次性
-p子进程；免费起步套餐走 app-server 通道（插件把账号表注入进程、plan token 只在本机内存里交还官方 CLI 使用），两条都是官方二进制自签。 - 包装层全套：fail-closed 准入（兑现不了的请求在 spawn 前拒绝）、稳定错误码、重试/超时看门狗、并发门、会话锁、resume 死会话自愈——两条路线行为对齐。
- 设置卡片可切换：套餐 / 模型 / 推理强度三个下拉，写入插件自己的 loopback 路由，不重启生效，不写 ZCode 的任何状态文件。
- DSH harness 增强只接了一半：工具执行经 MCP 桥回 DSH 工具管线、审批经 DSH 审批面生效（v0.3.0）；沙箱策略、子代理编排、上下文压缩仍未接——工具调用的沙箱隔离由 DSH 工具管线按其自身策略决定，ZCode 侧的
--mode guarded非交互行为依旧未实测（见已知限制）。toolAllowlist/toolDenylist只是配置透传，是否真收窄 ZCode 的模型可见工具面未在本机实测验证（probe8 因 provider 路由不通未拿到模型侧工具面）。ZCode 作为 MCP 客户端的实际行为（工具命名、调用频率）同样未实测。 - 一轮一进程：每轮冷启动一个 CLI 子进程，首字延迟 1~3 秒；免费路线还要多付 app-server 就绪探针的时间。
- prompt 走 argv 有 30,000 字符硬顶（Windows 命令行上限）：
-p路线超长历史直接报错而不截断——宁可失败不答错题。免费路线走 stdin 无此限制。 - 模型切换受限：CLI 没有
--model/--effort，付费路线下模型目录是静态的两个 id；免费路线经 app-server 真实下发。 - 若 ZCode 的 harness 本身弱，本插件救不了：工具乱跑没人拦、上下文爆窗只能收到错误码。插件能做的只有把失败翻译成可读的错误。
- 把 DSH 的一轮对话渲染成一段 prompt，付费路线用
-p一次性交给zcode.cjs（恒带--mode guarded），免费路线经 app-serversession/send。 - 把 ZCode 的输出帧按 DSH 的
StreamChunk顺序投影（block-start → delta* → block-end → usage → finish），空输出与不可识别输出永不静默成功。 - 在启动子进程之前拒绝它兑现不了的请求：
tools、temperature/maxTokens/非空stop、reject政策下的 image/file block，各配稳定错误码。 - 子进程环境是闭集：OS 基础变量白名单 + 五项契约值 +
passEnv，宿主其他变量不外泄；NODE_OPTIONS强制并入 ipv4-first DNS 修复，未知 flag 丢弃不透传。 - 设置页卡片读写插件自己的 loopback 路由
GET/POST /plugins/dsh-zcode-cli/state；「套餐」下拉自 2026-10-25 起是传输选择（免费＝app-server，付费＝-p），两者都是官方 CLI 子进程。
不做什么：不做模型发现（ZCode 没有免配额的模型列表）、不猜计费（150% 倍率无服务端读数前不宣称）、不伪造 sessionId、不写 ZCode 的 setting.json / provider_config.json。
pwsh -File scripts/install-env.ps1看 dry-run，确认后pwsh -File scripts/install-env.ps1 -Apply（已存在且不同的变量默认跳过，需-Force覆盖）。- 在 profile 的
package.jsondependencies与cordis.patch.yml里加本包条目（改前备份）。 - 重启 DSH（改插件源码同样需要重启才生效）。
细节、契约表与实测基线见 docs/dsh-provider-contract.md。
node scripts/run-tests.mjs # AC11 行尾 → tsc --noEmit → build → tsc client → build:client → 包入口点 → 测试面计数 → node --testtests/ 下 15 个 *.test.mjs；脚本里的显式清单、docs/dsh-provider-contract.md 的「测试面」计数与磁盘实点三者必须一致，否则门禁在跑测试前就停。用例总数同样锁死（194，EXPECTED_TEST_CASES 与文档「测试用例」行），删掉一个 test() 块也会让门禁变红。MCP 工具桥由 tests/mcp-bridge.test.mjs 覆盖（协议握手、loopback/token 门禁、schema 校验、agent 平面解析、fail-closed 降级）。免费路线由一个实现了 app-server 协议的 fake CLI 端到端覆盖（流式/短答/resume/死会话/准入），浏览器半边字面量由 tests/client.test.mjs 逐项钉住。
- 工具隔离依赖 CLI 自身：
toolPolicy: reject只拒绝下发 DSH 的工具 schema，关不掉 ZCode CLI 内部的工具能力；--mode guarded下 CLI 内部工具行为未验证。本 provider 不宣称「工具已禁用」。 - prompt 在进程命令行可见：
-p形态把整轮 prompt 放进 argv，同机其他进程可读。不要把凭据写进 prompt。 - 成功路径未实测：账号返回
1309（套餐到期），-p成功时的 stdout 形状、sessionId 获取、guarded非交互行为、150% 计费均无读数（免费路线的 app-server sessionId 已可用）。 - 原子写仅单进程有效：
sessions.json用带pid + uuid的临时名 + rename，无跨进程锁。
完整清单（L1–L10）见 docs/dsh-provider-contract.md 的「已知限制」。