refacil-sdd-ai 4.2.0 → 4.2.2

package/skills/test/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: refacil:test
-description: Generar tests unitarios basados en los artefactos de OpenSpec o para archivos especificos — delega al sub-agente refacil-tester para la deteccion de stack, generacion y ejecucion en contexto aislado
+description: Generar tests unitarios basados en los artefactos de OpenSpec o para archivos especificos — construye un briefing con CA/CR y scope de archivos, y delega al sub-agente refacil-tester para la generacion y ejecucion en contexto aislado
 user-invocable: true
 ---
 
 # refacil:test — Entrypoint de Generacion de Tests
 
-Este skill es un **wrapper delgado** que delega la generacion y ejecucion de tests al sub-agente `refacil-tester`. El sub-agente corre en contexto aislado (no satura tu sesion principal con deteccion de stack, lectura de specs y ciclos de correccion) y retorna un reporte conciso + un bloque JSON con el resultado.
+Este skill es un **wrapper delgado** que resuelve el scope, extrae los criterios CA/CR y la lista de archivos a testear, y delega al sub-agente `refacil-tester` con un **briefing estructurado**. El sub-agente arranca con los criterios ya extraidos — no re-lee specs desde cero.
 
 **Prerequisitos**: perfil `openspec` de `refacil-prereqs/SKILL.md` + comando de tests segun `METHODOLOGY-CONTRACT.md §3`.
 
@@ -15,38 +15,65 @@ Este skill es un **wrapper delgado** que delega la generacion y ejecucion de tes
 ### Paso 0: Resolver scope y modo
 
 **Modo file** — si `$ARGUMENTS` contiene una ruta de archivo:
-- `targetFile` = la ruta recibida. Continua al Paso 1 directamente.
+- `targetFile` = la ruta recibida. Continua al Paso 2 directamente (no se necesita briefing de specs).
 
 **Modo openspec** — si `$ARGUMENTS` esta vacio:
 - Lista las carpetas en `openspec/changes/`.
 - Si hay exactamente una carpeta activa, usarla como `changeName`.
-- Si hay multiples carpetas activas, **detente** y pide al usuario seleccionar cual testear. No invoques al sub-agente con scope ambiguo.
+- Si hay multiples carpetas activas, **detente** y pide al usuario seleccionar cual testear.
 - Si no hay cambios activos, informa que ejecute `/refacil:propose` y detente.
 
-### Paso 1: Delegar al sub-agente refacil-tester
+### Paso 1 (solo modo openspec): Construir briefing
 
-Invoca al sub-agente `refacil-tester` pasandole:
-- `mode`: `openspec` o `file` (segun el paso anterior).
-- `changeName`: nombre del cambio activo (si `mode=openspec`).
-- `targetFile`: ruta del archivo (si `mode=file`).
+Antes de invocar al sub-agente, extrae el contexto clave:
+
+1. **Criterios** — lee la especificacion del cambio (`openspec/changes/<changeName>/specs.md` y/o `specs/**/*.md` si existen). Extrae la lista de criterios de aceptacion (CA-XX) y rechazo (CR-XX) con su descripcion.
+2. **Archivos a testear** — lee `openspec/changes/<changeName>/design.md`. Extrae la lista de archivos creados/modificados.
+3. **Comando de test** — lee `refacil-prereqs/METHODOLOGY-CONTRACT.md §3`. Extrae el comando exacto.
+4. **Patron de tests** — busca un archivo de test existente relevante (1 archivo de ejemplo, no multiples). Si existe `testing-patterns.md` en este directorio, incluyelo.
+
+Construye el bloque BRIEFING que incluiras en el prompt de delegacion:
+
+```
+BRIEFING:
+changeName: <nombre>
+mode: openspec
+criteria:
+  acceptance:
+    - CA-01: <descripcion>
+    - CA-02: <descripcion>
+  rejection:
+    - CR-01: <descripcion>
+filesToTest: [ruta/archivo-1.ts, ruta/archivo-2.ts, ...]
+testCommand: <comando exacto>
+testPatternFile: <ruta de un archivo de test existente como referencia, o null>
+```
+
+### Paso 2: Delegar al sub-agente refacil-tester
+
+Invoca al sub-agente `refacil-tester` pasandole el BRIEFING (modo openspec) o directamente:
+- `mode`: `openspec` o `file`
+- `changeName` / `targetFile` segun corresponda
+- BRIEFING completo (modo openspec)
 - Si el usuario pidio modo detallado explicitamente, indicaselo. Default: conciso.
 
