dsh-doublecheck 0.5.0 → 0.6.0

package/CHANGELOG.md

@@ -2,6 +2,23 @@
 
 All notable changes to dsh-doublecheck are recorded here, newest first.
 
+## v0.6.0 — 2026-08-14
+
+The hardening release: the whole model-visible surface honors `language`, the projection schema's runtime dependency is declared, and the gates get quieter and more precise.
+
+- **Runtime dependency fix**: `zod` moved from devDependencies to `dependencies` — the built `lib/` imports it for the `doublecheck` projection schema (`ZodType` is the sessionProjections registry contract), and git-hosted installs skip devDependencies.
+- **Complete localization**: the switch notices, the `/doublecheck` command replies (including a richer `status` line with intensity, default switch, `remindOnce`, and the edit count), the held-back-findings note, and the critic's task prompt now honor `language: 'en' | 'zh'`. The workspace spec/report documents keep their English headings as stable artifacts.
+- **Fail-fast spec commit**: `doublecheck_spec` rejects empty or whitespace-only dimensions instead of recording an uncheckable contract (the invariant companion reuses the shared field list).
+- **Deterministic review order**: findings are sorted blocker-first (stable within a severity) in both the injected prose and the durable `doublecheck-review` record.
+- **Custom guard tools**: `mutationTargetPath` recognizes the `path` argument key beside `file_path`, and a guard-tool call that names no file at all no longer trips the red gate.
+- **O(1) switch reads**: the durable `doublecheck/state` fold rides the guard's incremental snapshot instead of rescanning the whole log per tool call.
+- **One effective switch**: the `/doublecheck` command now reads the same effective switch the gates enforce (process-local override → durable `doublecheck/state` → configured default), so `status` and repeated `on|off` answer consistently even on rc.6 hosts where the override is in-memory.
+- **Standalone invariant companion subpath**: `dsh-doublecheck/invariant` is now a real `exports` entry (`./invariant` → `lib/invariant.js` + `.d.ts`); the row was documented but not importable before.
+- **Wider default test coverage**: `deno test` and `uv run pytest` joined the default test-command patterns.
+- **`strict.patch.yml` restored**: the v0.5-changeloged all-gates-`block` overlay now actually ships (added to `files`).
+- **Release pipeline**: `NPM_TOKEN` lives in the repo secrets; the publish step skips versions already on the registry (idempotent re-tags) instead of failing, and a new `release` job creates the GitHub Release with the top changelog section as its notes.
+- **Package metadata**: `publishConfig.access: 'public'`, `sideEffects: false`, an npm version badge across the five READMEs, and `README.hi.md` fully synced to v0.6.
+
 ## v0.5.0 — 2026-08-14
 
 The discipline loop gets a human-facing cockpit and a hardened delivery pipeline.

package/README.es.md

@@ -2,7 +2,8 @@
 
 > **Verifica dos veces antes de publicar: interroga los requisitos, prueba la implementación, demuestra la entrega.**
 
