Skip to content
Deep Work Plan ya está en Product Hunt Vótalo
← Todos los documentos

Conformidad

Versión 1.3. Estado: Estable. Este documento define qué significa que un repositorio sea conforme con Deep Work Plan — es decir, AI-first y pilotable por agentes. Las palabras clave DEBE, NO DEBE, DEBERÍA, NO DEBERÍA y PUEDE se interpretan como se describe en el RFC 2119.

La conformidad existe para que “AI-first” sea una propiedad objetiva y comprobable, no una impresión. Un repositorio cumple los criterios de abajo o no los cumple. La sub-skill verify (/dwp-verify) los comprueba de forma mecánica.

Un repositorio conforme

Un repositorio conforme con DWP DEBE cumplir todo lo siguiente. Cada artefacto DEBE estar razonado para el repositorio — adaptado a sus lenguajes, frameworks y comandos reales. Un esbozo genérico, un marcador de posición o contenido copiado de otro repositorio no satisface un criterio.

  1. AGENTS.md en la raíz. El repositorio DEBE contener un AGENTS.md en la raíz que incluya (a) un índice de la documentación, (b) las reglas obligatorias del repositorio y (c) un bloque de Comandos Rápidos cuyos comandos sean reales y ejecutables en este repositorio. NO DEBEN aparecer comandos de marcador de posición (por ejemplo, npm test en un repositorio que no usa npm). El índice NO DEBE enlazar un archivo de docs/ que no exista, y el archivo DEBERÍA mantenerse dentro de un presupuesto de 150–500 líneas, moviendo el detalle a docs/ y enlazándolo en lugar de crecer sin límite.
  2. CLAUDE.md resuelve a AGENTS.md. DEBE existir un CLAUDE.md que resuelva a AGENTS.md (un enlace simbólico o un equivalente que garantice una única fuente de verdad). Ambos NO DEBEN divergir.
  3. Una jerarquía docs/. El repositorio DEBE contener un directorio docs/ que cubra las categorías estándar (arquitectura, estándares, pruebas, comandos de desarrollo, seguridad e incorporación de agentes) con contenido real y específico del repositorio. Los módulos complejos DEBERÍAN llevar su propio README.md. La guía de pruebas DEBE definir una cadena de herramientas real de pruebas, linter y comprobación de tipos — o, para un repositorio que no tenga ninguna, una configuración concreta propuesta a partir del stack durante la incorporación. Una guía de pruebas vacía o “sin pruebas” no satisface este criterio: sin una forma definida de validar el comportamiento, un plan no tiene una puerta de validación objetiva.
  4. Un hogar .agents/. El repositorio DEBE contener un directorio .agents/ con agents/, commands/ y skills/, además de un catálogo en .agents/docs/ que coincida con lo que hay en disco. Los comandos dwp-* DEBEN ser delegadores finos hacia el skill instalado. Una ruta .claude DEBE resolver a .agents.
  5. Un espacio .dwp/ ignorado por git. El repositorio DEBE contener un directorio .dwp/ con plans/, y .dwp/ DEBE estar ignorado por git. Un espacio de trabajo tmp/ DEBERÍA existir y DEBERÍA estar ignorado por git.
  6. El skill de la metodología es resoluble. El skill de Deep Work Plan DEBE estar instalado o referenciado de modo que un agente en el repositorio pueda invocar sus sub-skills.

Un repositorio es totalmente conforme con cero addons opcionales. Los addons opcionales (devcontainer, Dailybot, dependency-upgrade, design-system) NO DEBEN ser requeridos para la conformidad. Desde el estándar 2.3.0 la revisión local de AI Diff Reviewer (skill vendorizada + archivo de extensión) es parte de la línea base: su ausencia es un fallo para un repositorio que declare 2.3.0 o posterior, y un hallazgo de versión del harness para un repositorio heredado. Su superficie de CI sigue siendo opcional.

Un plan bien formado

