Skip to content
← Todos los capítulos

Capítulo 02

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

La skill de metodología delega la intención en nueve sub-skills especializadas: seis operaciones centrales de ejecución, dos asistentes de ciclo de vida y un motor de autoría:

  • create (crear) — Genera un plan nuevo a partir de un objetivo. El agente analiza el objetivo, lo descompone en tareas secuenciales y escribe los archivos del plan. En modo guiado materializa directamente un plan Lite (compacto y en línea en README.md), permitiendo al desarrollador conservarlo, promoverlo a plan Full o editarlo; en modo trust materializa directamente la representación solicitada sin confirmación interactiva. El análisis de requisitos y la verificación de calidad se ejecutan en ambos modos.
  • execute (ejecutar) — Recorre el plan tarea por tarea de forma secuencial. El agente actualiza el registro de progreso, ejecuta las puertas de validación y confirma cada tarea en git. En modo trust, la ejecución continúa de forma desatendida sin preguntas entre tareas.
  • refine (refinar) — Modifica un plan existente (agregando, editando, dividiendo o reordenando tareas, o promoviendo un plan Lite a Full) preservando estrictamente la evidencia completada y prohibiendo debilitar criterios sin confirmación.
  • resume (reanudar) — Continúa un plan interrumpido. El agente lee el journal de solo adición y los archivos de tarea para reconstruir el estado, continuando desde la primera tarea incompleta sin repetir trabajo concluido.
  • status (estado) — Informa del progreso sin ejecutar nada (estrictamente de solo lectura). Resume las tareas completadas, en curso y pendientes sin modificar archivos.
  • verify (verificar) — Comprueba la conformidad sin alterar nada (estrictamente de solo lectura). Informa si el repositorio cumple el estándar AI-first y si las tareas llevan criterios explícitos y puertas de validación.
  • onboard (incorporar) — Inspecciona el repositorio objetivo para razonar —nunca copiar y pegar— un AGENTS.md adaptado, la jerarquía estándar de docs/, documentación por módulo y el kit .agents/ con enlaces simbólicos.
  • upgrade (actualizar) — Comprueba versiones publicadas upstream, solicita consentimiento antes de descargar, instala etiquetas estables fijadas y reconcilia adaptaciones locales sin tocar los planes .dwp/ existentes.
  • author (autoría) — Crea o evoluciona skills, agentes o comandos locales del repositorio adaptados a flujos de trabajo recurrentes reales, y mantiene sincronizado el catálogo en .agents/docs/.

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. La configuración de extensiones a nivel de repositorio se registra en .dwp/config.json (dwp-config/v1), mientras que los planes residen en carpetas numeradas:

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

La anatomía de tarea de diez secciones

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.

v6 y v7: la misma metodología, una estructura más estricta

El estándar DWP actual es 7.0.0, implementado por la línea 7.x del skill. Ese paquete usa v7 de forma predeterminada para cada plan nuevo; una solicitud explícita de v6 sigue materializando un plan v6. Los planes v1, v2, v5 y v6 existentes conservan la generación registrada y nunca se migran en silencio; pasar un plan v5 a v6 requiere una solicitud explícita de migración.

v6 conserva la misma metodología de plan → tarea → puerta de validación → finalización, los comandos slash y la ubicación .dwp/plans/. Endurece la estructura de ingeniería con un contrato, un diario de solo anexado, manifiestos de contexto por tarea, un planificador y declaraciones explícitas de capacidades del entorno de ejecución. v7 conserva esa capa de registros y añade un marcador de tarea opcional parallel_safe, un evento de diario delegation para el trabajo acotado que se entrega a otro agente y el registro de addons .dwp/config.json; sin ningún addon de delegación habilitado, todo plan se sigue ejecutando de forma secuencial en la sesión actual. La decisión de arquitectura es GO; no se ha medido una superioridad ni una no inferioridad empírica en los resultados de los agentes.