前言¶
在 DSH 插件体系里，恢复、回滚、失败回滚、陈旧计划拒绝这些动作通常由外部恢复执行器完成。对使用者来说，关键不是插件是否替谁执行恢复，而是演练结束后能否留下可检查的证据：相关对象是否仍是工作区里的普通文件，SHA-256 和 revision 是否一致，阶段顺序是否符合 manifest，RTO 是否达标，缺失或过期证据是否被明确披露。
下面介绍 dsh-recovery-proof。它是 DeepSeek Harness 的一个只读恢复演练证据核验插件。
这是什么¶
dsh-recovery-proof 是一个只读恢复演练证据核验器，仓库地址为：
https://github.com/dongsheng123132/dsh-recovery-proof
已核实信息如下：
- 维护者：
dongsheng123132 - 版本：
0.2.0 - 许可证：
MIT - 运行要求：
Node.js >=22
它不恢复文件，不创建 checkpoint，也不替代 Turn Rewind 或 Checkpoint Rewind 等恢复执行器。它的职责是检查一次外部恢复演练是否留下了可复核的证据，并输出一个 content-addressed JSON 报告。
核心功能¶
1、核验引用对象是否真实存在¶
插件会检查 manifest 中引用的 prestate、rescue、restored 或 rollback 对象是否满足以下条件：
- 是工作区里的普通文件；
- 具有声明的 SHA-256；
- 具有声明的 revision。
这意味着它关注的是“对象是否按声明落在工作区里”，而不是执行恢复动作本身。
2、核验阶段顺序是否符合 manifest¶
插件会检查以下流程是否遵循 manifest 中声明的精确阶段顺序：
- recovery；
- failed-apply rollback；
- stale-plan rejection。
同时还会检查更具体的语义约束：
- rescue 证据必须出现在 apply 之前；
- failed apply 之后必须跟随一次 successful rollback；
- stale plan 必须被拒绝。
3、核验 RTO 是否满足场景阈值¶
插件会检查累计结构性事件时长是否保持在每个场景的 RTO 阈值内。这里的输入是结构化的事件文件，而不是聊天内容或提示词内容。
4、输出 content-addressed JSON 报告¶
插件会生成一个 content-addressed JSON 报告，报告中会披露：
- missing evidence；
- stale evidence；
- failed rules。
也就是说，核验结果不是只给一个通过或不通过，而是把失败点和证据缺口写进报告。
5、注册 DSH bundle tools¶
插件会注册以下 bundle tools：
dsh_recovery_proof_inspect
dsh_recovery_proof_verify
它还提供 CLI 的 inspect 和 verify 命令，输入需要显式指定 workspace、manifest、event 和 artifact-dir。
6、提供 Codex plugin 和 proof-only MCP server¶
插件还提供 Codex plugin 和 proof-only MCP server，其中 MCP 暴露两个工具：
recovery_manifest_inspect
recovery_evidence_verify
这个 MCP 侧只用于受限核验，不执行恢复动作。
安装与启用¶
安装命令如下：
dsh plugin install github:dongsheng123132/dsh-recovery-proof
安装后使用下面的命令在插件体系中启用该插件：
dsh plugin compose dsh-recovery-proof
典型用法¶
inspect 用法¶
inspect 命令接收显式的 workspace-root 和 manifest 路径：
dsh-recovery-proof inspect --workspace-root ./examples/basic --manifest recovery.manifest.json
这一步用于检查 manifest 声明的恢复演练结构，而不写 artifact。
verify 用法¶
verify 命令会读取事件文件，并输出到显式的 artifact-dir：
dsh-recovery-proof verify --workspace-root ./examples/basic --manifest recovery.manifest.json --events recovery.events.jsonl --artifact-dir artifacts
这一步会执行完整的证据核验流程，并把报告写入 artifacts 目录。
输入与输出边界¶
1、输入是显式 JSON/JSONL 文件¶
插件的输入是显式 JSON 或 JSONL 文件。以下内容会被拒绝：
- secret-shaped fields；
- token-shaped fields；
- prompt-shaped fields；
- chat-shaped fields；
- content-shaped fields。
也就是说，插件不是通过读取聊天内容、提示词或密钥材料来做判断，而是围绕结构化证据工作。
2、路径必须留在 workspaceRoot 内¶
所有输入路径和输出目录都必须位于 workspaceRoot 下。以下输入会被拒绝：
- symlink input；
- symlink output directory。
输出只会写入显式指定的 workspace-relative artifactDir，并且使用 atomic write 和 SHA-256 read-back check。
3、不执行恢复动作¶
插件的边界比较明确：
- no shell is spawned；
- no network is used；
- no recovery action is executed；
- no install lifecycle scripts。
它只做证据核验，不做恢复执行。
4、MCP 侧不访问文件系统¶
MCP 工具不会访问文件系统，不会解引用对象路径，不会写入 artifact，也不会执行恢复动作。其结果会明确说明：object-content verification was not performed。
如果需要把对象哈希和 content-addressed 报告与工作区做核对，应该使用 DSH 或 CLI 入口。
适用场景与注意¶
这个插件适合以下场景：
- 已经有外部恢复演练流程，需要核验演练证据；
- 需要检查 manifest 中引用的对象是否符合声明的 SHA-256 和 revision；
- 需要检查 recovery、failed-apply rollback、stale-plan rejection 的阶段顺序；
- 需要检查 RTO 是否满足场景阈值；
- 需要把 missing/stale evidence 和 failed rules 写入报告。
不适用的场景包括：
- 需要插件直接恢复文件；
- 需要插件创建 checkpoint；
- 需要插件替代
Turn Rewind或Checkpoint Rewind等恢复执行器。
需要注意的是：插件以当前 dsh 进程权限运行。安装前应检查源码和许可证。
结尾¶
dsh-recovery-proof 的价值在于把恢复演练从“执行动作”拆到“核验证据”这一步。它不替代恢复执行器，而是检查外部演练是否留下了可复核的对象证据、阶段证据和 RTO 证据，并把失败项写进 content-addressed JSON 报告。
当前已核实材料提供 GitHub 仓库地址：
https://github.com/dongsheng123132/dsh-recovery-proof
独立目录页地址未在已核实材料中给出。
