refacil-sdd-ai 3.0.0 → 3.0.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "3.0.0",
+  "version": "3.0.2",
   "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/apply/SKILL.md

@@ -68,10 +68,9 @@ Al terminar la implementacion de OpenSpec, agrega este resumen:
  Archivos modificados: [lista]
  Tasks completadas: [X/Y]
 
- Siguientes pasos:
- 1. /refacil:test — Generar tests unitarios
- 2. /refacil:verify — Validar implementacion vs specs
-    (si encuentra correcciones, te ofrece aplicarlas automaticamente)
+ El siguiente paso es generar/ajustar tests unitarios.
+ Quieres que continue con /refacil:test?
+ (Luego el flujo sigue con /refacil:verify)
 ```
 
 ## Reglas
@@ -79,3 +78,4 @@ Al terminar la implementacion de OpenSpec, agrega este resumen:
 - NUNCA generar artefactos SDD desde este comando — eso es responsabilidad exclusiva de `/refacil:propose`
 - Antes de implementar, cumplir las precondiciones del Paso 0 (artefactos completos) y del Paso 1 (rama de trabajo valida)
 - Si `openspec/changes/` no tiene cambios activos o estan incompletos, informar y redirigir a `/refacil:propose`
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad del Paso 3, invocar inmediatamente el **Skill tool** con `skill: "refacil:test"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:test`. (Ver `METHODOLOGY-CONTRACT.md §5`.)

package/skills/archive/SKILL.md

@@ -45,9 +45,20 @@ Segun el tipo, sigue el paso correspondiente:
 
 Los bug fixes solo contienen `summary.md` (y opcionalmente `.review-passed`), no tienen los artefactos completos que OpenSpec espera. Por eso se archivan **sin delegar a OpenSpec**.
 
-1. **Mover a archive**: Mueve la carpeta completa del fix a `openspec/changes/archive/[fecha-ISO]-[nombre-fix]/`
+1. **Mover a archive (operacion de move, no copy)**: traslada la carpeta completa del fix desde `openspec/changes/[nombre-fix]/` a `openspec/changes/archive/[fecha-ISO]-[nombre-fix]/`. La carpeta de origen **debe quedar eliminada** al finalizar.
 
-2. **Documentar en specs**: Lee el `summary.md` y el `.review-passed` del fix, y crea un spec individual para el bug en `openspec/specs/[nombre-descriptivo]/spec.md`.
+   Orden de ejecucion recomendado (determinista y cross-platform):
+   1. Asegurar que existe el directorio `openspec/changes/archive/` (crearlo si no existe).
+   2. Preferir un **move atomico** con `git mv "openspec/changes/[nombre-fix]" "openspec/changes/archive/[fecha-ISO]-[nombre-fix]"` cuando el fix ya esta bajo control de git (mueve y stagea de una).
+   3. Si `git mv` no aplica (archivos no trackeados o error), usar en su lugar:
+      - Linux/macOS: `mv "openspec/changes/[nombre-fix]" "openspec/changes/archive/[fecha-ISO]-[nombre-fix]"`
+      - Windows (bash de Claude Code): el mismo `mv` funciona sobre rutas POSIX (`/c/Users/...`). **No usar `cp -r` sin el `rm -rf` posterior** — es la causa raiz tipica del bug en que la carpeta de origen sobrevive.
+   4. **Verificacion obligatoria post-move**: ejecutar una listado/test de existencia para confirmar que:
+      - `openspec/changes/[nombre-fix]/` **ya NO existe**.
+      - `openspec/changes/archive/[fecha-ISO]-[nombre-fix]/` **SI existe** y contiene `summary.md` (+ `.review-passed` si lo habia).
+   5. Si la verificacion falla (la carpeta de origen sobrevivio), eliminarla explicitamente con `rm -rf "openspec/changes/[nombre-fix]"` y re-verificar. No continuar al paso 2 hasta que el estado sea consistente.
+
+2. **Documentar en specs**: Lee el `summary.md` y el `.review-passed` del fix (desde la ruta **archivada** en `openspec/changes/archive/[fecha-ISO]-[nombre-fix]/`, ya no desde la ruta original), y crea un spec individual para el bug en `openspec/specs/[nombre-descriptivo]/spec.md`.
 
    **Nombre de la carpeta en specs**: Usa una descripcion corta y clara del bug en kebab-case (ej. `fix-session-timeout-redis`, `fix-null-pointer-payment-callback`). **NO uses IDs de tickets** (REF-123, JIRA-456, etc.) — el nombre debe ser descriptivo para que `/refacil:explore` pueda encontrar y entender el fix sin contexto externo.
 
@@ -119,11 +130,17 @@ El objetivo es que `openspec/specs/` documente como funciona el sistema HOY.
 
 ### Paso 3: Confirmar
 
+Antes de mostrar el resumen, ejecutar una **verificacion final de limpieza** (aplica tanto a bug fixes como a cambios regulares):
+
+- `openspec/changes/[nombre-original]/` **NO debe existir** (solo la version archivada debe sobrevivir en `openspec/changes/archive/...`).
+- Si la carpeta de origen sobrevivio por cualquier razon (fallo del move, OpenSpec dejo residuos, copia en vez de mover), eliminarla explicitamente con `rm -rf "openspec/changes/[nombre-original]"` antes de confirmar al usuario.
+
 ```
 === Cambio archivado ===
  Cambio: [nombre]
  Tipo: [Bug fix | Cambio regular]
  Ubicacion: openspec/changes/archive/[fecha]-[nombre]/
