MauricioPerera/patch-guard

patch-guard

DeepSeek Harness（dsh）的组合插件，在启动时检查 dsh-tools 物化器 bug 的本地补丁（discussion #4747）是否仍存在于全局安装的 dsh-tools 中。

它不暴露任何模型工具——这是一个启动检查，仅控制台。零 npm 依赖。

为什么存在

Bug #4747 的修复是作为手动补丁应用到全局安装的 @deepseek-ai/dsh-tools 的编译后 lib/index.js 上的——它不是已发布包的一部分。一次 npm update -g @deepseek-ai/dsh 就会在没有任何错误或警告的情况下将其重新安装为未打补丁的状态。任何在其 schema 中带有 object/array 参数（或一个孤立的 oneOf）的插件，都会开始对某些模型出现参数验证失败，而没有任何关于真实原因的明显线索。

安装

将其挂载到 dsh 的配置文件中（~/.dsh/profiles//cordis.patch.yml）：

- insert:
- id: patch-guard
name: 'file:///C:/ruta/a/patch-guard/host.js'

重启 dsh 进程。结果会出现在运行 dsh 的控制台（终端，或者如果你重定向了的话，日志文件）中，而不是 Web UI 或聊天中。

它做什么

启动时，它会动态导入该 dsh 实际加载的真正 dsh-tools（不是它自己的副本——见下文），并用一个以 JSON 字符串形式传入的 object 参数真正调用其 validateJsonSchemaValue()，这正是没有补丁时会失败的形式。如果该值最终被强制转换为对象且没有违规，则补丁存在；否则不存在。

[patch-guard] OK — dsh-tools materializer patch (discussion #4747) is present at C:\...\dsh-tools\lib\index.js
[patch-guard] WARNING — dsh-tools materializer patch (discussion #4747) is MISSING at C:\...\dsh-tools\lib\index.js — object/array tool params sent as JSON strings by some models will fail validation. ...

设计决策（为什么这样构建）

- 行为检查，而非文本检查。 用 grep 在源代码中查找补丁的特定片段，一旦该代码被重新格式化或包版本变化就会失效。用只有补丁存在时才会通过的用例调用真实函数——无论代码是否有语法错误/警告——衡量的是真正重要的东西：行为。
- 不将 @deepseek-ai/dsh-tools 声明为自己的依赖。 对某个 specifier 的导入（import ... from '@deepseek-ai/dsh-tools'）总是从该文件自身的位置解析——如果 patch-guard 有自己的 node_modules/@deepseek-ai/dsh-tools（通过 npm install 全新安装，没有手动补丁），检查将始终检查那个单独的副本，并且始终是未打补丁的，无论 dsh 实际加载的 dsh-tools 的真实状态如何。相反，它通过 npm root -g 解析真实路径，并对该确切绝对路径执行动态 import()。
- 直接使用控制台（console.log/console.warn），不要用 ctx.logger。 实机发现：此部署中的 ctx.logger 没有任何会打印到控制台的 exporter——默认注册的唯一 exporter（Cordis core）只把消息存进一个没人读取的内存缓冲区。那里的警告到不了任何人手里。console.log/console.warn 确实会出现在终端里——dsh web 自己的启动横幅（dsh web: http://127.0.0.1:3080）用的就是这个。
- 用 exec()，不要用 execFile()，来运行 npm root -g。 在 Windows 上，npm 实际上是 npm.cmd——execFile 默认不经过 shell，无法解析它（spawn npm ENOENT，实机发现）。execFile(..., {shell:true}) 能解决，但 Node 会抛出关于未转义参数的 DeprecationWarning；由于这里的命令是固定字符串、没有外部输入，exec() 才是正确的工具，而且不会产生该警告。

已验证状态

- 正向分支：通过 dsh --profile headless 启动，确认“present”，并带有本机打过补丁的 dsh-tools 的真实路径。
- 反向分支：单独针对一个模拟模块进行了测试，该模块复现了未打补丁的行为（未触碰生产环境真实的 dsh-tools）——检测逻辑正确识别出了未打补丁的情况。