refacil-sdd-ai 4.1.3 → 4.1.4

package/agents/auditor.md

@@ -64,10 +64,11 @@ SCOPE_ERROR: <razon>
 ```
 El main agent se encargara de clarificar con el usuario.
 
-### Paso 1: Recopilar archivos
+### Paso 1: Recopilar archivos y separar scope bloqueante de contexto preexistente
 
 - Si hay artefactos de OpenSpec en el scope (`proposal.md`, `design.md`, `specs/`, `tasks.md`), leelos primero para entender la intencion.
-- Identifica todos los archivos creados/modificados (usa `git diff --name-only` + `git status --porcelain` si aplica).
+- Identifica los archivos del cambio con `git diff --name-only HEAD` (si hay commits) y `git status --porcelain` (si hay cambios sin commitear). La union de ambos es el **scope bloqueante** — problemas ahi SI bloquean.
+- Archivos que lees como contexto pero que NO aparecen en ese listado son **contexto preexistente** — problemas ahi NO bloquean.
 - Lee cada archivo relevante.
 
 ### Paso 2: Evaluar contra checklist
@@ -79,6 +80,8 @@ Para CADA item del checklist cargado, evalua:
 
 Se especifico. No des PASS generico — justifica brevemente.
 
+Para cada FAIL, anota si el codigo afectado pertenece al **scope bloqueante** (archivo modificado en este cambio) o es **preexistente** (ya estaba asi antes). Esa distincion determina si bloquea o es opcional.
+
 ### Paso 3: Clasificar severidad en cada FAIL
 
 - **CRITICO**: Riesgo de seguridad, datos, o incumplimiento de spec.
@@ -90,19 +93,38 @@ Usa severidad para priorizar, no para inflar el reporte.
 
 ### Paso 4: Emitir reporte + bloque JSON
 
+El veredicto y `blockers` se determinan **exclusivamente** por hallazgos en el scope bloqueante (codigo nuevo/modificado):
+- **APROBADO**: No hay FAILs CRITICO/ALTO en codigo nuevo.
+- **APROBADO CON OBSERVACIONES**: Solo FAILs MEDIO/BAJO en codigo nuevo.
+- **REQUIERE CORRECCIONES**: Al menos un FAIL CRITICO/ALTO en codigo nuevo.
+
 Tu respuesta final DEBE tener exactamente esta estructura:
 
 ```
 === Review Report ===
 VEREDICTO: APROBADO | APROBADO CON OBSERVACIONES | REQUIERE CORRECCIONES
 BLOCKERS: si | no
+(veredicto y blockers solo reflejan el codigo introducido en este cambio)
 
-## Hallazgos priorizados (solo FAIL, maximo 5)
+## Hallazgos en codigo nuevo (maximo 5, priorizados)
 1. [CRITICO|ALTO|MEDIO|BAJO] [seccion/item] — [problema]
    - Evidencia: [archivo:linea o comportamiento]
    - Correccion sugerida: [accion concreta]
 
+---
+
+## Deuda preexistente encontrada — opcional, no bloquea
+
+> Estos problemas ya existian antes de este cambio. No son bloqueantes para el review actual.
+> Son tuya decision: si te toma poco tiempo, resolverlos aqui deja el repo en mejor estado del que lo encontraste — y eso suma. Si no, puedes crear una tarea aparte para atacarlos con foco.
+
+1. [CRITICO|ALTO|MEDIO|BAJO] [seccion/item] — [problema en archivo:linea]
+   - Correccion sugerida: [accion concreta]
+
+---
+
 ## Correcciones minimas para aprobar
+(solo issues del scope bloqueante)
 1. [item accionable]
 2. [item accionable]
 
@@ -114,8 +136,9 @@ Siguiente paso: [/refacil:archive | /refacil:verify]
   "date": "<fecha ISO actual — obtenla con: date -u +%Y-%m-%dT%H:%M:%SZ>",
   "changeName": "<nombre-cambio o null si no es un cambio activo>",
   "summary": "<resumen de 1 linea>",
-  "failCount": <numero entero de FAILs encontrados>,
-  "blockers": <true|false>
+  "failCount": <numero entero de FAILs en codigo NUEVO>,
+  "preexistingCount": <numero entero de FAILs preexistentes encontrados>,
+  "blockers": <true|false — solo codigo nuevo>
 }
 ```
 ```
@@ -124,6 +147,7 @@ Siguiente paso: [/refacil:archive | /refacil:verify]
 - Usa el fence literal ` ```refacil-review-result ` (no ` ```json `) para que el wrapper lo parsee sin ambiguedad.
 - Emitelo SIEMPRE, incluso si el veredicto es `REQUIERE CORRECCIONES`. El wrapper decide si escribir `.review-passed` o no segun el `verdict`.
 - El `date` debe ser timestamp ISO real. Corre `date -u +%Y-%m-%dT%H:%M:%SZ` via Bash si no estas seguro.
+- Si no hay deuda preexistente, omite esa seccion del reporte (no la incluyas vacia).
 
 ### Paso 5: Modo detallado (opcional)
 
@@ -133,10 +157,12 @@ Si el main agent indica `mode: detailed`, despues del reporte conciso y ANTES de
 
 - Ser constructivo: no solo decir que falla, sino como corregirlo.
 - No ser excesivamente estricto con N/A — si no aplica, marcarlo.
-- Si todo es PASS, felicitar brevemente y sugerir `/refacil:archive`.
-- Si hay FAILs criticos (seguridad, tests), marcar como bloqueantes y sugerir `/refacil:verify`.
+- Si todo es PASS en codigo nuevo, felicitar brevemente y sugerir `/refacil:archive`.
+- Si hay FAILs CRITICOS/ALTOS en codigo nuevo, marcar como bloqueantes y sugerir `/refacil:verify`.
 - No reportar ruido: evita listar mejoras cosmeticas como bloqueantes.
-- Si hay demasiados hallazgos, prioriza los 5 de mayor impacto primero.
+- Si hay demasiados hallazgos en codigo nuevo, prioriza los 5 de mayor impacto primero.
+- La deuda preexistente se lista completa (sin limite de 5) pero siempre marcada como opcional.
+- El tono para la deuda preexistente debe ser motivador, no culpante — el dev no la introdujo, pero puede ser el heroe que la elimina.
 - Usa modo **conciso** por defecto.
 
 ## Compatibilidad cross-platform

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "4.1.3",
+  "version": "4.1.4",
   "description": "SDD-AI: Specification-Driven Development with AI — metodologia de desarrollo con IA usando OpenSpec, Claude Code y Cursor",
   "bin": {
     "refacil-sdd-ai": "./bin/cli.js"

package/skills/review/SKILL.md

@@ -66,8 +66,9 @@ Siguiente paso:
   "date": "<ISO>",
   "changeName": "<nombre-cambio o null>",
   "summary": "<resumen 1 linea>",
-  "failCount": <int>,
-  "blockers": <bool>
+  "failCount": <int — solo FAILs en codigo nuevo>,
+  "preexistingCount": <int — FAILs en codigo preexistente, no bloqueantes>,
+  "blockers": <bool — solo codigo nuevo>
 }
 ```
 ```
@@ -89,7 +90,8 @@ Parsea el bloque ` ```refacil-review-result ` del sub-agente. Si `verdict` es **
   "date": "<ISO>",
   "changeName": "<nombre-cambio>",
   "summary": "<resumen 1 linea>",
-  "failCount": <int>,
+  "failCount": <int — solo FAILs en codigo nuevo>,
+  "preexistingCount": <int — FAILs preexistentes, no bloqueantes>,
   "blockers": false
 }
 ```