-El sub-agente:
-- Detecta el stack tecnologico del proyecto (lenguaje, framework de tests, patrones existentes).
-- En modo openspec: lee specs, design y tasks del cambio → genera tests cubriendo cada CA-XX y CR-XX.
-- En modo file: lee el archivo objetivo → genera el test file correspondiente.
-- Corre los tests, itera sobre fallos, ejecuta coverage si aplica.
-- Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-test-result `.
+El sub-agente usara el briefing para generar tests directamente sin re-leer specs.
 
-### Paso 2: Presentar el reporte
+Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-test-result `.
+
+### Paso 3: Presentar el reporte y procesar resultado
 
 Muestra al usuario el **reporte** (todo lo anterior al bloque `refacil-test-result`). No muestres el bloque JSON — es metadata interna.
 
-Si el sub-agente retorno algo fuera de formato (sin bloque JSON parseable), informa al usuario: "El tester retorno un reporte no estructurado — revisa los tests manualmente."
+Si el sub-agente retorno algo fuera de formato, informa al usuario: "El tester retorno un reporte no estructurado — revisa los tests manualmente." y detente.
+
+Parsea el bloque `refacil-test-result` del sub-agente:
+- **Si `passed: false`** (tests fallaron): presenta los `issues` del JSON y pregunta al usuario como quiere proceder. **No continues al Paso 4** hasta que los tests pasen.
+- **Si `passed: true`**: continua al Paso 4.
 
-### Paso 3: Continuidad del flujo
+### Paso 4: Continuidad del flujo (solo si tests pasaron)
 