-[![version](https://img.shields.io/badge/version-0.5.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![version](https://img.shields.io/badge/version-0.6.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![npm](https://img.shields.io/npm/v/dsh-doublecheck)](https://www.npmjs.com/package/dsh-doublecheck)
 [![license](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
 [![topics](https://img.shields.io/badge/topics-dsh%20%7C%20dsh--plugin-22c55e)](https://github.com/topics/dsh-plugin)
 
@@ -35,20 +36,23 @@ grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶
 | **review** | Un crítico adversario bifurcado audita la entrega contra el spec. | ✅ v0.3 |
 | **verify** | `doublecheck_report` + un workflow de verificación por dimensión demuestran la entrega. | ✅ v0.4 |
 
-## Funciones (v0.5)
+## Funciones
 
 - 🔥 **Skill `grill-requirements`** — un skill empaquetado en formato Agent Skills que interroga la tarea en seis dimensiones (**objetivo, alcance, criterios de aceptación, modos de fallo, prioridades, no-objetivos**) con la UI nativa `ask_user_question` de DSH, se niega a escribir código hasta el consenso y registra el contrato.
 - 🧰 **Skills de etapa para todo el bucle** — `red-green-tdd` (escribe la prueba que falla, ejecuta red, implementa, ejecuta green), `delivery-review` (autorrevisión adversaria contra el spec una vez en green) y `delivery-proof` (consolida la evidencia en el informe de entrega antes de declarar completado) se unen a `grill-requirements`: las seis etapas tienen guía de modelo, no solo la primera.
-- 📜 **Herramienta `doublecheck_spec`** — guarda el spec acordado en el registro de sesión y escribe una copia en markdown en el workspace, para que el contrato sobreviva a la conversación.
+- 📜 **Herramienta `doublecheck_spec`** — guarda el spec acordado en el registro de sesión y escribe una copia en markdown en el workspace, para que el contrato sobreviva a la conversación. Las dimensiones vacías o solo con espacios se rechazan en el commit (v0.6): el grill debe asentar las seis antes de que el spec cuente.
 - 🔄 **Re-grill ante cambio de tarea** — un spec registrado cubre su propia tarea: una nueva petición directa del usuario después del último spec reabre la puerta grill para ese seguimiento, en lugar de heredar el contrato anterior en silencio.
 - 🛡️ **Guard de disciplina** — una puerta blanda en el pipeline de políticas de herramientas. Tarea vaga + sin spec + rumbo a `edit`/`write` → **recordar**, **pedir aprobación humana** o **bloquear**, según `intensity`.
-- 🟥🟩 **Puertas de evidencia red/green** (`modules.tdd`) — comprobaciones duras sobre el registro de sesión: una edición de implementación requiere una **prueba que falla registrada** desde la última prueba que pasa (escribir archivos de prueba siempre está permitido — así ocurre el paso red), y un turno que termina con ediciones pero sin ninguna prueba que pasa recibe un recordatorio green inyectado.
-- 👁️ **Revisión adversaria** (`modules.adversary`) — una vez que la entrega alcanza green, un subagente crítico bifurcado (seam nativo de subagentes de DSH, provider `fork` por defecto) audita la sesión contra el spec registrado con una postura adversaria y devuelve hallazgos estructurados. `remind` inyecta la crítica; `warn`/`block` además dirigen una ronda para que el modelo responda a los hallazgos. `adversaryModel` enruta al crítico hacia un modelo separado; la allowlist de herramientas del crítico es de solo lectura por defecto. Los hallazgos viajan por la fuente de mensajes durable `doublecheck-review`. La revisión se rearma cuando el crítico termina: las ediciones de implementación posteriores al último registro de revisión disparan otra ronda, y cancelar el turno aborta al crítico en vuelo.
+- 🟥🟩 **Puertas de evidencia red/green** (`modules.tdd`) — comprobaciones duras sobre el registro de sesión: una edición de implementación requiere una **prueba que falla registrada** desde la última prueba que pasa (escribir archivos de prueba siempre está permitido — así ocurre el paso red), y un turno que termina con ediciones pero sin ninguna prueba que pasa recibe un recordatorio green inyectado. Las herramientas guard personalizadas funcionan de serie: las puertas leen las claves de argumento `file_path` y `path`, y una llamada que no nombra ningún archivo no se trata como edición de implementación.
+- 👁️ **Revisión adversaria** (`modules.adversary`) — una vez que la entrega alcanza green, un subagente crítico bifurcado (seam nativo de subagentes de DSH, provider `fork` por defecto) audita la sesión contra el spec registrado con una postura adversaria y devuelve hallazgos estructurados, ordenados con los blockers primero. `remind` inyecta la crítica; `warn`/`block` además dirigen una ronda para que el modelo responda a los hallazgos. `adversaryModel` enruta al crítico hacia un modelo separado; la allowlist de herramientas del crítico es de solo lectura por defecto. Los hallazgos viajan por la fuente de mensajes durable `doublecheck-review`. La revisión se rearma cuando el crítico termina: las ediciones de implementación posteriores al último registro de revisión disparan otra ronda, y cancelar el turno aborta al crítico en vuelo.
+- 🌐 **Superficie de modelo totalmente localizada** — cada cadena visible para el modelo que el paquete inyecta o responde (recordatorios, feedback de denegación/consulta, dirección de revisión, avisos de cambio, respuestas de `/doublecheck` y el prompt de tarea del crítico) respeta `language: 'en' | 'zh'`; los documentos spec/report del workspace conservan sus encabezados estables en inglés.
 - 📊 **Informe doublecheck + workflow de verificación** (`doublecheck_report`, v0.4) — consolida la evidencia de disciplina de la sesión (spec, cronología red/green, hallazgos de revisión, ediciones) en un informe de entrega con un veredicto derivado (`grill → draft → red → green → objections/verified → proven/challenged/unverified`), escrito en el workspace. Con `verify`, los verificadores por dimensión corren a través del seam de workflow de DSH (`verifyMode: all` lanza un verificador paralelo por dimensión; `single` ejecuta uno combinado) y sus veredictos se pliegan en el informe — `proven` exige un veredicto para cada dimensión.
 - 🚦 **Puerta de entrega** — en el límite del turno, una entrega que llegó a green sin `doublecheck_report` registrado recibe un recordatorio de informe esperado antes de declarar completado; un informe exitoso avanza la etapa a `verify`.
-- 🔁 **Estado duradero** — todo artefacto visible para el modelo (spec, recordatorios, feedback de denegación, hallazgos de revisión, el interruptor `/doublecheck on|off`) queda en el registro de sesión; las decisiones de las puertas se derivan solo del registro (`tool/call` + `tool/result`, incluidos los sub-despachos de Code Mode), así que las sesiones reanudadas o bifurcadas se comportan igual. `remindOnce` también es duradero: una sesión que ya recibió un recordatorio nunca lo recibe dos veces, incluso tras un reinicio.
-- ⌨️ **Comando de sesión `/doublecheck`** — `status` informa el interruptor efectivo, los módulos configurados y la etapa plegada; `report` pliega el informe de entrega al momento; `on|off` escribe el override durable `doublecheck/state` e inyecta un aviso de cambio.
+- 🔁 **Estado duradero** — todo artefacto visible para el modelo (spec, recordatorios, feedback de denegación, hallazgos de revisión, el interruptor `/doublecheck on|off`) queda en el registro de sesión; las decisiones de las puertas se derivan solo del registro (`tool/call` + `tool/result`, incluidos los sub-despachos de Code Mode), así que las sesiones reanudadas o bifurcadas se comportan igual. `remindOnce` también es duradero: una sesión que ya recibió un recordatorio nunca lo recibe dos veces, incluso tras un reinicio. El plegado del interruptor viaja en un snapshot incremental, así que las sesiones largas se mantienen en O(eventos nuevos) por llamada de herramienta.
+- ⌨️ **Comando de sesión `/doublecheck`** — `status` informa el interruptor efectivo, los módulos configurados, la intensidad de aplicación y los hechos de etapa plegados (spec, color de pruebas, revisión, número de ediciones); `report` pliega el informe de entrega al momento; `on|off` escribe el override durable `doublecheck/state` e inyecta un aviso de cambio.
 - 📚 **Herramienta `doublecheck_skills`** — lista y carga los skills del paquete a través del seam oficial del registro de skills.
+- 🔒 **Overlay estricto** — `strict.patch.yml` activa todas las puertas con intensidad `block` en una sola capa de patch (se incluye con el paquete).
+- 🧩 **Compañero invariante independiente** — la fila `dsh-doublecheck/invariant` es una exportación de subruta real: informa de las contradicciones de la ruta de escritura del paquete (forma spec/report/review) a través del registro `invariants` del host sin cargar el guard.
 
 ## Demo
 
@@ -76,13 +80,19 @@ Ambas filas de plugin se activan automáticamente con el profile. También sirve
 
 ```sh
 pnpm pack
-dsh plugin --profile <name> add ./dsh-doublecheck-0.5.0.tgz
+dsh plugin --profile <name> add ./dsh-doublecheck-0.6.0.tgz
 ```
 
 La instalación por git no necesita npm:
 
 ```sh
-dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.5.0"
+dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.6.0"
+```
+
+Para un modo estricto sin configuración (todas las puertas activas, intensidad `block`), aplica el overlay incluido encima del bundle patch:
+
+```sh
+dsh --profile <name> --patch ./node_modules/dsh-doublecheck/strict.patch.yml
 ```
 
 ## Desinstalación
@@ -131,6 +141,7 @@ Sobrescribe cualquier fila **por id** en el `cordis.patch.yml` del profile. Un p
       - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
     reportMutationTools: ['edit', 'write']
     reportTestFilePatterns:
       - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
@@ -156,11 +167,14 @@ Sobrescribe cualquier fila **por id** en el `cordis.patch.yml` del profile. Un p
       - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
     testFilePatterns:
       - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
       - '\\.(test|spec)\\.[A-Za-z0-9]+$'
 ```
 
+El `strict.patch.yml` incluido es exactamente esta fila guard con `intensity: block` y todos los módulos activos — aplícalo como capa de patch después del bundle patch para el modo estricto sin editar un profile a mano.
+
 ### `intensity`
 
 | Valor | Comportamiento ante un `edit`/`write` sujeto a la puerta |
@@ -174,13 +188,13 @@ Sobrescribe cualquier fila **por id** en el `cordis.patch.yml` del profile. Un p
 | Clave | Por defecto | Significado |
 |---|---|---|
 | `modules.grill` | `true` | En `false` desactiva la puerta grill. El interruptor de los skills/herramientas grill es el flag `disabled` de su fila. |
-| `modules.tdd` | `false` | En `true` activa las puertas de evidencia red/green (v0.2). |
+| `modules.tdd` | `true` | En `true` activa las puertas de evidencia red/green (v0.2); activado por defecto desde v0.5. |
 | `modules.adversary` | `false` | En `true` activa la revisión del crítico bifurcado en green (v0.3); usa el seam `ctx.subagents` — un seam ausente se resuelve como un aviso «no disponible». |
 | `guardTools` | `['edit', 'write']` | Nombres de herramientas de mutación que vigila el guard. |
 | `vagueTaskMaxChars` | `200` | Las tareas más largas nunca se consideran vagas. Las tareas breves que nombran un archivo, ruta, URL, una palabra clave con guion bajo o una palabra clave con guion son concretas. |
 | `remindOnce` | `true` | Inyectar el recordatorio de cada puerta como máximo una vez por sesión. |
 | `testToolNames` | `['bash', 'pwsh']` | Nombres de herramientas de shell que pueden ejecutar pruebas. |
-| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test)* | Expresiones regulares con las que debe coincidir un comando para contar como ejecución de prueba. |
+| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test, deno test, uv run pytest)* | Expresiones regulares con las que debe coincidir un comando para contar como ejecución de prueba. |
 | `testFilePatterns` | *(directorios de prueba, `*.test.*` / `*.spec.*`)* | Expresiones regulares que identifican archivos de prueba — siempre editables, exentos de la puerta red. |
 | `adversaryModel` | `null` | Ruta del modelo crítico; `null` = el modelo principal se autorrevisa. |
 | `adversaryProvider` | `'fork'` | Nombre del provider de subagentes en el que corre el crítico. |
@@ -228,10 +242,23 @@ Sin cambios en el agent-loop. Cada registro es un `ctx.effect` / `ctx.on` / `reg
 - Los recordatorios llegan como contexto `{kind:'plugin'}`, así que las UIs de transcripción los muestran como metadatos de inyección.
 - La crítica del adversario llega de la misma manera cuando el crítico se asienta, con hallazgos etiquetados por severidad; bajo `warn`/`block` el bucle se dirige una ronda para que el modelo les responda.
 - `doublecheck_report` devuelve el informe consolidado como resultado de herramienta (spec, cronología de pruebas, revisión, verificación, veredicto), así que «demostrar la entrega» está a una llamada de distancia.
+- `/doublecheck` responde directamente en la transcripción: `status` muestra el interruptor, los módulos, la intensidad y los hechos de etapa; `report` imprime el informe plegado; `on|off` cambia el interruptor de sesión.
+
+## Comando de sesión
+
+```
+/doublecheck status|report|on|off
+```
+
+- `status` — interruptor efectivo (el override durable vence al valor por defecto de la config), módulos configurados, intensidad de aplicación y los hechos de etapa plegados (spec registrado, color red/green, revisión en registro, número de ediciones).
+- `report` — pliega el informe de entrega desde el registro de sesión al momento (sin workflow de verificación; `doublecheck_report` es dueño de esa ruta).
+- `on` / `off` — escribe el evento durable `doublecheck/state` (sobrevive a reinicio, reanudación y bifurcación — el replay ES el estado) e inyecta un aviso de cambio visible para el modelo.
+
+Todas las respuestas del comando respetan el ajuste `language` de la fila guard.
 
 ## Hoja de ruta
 
-El bucle de disciplina de seis etapas está completo: **grill → design → red → green → review → verify** se incluyen todas en este paquete (v0.1 → v0.4). Trabajo futuro: cobertura de snapshot para las transcripciones de review/informe y un formato de informe más rico.
+El bucle de disciplina de seis etapas está completo: **grill → design → red → green → review → verify** se incluyen todas en este paquete (v0.1 → v0.6). Los fixtures de regresión con transcripciones reales fijan las formas de los eventos durables (`tests/fixtures/`). Trabajo futuro: un formato de informe más rico, una insignia de estado de disciplina para la Web UI y la siembra de spec entre sesiones desde el archivo del workspace.
 
 ## Desarrollo
 

package/README.hi.md

@@ -2,9 +2,11 @@
 
 > **शिप करने से पहले दोबारा जाँचें: आवश्यकताओं की पड़ताल करें, कार्यान्वयन का परीक्षण करें, डिलीवरी साबित करें।**
 
-[![version](https://img.shields.io/badge/version-0.5.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![version](https://img.shields.io/badge/version-0.6.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![npm](https://img.shields.io/npm/v/dsh-doublecheck)](https://www.npmjs.com/package/dsh-doublecheck)
 [![license](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
 [![topics](https://img.shields.io/badge/topics-dsh%20%7C%20dsh--plugin-22c55e)](https://github.com/topics/dsh-plugin)
+[![CI](https://img.shields.io/github/actions/workflow/status/PerryLink/dsh-doublecheck/ci.yml?branch=main)](https://github.com/PerryLink/dsh-doublecheck/actions/workflows/ci.yml)
 
 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) के लिए एक **इंजीनियरिंग-अनुशासन बंडल**। एजेंट तुरंत कोड लिखना चाहते हैं; आवश्यकताएँ मान लिए जाना पसंद नहीं करतीं। `dsh-doublecheck` एक अनुशासन-चक्र स्थापित करता है जो एजेंट को **पहले संपादन से पहले आवश्यकताओं की पड़ताल करने** और **डिलीवरी का दावा करने के बजाय उसे साबित करने** के लिए बाध्य करता है — पूरी तरह DSH के अपने एक्सटेंशन पॉइंट्स (स्किल रजिस्ट्री, टूल पॉलिसी पाइपलाइन, अप्रूवल सीम, उप-एजेंट और वर्कफ़्लो सीम, सेशन लॉग) पर मूल रूप से पुनः लागू, किसी उधार की प्रॉम्प्ट फ़ाइल पर नहीं। DSH `0.1.0-rc.6` के विरुद्ध परीक्षण किया गया।
 
@@ -35,20 +37,23 @@ grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶
 | **review** | एक फ़ॉर्क किया गया विरोधी-आलोचक spec के विरुद्ध डिलीवरी का ऑडिट करता है। | ✅ v0.3 |
 | **verify** | `doublecheck_report` + प्रति-आयाम सत्यापन वर्कफ़्लो डिलीवरी साबित करते हैं। | ✅ v0.4 |
 
-## विशेषताएँ (v0.5)
+## विशेषताएँ
 
 - 🔥 **`grill-requirements` स्किल** — Agent Skills प्रारूप में पैक की गई स्किल, जो DSH की मूल `ask_user_question` UI से कार्य की छह आयामों (**लक्ष्य, दायरा, स्वीकृति-मानदंड, विफलता-स्थितियाँ, प्राथमिकताएँ, निषेध**) पर पड़ताल करती है, सहमति तक कोड लिखने से इनकार करती है और अनुबंध दर्ज करती है।
 - 🧰 **पूरे चक्र के लिए चरण-स्किल्स** — `red-green-tdd` (असफल परीक्षण लिखें, red चलाएँ, लागू करें, green चलाएँ), `delivery-review` (green के बाद spec के विरुद्ध प्रतिकूल आत्म-समीक्षा) और `delivery-proof` (पूर्णता घोषित करने से पहले प्रमाण को डिलीवरी रिपोर्ट में समेकित करें) `grill-requirements` से जुड़ गए: छहों चरणों में मॉडल-मार्गदर्शन है, सिर्फ़ पहले में नहीं।
-- 📜 **`doublecheck_spec` टूल** — सहमत spec को सेशन लॉग में दर्ज करता है और वर्कस्पेस में markdown प्रति लिखता है, ताकि अनुबंध बातचीत के बाद भी बचा रहे।
+- 📜 **`doublecheck_spec` टूल** — सहमत spec को सेशन लॉग में दर्ज करता है और वर्कस्पेस में markdown प्रति लिखता है, ताकि अनुबंध बातचीत के बाद भी बचा रहे। खाली या केवल-व्हाइटस्पेस आयाम कमिट पर अस्वीकार होते हैं (v0.6): spec गिनने से पहले grill को छहों आयाम निपटाने होंगे।
 - 🔄 **कार्य-बदलाव पर फिर grill** — दर्ज spec अपने ही कार्य को कवर करता है: नवीनतम spec के बाद उपयोगकर्ता का नया सीधा अनुरोध उस फ़ॉलो-अप के लिए grill द्वार फिर खोल देता है, पुराने अनुबंध को चुपचाप विरासत में लेने के बजाय।
 - 🛡️ **अनुशासन गार्ड** — टूल पॉलिसी पाइपलाइन पर एक नरम द्वार। अस्पष्ट कार्य + spec नहीं + `edit`/`write` की ओर बढ़ना → `intensity` के अनुसार **याद दिलाना**, **मानव अनुमोदन माँगना** या **रोकना**।
-- 🟥🟩 **Red/green प्रमाण-द्वार** (`modules.tdd`) — सेशन लॉग पर कड़ी जाँचें: कार्यान्वयन संपादन के लिए पिछले पास होने वाले परीक्षण के बाद से एक **असफल परीक्षण लॉग में दर्ज** होना चाहिए (परीक्षण फ़ाइलें लिखना हमेशा अनुमत है — red चरण ऐसे ही घटता है), और जो टर्न संपादनों के साथ पर बिना किसी पास होने वाले परीक्षण के समाप्त होता है, उसमें green अनुस्मारक इंजेक्ट होता है।
-- 👁️ **विरोधी-समीक्षा** (`modules.adversary`) — जब डिलीवरी green पर पहुँच जाती है, तब एक फ़ॉर्क किया गया आलोचक उप-एजेंट (DSH का मूल उप-एजेंट सीम, डिफ़ॉल्ट `fork` provider) प्रतिकूल रुख़ के साथ दर्ज spec के विरुद्ध सेशन का ऑडिट करता है और संरचित निष्कर्ष लौटाता है। `remind` आलोचना इंजेक्ट करता है; `warn`/`block` इसके अलावा एक राउंड चलाकर मॉडल से निष्कर्षों का उत्तर दिलवाते हैं। `adversaryModel` आलोचक को अलग मॉडल पर भेजता है; आलोचक की टूल allowlist डिफ़ॉल्ट रूप से read-only है। निष्कर्ष टिकाऊ `doublecheck-review` संदेश-स्रोत पर सवार होते हैं। आलोचक के निपटने के बाद समीक्षा फिर सक्रिय हो जाती है: नवीनतम समीक्षा-रिकॉर्ड के बाद कार्यान्वयन संपादन अगला राउंड चलाते हैं, और टर्न रद्द करने पर चालू आलोचक बाधित होता है।
+- 🟥🟩 **Red/green प्रमाण-द्वार** (`modules.tdd`) — सेशन लॉग पर कड़ी जाँचें: कार्यान्वयन संपादन के लिए पिछले पास होने वाले परीक्षण के बाद से एक **असफल परीक्षण लॉग में दर्ज** होना चाहिए (परीक्षण फ़ाइलें लिखना हमेशा अनुमत है — red चरण ऐसे ही घटता है), और जो टर्न संपादनों के साथ पर बिना किसी पास होने वाले परीक्षण के समाप्त होता है, उसमें green अनुस्मारक इंजेक्ट होता है। कस्टम guard टूल बॉक्स से बाहर काम करते हैं: द्वार `file_path` और `path` दोनों argument-कुंजियाँ पढ़ते हैं, और जो कॉल कोई फ़ाइल नहीं बताती वह कार्यान्वयन संपादन नहीं मानी जाती।
+- 👁️ **विरोधी-समीक्षा** (`modules.adversary`) — जब डिलीवरी green पर पहुँच जाती है, तब एक फ़ॉर्क किया गया आलोचक उप-एजेंट (DSH का मूल उप-एजेंट सीम, डिफ़ॉल्ट `fork` provider) प्रतिकूल रुख़ के साथ दर्ज spec के विरुद्ध सेशन का ऑडिट करता है और blocker-प्रथम क्रम में संरचित निष्कर्ष लौटाता है। `remind` आलोचना इंजेक्ट करता है; `warn`/`block` इसके अलावा एक राउंड चलाकर मॉडल से निष्कर्षों का उत्तर दिलवाते हैं। `adversaryModel` आलोचक को अलग मॉडल पर भेजता है; आलोचक की टूल allowlist डिफ़ॉल्ट रूप से read-only है। निष्कर्ष टिकाऊ `doublecheck-review` संदेश-स्रोत पर सवार होते हैं। आलोचक के निपटने के बाद समीक्षा फिर सक्रिय हो जाती है: नवीनतम समीक्षा-रिकॉर्ड के बाद कार्यान्वयन संपादन अगला राउंड चलाते हैं, और टर्न रद्द करने पर चालू आलोचक बाधित होता है।
+- 🌐 **पूरी तरह स्थानीयकृत मॉडल सतह** — पैकेज द्वारा इंजेक्ट या उत्तर दिए गए हर मॉडल-दृश्य वाक्य (अनुस्मारक, अस्वीकृति/पूछताछ फ़ीडबैक, समीक्षा-steering, स्विच सूचनाएँ, `/doublecheck` उत्तर, आलोचक का कार्य-प्रॉम्प्ट) `language: 'en' | 'zh'` का सम्मान करते हैं; वर्कस्पेस spec/report दस्तावेज़ अपने स्थिर अंग्रेज़ी शीर्षक रखते हैं।
 - 📊 **Doublecheck रिपोर्ट + सत्यापन वर्कफ़्लो** (`doublecheck_report`, v0.4) — सेशन के अनुशासन-प्रमाण (spec, red/green समयरेखा, समीक्षा-निष्कर्ष, संपादन) को एक डिलीवरी रिपोर्ट में समेकित करता है, जिसमें व्युत्पन्न निर्णय होता है (`grill → draft → red → green → objections/verified → proven/challenged/unverified`), वर्कस्पेस में लिखी जाती है। `verify` के साथ, प्रति-आयाम जाँचकर्ता DSH के वर्कफ़्लो सीम से चलते हैं (`verifyMode: all` हर आयाम के लिए एक समानांतर जाँचकर्ता लॉन्च करता है; `single` एक संयुक्त जाँचकर्ता चलाता है) और उनके निर्णय रिपोर्ट में समाहित होते हैं — `proven` के लिए हर आयाम का निर्णय ज़रूरी है।
 - 🚦 **डिलीवरी द्वार** — टर्न-सीमा पर, जो डिलीवरी बिना दर्ज `doublecheck_report` के green पर पहुँची है, उसे पूर्णता घोषित करने से पहले रिपोर्ट-अपेक्षित अनुस्मारक मिलता है; सफल रिपोर्ट चरण को `verify` पर बढ़ा देती है।
-- 🔁 **टिकाऊ स्थिति** — मॉडल को दिखने वाली हर चीज़ (spec, अनुस्मारक, अस्वीकृति-फ़ीडबैक, समीक्षा-निष्कर्ष, `/doublecheck on|off` स्विच) सेशन लॉग में दर्ज होती है; द्वारों के निर्णय केवल लॉग से निकलते हैं (`tool/call` + `tool/result`, Code Mode उप-प्रेषण सहित), इसलिए पुनः आरंभ या फ़ॉर्क की गई सेशन भी वैसा ही व्यवहार करती हैं। `remindOnce` भी टिकाऊ है: जिस सेशन को अनुस्मारक मिल चुका, उसे दोबारा कभी नहीं मिलता, रीस्टार्ट के बाद भी।
-- ⌨️ **`/doublecheck` सेशन कमांड** — `status` प्रभावी स्विच, कॉन्फ़िगर किए मॉड्यूल और folded चरण बताता है; `report` डिलीवरी रिपोर्ट वहीं fold करता है; `on|off` टिकाऊ `doublecheck/state` ओवरराइड लिखता है और स्विच-सूचना इंजेक्ट करता है।
+- 🔁 **टिकाऊ स्थिति** — मॉडल को दिखने वाली हर चीज़ (spec, अनुस्मारक, अस्वीकृति-फ़ीडबैक, समीक्षा-निष्कर्ष, `/doublecheck on|off` स्विच) सेशन लॉग में दर्ज होती है; द्वारों के निर्णय केवल लॉग से निकलते हैं (`tool/call` + `tool/result`, Code Mode उप-प्रेषण सहित), इसलिए पुनः आरंभ या फ़ॉर्क की गई सेशन भी वैसा ही व्यवहार करती हैं। `remindOnce` भी टिकाऊ है: जिस सेशन को अनुस्मारक मिल चुका, उसे दोबारा कभी नहीं मिलता, रीस्टार्ट के बाद भी। स्विच-fold इंक्रीमेंटल snapshot पर चलता है, इसलिए लंबी सेशनों में प्रति टूल-कॉल O(नए इवेंट) ही खर्च होता है।
+- ⌨️ **`/doublecheck` सेशन कमांड** — `status` प्रभावी स्विच, कॉन्फ़िगर किए मॉड्यूल, प्रवर्तन-तीव्रता और folded चरण-तथ्य (spec, परीक्षण-रंग, समीक्षा, संपादन-संख्या) बताता है; `report` डिलीवरी रिपोर्ट वहीं fold करता है; `on|off` टिकाऊ `doublecheck/state` ओवरराइड लिखता है और स्विच-सूचना इंजेक्ट करता है।
 - 📚 **`doublecheck_skills` टूल** — आधिकारिक स्किल-रजिस्ट्री सीम से पैकेज की स्किल्स सूचीबद्ध व लोड करता है।
+- 🔒 **सख़्त overlay** — `strict.patch.yml` एक patch परत में सभी द्वारों को `block` तीव्रता पर चालू कर देता है (पैकेज के साथ शिप होता है)।
+- 🧩 **स्वतंत्र invariant साथी** — `dsh-doublecheck/invariant` पंक्ति एक वास्तविक उप-पथ निर्यात है: guard लोड किए बिना host के `invariants` रजिस्ट्री से पैकेज-स्वामित्व वाले लेखन-पथ विरोधाभासों (spec/report/review आकार) की रिपोर्ट करती है।
 
 ## डेमो
 
@@ -76,13 +81,19 @@ dsh --profile <name> --dump-config   # "# == dsh-doublecheck" परत दि
 
 ```sh
 pnpm pack
-dsh plugin --profile <name> add ./dsh-doublecheck-0.5.0.tgz
+dsh plugin --profile <name> add ./dsh-doublecheck-0.6.0.tgz
 ```
 
 git से स्थापना के लिए npm की ज़रूरत नहीं:
 
 ```sh
-dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.5.0"
+dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.6.0"
+```
+
+ज़ीरो-कॉन्फ़िगरेशन सख़्त मोड (सभी द्वार चालू, `block` तीव्रता) के लिए, bundle patch के ऊपर शिप किया गया overlay लगाएँ:
+
+```sh
+dsh --profile <name> --patch ./node_modules/dsh-doublecheck/strict.patch.yml
 ```
 
 ## अनइंस्टॉल
@@ -126,11 +137,13 @@ profile के `cordis.patch.yml` में किसी भी पंक्त
     reportFile: 'specs/doublecheck-report.md'   # डिफ़ॉल्ट: 'doublecheck-report.md'
     reportVerify: true            # डिफ़ॉल्ट रूप से सत्यापन वर्कफ़्लो चलाएँ
     verifyProvider: 'fork'        # प्रति-आयाम जाँचकर्ताओं के लिए provider
+    verifyMode: 'all'             # 'all' = प्रति आयाम समानांतर जाँचकर्ता; 'single' = एक संयुक्त
     reportTestToolNames: ['bash', 'pwsh']
     reportTestCommandPatterns:
       - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
     reportMutationTools: ['edit', 'write']
     reportTestFilePatterns:
       - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
@@ -151,16 +164,21 @@ profile के `cordis.patch.yml` में किसी भी पंक्त
     guardTools: ['edit', 'write']
     vagueTaskMaxChars: 200
     remindOnce: true
+    language: en                    # 'en' | 'zh'
+    enableByDefault: true
     testToolNames: ['bash', 'pwsh']
     testCommandPatterns:
       - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
     testFilePatterns:
       - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
       - '\\.(test|spec)\\.[A-Za-z0-9]+$'
 ```
 
+शिप किया गया `strict.patch.yml` ठीक यही guard पंक्ति है `intensity: block` और सभी मॉड्यूल चालू — profile हाथ से संपादित किए बिना सख़्त मोड के लिए इसे bundle patch के बाद patch परत के रूप में लगाएँ।
+
 ### `intensity`
 
 | मान | द्वार-नियंत्रित `edit`/`write` पर व्यवहार |
@@ -174,13 +192,15 @@ profile के `cordis.patch.yml` में किसी भी पंक्त
 | कुंजी | डिफ़ॉल्ट | अर्थ |
 |---|---|---|
 | `modules.grill` | `true` | `false` पर grill द्वार बंद। grill स्किल/टूल का स्विच उनकी पंक्ति का `disabled` फ़्लैग है। |
-| `modules.tdd` | `false` | `true` पर red/green प्रमाण-द्वार चालू (v0.2)। |
+| `modules.tdd` | `true` | `true` पर red/green प्रमाण-द्वार चालू (v0.2); v0.5 से डिफ़ॉल्ट रूप से सक्षम। |
 | `modules.adversary` | `false` | `true` पर green (v0.3) पर फ़ॉर्क किए आलोचक की समीक्षा चालू होती है; `ctx.subagents` सीम का उपयोग करती है — सीम अनुपस्थित होने पर «अनुपलब्ध» सूचना दर्ज होती है। |
-| `guardTools` | `['edit', 'write']` | वे परिवर्तन-टूल नाम जिन पर गार्ड नज़र रखता है। |
+| `enableByDefault` | `true` | बिना `/doublecheck on|off` रिकॉर्ड वाली सेशनों के लिए मास्टर स्विच। |
+| `language` | `'en'` | इंजेक्ट होने वाले अनुस्मारक/अस्वीकृति/समीक्षा गद्य की भाषा (`en` / `zh`)। |
+| `guardTools` | `['edit', 'write']` | वे परिवर्तन-टूल नाम जिन पर दोनों द्वार नज़र रखते हैं। |
 | `vagueTaskMaxChars` | `200` | इससे लंबे कार्य कभी अस्पष्ट नहीं माने जाते। फ़ाइल, पथ, URL, अंडरस्कोर कीवर्ड या हाइफ़न युक्त कीवर्ड बताने वाले छोटे कार्य ठोस होते हैं। |
-| `remindOnce` | `true` | प्रत्येक द्वार का अनुस्मारक प्रति सेशन अधिकतम एक बार इंजेक्ट करें। |
+| `remindOnce` | `true` | प्रत्येक द्वार का अनुस्मारक प्रति सेशन अधिकतम एक बार — रीस्टार्ट के बाद भी टिकाऊ (लॉग से folded)। |
 | `testToolNames` | `['bash', 'pwsh']` | वे शेल टूल नाम जो परीक्षण चला सकते हैं। |
-| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test)* | वे regex जिनसे मेल खाने पर कमांड परीक्षण-रन माना जाता है। |
+| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test, deno test, uv run pytest)* | वे regex जिनसे मेल खाने पर कमांड परीक्षण-रन माना जाता है। |
 | `testFilePatterns` | *(परीक्षण डायरेक्टरियाँ, `*.test.*` / `*.spec.*`)* | वे regex जो परीक्षण फ़ाइलें पहचानते हैं — हमेशा संपादन-योग्य, red द्वार से मुक्त। |
 | `adversaryModel` | `null` | आलोचक मॉडल मार्ग; `null` = मुख्य मॉडल स्वयं समीक्षा करता है। |
 | `adversaryProvider` | `'fork'` | वह उप-एजेंट provider नाम जिस पर आलोचक चलता है। |
@@ -197,8 +217,9 @@ profile के `cordis.patch.yml` में किसी भी पंक्त
 | `reportFile` | `'doublecheck-report.md'` | वह वर्कस्पेस फ़ाइल जो रिपोर्ट markdown प्राप्त करती है। |
 | `reportVerify` | `true` | टूल के `verify` फ़्लैग का डिफ़ॉल्ट। |
 | `verifyProvider` | `'fork'` | वह उप-एजेंट provider जिस पर प्रति-आयाम जाँचकर्ता चलते हैं। |
-| `reportTestToolNames` / `reportTestCommandPatterns` | *(same defaults as the guard row)* | रिपोर्ट-स्कोप परीक्षण-रन वर्गीकरण। |
-| `reportMutationTools` / `reportTestFilePatterns` | *(same defaults as the guard row)* | रिपोर्ट-स्कोप कार्यान्वयन-संपादन वर्गीकरण। |
+| `verifyMode` | `'all'` | `all` = प्रति आयाम एक समानांतर जाँचकर्ता; `single` = एक संयुक्त जाँचकर्ता (एक उप-एजेंट, सस्ता)। |
+| `reportTestToolNames` / `reportTestCommandPatterns` | *(guard पंक्ति के समान डिफ़ॉल्ट)* | रिपोर्ट-स्कोप परीक्षण-रन वर्गीकरण। |
+| `reportMutationTools` / `reportTestFilePatterns` | *(guard पंक्ति के समान डिफ़ॉल्ट)* | रिपोर्ट-स्कोप कार्यान्वयन-संपादन वर्गीकरण। |
 
 रिपोर्ट के वर्गीकरण नियंत्रण गार्ड से स्वतंत्र हैं: द्वार-प्रवर्तन और रिपोर्ट-फ़ोल्ड को अलग-अलग ट्यून किया जा सकता है, बिना एक के चुपचाप दूसरे को बदले। सत्यापन ईमानदारी से घटता है: `workflowEngine` सीम अनुपस्थित या रन अस्वीकृत होने पर `verification: null` रह जाता है और markdown यह बताता है।
 
@@ -213,11 +234,12 @@ profile के `cordis.patch.yml` में किसी भी पंक्त
 | red द्वार | `tools/pre-execute` वॉटरफ़ॉल — कार्यान्वयन संपादनों से पहले असफल-परीक्षण प्रमाण की कड़ी जाँच |
 | अनुस्मारक इंजेक्शन | `tools/post-execute` वॉटरफ़ॉल — `additionalContexts` → `user/message` के रूप में दर्ज |
 | green द्वार | `agent/turn-stopping` serial — जब संपादनों में पास होने वाला परीक्षण न हो तो समापन अनुस्मारक इंजेक्ट करता है |
-| विरोधी-समीक्षा | `ctx.subagents.start()` — forked critic with structured findings schema, injected at green; `warn`/`block` steer one round |
-| डिलीवरी रिपोर्ट | `doublecheck_report` tool — session-log fold + workspace markdown |
-| सत्यापन वर्कफ़्लो | `ctx.workflowEngine.start()` — one parallel checker per spec dimension, structured checks |
-| टिकाऊ स्थिति | session log fold over `tool/call` + `tool/result` + `tool/code-dispatch` + injected structured sources; model-visible ⟺ logged |
-| आंतरिक इवेंट | `doublecheck/spec`, `doublecheck/reminder`, `doublecheck/review`, `doublecheck/report` (typed via declaration merging, `@mode emit`) |
+| विरोधी-समीक्षा | `ctx.subagents.start()` — संरचित findings schema वाला forked आलोचक, green पर इंजेक्ट; `warn`/`block` एक राउंड steer करते हैं |
+| डिलीवरी रिपोर्ट | `doublecheck_report` टूल — सेशन-लॉग fold + वर्कस्पेस markdown |
+| सत्यापन वर्कफ़्लो | `ctx.workflowEngine.start()` — प्रति spec आयाम एक समानांतर जाँचकर्ता, संरचित जाँचें |
+| टिकाऊ स्थिति | `tool/call` + `tool/result` + `tool/code-dispatch` + इंजेक्टेड संरचित स्रोतों पर सेशन-लॉग fold; model-visible ⟺ logged |
+| सेशन कमांड | `ctx.commands.register()` — `/doublecheck status|report|on|off`; `on|off` टिकाऊ `doublecheck/state` सेशन इवेंट लिखता है |
+| आंतरिक इवेंट | `doublecheck/spec`, `doublecheck/reminder`, `doublecheck/review`, `doublecheck/report` (declaration merging से typed, `@mode emit`) |
 
 agent-loop में कोई बदलाव नहीं। हर पंजीकरण प्रतिवर्ती `ctx.effect` / `ctx.on` / सेवा `register()` है।
 
@@ -228,10 +250,23 @@ agent-loop में कोई बदलाव नहीं। हर पंज
 - अनुस्मारक `{kind:'plugin'}` संदर्भ के रूप में आते हैं, इसलिए ट्रांसक्रिप्ट UI उन्हें इंजेक्शन मेटाडेटा के रूप में दिखाते हैं।
 - आलोचक के स्थिर होने के बाद विरोधी-आलोचना उसी तरह आती है, गंभीरता-टैग वाले निष्कर्षों के साथ; `warn`/`block` के तहत चक्र एक राउंड चलाया जाता है ताकि मॉडल उनका उत्तर दे।
 - `doublecheck_report` समेकित रिपोर्ट को टूल परिणाम के रूप में लौटाता है (spec, परीक्षण समयरेखा, समीक्षा, सत्यापन, निर्णय), इसलिए «डिलीवरी साबित करना» एक कॉल की दूरी पर है।
+- `/doublecheck` ट्रांसक्रिप्ट में सीधे उत्तर देता है: `status` स्विच, मॉड्यूल, तीव्रता और चरण-तथ्य दिखाता है, `report` folded रिपोर्ट छापता है, `on|off` सेशन स्विच बदलता है।
+
+## सेशन कमांड
+
+```
+/doublecheck status|report|on|off
+```
+
+- `status` — प्रभावी स्विच (टिकाऊ ओवरराइड कॉन्फ़िगरेशन डिफ़ॉल्ट से ऊपर), कॉन्फ़िगर किए मॉड्यूल, प्रवर्तन-तीव्रता और folded चरण-तथ्य (spec दर्ज, red/green रंग, समीक्षा दर्ज, संपादन-संख्या)।
+- `report` — सेशन लॉग से डिलीवरी रिपोर्ट वहीं fold करता है (कोई सत्यापन वर्कफ़्लो नहीं; वह रास्ता `doublecheck_report` टूल का है)।
+- `on` / `off` — टिकाऊ `doublecheck/state` इवेंट लिखता है (रीस्टार्ट, रिज़्यूम और फ़ॉर्क के बाद भी बचा रहता है — replay ही state है) और मॉडल-दृश्य स्विच सूचना इंजेक्ट करता है।
+
+सभी कमांड उत्तर guard पंक्ति की `language` सेटिंग का सम्मान करते हैं।
 
 ## रोडमैप
 
-छह-चरणीय अनुशासन-चक्र पूर्ण है: **grill → design → red → green → review → verify** — सभी इस पैकेज में शिप होते हैं (v0.1 → v0.4)। भावी कार्य: review/रिपोर्ट ट्रांसक्रिप्ट के लिए snapshot कवरेज और समृद्ध रिपोर्ट फ़ॉर्मेटिंग।
+छह-चरणीय अनुशासन-चक्र पूर्ण है: **grill → design → red → green → review → verify** — सभी इस पैकेज में शिप होते हैं (v0.1 → v0.6)। वास्तविक-ट्रांसक्रिप्ट रिग्रेशन फ़िक्स्चर टिकाऊ इवेंट आकारों को पिन करते हैं (`tests/fixtures/`)। भावी कार्य: समृद्ध रिपोर्ट फ़ॉर्मेटिंग, एक Web-UI अनुशासन-स्थिति बैज, और वर्कस्पेस spec फ़ाइल से क्रॉस-सेशन spec सीडिंग।
 
 ## विकास
 

package/README.md

@@ -2,7 +2,8 @@
 
 > **Double-check before you ship: grill the requirements, test the implementation, prove the delivery.**
 
-[![version](https://img.shields.io/badge/version-0.5.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![version](https://img.shields.io/badge/version-0.6.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![npm](https://img.shields.io/npm/v/dsh-doublecheck)](https://www.npmjs.com/package/dsh-doublecheck)
 [![license](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
 [![topics](https://img.shields.io/badge/topics-dsh%20%7C%20dsh--plugin-22c55e)](https://github.com/topics/dsh-plugin)
 [![CI](https://img.shields.io/github/actions/workflow/status/PerryLink/dsh-doublecheck/ci.yml?branch=main)](https://github.com/PerryLink/dsh-doublecheck/actions/workflows/ci.yml)
@@ -36,20 +37,23 @@ grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶
 | **review** | A forked adversary critic audits the delivery against the spec. | ✅ v0.3 |
 | **verify** | `doublecheck_report` + a per-dimension verification workflow prove the delivery. | ✅ v0.4 |
 
-## Features (v0.5)
+## Features
 
 - 🔥 **`grill-requirements` skill** — a bundled Agent-Skills-format skill that interrogates the task across six dimensions (**goal, scope, acceptance criteria, failure modes, priorities, non-goals**) using DSH's native `ask_user_question` UI, refuses to write code until consensus, and records the contract.
 - 🧰 **Stage skills for the whole loop** — `red-green-tdd` (write the failing test, run red, implement, run green), `delivery-review` (adversarial self-review against the spec once green), and `delivery-proof` (consolidate the evidence into the delivery report before claiming completion) join `grill-requirements`, so all six stages have model guidance, not just the first.
-- 📜 **`doublecheck_spec` tool** — commits the grilled spec to the session log and writes a markdown copy to the workspace, so the contract survives the conversation.
+- 📜 **`doublecheck_spec` tool** — commits the grilled spec to the session log and writes a markdown copy to the workspace, so the contract survives the conversation. Empty or whitespace-only dimensions are rejected at the commit (v0.6): the grill must settle all six before the spec counts.
 - 🔄 **Task-change re-grill** — a committed spec covers its own task: a new direct-user request after the latest spec commit reopens the grill gate for that follow-up instead of silently inheriting the old contract.
 - 🛡️ **Discipline guard** — a soft gate on the tool policy pipeline. Vague task + no spec + heading for `edit`/`write` → **remind**, **hold for human approval**, or **block**, depending on `intensity`.
-- 🟥🟩 **Red/green evidence gates** (`modules.tdd`) — hard checks over the session log: an implementation edit requires a **failing test run on record** since the last passing run (writing test files is always allowed — that is how the red step happens), and a turn that ends with edits but no passing run gets a green reminder injected.
-- 👁️ **Adversary review** (`modules.adversary`) — once the delivery reaches green, a forked critic subagent (DSH's native subagent seam, default `fork` provider) audits the session against the committed spec with an adversarial stance and returns structured findings. `remind` injects the critique; `warn`/`block` additionally steer one round to make the model answer the findings. `adversaryModel` routes the critic to a separate model; the critic's tool allowlist is read-only by default. Findings ride the durable `doublecheck-review` message source. The review re-arms after the critic settles: implementation edits after the latest review record trigger another round, and cancelling the turn aborts the in-flight critic.
+- 🟥🟩 **Red/green evidence gates** (`modules.tdd`) — hard checks over the session log: an implementation edit requires a **failing test run on record** since the last passing run (writing test files is always allowed — that is how the red step happens), and a turn that ends with edits but no passing run gets a green reminder injected. Custom guard tools work out of the box: the gates read both `file_path` and `path` argument keys, and a call that names no file at all is not treated as an implementation edit.
+- 👁️ **Adversary review** (`modules.adversary`) — once the delivery reaches green, a forked critic subagent (DSH's native subagent seam, default `fork` provider) audits the session against the committed spec with an adversarial stance and returns structured findings, sorted blocker-first. `remind` injects the critique; `warn`/`block` additionally steer one round to make the model answer the findings. `adversaryModel` routes the critic to a separate model; the critic's tool allowlist is read-only by default. Findings ride the durable `doublecheck-review` message source. The review re-arms after the critic settles: implementation edits after the latest review record trigger another round, and cancelling the turn aborts the in-flight critic.
+- 🌐 **Fully localized model surface** — every model-visible string the package injects or answers with (reminders, deny/ask feedback, review steering, switch notices, `/doublecheck` replies, and the critic's task prompt) honors `language: 'en' | 'zh'`; the workspace spec/report documents keep their stable English headings.
 - 📊 **Doublecheck report + verification workflow** (`doublecheck_report`, v0.4) — consolidates the session's discipline evidence (spec, red/green timeline, review findings, edits) into a delivery report with a derived verdict (`grill → draft → red → green → objections/verified → proven/challenged/unverified`), written to the workspace. With `verify`, per-dimension checkers run through DSH's workflow seam (`verifyMode: all` fans out one parallel checker per dimension; `single` runs one combined checker) and their verdicts fold into the report — `proven` requires a verdict for every dimension.
 - 🚦 **Delivery gate** — at the turn boundary, a delivery that reached green with no `doublecheck_report` on record gets a report-expected reminder before completion claims; a successful report advances the stage fold to `verify`.
-- 🔁 **Durable state** — every model-visible artifact (spec, reminders, deny feedback, review findings, the `/doublecheck on|off` switch) lands in the session log; gate decisions derive from the log alone (`tool/call` + `tool/result`, including Code Mode sub-dispatches), so resumed and forked sessions enforce identically. `remindOnce` is durable too: a session that already received a reminder never gets it twice, even after a restart.
-- ⌨️ **`/doublecheck` session command** — `status` reports the effective switch, the configured modules, and the folded stage; `report` folds the delivery report on the spot; `on|off` writes the durable `doublecheck/state` override and injects a switch notice.
+- 🔁 **Durable state** — every model-visible artifact (spec, reminders, deny feedback, review findings, the `/doublecheck on|off` switch) lands in the session log; gate decisions derive from the log alone (`tool/call` + `tool/result`, including Code Mode sub-dispatches), so resumed and forked sessions enforce identically. `remindOnce` is durable too: a session that already received a reminder never gets it twice, even after a restart. The switch fold rides an incremental snapshot, so long sessions stay O(new events) per tool call.
+- ⌨️ **`/doublecheck` session command** — `status` reports the effective switch, the configured modules, the enforcement intensity, and the folded stage facts (spec, test color, review, edit count); `report` folds the delivery report on the spot; `on|off` writes the durable `doublecheck/state` override and injects a switch notice.
 - 📚 **`doublecheck_skills` tool** — lists and loads the package's skills through the official skill registry seam.
+- 🔒 **Strict overlay** — `strict.patch.yml` turns every gate on at `block` intensity in one patch layer (ships with the package).
+- 🧩 **Standalone invariant companion** — the `dsh-doublecheck/invariant` row is a real subpath export: it reports package-owned write-path contradictions (spec/report/review shape) through the host `invariants` registry without loading the guard.
 
 ## Demo
 
@@ -77,13 +81,19 @@ Both plugin rows activate automatically with the profile. Tarball installs work
 
 ```sh
 pnpm pack
-dsh plugin --profile <name> add ./dsh-doublecheck-0.5.0.tgz
+dsh plugin --profile <name> add ./dsh-doublecheck-0.6.0.tgz
 ```
 
 Git installs need no npm:
 
 ```sh
-dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.5.0"
+dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.6.0"
+```
+
+For a zero-configuration strict mode (every gate on, `block` intensity), apply the shipped overlay on top of the bundle patch:
+
+```sh
+dsh --profile <name> --patch ./node_modules/dsh-doublecheck/strict.patch.yml
 ```
 
 ## Uninstall
@@ -132,6 +142,7 @@ Override any row **by id** in the profile's `cordis.patch.yml`. A patch replaces
       - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
     reportMutationTools: ['edit', 'write']
     reportTestFilePatterns:
       - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
@@ -157,11 +168,14 @@ Override any row **by id** in the profile's `cordis.patch.yml`. A patch replaces
       - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
       - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
     testFilePatterns:
       - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
       - '\\.(test|spec)\\.[A-Za-z0-9]+$'
 ```
 
+The shipped `strict.patch.yml` is exactly this guard row at `intensity: block` with every module on — apply it as a patch layer after the bundle patch for strict mode without hand-editing a profile.
+
 ### `intensity`
 
 | Value | Behavior on a gated `edit`/`write` |
@@ -183,7 +197,7 @@ Override any row **by id** in the profile's `cordis.patch.yml`. A patch replaces
 | `vagueTaskMaxChars` | `200` | Longer tasks are never treated as vague. Brief tasks naming a file, path, URL, an underscore keyword, or a hyphenated keyword are concrete. |
 | `remindOnce` | `true` | Inject each gate's reminder at most once per session — durable across restarts (folded from the log). |
 | `testToolNames` | `['bash', 'pwsh']` | Shell tool names that can run tests. |
-| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test)* | Regexes a command must match to count as a test run. |
+| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test, deno test, uv run pytest)* | Regexes a command must match to count as a test run. |
 | `testFilePatterns` | *(test dirs, `*.test.*` / `*.spec.*`)* | Regexes identifying test files — always editable, exempt from the red gate. |
 | `adversaryModel` | `null` | Critic model route; `null` = main model self-reviews. |
 | `adversaryProvider` | `'fork'` | Subagent provider name the critic runs on. |
@@ -233,7 +247,7 @@ No agent-loop changes. Every registration is a reversible `ctx.effect` / `ctx.on
 - Reminders arrive as `{kind:'plugin'}` context, so transcript UIs present them as injection metadata.
 - The adversary critique arrives the same way after the critic settles, with severity-tagged findings; under `warn`/`block` the loop is steered one round so the model answers them.
 - `doublecheck_report` returns the consolidated report as a tool result (spec, test timeline, review, verification, verdict), so "prove the delivery" is one call away.
-- `/doublecheck` answers in the transcript directly: `status` shows the switch/modules/stage, `report` prints the folded report, `on|off` flips the session switch.
+- `/doublecheck` answers in the transcript directly: `status` shows the switch, modules, intensity, and stage facts, `report` prints the folded report, `on|off` flips the session switch.
 
 ## Session command
 
@@ -241,13 +255,15 @@ No agent-loop changes. Every registration is a reversible `ctx.effect` / `ctx.on
 /doublecheck status|report|on|off
 ```
 
-- `status` — effective switch (durable override beats the config default), configured modules, and the folded stage (spec committed, red/green color, review on record).
+- `status` — effective switch (durable override beats the config default), configured modules, enforcement intensity, and the folded stage facts (spec committed, red/green color, review on record, edit count).
 - `report` — folds the delivery report from the session log on the spot (no verification workflow; `doublecheck_report` owns that path).
 - `on` / `off` — writes the durable `doublecheck/state` event (survives restart, resume, and fork — replay IS the state) and injects a model-visible switch notice.
 
+All command replies honor the guard row's `language` setting.
+
 ## Roadmap
 
-The six-stage discipline loop is complete: **grill → design → red → green → review → verify** all ship in this package (v0.1 → v0.5). Real-transcript regression fixtures pin the durable event shapes (`tests/fixtures/`). Future work: richer report formatting, a Web-UI discipline-status badge, and cross-session spec seeding from the workspace file.
+The six-stage discipline loop is complete: **grill → design → red → green → review → verify** all ship in this package (v0.1 → v0.6). Real-transcript regression fixtures pin the durable event shapes (`tests/fixtures/`). Future work: richer report formatting, a Web-UI discipline-status badge, and cross-session spec seeding from the workspace file.
 
 ## Develop