+ Carpeta original eliminada: SI
  Specs sincronizadas: SI
  Tests: PASS
 
@@ -135,13 +152,16 @@ El objetivo es que `openspec/specs/` documente como funciona el sistema HOY.
 Despues de confirmar el archivado, recomienda al usuario subir los cambios al remoto:
 
 ```
-Tip: Ejecuta /refacil:up-code para subir los cambios a tu rama de desarrollo.
+El siguiente paso es subir el cambio y crear el PR.
+Quieres que continue con /refacil:up-code?
 ```
 
 ## Reglas
 
 - Siempre verificar completitud antes de archivar
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad del Paso 4, invocar inmediatamente el **Skill tool** con `skill: "refacil:up-code"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:up-code`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 - La sincronizacion de specs es OBLIGATORIA en la metodologia Refacil
 - La metadata de `.review-passed` debe persistirse separada en YAML (`review.yaml`) dentro de cada carpeta de spec
 - No eliminar artefactos, solo moverlos a archive/ para trazabilidad
+- **La carpeta original en `openspec/changes/[nombre]/` NO debe sobrevivir al archivado** — ni para bug fixes (Paso 2A) ni para cambios regulares (Paso 2B). Usar `git mv` o `mv` (no `cp -r`) y verificar explicitamente. Si queda residuo, borrarlo con `rm -rf` antes del Paso 3.
 - Usa modo de salida **conciso** por defecto y **detallado** solo si el usuario lo pide (ver `METHODOLOGY-CONTRACT.md`)

package/skills/bug/SKILL.md

@@ -121,10 +121,9 @@ Este archivo es obligatorio para la trazabilidad del fix y permite que el hook d
  Trazabilidad: openspec/changes/fix-[nombre]/summary.md
  [comando-test]: PASS
 
- Siguientes pasos:
- 1. /refacil:review — Review del fix (obligatorio antes de archivar)
- 2. /refacil:archive — Archiva el fix y documenta en openspec/specs/fix-[nombre]/spec.md (OpenSpec) + review.yaml
- 3. /refacil:up-code — Subir los cambios a tu rama de desarrollo
+ El siguiente paso es el review del fix (obligatorio antes de archivar).
+ Quieres que continue con /refacil:review?
+ (Luego el flujo sigue con /refacil:archive y /refacil:up-code)
 ```
 
 ## Reglas
@@ -137,3 +136,4 @@ Este archivo es obligatorio para la trazabilidad del fix y permite que el hook d
 - El Paso 3.5 (bus cross-repo) es **opcional** — solo invocarlo si la causa raiz parece cross-repo. Ver `refacil-prereqs/BUS-CROSS-REPO.md`.
 - Responder en español con terminos tecnicos en ingles
 - Usa modo de salida **conciso** por defecto y **detallado** solo si el usuario lo pide (ver `METHODOLOGY-CONTRACT.md`)
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad al cierre del fix, 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`.)

