Verify E2e

Verify E2E

dod-checker responde «¿T7 cumple R3.2?». Este skill responde otra pregunta: ¿la feature entera funciona? Son verificaciones distintas y ninguna reemplaza a la otra — 29 tareas en hecho, cada una verificada contra sus criterios, siguen sin decir nada sobre si el flujo completo camina de principio a fin.

El workflow del proyecto es: brainstorm → requirements + design → plan de tareas → implementación TDD (implement-task) → verificación por tarea (dod-checker) → verificación end-to-end (este skill) → cierre (close-feature). Este skill es el paso 7 y se detiene ahí.

Producís vos un solo documento: e2e-tests-plan.md. Los otros dos productos del ciclo tienen cada uno su propio dueño, y no sos vos: los scripts los escribe el subagente e2e-test-writer y el reporte lo escribe el subagente e2e-triager. Es la misma regla de un solo productor por documento que rige el resto del proyecto.

Modos y compuertas

Hay tres compuertas, y por defecto las tres están activas. El modo se dice al invocar; no hay archivo de configuración, y no lo agregues: el default vive acá, en este archivo, que es el único lugar que manda sobre este paso.

Vocabulario exacto, tal como puede venir en la invocación:

• sin nada → las tres activas
• --modo autonomo → ninguna; el ciclo corre del spec al reporte sin parar
• --sin plan, --sin scripts, --sin ruteo → desactiva esa y solo esa
• se combinan: --sin scripts --sin ruteo

Dos cuidados. Desactivá exactamente lo que te dijeron y nada más: un --sin scripts no autoriza a saltear la compuerta de ruteo, aunque las dos estén en el mismo ciclo. Y decí al arrancar qué modo entendiste, en una línea, antes de hacer nada. Si la persona se equivocó al escribirlo, ese es el único momento barato para descubrirlo.

Fase 1 — Entender el proceso y verificar precondiciones

La carpeta del spec es docs/AAAA-MM-DD-<feature>/. Si hay varias y no está claro cuál, preguntá.

Leé, en este orden: requirements.md (los criterios numerados son la materia prima del plan), design.md (de ahí sale cuál es la superficie de la app y cómo se levanta) y tasks.md (la columna Estado dice qué está realmente implementado).

Después comprobá cuatro cosas, y paralo todo si falla cualquiera:

1. requirements.md y design.md dicen aprobado en su encabezado. Si no, remití al skill specify. Un plan de tests e2e escrito sobre un spec sin aprobar prueba una feature que todavía puede cambiar.
2. Hay algo implementado que valga la pena probar. Si toda la tabla de tasks.md está en pendiente, no hay nada que verificar de punta a punta todavía. Si algunas tareas están en hecho y otras no, decilo y preguntá si vale la pena igual: un e2e sobre una feature a medias falla por diseño, y esos fallos no significan nada.
3. Existe una app navegable. Esto es lo que hace posible el resto: Playwright necesita una URL que abrir. Buscá un script dev/start/serve en package.json, un index.html, un servidor, un baseURL en playwright.config.ts. Si no hay ninguno, pará y decilo con todas las letras: sin superficie navegable no hay e2e que generar, y el remedio no es inventarlo ni caer a tests de unidad disfrazados —para eso ya está Vitest— sino construir la interfaz como una feature aparte, con su propio brainstorming. No escribas ningún archivo cuando pares acá.
4. Playwright está instalado y con browser. @playwright/test en devDependencies y el browser bajado. Si falta, reportalo con el comando que lo arregla (npm i -D @playwright/test, npx playwright install chromium) y esperá: instalar dependencias o bajar un browser de cientos de megas es una decisión de la persona, no tuya.

Cerrá la fase contando en una línea qué encontraste: la superficie de la app, cómo se levanta, y cuántas tareas hay en hecho.

Fase 2 — El plan de tests e2e

Escribí e2e-tests-plan.md en la carpeta del spec, siguiendo assets/e2e-tests-plan-template.md.

Son exactamente tres casos: uno de happy path y dos de fallo. No cuatro porque encontraste otro flujo interesante, ni dos porque el tercero se parecía. El número es fijo a propósito: un plan e2e que crece sin techo termina siendo una segunda suite de tests unitarios, lenta y frágil, que nadie corre.

