refacil-sdd-ai 4.1.2 → 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.2",
+  "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/prereqs/METHODOLOGY-CONTRACT.md

@@ -108,3 +108,8 @@ Si el usuario no pide detalle, usa modo conciso.
 - **`.review-passed`** y cualquier archivo cuyo nombre empiece por **`.`** son **ocultos** en muchos entornos: en shell, **`ls` sin `-a` / `-la` no los lista** — no concluyas que no existen por eso (evita falsos negativos en prereqs, review, verify, `up-code` y archive).
 - **Preferido**: herramienta **`Glob`** (patron bajo `openspec/changes/<nombre>/`), **`Read`** sobre la ruta exacta `openspec/changes/<nombre>/.review-passed`, o Bash **`test -f`** / **`[ -f ... ]`** sobre esa ruta.
 - Si el usuario dice que el archivo existe y tu comprobacion lo nego, **re-verifica** con uno de los metodos anteriores antes de insistir.
+
+## 9) Identificador de carpeta bajo `openspec/changes/<cambio>/`
+
+- El **nombre de la carpeta** del cambio activo es el identificador que usa el CLI de OpenSpec (`openspec status --change`, flujos de archive, etc.).
+- **Debe empezar con una letra ASCII** `[a-zA-Z]`. Si el primer caracter es un digito u otro simbolo, el CLI rechaza el nombre (p. ej. `Invalid change name: Change name must start with a letter`).

package/skills/prereqs/OPENSPEC-DELTAS.md

@@ -10,6 +10,7 @@ Lee este archivo **ademas** de la skill `openspec-*` que indique el comando `ref
 
 ## propose — `openspec-propose`
 
+- **Nombre de carpeta del cambio** (`openspec/changes/<nombre>/`): cumplir **`METHODOLOGY-CONTRACT.md` §9** — el primer caracter **debe** ser letra ASCII; **prohibido** crear el cambio con nombre que empiece por digito (incluye prefijos tipo `YYYY-MM-DD-...`). El CLI OpenSpec falla con esos nombres (`openspec status --change`, etc.). Fijar o validar el slug **antes** de generar artefactos.
 - Criterios de aceptacion: formato **Dado / Cuando / Entonces**.
 - Incluir **criterios de rechazo** (edge cases) en specs.
 - Tasks con estimacion de esfuerzo **S / M / L**.

package/skills/propose/SKILL.md

@@ -21,6 +21,16 @@ Si el usuario NO proporciono suficiente contexto en $ARGUMENTS, preguntale:
 
 Si $ARGUMENTS ya es claro, no preguntes de nuevo.
 
+### Paso 1.5: Identificador de carpeta del cambio (bloqueante — CLI OpenSpec)
+
+El directorio `openspec/changes/<nombre>/` **no puede** usar un `<nombre>` cuyo **primer caracter no sea una letra ASCII** `[a-zA-Z]` — ver **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §9**. Nombres como `2026-04-17-exponer-algo` hacen fallar `openspec status --change` y otros comandos.
+
+**Antes del Paso 2:**
+
+1. Acuerda o deriva el **slug final** del cambio (kebab-case: `feat-...`, `exponer-...`, `imp-...`, etc.). Fecha o ticket no van al **inicio** del nombre.
+2. Si el usuario o OpenSpec proponen un nombre invalido, **corrigelo** (p. ej. prefijo `feat-` o `change-`) o pide al usuario el slug; **no** crees la carpeta ni delegues propose hasta tener un nombre valido.
+3. Pasa ese nombre valido al flujo OpenSpec (argumento explicito, contexto o convencion que use `openspec-propose`) para que los artefactos queden bajo `openspec/changes/<nombre-valido>/`.
+
 ### Paso 2: Delegar a OpenSpec ff (fast-forward)
 
 1. Lee `openspec-propose/SKILL.md` en `.claude/skills/` o `.cursor/skills/`.
@@ -78,6 +88,7 @@ Quieres que continue con /refacil:apply?
 
 ## Reglas
 
+- **Nombre de carpeta del cambio**: cumplir siempre **§9** del contrato metodologico (primer caracter letra ASCII; nunca iniciar con digito).
 - **NUNCA escribir, modificar o generar codigo fuente** en esta fase — solo artefactos SDD: `proposal.md`, `design.md`, `tasks.md`, y especificacion en `specs.md` y/o `specs/**/*.md` (convencion OpenSpec)
 - Aunque el usuario pase una descripcion completa y detallada en $ARGUMENTS, la salida es EXCLUSIVAMENTE artefactos de planificacion
 - Si el usuario pide que tambien implemente, responder: "La implementacion se hace con `/refacil:apply` despues de aprobar los artefactos."

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
 }
 ```