package/skills/explore/SKILL.md

@@ -37,13 +37,25 @@ Si el sub-agente pidio clarificacion (porque el prompt no traia pregunta explici
 
 ### Paso 3: Siguiente paso
 
-El sub-agente ya incluye recomendaciones al final de su reporte. Si el usuario responde a alguna (ej. "si quiero crear la propuesta"), redirigelo al skill correspondiente (`/refacil:propose`, `/refacil:bug`, etc.).
+El sub-agente ya incluye recomendaciones al final de su reporte. Aplica la regla de continuidad natural de `METHODOLOGY-CONTRACT.md §5`:
+
+- Si el reporte converge en **un solo** siguiente paso (ej. el hallazgo claramente indica un feature nuevo o un bug), cierra con la formula unica:
+  - *"El siguiente paso es [descripcion]. Quieres que continue con `/refacil:propose`?"* (o `/refacil:bug`, segun corresponda).
+- Si hay **varios caminos validos**, listalos numerados y pide al usuario seleccionar.
 
 ## Reglas
 
 - **Siempre delega al sub-agente**. No repliques la logica de exploracion aqui.
 - **No invoques sin pregunta**. Si `$ARGUMENTS` esta vacio, pide la pregunta primero.
 - **No escribes archivos**. Exploracion es read-only end-to-end.
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad del Paso 3, invocar inmediatamente el **Skill tool** con el nombre exacto resuelto a partir del hallazgo del sub-agente. Resolucion determinista:
+  - Hallazgo = feature nuevo o mejora → `skill: "refacil:propose"`
+  - Hallazgo = bug funcional o error en produccion → `skill: "refacil:bug"`
+  - Hallazgo = falta configuracion inicial del repo → `skill: "refacil:setup"`
+  - Hallazgo = duda de flujo o no queda claro el siguiente comando → `skill: "refacil:guide"`
+  - Si no hay match claro, NO invocar — listar opciones numeradas al usuario y pedir seleccion explicita antes de continuar.
+
+  No describirlo en texto ni esperar que el usuario escriba el comando. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 
 ## Ver tambien
 

package/skills/guide/SKILL.md

@@ -13,7 +13,10 @@ Eres un guia **breve**: eliges el siguiente comando; el detalle de cada flujo es
 1. Pregunta que necesita el usuario (o usa su primer mensaje).
 2. Muestra el menu numerado (abajo).
 3. Responde con: **comando** a ejecutar + **orden de pasos en una linea** (ej: `propose` → revisar artefactos → `apply` → `test` → `verify` → `review` → `archive` → `up-code`).
-4. Si pide mas detalle: "Ver README de refacil-sdd-ai (npm o repo del paquete): Flujos de trabajo y Comandos del CLI."
+4. Si por el contexto ya hay un **unico siguiente paso posible**, reformula en lenguaje natural y cierra con confirmacion:
+   - "El siguiente paso es X. Quieres que continue con `/refacil:X`?"
+5. Si hay varios caminos validos, lista opciones y pide seleccion explicita.
+6. Si pide mas detalle: "Ver README de refacil-sdd-ai (npm o repo del paquete): Flujos de trabajo y Comandos del CLI."
 
 ## Menu
 
@@ -52,3 +55,19 @@ Detalle completo en el README de refacil-sdd-ai (seccion `refacil-bus`).
 
 - **Claude Code:** comandos `/refacil:*` en el chat.
 - **Cursor:** comandos `/refacil:*` en Composer; `@` para archivos de contexto.
+
+## Reglas
+
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) a la pregunta de continuidad del paso 4 de Instrucciones, invocar inmediatamente el **Skill tool** con el nombre exacto resuelto a partir de la opcion del menu que recomendaste. Resolucion determinista segun la opcion del Menu:
+  - Opcion 1 (Feature nuevo) → `skill: "refacil:propose"`
+  - Opcion 2 (Bug) → `skill: "refacil:bug"` (o `skill: "refacil:setup"` primero si falta `openspec/`)
+  - Opcion 3 (Explorar) → `skill: "refacil:explore"`
+  - Opcion 4 (Tests) → `skill: "refacil:test"`
+  - Opcion 5 (Validar implementacion) → `skill: "refacil:verify"`
+  - Opcion 6 (Review de calidad) → `skill: "refacil:review"`
+  - Opcion 7 (Subir codigo y crear PR) → `skill: "refacil:up-code"`
+  - Opcion 8 (Configurar repo) → `skill: "refacil:setup"`
+  - Opcion 9 (Bus entre agentes) → `skill: "refacil:join"` (u otra del grupo `refacil:say`/`refacil:ask`/`refacil:reply`/`refacil:attend`/`refacil:inbox` segun la intencion expresada).
+  - Si la intencion no mapea exactamente a una opcion, NO invocar — listar opciones numeradas y pedir seleccion explicita.
+
+  No describirlo en texto ni esperar que el usuario escriba el comando. (Ver `METHODOLOGY-CONTRACT.md §5`.)

