dsh-doublecheck 0.6.0 → 0.7.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,28 @@
2
2
 
3
3
  All notable changes to dsh-doublecheck are recorded here, newest first.
4
4
 
5
+ ## v0.7.1 — 2026-08-19
6
+
7
+ ### Fixed
8
+
9
+ - **Invariant companion survives hot-reload**: the guard's inline invariant registration now holds the host registry's disposer through the inject scope's `ctx.effect` (the registry binds its own effect to the service context, so the returned disposer is the only unregistration path). Disposing the guard fiber — config hot-reload, profile disable — unregisters the companion and its `doublecheck/*` listeners; remounting re-registers cleanly instead of throwing `package "dsh-doublecheck" is already registered`. Regression covered by a dispose-and-remount lifecycle test against a duplicate-strict registry.
10
+
11
+ ## v0.7.0 — 2026-08-16
12
+
13
+ The delivery quality gate release: the discipline loop grows a productized front panel that aggregates the session's durable evidence into one **deliverable / rework required** decision.
14
+
15
+ - **Delivery quality gate** (`/gate status|run|config`): a configurable four-phase checklist — **requirements interrogation** (a key-question checklist confirmed item by item against the committed spec), **test evidence** (latest run color, failing runs after green, and an optional coverage threshold parsed from test output), **implementation consistency** (a local forked reviewer maps diffs to spec dimensions), and the **review conclusion** — folded from the durable session log. One binary decision with red items, rework suggestions, and a PR-ready markdown report (`gate-report.md` + the durable `doublecheck/gate` session event, `ignorable`-stamped).
16
+ - **dsh-auto-review weak dependency**: `gate.review.engine: auto` consumes the engine's durable `autoReview/verdict` / `autoReview/rejection` records when they exist (rejections become red lights), and degrades to the local forked reviewer with an honest warn note — "not installed" vs "installed but has no verdict records in this session" (detected structurally plus a `ctx.commands.list()` presence probe; no import, no hard dependency). `engine: local` always reviews locally. The gate never synthesizes approval requests.
17
+ - **Plan-mode integration**: a rework verdict suggests re-opening the work in plan mode — in the report banner, on the `/gate status` panel line (reading the optional `ctx.planMode` service), and in a once-per-session short turn notice riding the new `doublecheck-gate` message source (`doublecheck/reminder` gate `'gate'`, verdict `'gate-red'`).
18
+ - **Pluggable checklist (Schema config)**: `gate.requirements.checklist` is a Schema-validated array (`id` / `question` / `specDimension` / `required`), every phase has an `enabled` switch, and the thresholds and reviewer knobs are config keys; validated fail-loud at load (duplicate ids, unknown dimensions, bad regexes, empty tool lists throw) and exposed through the **`doublecheck.gate` settings namespace** (`expose: true`, `applies: restart`) when the harness settings service is mounted.
19
+ - **Audit-safe reports**: gate reports embed counts, ids, and verdicts only — no file contents or session text. Model-produced finding texts pass a secret redactor (cloud keys, GitHub/OpenAI/Slack tokens, bearer tokens, private-key blocks, password assignments, long hex/base64 runs) before storage or display.
20
+ - **Panel surfaces**: `/gate status` renders the live deterministic phases plus the latest settled run (verdict, red count, engine, timestamp); the `doublecheck` session projection now carries `gateVerdict` + `gateRedCount` (stateVersion 2); `/doublecheck status` shows the latest gate verdict; the four-phase progress doubles as the in-conversation card.
21
+ - **Short role-statement prose**: the gate-red turn notice and the consistency reviewer task open with a one-sentence role statement and stay short (Minimal-persona style); `en` / `zh` localized.
22
+ - **Invariant companion + skills**: the invariant now checks the `doublecheck/gate` announcement (verdict re-derivation, all four phases present); the `delivery-proof` skill routes the model through `/gate run` before completion claims; `strict.patch.yml` restates the full gate block with `requireCoverage: true`.
23
+ - **OMDSH Workshop intake manifest**: `package.json#dshWorkshop` (`omdsh-workshop-package/v1`) declares the transactional `harness-profile` integration, lifecycle, permissions, and the named runtime capability (`/gate status`) for the hub.omdsh.dev Registry intake. Author-declared facts only — verification evidence stays pending until the Workshop adapter run produces it.
24
+ - **Community engineering**: structured issue forms (bug report / feature request), a pull-request checklist template, a security policy with private vulnerability reporting, GitHub Discussions enabled (welcome post), main-branch CI status protection, npm downloads badge, and a Contributors section across the five READMEs.
25
+ - **CI profile smoke**: a `smoke` job packs the bundle, installs it into a scratch profile with the real `dsh` CLI, and asserts both rows mount (`scripts/assert-profile.mjs`) — the end-to-end check for `cordis.patch.yml` that unit tests cannot see. Ported from PR #1, which this closes.
26
+
5
27
  ## v0.6.0 — 2026-08-14
6
28
 
7
29
  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.
package/README.es.md CHANGED
@@ -1,279 +1,258 @@
1
+ <div align="center">
2
+
1
3
  # dsh-doublecheck
2
4
 
3
- > **Verifica dos veces antes de publicar: interroga los requisitos, prueba la implementación, demuestra la entrega.**
5
+ **La puerta de calidad de entrega para DeepSeek Harness: interroga los requisitos, prueba la implementación, demuestra la entrega — y controla el traspaso con una decisión de entregable / rehacer.**
4
6
 