• El happy path (E1) es el recorrido completo que le da sentido a la feature, de la primera pantalla al resultado observable. Si tenés que elegir entre dos, quedate con el que cruza más criterios de aceptación.
• Los dos de fallo (E2, E3) salen de los criterios que ya describen un rechazo o un error en requirements.md —los IF ... THEN— y se citan por id. No los inventes. Un caso de fallo inventado prueba una decisión de producto que nadie tomó, y cuando falla no se sabe si el bug está en el código o en el supuesto.
• Si en requirements.md no hay dos criterios de error, decilo: es un hueco del spec, va a Pendientes del plan, y lo decide una persona. No lo tapes eligiendo cualquier cosa.

Cada caso lleva id, título, criterios que cubre, precondiciones, pasos numerados en términos de lo que hace un usuario (no de selectores CSS: eso lo resuelve quien escribe el script) y resultado esperado observable.

Compuerta plan: presentá los tres títulos y los criterios que cubren, decí dónde quedó el archivo, y parate. No sigas sin un sí.

Generar los scripts

Invocá al subagente e2e-test-writer, uno solo, pasándole la ruta del plan aprobado y la carpeta destino end2end/AAAA-MM-DD-<feature>/. Es el único que escribe ahí; no toques vos los archivos que produce, ni siquiera para un arreglo chico.

Compuerta scripts: contá qué archivos generó y parate antes de correrlos.

Correr y diagnosticar

Invocá al subagente e2e-triager. Corre los tests, diagnostica cada fallo y escribe e2e-test-report.md en la carpeta del spec. Te devuelve además un veredicto estructurado en JSON, que es lo que usás para rutear.

No corras vos los tests antes de invocarlo: la corrida es suya, y una segunda corrida por afuera solo agrega un resultado que después hay que reconciliar.

Compuerta ruteo: presentá el resumen del reporte y qué pensás hacer con cada fallo, y esperá el sí antes de tocar nada.

Ruteo

El campo ruteo del veredicto tiene tres destinos, y cada uno es un camino distinto:

• aFase2 — el test estaba mal escrito. Volvé a la fase 2, corregí solo esos casos del plan, y rehacé el ciclo desde ahí. Máximo dos rondas. A la tercera, pará y subilo a la persona: un caso que no se estabiliza en dos intentos no es un test mal escrito, es una ambigüedad del spec disfrazada.
• aTDD — el fallo es del código. La tarea nombrada vuelve a en curso en tasks.md y el fallo e2e queda asentado en su Registro como el punto de partida. Eso lo escribís vos, no el triager: Estado y Registro son la región de quien implementa, y en este ciclo quien implementa es esta sesión. A partir de ahí el arreglo es el TDD de siempre, con el skill implement-task, y la tarea vuelve a hecho solo cuando dod-checker devuelva cumple. El ciclo e2e termina acá; no arranques la reparación en el mismo mensaje.
• aSpecify — el test y el código hacen lo que dicen, y lo que está mal es el criterio. Nombrá al skill specify y pará. No corrijas requirements.md vos.

Un caso en indeterminado no se rutea a ningún lado: se cuenta y se sube. Adivinar el destino de un fallo ambiguo cuesta más que preguntarlo.

Si todo dio verde, decilo y nombrá el paso 8, el skill close-feature: corre la higiene completa sobre el estado final y hace el commit de cierre. No lo arranques vos. Y decilo al cerrar, no después, porque este ciclo es justo el que puede invalidar un veredicto viejo — poblar end2end/ ya dejó una vez en rojo el comando que una tarea declaraba en verde, sin que esa tarea cambiara nada. El reporte queda como el registro durable de esta corrida.

Por qué no hay un agente que repare el código

Porque ya existe uno y es el TDD del proyecto. Un fallo e2e cuya causa es el código es un bug en una tarea ya implementada: una tarea que vuelve a en curso, con un test rojo de partida que encima ya está escrito. Un agente que editara src/ para poner el e2e en verde sería un segundo escritor del código, saltearía el ciclo TDD que CLAUDE.md fija como regla, y podría cerrar el síntoma dejando la causa. El loop automático de este skill es el del lado del test; el lado del código sale del loop a propósito.

Archivos de este skill

• assets/e2e-tests-plan-template.md — estructura de e2e-tests-plan.md