package/skills/prereqs/METHODOLOGY-CONTRACT.md

@@ -80,6 +80,16 @@ Modo por defecto: **conciso**.
 
 Si el usuario no pide detalle, usa modo conciso.
 
+### Continuidad natural del flujo (confirmacion)
+
+- Cuando exista **un unico siguiente paso posible** dentro del flujo, no limitarse a "ejecuta `/refacil:...`".
+- En ese caso, cerrar con una pregunta de continuidad en lenguaje natural usando la **formula unica**:
+  - *"El siguiente paso es [descripcion breve]. Quieres que continue con `/refacil:<skill>`?"*
+- Cuando haya **multiples siguientes pasos validos** (ramificacion real), listar opciones numeradas y pedir seleccion explicita.
+- Si el paso actual es **terminal** (fin de flujo, p.ej. PR creado), cerrar sin preguntar por siguiente skill.
+
+**Regla operativa (obligatoria)**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", "yes", etc.) a la pregunta de continuidad, **invocar directamente la siguiente skill via el Skill tool** en el mismo turno. No pedir al usuario que escriba `/refacil:X` ni que repita el contexto — la sesion debe continuar sin friccion.
+
 ## 6) Scope de review y push
 
 - `up-code` y `check-review` solo deben auto-ejecutar review cuando hay un unico cambio pendiente.

package/skills/propose/SKILL.md

@@ -68,7 +68,8 @@ Responde "OK" para continuar, o indica que ajustes necesitas.
 
 ```
 Propuesta aprobada en: openspec/changes/[nombre]/
-Siguiente paso: ejecuta /refacil:apply para implementar las tasks.
+El siguiente paso es implementar las tasks.
+Quieres que continue con /refacil:apply?
 ```
 
 ## Reglas
@@ -79,3 +80,4 @@ Siguiente paso: ejecuta /refacil:apply para implementar las tasks.
 - Siempre explorar el codebase ANTES de generar artefactos (para que el design sea realista)
 - Los criterios de aceptacion deben ser especificos y testeables
 - El Paso 2.5 (bus cross-repo) es **opcional** — solo invocarlo si el cambio toca un contrato con otro sistema. Ver `refacil-prereqs/BUS-CROSS-REPO.md`.
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad del Paso 4, invocar inmediatamente el **Skill tool** con `skill: "refacil:apply"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:apply`. (Ver `METHODOLOGY-CONTRACT.md §5`.)

package/skills/review/SKILL.md

@@ -56,7 +56,9 @@ BLOCKERS: si | no
 ## Correcciones minimas para aprobar
 ...
 
