El ciclo central

DWP define un conjunto reducido de operaciones que llevan un plan desde un objetivo hasta un trabajo terminado y revisable: crear → ejecutar → refinar → reanudar → estado, con verificar como la comprobación de conformidad que confirma el resultado. Juntas forman el ciclo que un agente sigue durante toda la vida de un plan. Los agentes ejecutan una tarea a la vez y validan cada paso antes de avanzar.

Este ciclo es la forma operativa del desarrollo guiado por especificación. El plan es la especificación contra la que ejecuta un agente, cada tarea lleva criterios de aceptación explícitos, y el paso de validación es la puerta que convierte una afirmación de finalización en evidencia de ella. Como el plan y su registro de avance viven en el repositorio, el ciclo es reanudable entre sesiones y agentes.

Las operaciones

• crear: generar un plan nuevo a partir de un objetivo. El agente analiza el objetivo, lo descompone en tareas secuenciales y escribe los archivos del plan. Debe formular preguntas aclaratorias antes de escribir cuando el objetivo es ambiguo. En modo guiado, el agente materializa directamente un plan Lite — una propuesta compacta y ya ejecutable — y el desarrollador decide conservarlo, promoverlo a un plan Full de archivo por tarea, editarlo o detenerse; en modo trust, el agente materializa directamente la representación elegida (Lite o Full), sin paso de revisión. Consulta la especificación para ambas representaciones. El análisis de requisitos y la comprobación de calidad del plan se ejecutan en ambos casos.
• ejecutar: recorrer el plan tarea por tarea. El agente actualiza el registro de avance tras cada tarea y marca su estado de finalización. No debe omitir tareas sin registrar el motivo.
• refinar: modificar un plan existente. El agente puede agregar, quitar o reordenar tareas, pero debe preservar el trabajo completado y actualizar la tabla de tareas.
• reanudar: continuar un plan interrumpido. El agente lee el registro de avance y los archivos de tarea para reconstruir el estado, y luego continúa desde la primera tarea incompleta.
• estado: reportar el avance sin ejecutar. El agente resume las tareas completadas, en curso y pendientes, y no cambia nada.
• verificar: comprobar la conformidad sin cambiar nada. El agente reporta si el repositorio cumple el estándar y si un plan está bien formado — cada tarea con criterios de aceptación y una puerta de validación. Consulta el documento de Conformidad de la especificación.

El directorio de salida .dwp/

Todos los artefactos de DWP viven bajo un directorio .dwp/ ignorado por git en la raíz del repositorio. Mantener el espacio de trabajo fuera del control de versiones implica que el estado de trabajo de un plan nunca contamina el historial del proyecto.

.dwp/
├── plans/
│   └── PLAN_<slug>/
│       ├── README.md
│       ├── PROGRESS.md
│       └── <n>.task_<slug>.md
└── config.yaml

La anatomía de tarea de diez secciones

Archivo de tarea

1. 01 Title
2. 02 Context
3. 03 Read Before Starting
4. 04 Goal
5. 05 Touched Surface
6. 06 Instructions
7. 07 Acceptance Criteria
8. 08 Outputs
9. 09 Validation
10. 10 Execution Checklist + Completion & Log

Cada archivo de tarea contiene estas diez secciones, en orden. La estructura garantiza que cada unidad de trabajo sea autónoma y revisable:

1. Objetivo: un párrafo que indica qué logra la tarea.
2. Contexto: antecedentes, enlaces y por qué existe esta tarea.
3. Superficie tocada: qué cambia la tarea y la clase de riesgo que selecciona su validación.
4. Pasos: acciones concretas y ordenadas que ejecutar.
5. Criterios de aceptación: una lista de condiciones que definen lo terminado.
6. Validación: comandos o pruebas que ejecutar para verificar el trabajo.
7. Archivos: rutas que se espera crear o modificar.
8. Dependencias: otras tareas o requisitos externos.
9. Riesgos: qué podría salir mal y sus mitigaciones.
10. Finalización y registro: un marcador de estado más notas cronológicas.

Validación, finalización y reanudación

La validación forma parte de la tarea, no es algo accesorio: cada tarea nombra los comandos o pruebas que demuestran que está terminada, y el agente los ejecuta antes de marcar la finalización. Las pruebas son de primera clase aquí: una tarea que agrega nueva funcionalidad o cambia el comportamiento debe agregar o actualizar pruebas automatizadas para ese comportamiento y ejecutar el control completo de calidad de código del repositorio (pruebas más linter y comprobación de tipos), no solo confirmar que la compilación tiene éxito; las pruebas existentes deben seguir en verde, actualizadas al comportamiento previsto en lugar de omitidas. La seguridad es de primera clase del mismo modo — cualquier tarea que toca autenticación, manejo de entradas, secretos, superficie de red o dependencias lleva las expectativas de seguridad de ese cambio en sus criterios de aceptación y mantiene cada commit libre de secretos, y cada plan se cierra con el Final Review — el pase de seguridad sobre todo el conjunto de cambios, la validación completa sobre el estado final y la reconciliación de decisiones de skills. La finalización se registra con un marcador de estado explícito ([ ] sin empezar, [~] en curso, [x] hecho, [!] bloqueado) en la sección de Finalización y registro. La reanudación se apoya en estos marcadores y en el registro de avance: un agente puede reconstruir con exactitud dónde se detuvo el plan y continuar desde la primera tarea incompleta sin rehacer el trabajo terminado.