5
- [![version](https://img.shields.io/badge/version-0.6.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
6
- [![npm](https://img.shields.io/npm/v/dsh-doublecheck)](https://www.npmjs.com/package/dsh-doublecheck)
7
- [![license](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
8
- [![topics](https://img.shields.io/badge/topics-dsh%20%7C%20dsh--plugin-22c55e)](https://github.com/topics/dsh-plugin)
7
+ *Los requisitos se interrogan antes de la primera edición; la entrega se demuestra, nunca se afirma.*
9
8
 
10
- Un **bundle de disciplina de ingeniería** para [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness). A los agentes les encanta empezar a programar; los requisitos odian que se los dé por sentados. `dsh-doublecheck` instala un bucle de disciplina que obliga al agente a **interrogar los requisitos antes de la primera edición y a demostrar la entrega en lugar de afirmarla** — reimplementado de forma nativa sobre los puntos de extensión propios de DSH (registro de skills, pipeline de políticas de herramientas, seam de aprobación, seams de subagente y workflow, registro de sesión), no sobre archivos de prompt prestados. Probado contra DSH `0.1.0-rc.6`.
9
+ [![License](https://img.shields.io/badge/license-Apache%202.0-blue.svg)](LICENSE)
10
+ [![DSH plugin](https://img.shields.io/badge/dsh-plugin-✅-green)](https://github.com/topics/dsh-plugin)
11
+ [![Node](https://img.shields.io/badge/node-%5E22.19%20%7C%7C%20%3E%3D24-brightgreen.svg)](#)
12
+ [![CI](https://img.shields.io/github/actions/workflow/status/PerryLink/dsh-doublecheck/ci.yml?branch=main&label=CI)](https://github.com/PerryLink/dsh-doublecheck/actions)
13
+ [![Version](https://img.shields.io/github/v/tag/PerryLink/dsh-doublecheck?label=version)](https://github.com/PerryLink/dsh-doublecheck/releases)
14
+ [![npm version](https://img.shields.io/npm/v/dsh-doublecheck)](https://www.npmjs.com/package/dsh-doublecheck)
15
+ [![npm downloads](https://img.shields.io/npm/dm/dsh-doublecheck)](https://www.npmjs.com/package/dsh-doublecheck)
11
16
 
12
- La metodología está inspirada en [obra/superpowers](https://github.com/obra/superpowers) y [TimothyVang/Grill-me](https://github.com/TimothyVang/Grill-me). Todos los prompts, términos, ejemplos y archivos de este paquete están escritos desde cero: nada se copia de ninguno de los dos proyectos.
17
+ [English](README.md) · [简体中文](README.zh.md) · [Español](README.es.md) · [Português](README.pt.md) · [हिन्दी](README.hi.md)
13
18
 
14
- ## Por qué
19
+ </div>
15
20
 
16
- - Las tareas vagas producen software equivocado. Una petición breve («hazme una función») esconde seis decisiones sin resolver; hoy el agente las adivina todas y tú pagas por la suposición.
17
- - Los equipos disciplinados hacen esto con humanos: revisión de requisitos → prueba que falla → prueba que pasa → autorrevisión → prueba de entrega. Los agentes merecen el mismo bucle, impuesto por el harness y no por la buena voluntad.
21
+ ---
18
22
 
19
- ## El bucle de disciplina
23
+ ## Compatibilidad
20
24
 
21
- ```
22
- grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶ verify
23
- │ │
24
- │ (v0.1) (v0.2+) (v0.3) (v0.4)
25
- │
26
- └─ horno de requisitos: seis dimensiones, puerta de consenso,
27
- spec estructurado guardado en la sesión y en el workspace
28
- ```
25
+ | Superficie | Estado |
26
+ |---|---|
27
+ | Harness | DeepSeek Harness `0.1.0-rc.6` |
28
+ | Node | `^22.19.0 \|\| >=24.0.0` |
29
+ | Plataformas | Todas (host puro; sin código nativo, sin solicitudes de red directas propias) |
30
+ | Modelo | Cualquiera (el guard nunca llama a un modelo; las fases de crítico y revisor se ejecutan como subagentes del harness) |
29
31
 
30
- | Etapa | Significado | Estado |
31
- |---|---|---|
32
- | **grill** | Interrogar las seis dimensiones de requisitos; negarse a implementar hasta el consenso. | ✅ v0.1 |
33
- | **design** | Spec registrado con `doublecheck_spec`. | ✅ v0.1 |
34
- | **red** | Una prueba que falla demuestra el hueco; las ediciones de implementación necesitan tenerla registrada. | ✅ v0.2 |
35
- | **green** | Una prueba que pasa tras las ediciones cierra el bucle. | ✅ v0.2 |
36
- | **review** | Un crítico adversario bifurcado audita la entrega contra el spec. | ✅ v0.3 |
37
- | **verify** | `doublecheck_report` + un workflow de verificación por dimensión demuestran la entrega. | ✅ v0.4 |
38
-
39
- ## Funciones
40
-
41
- - 🔥 **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.
42
- - 🧰 **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.
43
- - 📜 **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.
44
- - 🔄 **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.
45
- - 🛡️ **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`.
46
- - 🟥🟩 **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.
47
- - 👁️ **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.
48
- - 🌐 **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.
49
- - 📊 **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.
50
- - 🚦 **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`.
51
- - 🔁 **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.
52
- - ⌨️ **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.
53
- - 📚 **Herramienta `doublecheck_skills`** — lista y carga los skills del paquete a través del seam oficial del registro de skills.
54
- - 🔒 **Overlay estricto** — `strict.patch.yml` activa todas las puertas con intensidad `block` en una sola capa de patch (se incluye con el paquete).
55
- - 🧩 **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.
56
-
57
- ## Demo
58
-
59
- Una ejecución headless real con `intensity: block` y todas las puertas habilitadas, transcripción registrada desde el registro de sesión duradero:
32
+ ## Qué obtienes
60
33
 
61
- ```sh
62
- dsh --profile demo headless "把这个项目里最慢的代码直接改快,别问我任何问题,直接改文件。"
63
- ```
34
+ `dsh-doublecheck` instala dos filas de plugin que leen y aplican desde el mismo registro de sesión durable:
64
35
 
65
- 1. **grill** bloquea la primera edición — no hay spec registrado:
66
- `Error: Blocked by the dsh-doublecheck requirements guard: the task statement is vague and no doublecheck_spec exists for this session.`
67
- 2. El modelo registra el spec (`doublecheck_spec`), escribe una prueba que falla (los archivos de prueba siempre son editables) y la ejecuta — el registro anota `[exit code: 1]`, el paso red.
68
- 3. Las ediciones de implementación ahora pasan; una ejecución posterior anota `4 passed`, el paso green.
69
- 4. El crítico bifurcado audita la entrega; sus hallazgos etiquetados por severidad se inyectan, y `warn`/`block` dirigen una ronda para que el modelo les responda.
70
- 5. `doublecheck_report` pliega todo en un informe markdown con un veredicto derivado — `proven` cuando todas las comprobaciones de verificación por dimensión pasan, `challenged` cuando un verificador objeta.
36
+ 1. **`doublecheck-grill`** — el horno de requisitos: la skill empaquetada `grill-requirements` más las herramientas orientadas al modelo `doublecheck_skills`, `doublecheck_spec` y `doublecheck_report`, y el flujo de verificación por dimensión.
37
+ 2. **`doublecheck-guard`** — el guard de disciplina: la puerta grill, las puertas de evidencia rojo/verde, la revisión adversarial, los comandos `/doublecheck` y `/gate`, el espacio de ajustes `doublecheck.gate` y la puerta de entrega de cuatro fases.
71
38
 
72
- ## Instalación
39
+ Juntos imponen el **bucle de disciplina** — *grill → design → red → green → review → verify*:
73
40
 
74
- ```sh
75
- dsh plugin --profile <name> add dsh-doublecheck
76
- dsh --profile <name> --dump-config # espera una capa "# == dsh-doublecheck"
41
+ ```text
42
+ grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶ verify
43
+ │
44
+ └─ seis dimensiones de requisitos, puerta de consenso,
45
+ spec estructurado confirmado en la sesión + el workspace
77
46
  ```
78
47
 
79
- Ambas filas de plugin se activan automáticamente con el profile. También sirve instalar desde tarball:
80
-
81
- ```sh
82
- pnpm pack
83
- dsh plugin --profile <name> add ./dsh-doublecheck-0.6.0.tgz
84
- ```
48
+ | Etapa | Significado |
49
+ |---|---|
50
+ | **grill** | Interroga las seis dimensiones de requisitos; se niega a implementar hasta el consenso. |
51
+ | **design** | El spec acordado se confirma mediante `doublecheck_spec`. |
52
+ | **red** | Una ejecución de prueba fallida demuestra la brecha antes de las ediciones de implementación. |
53
+ | **green** | Una ejecución de prueba aprobada tras las ediciones cierra el bucle. |
54
+ | **review** | Un crítico adversarial bifurcado audita la entrega contra el spec. |
55
+ | **verify** | `doublecheck_report` + un flujo de verificación por dimensión demuestran la entrega. |
85
56
 
86
- La instalación por git no necesita npm:
57
+ ## Inicio rápido
87
58
 
88
59
  ```sh
89
- dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.6.0"
90
- ```
60
+ # 1. install the bundle into your profile
61
+ dsh plugin --profile web add "github:PerryLink/dsh-doublecheck#main"
91
62
 
92
- Para un modo estricto sin configuración (todas las puertas activas, intensidad `block`), aplica el overlay incluido encima del bundle patch:
63
+ # or from npm (published releases)
64
+ dsh plugin --profile web add dsh-doublecheck
93
65
 
94
- ```sh
95
- dsh --profile <name> --patch ./node_modules/dsh-doublecheck/strict.patch.yml
66
+ # 2. restart and verify the row
67
+ dsh --profile web --dump-config | grep -E -A3 'id: doublecheck-(grill|guard)'
96
68
  ```
97
69
 
98
- ## Desinstalación
70
+ Ambas filas (`doublecheck-grill` y `doublecheck-guard`) se activan automáticamente con el perfil.
99
71
 
100
- ```sh
101
- dsh plugin --profile <name> remove dsh-doublecheck
102
- ```
72
+ ## Instalación y desinstalación
103
73
 
104
- Para mantener el paquete pero desactivar una fila: sobrescríbela por id con `disabled: true` en el `cordis.patch.yml` del profile (`doublecheck-grill` / `doublecheck-guard`).
74
+ - **canal git** (última `main`): `dsh plugin --profile web add "github:PerryLink/dsh-doublecheck#main"` — el script `prepare` compila solo con dependencias de producción.
75
+ - **canal npm** (versiones publicadas): `dsh plugin --profile web add dsh-doublecheck`.
76
+ - **canal tarball**: `pnpm pack` en este repo y luego `dsh plugin --profile web add ./dsh-doublecheck-<version>.tgz`.
77
+ - **desinstalar**: `dsh plugin --profile web remove dsh-doublecheck` (o elimina las filas del parche de perfil).
105
78
 
106
- ## Compatibilidad
79
+ Para un modo estricto sin configuración (cada puerta activa con intensidad `block`, cobertura de la puerta requerida), aplica la capa superpuesta incluida sobre el parche del bundle: `dsh --profile web --patch ./node_modules/dsh-doublecheck/strict.patch.yml`.
107
80
 
108
- - Verificado contra los peers `0.1.0-rc.6` (`@deepseek-ai/cordis ^4.0.1`); última verificación 2026-08-14 (Windows + Node 22).
109
- - El interruptor de sesión durable (`/doublecheck on|off` → `doublecheck/state`) necesita la superficie de escritura `ignorable` del host (harness posterior a rc.6): los hosts rc.6 ignoran el options bag y el evento queda required-on-read, así que allí prefiere el cambio en memoria hasta actualizar el harness.
81
+ ## Configuración
110
82
 
111
- ## Permisos y datos
83
+ Todos los ajustes son campos `Config` de Schemastery (modificables desde cordis.yml). Una sobrescritura dirigida por id reemplaza la fila completa — vuelve a declarar cada clave que necesites. `cordis.patch.yml` documenta cada clave en línea; los valores por defecto del Schema son la única fuente de los valores de ajuste.
112
84
 
113
- - **Lee**: solo en proceso el registro de sesión (`tool/call` / `tool/result` / `tool/code-dispatch` y fuentes `user/message` inyectadas).
114
- - **Escribe**: `doublecheck-spec.md` y `doublecheck-report.md` en el workspace de la sesión (rutas configurables), vía el seam `ctx.fs`.
115
- - **Llamadas al modelo**: solo la revisión adversaria opcional (`modules.adversary`, off por defecto) y el workflow de verificación de `doublecheck_report` (on por defecto) lanzan subagentes; nada más llama al modelo o a la red.
116
- - **Nunca toca**: credenciales, variables de entorno ni archivos fuera del workspace de la sesión.
85
+ | Clave | Predeterminado | Significado |
86
+ |---|---|---|
87
+ | `specFile` | `'doublecheck-spec.md'` | Archivo del workspace para el markdown del spec confirmado (fila grill). |
88
+ | `reportFile` | `'doublecheck-report.md'` | Archivo del workspace para el informe de entrega (fila grill). |
89
+ | `reportVerify` | `true` | Ejecutar el flujo de verificación por defecto (fila grill). |
90
+ | `verifyProvider` | `'fork'` | Proveedor de subagente para los verificadores por dimensión (fila grill). |
91
+ | `verifyMode` | `'all'` | `all` = un verificador paralelo por dimensión; `single` = un verificador combinado (fila grill). |
92
+ | `intensity` | `'remind'` | Fuerza de aplicación de las puertas grill, rojo/verde y de revisión (`remind` / `warn` / `block`). |
93
+ | `enableByDefault` | `true` | Interruptor maestro para sesiones sin registro `/doublecheck on\|off`. |
94
+ | `language` | `'en'` | Idioma de la prosa inyectada de recordatorio/denegación/revisión/puerta (`en` / `zh`). |
95
+ | `guardTools` | `['edit', 'write']` | Nombres de herramientas de mutación que vigilan ambas puertas. |
96
+ | `vagueTaskMaxChars` | `200` | Las tareas más largas nunca se tratan como vagas. |
97
+ | `remindOnce` | `true` | Inyecta cada recordatorio como máximo una vez por sesión (durable entre reinicios). |
98
+ | `testToolNames` | `['bash', 'pwsh']` | Nombres de herramientas shell que pueden ejecutar pruebas. |
99
+ | `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test, deno test, uv run pytest)* | Regex que un comando debe coincidir para contar como ejecución de prueba. |
100
+ | `testFilePatterns` | *(dirs de prueba, `*.test.*` / `*.spec.*`)* | Regex que identifican archivos de prueba — siempre editables, exentos de la puerta roja. |
101
+ | `modules.grill` | `true` | Apagado desactiva la puerta grill. |
102
+ | `modules.tdd` | `true` | Encendido habilita las puertas de evidencia rojo/verde. |
103
+ | `modules.adversary` | `false` | Encendido habilita la revisión de crítico bifurcado en verde. |
104
+ | `adversaryModel` | `null` | Ruta de modelo del crítico; `null` = el modelo principal se autorevisa. |
105
+ | `adversaryProvider` | `'fork'` | Proveedor de subagente sobre el que corre el crítico. |
106
+ | `adversaryMaxFindings` | `5` | Límite de hallazgos (1–20) inyectados en la sesión. |
107
+ | `adversaryTools` | `['read', 'glob', 'grep']` | Lista permitida de herramientas del crítico; mantenla de solo lectura. |
108
+ | `adversaryTimeoutMs` | `120000` | Presupuesto de tiempo duro para una ejecución del crítico. |
109
+ | `gate.enabled` | `true` | Interruptor maestro del panel de la puerta y el aviso rojo de límite de turno. |
110
+ | `gate.planSuggestion` | `true` | Añade la sugerencia de re-verificación en modo plan a los informes rojos. |
111
+ | `gate.reportFile` | `'gate-report.md'` | Archivo del workspace para el informe de la puerta. |
112
+ | `gate.requirements.checklist` | *(seis preguntas de dimensión de spec)* | Lista de preguntas clave enchufable: `{ id, question, specDimension, required }`. |
113
+ | `gate.requirements.minConfirmed` | `6` | Preguntas obligatorias mínimas que deben aprobar (1..cantidad obligatoria). |
114
+ | `gate.requirements.interrogateTool` | `'ask_user_question'` | Nombre de herramienta cuyas llamadas cuentan como evidencia de interrogatorio. |
115
+ | `gate.tests.requirePassingRun` | `true` | Una última ejecución de prueba no aprobada (o ausente) es una luz roja. |
116
+ | `gate.tests.allowFailingRuns` | `0` | Ejecuciones fallidas tras el último verde permitidas antes del rojo. |
117
+ | `gate.tests.requireCoverage` | `false` | Encendido exige evidencia de cobertura en la salida de prueba. |
118
+ | `gate.tests.minCoveragePct` | `80` | Porcentaje mínimo de cobertura (0–100). |
119
+ | `gate.consistency.*` | `provider: 'fork'`, `model: null`, `tools: ['read','glob','grep']`, `timeoutMs: 120000`, `maxFindings: 5` | Ajustes del revisor local de consistencia (`model: null` = modelo principal). |
120
+ | `gate.review.engine` | `'auto'` | `auto` = registros de veredicto de dsh-auto-review cuando están presentes, si no el revisor local; `local` = siempre local. |
121
+ | `gate.review.provider` | `'fork'` | Proveedor del revisor local de revisión (su `model`/`tools`/`timeoutMs`/`maxFindings` coinciden con `gate.consistency.*`). |
122
+
123
+ La mala configuración falla en voz alta al cargar: regex inválidas, listas de nombres vacías o duplicadas, umbrales fuera de rango e ids de lista duplicados lanzan error en lugar de no hacer nada en silencio. `strict.patch.yml` es la capa de todas las puertas en bloqueo que vuelve a declarar la fila guard con `intensity: block`, todos los módulos activos y el requisito de cobertura habilitado.
124
+
125
+ ## Herramientas y superficies
126
+
127
+ | Superficie | Tipo | Notas |
128
+ |---|---|---|
129
+ | `doublecheck_skills` | herramienta | Lista y carga las cuatro skills empaquetadas a través de la interfaz del registro de skills. |
130
+ | `doublecheck_spec` | herramienta | Confirma el spec de seis dimensiones en el registro de sesión y una copia markdown del workspace. |
131
+ | `doublecheck_report` | herramienta | Pliega la evidencia de disciplina en un informe de entrega (flujo de verificación por dimensión opcional). |
132
+ | `/doublecheck status\|report\|on\|off` | comando | Interruptor, módulos, intensidad, hechos de etapa, informe plegado y la sobrescritura durable on/off. |
133
+ | `/gate status\|run\|config` | comando | Progreso de la lista en vivo, el informe entregable/rehacer asentado y la configuración efectiva. |
134
+ | `grill-requirements`, `red-green-tdd`, `delivery-review`, `delivery-proof` | skill | Skills de disciplina empaquetadas que cubren las seis etapas del bucle. |
135
+ | `doublecheck.gate` | espacio de ajustes | La lista enchufable, expuesta a UIs con ajustes (`expose: true`, `applies: restart`). |
136
+ | `strict.patch.yml` | capa superpuesta | Cada puerta activa con intensidad `block` más el requisito de cobertura, en una capa de parche. |
137
+ | `dsh-doublecheck/invariant` | fila acompañante | Informa contradicciones de ruta de escritura propias del paquete a través del registro `invariants` del host. |
117
138
 
118
- ## Resolución de problemas
139
+ ## Fases de la puerta
119
140
 
120
- | Síntoma | Causa y solución |
121
- |---|---|
122
- | No aparece la capa `# == dsh-doublecheck` en `--dump-config` | Falta el bundle patch o una fila está `disabled` — revisa el orden de parches del profile y los ids de fila. |
123
- | Los gates nunca reaccionan | Ejecuta `/doublecheck status`: el interruptor de sesión puede estar apagado, o todos los `modules.*` están en false. |
124
- | "Adversary review did not run: the subagents seam is not mounted" | Esta composición de profile no provee subagentes — monta uno (las composiciones spine lo traen) o desactiva `modules.adversary`. |
125
- | `doublecheck_report` muestra `verification: null` | Falta el seam `workflowEngine` o el run fue rechazado/abortado — el informe lo indica en lugar de adivinar. |
126
- | El informe dice `unverified` | La verificación corrió pero no todas las dimensiones del spec devolvieron veredicto — reintenta con `verify: true`; `proven` exige las seis. |
141
+ La puerta de entrega agrega la evidencia durable de la sesión en una lista configurable de cuatro fases y asienta una decisión **entregable / rehacer requerido**. Cada fase pliega solo el registro de sesión (la reproducción ES el estado), por lo que una ejecución se vuelve a derivar idénticamente tras reanudar o bifurcar.
127
142
 
128
- ## Configuración
143
+ | Fase | Comprobaciones | Fuente de evidencia | Costo de modelo |
144
+ |---|---|---|---|
145
+ | Interrogatorio de requisitos | Lista de preguntas clave confirmadas una a una (seis preguntas de dimensión de spec por defecto) | `doublecheck_spec` confirmado + llamadas `ask_user_question` | ninguno |
146
+ | Evidencia de prueba | Color de la última ejecución, ejecuciones fallidas tras el verde, umbral de cobertura opcional | Ejecuciones de prueba shell en el registro de sesión (`[exit code: N]`, porcentajes de cobertura) | ninguno |
147
+ | Consistencia de implementación | Mapeo diff ↔ requisito: cada edición debe servir a una dimensión de spec | Revisor bifurcado local (hallazgos estructurados, herramientas de solo lectura) | un subagente |
148
+ | Conclusión de revisión | El veredicto de entrega; `engine: auto` consume los registros de veredicto durables de dsh-auto-review cuando están presentes, si no el revisor local | Eventos `autoReview/verdict` / `autoReview/rejection`, o el revisor bifurcado local | un subagente (local) |
129
149
 
130
- Sobrescribe cualquier fila **por id** en el `cordis.patch.yml` del profile. Un patch reemplaza toda la config de la fila — reescribe cada clave:
131
-
132
- ```yaml
133
- - id: doublecheck-grill
134
- config:
135
- specFile: 'specs/doublecheck-spec.md' # por defecto: 'doublecheck-spec.md'
136
- reportFile: 'specs/doublecheck-report.md' # por defecto: 'doublecheck-report.md'
137
- reportVerify: true # ejecutar el workflow de verificación por defecto
138
- verifyProvider: 'fork' # provider para los verificadores por dimensión
139
- reportTestToolNames: ['bash', 'pwsh']
140
- reportTestCommandPatterns:
141
- - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
142
- - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
143
- - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
144
- - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
145
- reportMutationTools: ['edit', 'write']
146
- reportTestFilePatterns:
147
- - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
148
- - '\\.(test|spec)\\.[A-Za-z0-9]+$'
149
-
150
- - id: doublecheck-guard
151
- config:
152
- intensity: warn
153
- modules:
154
- grill: true
155
- tdd: true # puertas de evidencia red/green (v0.2)
156
- adversary: true # revisión del crítico bifurcado (v0.3)
157
- adversaryModel: null
158
- adversaryProvider: 'fork' # provider de subagentes en el que corre el crítico
159
- adversaryMaxFindings: 5 # tope de hallazgos inyectados en la sesión
160
- adversaryTools: ['read', 'glob', 'grep'] # allowlist de herramientas del crítico (solo lectura)
161
- adversaryTimeoutMs: 120000 # presupuesto duro para una ejecución del crítico
162
- guardTools: ['edit', 'write']
163
- vagueTaskMaxChars: 200
164
- remindOnce: true
165
- testToolNames: ['bash', 'pwsh']
166
- testCommandPatterns:
167
- - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
168
- - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
169
- - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
170
- - '(?:^|[;&|]\s*)(?:deno\s+test|uv\s+run\s+pytest)(?:\s|$)'
171
- testFilePatterns:
172
- - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
173
- - '\\.(test|spec)\\.[A-Za-z0-9]+$'
174
- ```
150
+ Las luces rojas son comprobaciones fallidas (un spec ausente, una última ejecución fallida, cobertura bajo el mínimo, una edición sin mapear, hallazgos blocker/major) — cada una lleva una sugerencia de retrabajo. Las advertencias y los saltos nunca invierten la decisión. La puerta integra [dsh-auto-review](https://github.com/PerryLink/dsh-auto-review) como dependencia débil: `review.engine: auto` pliega sus registros de veredicto cuando están presentes y degrada al revisor local en caso contrario; la puerta nunca sintetiza solicitudes de aprobación.
175
151
 
176
- 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.
152
+ ## Informe de ejemplo
177
153
 
178
- ### `intensity`
154
+ `/gate run` devuelve este markdown — pégalo en la descripción de un PR:
179
155
 
180
- | Valor | Comportamiento ante un `edit`/`write` sujeto a la puerta |
181
- |---|---|
182
- | `remind` (por defecto) | La llamada sigue; un recordatorio viaja en el contexto del resultado hacia la siguiente petición del modelo. |
183
- | `warn` | La llamada queda retenida a la espera de aprobación humana única vía el seam de aprobación (deniega si no hay canal). |
184
- | `block` | La llamada se deniega con feedback que dirige al modelo a corregir primero la disciplina. |
156
+ ````markdown
157
+ # Delivery gate report
185
158
 
186
- ### Ajustes
159
+ > **Verdict: rework required** — 2 red item(s)
160
+ > The gate is red. Re-open the work in plan mode to re-check the open items before delivering.
187
161
 
188
- | Clave | Por defecto | Significado |
189
- |---|---|---|
190
- | `modules.grill` | `true` | En `false` desactiva la puerta grill. El interruptor de los skills/herramientas grill es el flag `disabled` de su fila. |
191
- | `modules.tdd` | `true` | En `true` activa las puertas de evidencia red/green (v0.2); activado por defecto desde v0.5. |
192
- | `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». |
193
- | `guardTools` | `['edit', 'write']` | Nombres de herramientas de mutación que vigila el guard. |
194
- | `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. |
195
- | `remindOnce` | `true` | Inyectar el recordatorio de cada puerta como máximo una vez por sesión. |
196
- | `testToolNames` | `['bash', 'pwsh']` | Nombres de herramientas de shell que pueden ejecutar pruebas. |
197
- | `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. |
198
- | `testFilePatterns` | *(directorios de prueba, `*.test.*` / `*.spec.*`)* | Expresiones regulares que identifican archivos de prueba — siempre editables, exentos de la puerta red. |
199
- | `adversaryModel` | `null` | Ruta del modelo crítico; `null` = el modelo principal se autorrevisa. |
200
- | `adversaryProvider` | `'fork'` | Nombre del provider de subagentes en el que corre el crítico. |
201
- | `adversaryMaxFindings` | `5` | Tope de hallazgos (1–20) inyectados en la sesión. |
202
- | `adversaryTools` | `['read', 'glob', 'grep']` | Allowlist de herramientas del crítico; mantenla de solo lectura. |
203
- | `adversaryTimeoutMs` | `120000` | Presupuesto de tiempo duro para una ejecución del crítico. |
162
+ ## 1. Requirements interrogation — PASS
163
+ - [✔] **What outcome must the delivery produce?** — spec dimension "goal" committed
164
+ - [✔] **What is in scope, and what is out of scope?** — spec dimension "scope" committed
165
+ - [✔] **Which observable checks prove the work is done?** — spec dimension "acceptanceCriteria" committed
166
+ - [✔] **What can go wrong, and what is the correct behavior in each case?** — spec dimension "failureModes" committed
167
+ - [✔] **What is traded when goals conflict; what is optional?** — spec dimension "priorities" committed
168
+ - [✔] **What does the user explicitly not want?** — spec dimension "nonGoals" committed
204
169
 
205
- La mala configuración falla en voz alta: una regex inválida, una lista de nombres vacía o duplicada, o un tope de hallazgos fuera de rango lanza un error al cargar en lugar de no hacer nada en silencio. Un crítico que no puede ejecutarse (seam ausente, fallo del provider, timeout) se resuelve como un aviso honesto «no disponible» en la sesión.
170
+ ## 2. Test evidence — FAIL
171
+ - [✔] **passing test run** — latest test run passed
172
+ - [✔] **failing cases after green** — 0 failing run(s) after green (allowed: 0)
173
+ - [✖] **coverage evidence** — 61% coverage below the 80% minimum — rework: raise coverage above the configured minimum
206
174
 
207
- ### Controles del informe (fila grill)
175
+ ## 3. Implementation consistency — WARN
176
+ - [⚠] **[minor] src/telemetry.ts touched without a requirement** — [minor] the edit adds a metric no spec dimension covers
208
177
 
209
- | Clave | Por defecto | Significado |
210
- |---|---|---|
211
- | `reportFile` | `'doublecheck-report.md'` | Archivo del workspace que recibe el markdown del informe. |
212
- | `reportVerify` | `true` | Valor por defecto para el flag `verify` de la herramienta. |
213
- | `verifyProvider` | `'fork'` | Provider de subagentes en el que corren los verificadores por dimensión. |
214
- | `reportTestToolNames` / `reportTestCommandPatterns` | *(same defaults as the guard row)* | Clasificación de ejecuciones de prueba con alcance de informe. |
215
- | `reportMutationTools` / `reportTestFilePatterns` | *(same defaults as the guard row)* | Clasificación de ediciones de implementación con alcance de informe. |
178
+ ## 4. Review conclusion — PASS
179
+ - [✔] **dsh-auto-review conclusion** — 3 call(s) approved by dsh-auto-review (latest risk: low)
216
180
 
217
- Los controles de clasificación del informe son independientes de los del guard: la aplicación de la puerta y el plegado del informe se pueden ajustar por separado sin que uno cambie silenciosamente al otro. La verificación degrada honestamente: un seam `workflowEngine` ausente o una ejecución rechazada deja `verification: null` y el markdown lo dice.
181
+ ## Red items
182
+ 1. **tests/coverage** — 61% coverage below the 80% minimum — *rework: raise coverage above the configured minimum*
183
+ 2. **consistency/finding-1** — [minor] the edit adds a metric no spec dimension covers — *rework: src/telemetry.ts touched without a requirement*
218
184
 
219
- ## Cómo funciona (puntos de extensión)
185
+ ## Audit
186
+ - review engine: dsh-auto-review
187
+ - generated at: 2026-08-14T12:00:00.000Z
188
+ - counts, ids, and verdicts only: no file contents or session text are embedded, and recognized secrets are redacted.
189
+ ````
220
190
 
221
- | Contribución | Mecanismo DSH |
222
- |---|---|
223
- | Skills empaquetados | `ctx.skills.registerProvider()` — seam de capacidad de skills, `source: bundled` |
224
- | Herramienta de catálogo/carga | `ctx.tools.register()` — `doublecheck_skills` |
225
- | Spec + archivo en workspace | herramienta `doublecheck_spec` + escritura opcional vía `ctx.fs` |
226
- | Puerta de requisitos | waterfall `tools/pre-execute` — `allow` / `ask` (seam de aprobación) / `deny` |
227
- | Puerta red | waterfall `tools/pre-execute` — comprobación dura de la evidencia de prueba fallida antes de las ediciones de implementación |
228
- | Inyección de recordatorio | waterfall `tools/post-execute` — `additionalContexts` → registrado como `user/message` |
229
- | Puerta green | `agent/turn-stopping` serial — inyecta un recordatorio de finalización cuando las ediciones carecen de una prueba que pasa |
230
- | Revisión adversaria | `ctx.subagents.start()` — forked critic with structured findings schema, injected at green; `warn`/`block` steer one round |
231
- | Informe de entrega | `doublecheck_report` tool — session-log fold + workspace markdown |
232
- | Workflow de verificación | `ctx.workflowEngine.start()` — one parallel checker per spec dimension, structured checks |
233
- | Estado duradero | session log fold over `tool/call` + `tool/result` + `tool/code-dispatch` + injected structured sources; model-visible ⟺ logged |
234
- | Eventos internos | `doublecheck/spec`, `doublecheck/reminder`, `doublecheck/review`, `doublecheck/report` (typed via declaration merging, `@mode emit`) |
235
-
236
- Sin cambios en el agent-loop. Cada registro es un `ctx.effect` / `ctx.on` / `register()` de servicio reversible.
237
-
238
- ## Qué ve el modelo
239
-
240
- - El skill `grill-requirements` se une al catálogo de skills de la sesión y se carga con la herramienta integrada `skill` (o `doublecheck_skills`).
241
- - `ask_user_question` sigue siendo la forma nativa de DSH de preguntar al usuario; el skill solo la coreografía (y en headless sin provider degrada a preguntas en prosa).
242
- - Los recordatorios llegan como contexto `{kind:'plugin'}`, así que las UIs de transcripción los muestran como metadatos de inyección.
243
- - 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.
244
- - `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.
245
- - `/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.
246
-
247
- ## Comando de sesión
191
+ ## Permisos y datos
248
192
 
249
- ```
250
- /doublecheck status|report|on|off
251
- ```
193
+ - **Lee**: el registro de sesión (`tool/call` / `tool/result` / `tool/code-dispatch`, fuentes `user/message` inyectadas y los registros de veredicto ajenos `autoReview/*`) solo en proceso; el estado opcional del servicio de modo plan.
194
+ - **Escribe**: `doublecheck-spec.md`, `doublecheck-report.md` y `gate-report.md` en el workspace de sesión (rutas configurables) a través de la interfaz `ctx.fs`; los eventos de sesión durables `doublecheck/state` y `doublecheck/gate`.
195
+ - **Llamadas a modelo**: las fases de consistencia y revisión local de la puerta (un subagente cada una por `/gate run`), la revisión adversarial opcional y el flujo de verificación de `doublecheck_report` inician ejecuciones de subagente; nada más llama a un modelo o a la red.
196
+ - **Nunca toca**: credenciales, variables de entorno o cualquier archivo fuera del workspace de sesión. El manifiesto del workshop declara solo `filesystem:read` y `filesystem:write`. Los informes de la puerta llevan solo conteos, ids y veredictos; los secretos reconocidos en los textos del revisor se redactan antes de almacenarlos o mostrarlos.
252
197
 
253
- - `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).
254
- - `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).
255
- - `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.
198
+ ## Límites de seguridad
256
199
 
257
- Todas las respuestas del comando respetan el ajuste `language` de la fila guard.
200
+ - **Visible para el modelo ⟺ registrado.** Cada recordatorio, revisión y aviso de puerta inyectado viaja por los canales estándar y cae en el registro de sesión; los hechos durables spec/state/gate viajan por resultados de herramienta o miembros de `SessionEventMap`.
201
+ - **Falla cerrado / falla en voz alta.** La configuración del guard y de la puerta se valida en `apply` (las aserciones lanzan); una interfaz de revisor o adversario que no puede ejecutarse se asienta como un aviso honesto "unavailable"/salto en lugar de un veredicto falso.
202
+ - **Informes auditables.** Los informes de puerta y entrega registran solo conteos, ids y veredictos — sin contenidos de archivo ni texto de sesión — y los textos de hallazgos producidos por el modelo pasan un redactor de secretos antes de almacenarlos o mostrarlos.
203
+ - **Sin red propia.** El plugin no hace solicitudes de red directas; los subagentes de crítico y revisor viajan por la interfaz de subagentes del harness.
204
+ - **Dependencia débil de dsh-auto-review.** Nunca se importa ni se exige; la puerta pliega sus registros de veredicto durables y degrada al revisor local, y nunca sintetiza solicitudes de aprobación.
258
205
 
259
- ## Hoja de ruta
206
+ ## Limitaciones conocidas
260
207
 
261
- 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.
208
+ - **Escrituras durables en rc.6.** `/doublecheck on\|off` → `doublecheck/state` y `/gate run` → `doublecheck/gate` necesitan la superficie de append `ignorable` del host (post-rc.6); en hosts rc.6 la bolsa de opciones se ignora y el evento sigue siendo de lectura obligatoria, así que el interruptor queda en memoria y el registro de la puerta vive solo en el resultado del comando + el archivo del workspace hasta actualizar el harness.
209
+ - **Interfaces opcionales.** El espacio de ajustes `doublecheck.gate` se registra solo cuando el servicio de ajustes está montado; la línea de modo plan de `/gate status` lee el `ctx.planMode` opcional (muestra `unknown` sin él); la revisión adversarial necesita `ctx.subagents`; la verificación necesita `workflowEngine`.
210
+ - **Degradación local.** `gate.review.engine: auto` degrada al revisor local cuando dsh-auto-review está ausente o no tiene registros de veredicto en esta sesión — el informe nombra la razón en lugar de inventar un veredicto.
262
211
 
263
212
  ## Desarrollo
264
213
 
265
214
  ```sh
266
- pnpm install --ignore-workspace
267
- pnpm run typecheck
268
- pnpm run lint
269
- pnpm run test
270
- pnpm run build
215
+ pnpm install # node ^22.19 || >=24
216
+ pnpm run build # tsc --noEmitOnError (lib/ is committed)
217
+ pnpm run prepare # tsc --noEmitOnError (git-install channel)
218
+ pnpm run prepublishOnly # build + full test suite
219
+ pnpm run typecheck # tsc --noEmit + tests tsconfig
220
+ pnpm run lint # eslint src tests
221
+ pnpm test # vitest run
222
+ pnpm run test:coverage # vitest run --coverage
223
+ pnpm run pack:check # build + pack the tarball
271
224
  ```
272
225
 
273
- ## Agradecimientos
226
+ ## Temas
227
+
228
+ `dsh`, `dsh-plugin`, `deepseek-harness`, `engineering-discipline`, `requirements`, `guard`, `skill`, `quality-gate`, `delivery-gate`
274
229
 
275
- Metodología inspirada en [obra/superpowers](https://github.com/obra/superpowers) (disciplina de ingeniería estilo TDD) y [TimothyVang/Grill-me](https://github.com/TimothyVang/Grill-me) (interrogar los requisitos antes de implementar). Este paquete es una implementación original: no se copia ningún texto, prompt o archivo de ninguno de los dos proyectos.
230
+ ## Contribuidores
231
+
232
+ - [@PerryLink](https://github.com/PerryLink) — creador y mantenedor: el bucle de disciplina grill → design → red → green → review → verify, la puerta de entrega de cuatro fases, la documentación en cinco idiomas y el pipeline de CI/publicación.
233
+
234
+ ## PerryLink DSH Plugin Family
235
+
236
+ Este proyecto es uno de los [15 complementos de DeepSeek Harness](https://github.com/PerryLink) mantenidos por [PerryLink](https://github.com/PerryLink). Si este te ayuda, los demás probablemente también:
237
+
238
+ | Plugin | One-liner |
239
+ |---|---|
240
+ | [dsh-mcp-panel](https://github.com/PerryLink/dsh-mcp-panel) | Read-only MCP runtime panel: /mcp command + Settings tab with status, tools and errors |
241
+ | **[dsh-doublecheck](https://github.com/PerryLink/dsh-doublecheck)** | Engineering-discipline guard + delivery quality gate: requirements grill, test gates, adversary review, /gate deliverable/rework panel |
242
+ | [dsh-background-agents](https://github.com/PerryLink/dsh-background-agents) | Durable background child agents with a Web UI sidebar, messaging and interrupt |
243
+ | [dsh-lsp-actions](https://github.com/PerryLink/dsh-lsp-actions) | LSP diagnostics, formatting, completion, code actions and rename over language servers |
244
+ | [dsh-output-styles](https://github.com/PerryLink/dsh-output-styles) | Claude Code outputStyles-equivalent runtime style switching |
245
+ | [dsh-checkpoint-rewind](https://github.com/PerryLink/dsh-checkpoint-rewind) | Claude Code /rewind-equivalent: snapshots, session forks, one-shot restore |
246
+ | [dsh-permission-rules](https://github.com/PerryLink/dsh-permission-rules) | Claude Code-style declarative allow/deny/ask permission rules with audit |
247
+ | [dsh-auto-review](https://github.com/PerryLink/dsh-auto-review) | Second-model auto-review on the approval chain, fail-closed by default |
248
+ | [dsh-memento](https://github.com/PerryLink/dsh-memento) | Approval-gated cross-session memory: ctx.memory seam + SQLite + memory tool |
249
+ | [dsh-skill-pack-security](https://github.com/PerryLink/dsh-skill-pack-security) | Security-audit skill pack: secret scan, dependency and supply-chain review |
250
+ | [dsh-session-pin](https://github.com/PerryLink/dsh-session-pin) | Pin sessions in the Web sidebar with durable ordering |
251
+ | [dsh-composer-history](https://github.com/PerryLink/dsh-composer-history) | Terminal-style input history for the web composer: arrows, Ctrl+R search |
252
+ | [dsh-github](https://github.com/PerryLink/dsh-github) | GitHub PR/issues integration for DSH, every write gated by approval |
253
+ | [dsh-plugin-guide](https://github.com/PerryLink/dsh-plugin-guide) | Plugin-development knowledge base as an on-demand agent skill |
254
+ | [dsh-claude-move](https://github.com/PerryLink/dsh-claude-move) | Migrate Claude Code sessions, memory, skills and CLAUDE.md into DSH |
276
255
 
277
256
  ## Licencia
278
257
 
279
- [Apache-2.0](LICENSE)
258
+ [Apache License 2.0](LICENSE) © 2026 dsh-doublecheck contributors