前言¶
在 DSH（DeepSeek Harness）里跑 agent，收尾时常见一句「测试都过了」——模型可以这么说，读者却无法确认它是否真的执行过命令、针对的是哪一次工作区状态。改完 A 又改 B 时，旧的通过结论也可能被静默沿用。现有做法多停在 system prompt 里提醒「记得跑测试」，或事后翻日志，执行权仍在模型转述层。
dsh-claimcheck 是维护者 Daphne999 发布的 DSH 工作流类插件：由插件自己跑项目的验收命令，把退出码与输出写入带 digest 的 JSON 证据，并把结果钉在当前工作区指纹上；树一变，证据即过期；若本轮改了文件却没有新鲜证据，收尾会被闸门拦下，提示先取证再宣称完成。社区目录页：https://www.skillhub.cn/plugins/Daphne999/dsh-claimcheck；源码与说明：https://github.com/Daphne999/dsh-claimcheck。
这是什么¶
一句话定位：可审计的完成闸门 + 本地证据链——不替代测试框架，负责执行、记录、过期判定与轮次拦截。
插件是零运行时依赖的 Host-only bundle（无 @deepseek-ai/* 导入），许可证 MIT，要求 Node ≥ 22。与生态里只提醒不拦截的 dsh-dod、不执行测试的 dsh-acceptance、偏回归评测的 dsh-eval-harness 等不同，claimcheck 强调自己执行、结果绑定工作区、会过期，产物是普通 JSON，可被其他工具消费。
核心功能¶
执行权与结论三态¶
- command 类检查通过 DSH 的 shell seam（
ctx.shell）真实执行；退出码、信号、超时、输出来自真实进程，模型不能伪造pass。 - verdict 只有
pass/fail/incomplete；缺证据永远是incomplete，不是 pass。manual类检查记为unknown，不会自动折算成通过。 - 工作区指纹（git HEAD + 工作区状态，或非 git 时的有界文件扫描）写入证据；指纹变化后
claim_status返回 stale。若检查命令运行期间改动了工作区，本次结论降级为incomplete并说明原因。
四个工具¶
| 工具 | 作用 |
|---|---|
claim_plan |
声明「什么算完成」；校验检查样式；拒绝危险命令与越界路径；最多 12 条 |
claim_verify |
真正执行并写证据；无计划时可按项目形状自动发现测试命令 |
claim_status |
只读判断证据是否仍有效（fresh / 过期原因），不执行、不写盘 |
claim_report |
从最新证据渲染交接用 Markdown，含 digest 与工作区指纹 |
检查类型示例（来自 README）：
{ "id": "unit", "kind": "command", "title": "单元测试通过", "command": "pnpm run test", "timeoutMs": 180000 }
{ "id": "doc", "kind": "file", "title": "README 更新", "path": "README.md", "contains": "claimcheck" }
{ "id": "ux", "kind": "manual", "title": "交互已人工确认", "requirement": "产品负责人签字" }
未提供计划时，claim_verify 可自动发现例如 package.json 的 test / typecheck / lint / build（按锁文件选包管理器）、pytest、cargo test、go test ./... 等。
证据落盘与完成闸门¶
证据写在会话工作区 .dsh/claimcheck/：runs/<runId>.json、latest.json、index.jsonl。schema 为 dsh-claimcheck/evidence@1，含 artifactDigest（覆盖除 digest 自身外字段）、每条检查的输出摘要、outputTruncated 等，CI 或脚本可直接读取。
每轮结束时，若本轮产生文件变更（write/edit、删改移、装依赖、带 --write/--fix 的 shell 等）而当前没有新鲜证据，插件会注入提醒并通过 agent.followup 让该轮继续。配置项 mode：warn（默认）、strict、off；maxNudgesPerSession 默认 3；纯问答、只读轮不触发。
诚实边界：插件提高伪造成本并让结果可审计，并非密码学意义上的不可伪造；人不装插件仍可跑任意命令，但每份证据指向插件实际执行的那次进程与那棵树。
安装与启用¶
方式 A · 市场/桌面端：搜索 dsh-claimcheck 安装（仓库带 dsh-plugin topic，由社区索引收录）。
方式 B · Release 离线包（v0.1.0，带 sha256）：
curl -LO https://github.com/Daphne999/dsh-claimcheck/releases/download/v0.1.0/dsh-claimcheck-0.1.0.tgz
curl -LO https://github.com/Daphne999/dsh-claimcheck/releases/download/v0.1.0/dsh-claimcheck-0.1.0.tgz.sha256
sha256sum -c dsh-claimcheck-0.1.0.tgz.sha256
mkdir -p ~/dsh-plugins/dsh-claimcheck && tar -xzf dsh-claimcheck-0.1.0.tgz -C ~/dsh-plugins/dsh-claimcheck
dsh plugin --profile <profile> add link:"$HOME/dsh-plugins/dsh-claimcheck"
方式 D · 写进 profile：
// ~/.dsh/profiles/<profile>/package.json
"dependencies": { "dsh-claimcheck": "link:/abs/path/to/dsh-claimcheck" },
"dsh": { "profile": { "bundles": [ /* ... */ "dsh-claimcheck" ] } }
装完重启宿主；列表中应出现「Claimcheck 验收取证」，会话中可用 claim_* 四个工具。
profile 的 cordis.patch.yml 可调整行为：
- id: dsh-claimcheck
config:
mode: warn # warn | strict | off
maxNudgesPerSession: 3
maxOutputBytes: 16384
evidenceDir: .dsh/claimcheck
autoDiscover: true
requireGateAfterWrite: true
典型用法¶
- 用
claim_plan声明 required 检查（或依赖autoDiscover让claim_verify发现命令）。 - 调用
claim_verify执行并生成证据；需要交接时用claim_report输出 Markdown。 - 改代码后先用
claim_status确认是否 stale；过期则重新claim_verify，再结束 agent 轮次。
安全方面：claim_plan / claim_verify 会拒绝 README 中列出的红线命令模式；file 检查拒绝绝对路径与 ..；执行策略与 DSH shell 工具一致。插件不联网、不上报遥测。
适用场景与注意¶
适合：希望 agent 在改代码后必须用真实命令退出码支撑「完成」、且证据能跟 git/工作区状态绑定的团队流程；需要把 JSON 证据交给 CI 或评审脚本的场景。
注意：检查命令以当前 DSH 宿主进程权限在本地工作区执行，安装前应阅读源码与 MIT 许可证，确认 RED_LINE_PATTERNS 与项目命令是否匹配你的安全策略。DSH 社区目录（如 skillhub.cn）与 DeepSeek / 幻方无官方从属关系，属「一切皆插件」生态下的第三方工作流扩展。
结尾¶
dsh-claimcheck 把「已完成」从一句自称，变成钉在工作区指纹上、会过期的可机读证据，并在无证据收尾时拦住轮次。目录：https://www.skillhub.cn/plugins/Daphne999/dsh-claimcheck；仓库：https://github.com/Daphne999/dsh-claimcheck。