-Siguiente paso: [/refacil:archive | /refacil:verify]
+Siguiente paso:
+- Si el veredicto es APROBADO o APROBADO CON OBSERVACIONES: el siguiente paso es archivar el cambio. Quieres que continue con /refacil:archive?
+- Si el veredicto es REQUIERE CORRECCIONES: el siguiente paso es validar de nuevo tras corregir. Quieres que continue con /refacil:verify?
 
 ```refacil-review-result
 {
@@ -105,6 +107,7 @@ Este archivo es evidencia de que el review se completo y es requerido por el hoo
 - **El marker lo crea este skill, no el sub-agente**. Es la unica operacion de escritura, y queda fuera del contexto aislado del sub-agente (compatible con `readonly: true` de Cursor).
 - **No muestres el bloque JSON al usuario**. Es solo para que tu (el wrapper) escribas el marker.
 - Si el sub-agente retorno algo fuera de formato (sin bloque JSON parseable y no es `SCOPE_ERROR`), informa al usuario: "El reviewer retorno un reporte no estructurado — no se creo marker. Revisa el reporte manualmente."
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad, invocar inmediatamente el **Skill tool** correspondiente: `skill: "refacil:archive"` si el veredicto es APROBADO/APROBADO CON OBSERVACIONES, o `skill: "refacil:verify"` si es REQUIERE CORRECCIONES. No describirlo en texto ni esperar que el usuario escriba el comando. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 
 ## Ver tambien
 

package/skills/setup/SKILL.md

@@ -82,5 +82,10 @@ Analiza el repo y genera `AGENTS.md` (espanol, terminos tecnicos en ingles). Si
  Node.js / OpenSpec / perfil / openspec/ / config / AGENTS.md / skills OK
 
  Reiniciar sesion Claude Code o Cursor si es la primera instalacion de skills.
- Siguiente: /refacil:guide
+ El siguiente paso es revisar el flujo disponible.
+ Quieres que continue con /refacil:guide?
 ```
+
+## Reglas
+
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad del Paso 8, invocar inmediatamente el **Skill tool** con `skill: "refacil:guide"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:guide`. (Ver `METHODOLOGY-CONTRACT.md §5`.)

package/skills/test/SKILL.md

@@ -58,8 +58,8 @@ Si el usuario ejecuta `/refacil:test` sin argumentos:
     Coverage minimo requerido: 80%
     Estado: CUMPLE / NO CUMPLE
 
-   Siguiente paso: /refacil:verify — Validar implementacion vs specs
-   (si encuentra correcciones, te ofrece aplicarlas automaticamente)
+   El siguiente paso es validar la implementacion vs specs.
+   Quieres que continue con /refacil:verify?
    ```
 
 ### Modo 2: Tests para archivo especifico (con argumento)
@@ -84,3 +84,4 @@ Si el usuario pasa un archivo: `/refacil:test src/mi-archivo.ext`
 - Usar los alias de rutas/imports del proyecto
 - Los tests deben pasar con el comando de test del proyecto sin errores
 - Ubicar los tests donde el proyecto los espera (misma carpeta, carpeta `test/`, `__tests__/`, etc.)
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad al finalizar el reporte de tests (Modo 1), 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`.)

package/skills/up-code/SKILL.md

@@ -97,6 +97,8 @@ A que rama quieres crear el PR? (recomendado: testing)
  antes de promover a otras ramas protegidas.
 ```
 
+**Este es el paso terminal del flujo SDD.** No preguntes por siguiente skill — el ciclo se cierra aqui. Aplica la regla de paso terminal de `METHODOLOGY-CONTRACT.md §5`.
+
 ## Reglas
 
 - Respetar estrictamente la politica de ramas protegidas e integracion por PR del `METHODOLOGY-CONTRACT.md`

package/skills/verify/SKILL.md

@@ -49,7 +49,8 @@ Felicita y sugiere:
 ```
 RESULTADO: APROBADO
 
-Siguiente paso: `/refacil:review` para el review con checklist del equipo.
+El siguiente paso es el review de calidad con checklist del equipo.
+Quieres que continue con `/refacil:review`?
 ```
 
 #### Si `result` es REQUIERE CORRECCIONES:
@@ -65,7 +66,7 @@ Correcciones necesarias:
 
 Quieres que aplique estas correcciones? (si/no)
 - Si: aplicare los fixes y re-verificare automaticamente
-- No: puedes corregirlos manualmente y ejecutar /refacil:verify de nuevo
+- No: puedes corregirlos manualmente y luego, si quieres, continuo con /refacil:verify
 ```
 
 ### Paso 4: Aplicar correcciones (si el usuario acepta)
@@ -90,6 +91,7 @@ Lista los issues para que el usuario los corrija manualmente. Sugiere `/refacil:
 - **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`.)
 
 ## Ver tambien