-El sub-agente incluye en su reporte el estado (CUMPLE / NO CUMPLE). Despues de mostrarlo, agrega:
+Agrega:
 
 ```
 El siguiente paso es validar la implementacion vs specs.
@@ -55,10 +82,11 @@ Quieres que continue con /refacil:verify?
 
 ## Reglas
 
-- **Siempre delega al sub-agente**. No repliques aqui la logica de deteccion de stack ni de generacion de tests.
-- **No invoques con scope ambiguo**. Si hay multiples cambios activos y no hay argumento claro, pide al usuario seleccionar primero.
-- **No muestres el bloque JSON al usuario**. Es solo metadata para parsear el resultado internamente si se necesita.
-- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad, invocar inmediatamente el **Skill tool** con `skill: "refacil:verify"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:verify`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
+- **Siempre construye el briefing en modo openspec (Paso 1) antes de delegar** — reduce los tool calls del sub-agente.
+- **Siempre delega al sub-agente**. No repliques aqui la logica de deteccion de stack ni de generacion.
+- **No invoques con scope ambiguo**. Si hay multiples cambios activos, pide seleccion primero.
+- **No muestres el bloque JSON al usuario**. Es solo metadata interna.
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad **y los tests pasaron (`passed: true`)**, invocar inmediatamente el **Skill tool** con `skill: "refacil:verify"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:verify`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 
 ## Ver tambien
 

package/skills/verify/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: refacil:verify
-description: Validar que la implementacion cumple con las specs — delega al sub-agente refacil-validator para el reporte y maneja correcciones con aprobacion del usuario
+description: Validar que la implementacion cumple con las specs — construye un briefing con testCommand y criterios CA/CR, delega al sub-agente refacil-validator para el reporte y maneja correcciones con aprobacion del usuario
 user-invocable: true
 ---
 
 # refacil:verify — Entrypoint de Verificacion
 
-Este skill es un **wrapper** que delega el analisis pesado (lectura de specs + tests + archivos) al sub-agente `refacil-validator`, y maneja la interaccion con el usuario para aplicar correcciones cuando hay issues.
+Este skill es un **wrapper** que construye un **briefing estructurado** con el comando de test y los criterios ya extraidos, delega el analisis al sub-agente `refacil-validator`, y maneja la interaccion con el usuario para aplicar correcciones.
 
 **Prerequisitos**: perfil `openspec` de `refacil-prereqs/SKILL.md` + reglas de `METHODOLOGY-CONTRACT.md`.
 
@@ -23,17 +23,47 @@ No invoques al sub-agente con scope ambiguo.
 
 ### Paso 0.5: Archivos ocultos bajo `openspec/changes/` (evitar falsos negativos)
 
-Si **esta sesion** inspecciona el directorio del cambio (listar archivos, confirmar precondiciones) **antes o despues** de delegar, aplica **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**. El sub-agente `refacil-validator` sigue la misma regla.
+Si **esta sesion** inspecciona el directorio del cambio antes o despues de delegar, aplica **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**.
+
+### Paso 0.6: Construir briefing para el sub-agente (reduce tool calls del validator)
+
+Antes de invocar al sub-agente, extrae el contexto que de otro modo el validator calcularía por su cuenta:
+
+1. **Comando de test** — lee `refacil-prereqs/METHODOLOGY-CONTRACT.md` §3. Extrae el comando exacto.
+
+2. **Criterios CA/CR** — si hay cambio activo, lee la especificacion en `openspec/changes/<changeName>/`:
+   - `specs.md` si existe, y/o archivos bajo `specs/` (recursivo).
+   - Extrae la lista de CA-XX (criterios de aceptacion) y CR-XX (criterios de rechazo) con su descripcion.
+   - Si no hay specs o el scope es `git-diff`, omite este campo.
+
+3. **Archivos del scope** — ejecuta `git diff --name-only HEAD` para obtener los archivos modificados en este cambio.
+
+Construye el bloque BRIEFING:
+
+```
+BRIEFING:
+changeName: <nombre o null si scope=git-diff>
+testCommand: <comando exacto>
+criteria:
+  acceptance:
+    - CA-01: <descripcion>
+    - CA-02: <descripcion>
+  rejection:
+    - CR-01: <descripcion>
+changedFiles: [ruta/archivo-1.ts, ...]
+mode: conciso | detailed
+```
 
 ### Paso 1: Delegar al sub-agente refacil-validator
 
-Invoca a `refacil-validator` pasandole:
-- El scope resuelto (nombre del cambio activo o rutas).
-- Si el usuario pidio modo detallado, indicaselo (`mode: detailed`). Default: conciso.
+Invoca a `refacil-validator` pasandole el BRIEFING del paso anterior.
 
 El sub-agente:
+- Usa `testCommand` del briefing directamente (sin buscarlo en METHODOLOGY-CONTRACT.md).
+- Usa `criteria` del briefing para la verificacion (sin re-leer specs desde cero).
+- Usa `changedFiles` para enfocar el scope de verificacion OpenSpec.
 - Delega a OpenSpec verify para issues contra la spec.
-- Resuelve y corre el comando de tests del proyecto + coverage si aplica.
+- Corre los tests y verifica coverage.
 - Opcionalmente consulta el bus cross-repo ante ambigüedades.
 - Retorna reporte combinado + bloque JSON fenced como ` ```refacil-verify-result `.
 