Un Deep Work Plan en .dwp/plans/ está bien formado cuando:

  1. Cada tarea DEBE declarar un alcance explícito, criterios de aceptación y al menos una puerta de validación (un comando o comprobación que pase o falle de forma objetiva).
  2. Cada tarea que agrega nueva funcionalidad central o cambia el comportamiento del producto DEBE incluir cobertura de pruebas automatizadas para ese comportamiento en sus criterios de aceptación, y DEBE ejecutar las pruebas del repositorio junto con sus comprobaciones de linter y de tipos en su puerta de validación — no solo la compilación. Las pruebas existentes DEBEN seguir en verde; un cambio de comportamiento DEBE actualizar una prueba que rompa en lugar de eliminarla u omitirla. Las tareas de pura documentación, configuración o investigación están exentas de crear pruebas, pero aun así ejecutan la puerta del repositorio.
  3. Cada tarea que toque autenticación, manejo de entradas, secretos o configuración, superficie de red o dependencias DEBE llevar las expectativas de seguridad de ese cambio en sus criterios de aceptación, y cada commit DEBE estar libre de material secreto.
  4. El plan DEBE persistir el progreso para que el trabajo sobreviva a la interrupción y pueda ser reanudado por un agente distinto. Una tarea NO DEBE registrarse como completed mientras alguno de sus registros de puerta de validación siga mostrando una ejecución fallida sin resolver, y el propio registro de finalización de una tarea NO DEBE contradecir su estado registrado (por ejemplo, una tarea completed cuyo registro todavía diga «Status: pending» es un defecto, no una aprobación).
  5. El plan DEBE cerrarse con su revisión final registrada. Un plan redactado bajo esta versión DEBE terminar con exactamente un Final Review obligatorio — el pase de seguridad, la validación de estado final y la reconciliación de skills. Un plan redactado bajo una versión anterior termina con las tres tareas finales obligatorias (Revisión de Seguridad, Descubrimiento de Skills y Agentes, Reporte Ejecutivo) y sigue siendo conforme. Un hallazgo de seguridad crítico bloquea la finalización hasta que se corrija o se acepte explícitamente. La propia finalización es una transacción verificada y recuperable, no un simple cambio de estado: la tarea terminal se cierra mediante un paso de publicación protegido que valida los artefactos del plan terminado antes de escribir el estado y deja un recibo FINALIZATION.json verificable por máquina; una publicación interrumpida se recupera a partir de la evidencia, nunca se redeclara completada en silencio. Cualquier puntero de evidencia que cite un registro de puerta DEBE resolverse dentro del propio folder del plan — un puntero colgante o que se escape es un hallazgo, no evidencia de aprobación.
  6. Las tareas DEBERÍAN reanclarse al objetivo del plan antes de ejecutarse, para evitar la desviación en un horizonte largo.

Verificar la conformidad

La conformidad DEBERÍA verificarse de forma mecánica y no por inspección. Ejecutar /dwp-verify produce un informe de aprobado/fallido frente a los criterios de arriba: la presencia y el contenido real de AGENTS.md, la resolución de CLAUDE.md, las categorías de docs/, la coincidencia catálogo-versus-disco de .agents/, el estado de gitignore de .dwp/ y tmp/ y — para un plan — que cada tarea lleve criterios de aceptación y una puerta de validación, con cobertura de pruebas para las tareas que cambian el comportamiento y la revisión final registrada presente. También comprueba, para un plan, que el Markdown del plan y su estado legible por máquina concuerden (un README y un state.json desincronizados es un hallazgo, nunca una aprobación silenciosa), que las tareas completadas lleven evidencia de puerta y de registro sin contradicciones, y — cuando un plan completado llega a ese punto — que un recibo de publicación respalde la finalización que declara. El comprobador es consciente de la versión: DEBE aceptar como conforme un plan heredado (tres tareas finales obligatorias, sin Superficie tocada), y DEBE rechazar un plan que declare esta versión y sea objetivamente inválido bajo ella. También reporta una línea de procedencia DWP standard: ausente o desactualizada como un hallazgo que nombra la actualización dirigida del harness. La capa mecánica es honesta con sus límites: sin un intérprete capaz (Python 3.9+) termina con salida distinta de cero y un veredicto UNVERIFIED explícito, en lugar de saltarse sus comprobaciones — un verificador nunca reporta un resultado que no verificó.

Un repositorio DEBERÍA reverificarse tras la incorporación y tras cada plan completado, de modo que la conformidad se mantenga en lugar de afirmarse una sola vez.