patch-guard

Plugin de composición para DeepSeek Harness (dsh) que chequea, al bootear, si el parche local del bug del materializador de dsh-tools (discussion #4747) sigue presente en el dsh-tools instalado globalmente.

No expone ninguna tool de modelo — es un chequeo de arranque, solo consola. Cero dependencias npm.

Por qué existe

El fix del bug #4747 se aplicó como parche manual al lib/index.js compilado del @deepseek-ai/dsh-tools instalado globalmente — no es parte del paquete publicado. Un npm update -g @deepseek-ai/dsh lo reinstala sin parche, sin error ni aviso de ningún tipo. Cualquier plugin con un parámetro object/array (o un oneOf suelto) en su schema empieza a fallar validación de argumentos para ciertos modelos, sin ninguna pista obvia de la causa real.

Instalación

Montarlo en el perfil de dsh (~/.dsh/profiles/<perfil>/cordis.patch.yml):

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

Reiniciar el proceso de dsh. El resultado aparece en la consola donde corre dsh (la terminal, o el archivo de log si lo redirigiste), no en la UI web ni en el chat.

Qué hace

Al arrancar, importa dinámicamente el dsh-tools real que carga ese dsh (no una copia propia — ver más abajo) y llama a su validateJsonSchemaValue() de verdad con un parámetro object pasado como string JSON, exactamente la forma que falla sin el parche. Si el valor termina coercionado a objeto y sin violaciones, el parche está; si no, no está.

[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. ...

Decisiones de diseño (por qué está armado así)

• Chequeo conductual, no textual. Grepear el código fuente por un fragmento específico del parche se rompe apenas ese código se reformatea o la versión del paquete cambia. Llamar a la función real con un caso que solo pasa si el parche está — con o sin errores/warnings de sintaxis del código, mide lo que realmente importa: el comportamiento.
• No declara @deepseek-ai/dsh-tools como dependencia propia. El import de un specifier (import ... from '@deepseek-ai/dsh-tools') se resuelve siempre desde la ubicación del propio archivo — si patch-guard tuviera su propio node_modules/@deepseek-ai/dsh-tools (instalado fresco vía npm install, sin el parche manual), el chequeo inspeccionaría SIEMPRE esa copia separada y SIEMPRE sin parchear, sin importar el estado real del dsh-tools que dsh efectivamente carga. En cambio, resuelve la ruta real vía npm root -g y hace import() dinámico de esa ruta absoluta exacta.
• Consola directa (console.log/console.warn), no ctx.logger. Encontrado en vivo: ctx.logger en este deployment no tiene ningún exporter que imprima a consola — el único exporter registrado por defecto (Cordis core) solo guarda los mensajes en un buffer en memoria que nadie lee. Un aviso ahí no llega a nadie. console.log/console.warn sí aparece en la terminal — es lo mismo que usa el propio dsh web para su banner de arranque (dsh web: http://127.0.0.1:3080).
• exec(), no execFile(), para correr npm root -g. En Windows, npm es en realidad npm.cmd — execFile no pasa por una shell por defecto y no puede resolverlo (spawn npm ENOENT, encontrado en vivo). execFile(..., {shell:true}) lo arregla pero Node tira un DeprecationWarning sobre argumentos sin escapar; como acá el comando es un string fijo sin input externo, exec() es la herramienta correcta y no genera el warning.

Estado verificado

• Rama positiva: booteado vía dsh --profile headless, confirmó "present" con la ruta real del dsh-tools parchado de esta máquina.
• Rama negativa: probada por separado contra un módulo simulado que reproduce el comportamiento sin parchear (sin tocar el dsh-tools real de producción) — la lógica de detección identifica correctamente el caso no parchado.