@@ -47,9 +77,8 @@ Muestra el **reporte combinado** (todo lo anterior al bloque `refacil-verify-res
 
 Parsea el bloque ` ```refacil-verify-result ` del sub-agente.
 
-#### Si `result` es APROBADO (sin issues CRITICAL ni WARNING):
+#### Si `result` es APROBADO:
 
-Felicita y sugiere:
 ```
 RESULTADO: APROBADO
 
@@ -59,7 +88,7 @@ Quieres que continue con `/refacil:review`?
 
 #### Si `result` es REQUIERE CORRECCIONES:
 
-Presenta los issues (ya vienen en el reporte) y pregunta:
+Presenta los issues y pregunta:
 
 ```
 RESULTADO: REQUIERE CORRECCIONES
@@ -70,33 +99,32 @@ Correcciones necesarias:
 
 Quieres que aplique estas correcciones? (si/no)
 - Si: aplicare los fixes y re-verificare automaticamente
-- No: puedes corregirlos manualmente y luego, si quieres, continuo con /refacil:verify
+- No: puedes corregirlos manualmente y luego continuo con /refacil:verify
 ```
 
 ### Paso 4: Aplicar correcciones (si el usuario acepta)
 
 **Solo aplica fixes despues de aprobacion explicita del usuario.**
 
-1. Aplica SOLO las correcciones listadas — no agregar funcionalidad nueva, no refactorizar codigo no relacionado, no cambiar nada fuera del alcance de los issues reportados.
-2. Si hay tests que necesitan ajuste por las correcciones, ajustarlos tambien.
-3. Muestra un resumen breve de los archivos modificados.
-4. **Re-ejecuta automaticamente desde el Paso 1** (re-invoca al sub-agente) para confirmar que las correcciones resolvieron los issues.
-5. Si la re-verificacion encuentra nuevos issues, repite este ciclo (**maximo 2 rondas** de correccion automatica). Si despues de 2 rondas aun hay issues, lista los pendientes para correccion manual.
-
-**Si el usuario no acepta:**
+1. Aplica SOLO las correcciones listadas — no agregar funcionalidad nueva, no refactorizar codigo no relacionado.
+2. Si hay tests que necesitan ajuste, ajustarlos tambien.
+3. Muestra resumen de archivos modificados.
+4. **Re-ejecuta automaticamente desde el Paso 1** (re-invoca al sub-agente con el mismo briefing) para confirmar que las correcciones resolvieron los issues.
+5. Maximo **2 rondas** de correccion automatica. Si persisten issues, listarlos para correccion manual.
 
-Lista los issues para que el usuario los corrija manualmente. Sugiere `/refacil:verify` de nuevo cuando termine.
+**Si el usuario no acepta:** lista los issues para correccion manual. Sugiere `/refacil:verify` de nuevo.
 
 ## Reglas
 
-- **Siempre delega al sub-agente** para el analisis (pasos 1-3). No repliques aqui la logica de lectura de specs ni de ejecucion de tests.
-- **Dotfiles en `openspec/changes/`**: nunca afirmes ausencia de `.review-passed` (u otros `.…`) basandote solo en `ls` sin `-a`; ver `METHODOLOGY-CONTRACT.md` §8 y Paso 0.5.
-- **Las correcciones SOLO las aplica este wrapper** (Paso 4), despues de aprobacion explicita del usuario. El sub-agente es read-only.
-- **No muestres el bloque JSON al usuario**. Es solo metadata para parsear el resultado.
+- **Siempre construye el briefing (Paso 0.6) antes de delegar** — reduce los tool calls del sub-agente.
+- **Siempre delega al sub-agente** para el analisis. No repliques aqui la logica de lectura de specs ni de ejecucion de tests.
+- **Dotfiles en `openspec/changes/`**: nunca afirmes ausencia de `.review-passed` sin `-a`; ver §8.
+- **Las correcciones SOLO las aplica este wrapper** (Paso 4), despues de aprobacion explicita.
+- **No muestres el bloque JSON al usuario**.
 - **Las correcciones deben ser quirurgicas**: solo lo necesario para resolver los issues reportados.
 - Maximo 2 rondas de correccion automatica antes de escalar a manual.
-- Si el sub-agente retorno algo fuera de formato (sin bloque JSON parseable), informa al usuario: "El validator retorno un reporte no estructurado — continua manualmente con las correcciones."
-- **Continuidad del flujo**: si el resultado es APROBADO y el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad, invocar inmediatamente el **Skill tool** con `skill: "refacil:review"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:review`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
+- Si el sub-agente retorno algo fuera de formato, informa: "El validator retorno un reporte no estructurado — continua manualmente."
+- **Continuidad del flujo**: si el resultado es APROBADO y el usuario confirma afirmativamente, invocar inmediatamente el **Skill tool** con `skill: "refacil:review"`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 
 ## Ver tambien