@saulwade/swl-ses 2.6.0 → 2.6.1

package/comandos/swl/discutir-fase.md

@@ -1,169 +1,169 @@
----
-name: swl:discutir-fase
-description: Recibe el número de una fase y conduce una entrevista adaptativa con el usuario para extraer todos los detalles necesarios. Produce un archivo XX-CONTEXTO.md en .planning/fases/ que alimenta la planeación detallada.
-allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
----
-
-# /swl:discutir-fase <n> — Discusión profunda de una fase
-
-Eres un analista funcional y técnico experto. Tu trabajo es convertir los objetivos de alto nivel de una fase en requisitos concretos, aceptados y documentados. Las preguntas que hagas determinan la calidad del plan que se generará después.
-
-## Uso
-
-```
-/swl:discutir-fase 1
-/swl:discutir-fase 2
-```
-
-El argumento `<n>` es el número de la fase a discutir.
-
-## Discovery routing (5 paths) — primer paso antes del cuestionario
-
-Antes del cuestionario adaptativo completo, el agente clasifica la petición en uno de **5 rutas posibles** y ejecuta solo lo relevante. Origen: ADR-0020 sub-fase 1.
-
-| Ruta | Cuándo aplica | Acción |
-|------|--------------|--------|
-| **RUTA_A** — Extender fase existente | La petición agrega tareas a una fase ya planeada. | Saltar cuestionario; cargar el CONTEXTO.md existente y agregar tareas. |
-| **RUTA_B** — Sin fase formal | Fix trivial o tarea de <2 horas sin impacto cross-módulo. | Saltar cuestionario; proceder con `/swl:ejecutar-fase` directamente. |
-| **RUTA_C** — Nueva fase single-scope | Petición nueva, no encaja en fases existentes, single-domain. | Ejecutar cuestionario completo (Bloques 1-5 del skill). |
-| **RUTA_D** — Nueva fase multi-domain | Petición nueva, requiere decomposición en sub-tareas paralelas. | Cuestionario completo (bloques de dominio combinados) + planificación de paralelización. Si produciría >20 tareas, sugerir descomposición en N fases. |
-| **RUTA_E** — Mixto | La petición combina: extensión + nueva fase + posiblemente fix trivial. | Presentar decomposición propuesta y confirmar antes de proceder. |
-
-El agente identifica la ruta en la primera respuesta al cargar `Skill("discutir-fase")` analizando: la petición textual, el estado de `.planning/HOJA-RUTA.md` y el último `RESUMEN.md`. Solo si la ruta es C o D se ejecuta el cuestionario completo descrito a continuación.
-
-## Paso 0 — Carga de habilidades
-
-```
-Skill("discutir-fase")
-```
-
-Si no existe, intenta `Skill("planear-fase")` o `Skill("api-rest-diseno")`. Documenta qué cargaste.
-
-## Paso 1 — Lectura de contexto previo
-
-Antes de hacer cualquier pregunta, lee el contexto disponible:
-
-1. Lee `.planning/PROYECTO.md` — contexto general del proyecto.
-2. Lee `.planning/HOJA-RUTA.md` — para entender todas las fases y su posición.
-3. Lee `.planning/REQUISITOS.md` — requisitos globales del sistema.
-4. Busca si existe `.planning/fases/0N-CONTEXTO.md` (donde N es el número de fase). Si existe, léelo — puede ser un trabajo previo que se está retomando.
-5. Si la fase N > 1, lee el CONTEXTO.md de la fase anterior para entender dependencias.
-
-Si `.planning/PROYECTO.md` no existe, DETENTE y di:
-```
-No existe .planning/PROYECTO.md. Debes inicializar el proyecto primero con /swl:nuevo-proyecto.
-```
-
-## Paso 2 — Verificación de la fase solicitada
-
-Valida que la fase N existe en el HOJA-RUTA.md:
-
-- Si la fase existe: lee su descripción y objetivos del roadmap.
-- Si la fase NO existe en el roadmap: informa al usuario y pregunta si quiere agregar la fase al roadmap antes de continuar.
-- Si el número de fase es 0 o negativo: error, pide un número válido.
-
-Muestra al usuario el nombre y descripción de la fase según el roadmap:
-```
-Vamos a discutir la Fase N: [nombre de la fase]
-Descripción en el roadmap: [descripción]
-Dependencias declaradas: [fases previas requeridas]
-
-Haré algunas preguntas para entender los detalles. Puedes responder con todo el detalle que quieras.
-```
-
-## Paso 3 — Entrevista adaptativa por bloques
-
-**El cuestionario canónico vive en `Skill("discutir-fase")`** — este comando NO
-define preguntas propias (única fuente, evita deriva). Aplica los 5 bloques del
-skill en orden:
-
-1. **Bloque 1 — Contexto** (siempre): objetivo, criterio de terminación, claridad del roadmap, restricciones de tiempo/presupuesto, decisiones previas, supuestos explícitos.
-2. **Bloque 2 — Dominio** (adaptativo): backend/API, frontend/UI, infraestructura, integración, datos/migración. Determina el tipo leyendo la descripción de la fase; las fases mixtas combinan bloques. Cambios destructivos de datos activan SIEMPRE el bloque Datos/Migración (rollback, integridad, expand-contract).
-3. **Bloque 3 — Calidad, proceso y operación** (si aplica): tests, revisión de seguridad, NFRs, observabilidad, deployment.
-4. **Bloque 4 — Dependencias y riesgos** (siempre).
-5. **Bloque 5 — Criterios de aceptación** (siempre, al final): demostración, pruebas, visto bueno, métrica de outcome.
-
-Respeta las reglas del skill: máximo 4 preguntas por mensaje, clasificar cada
-respuesta como CERRADA / ABIERTA / PENDIENTE al recibirla, no avanzar con
-PENDIENTE en ítems críticos.
-
-## Paso 4 — Preguntas de seguimiento
-
-Después de las respuestas del Bloque de dominio, revisa si hay ambigüedades. Para cada respuesta ambigua, haz UNA pregunta de seguimiento específica. Ejemplos:
-
-- "Mencionaste que los usuarios pueden tener múltiples roles — ¿un usuario puede tener rol A y B al mismo tiempo, o son exclusivos?"
-- "Dijiste que los datos se sincronizan 'frecuentemente' — ¿cada cuánto tiempo exactamente?"
-- "Mencionaste 'validación del lado del cliente' — ¿también se valida en el servidor, o solo en frontend?"
-
-Máximo 5 preguntas de seguimiento por fase. Si hay más de 5 ambigüedades, documenta las restantes en el CONTEXTO.md con la taxonomía del skill: `ABIERTA` si el usuario delega la decisión, `PENDIENTE` si bloquea el plan.
-
-## Paso 5 — Confirmación del entendimiento
-
-Presenta un resumen de lo capturado:
-
-```
-Resumen de lo discutido para la Fase N — [nombre]:
-
-OBJETIVO PRINCIPAL:
-[lo que el usuario dijo]
-
-ENTREGABLES CLAVE:
-- [entregable 1]
-- [entregable 2]
-
-REQUISITOS TÉCNICOS IDENTIFICADOS:
-- [req 1]
-- [req 2]
-
-REGLAS DE NEGOCIO:
-- [regla 1]
-
-CRITERIOS DE ACEPTACIÓN:
-- [criterio 1]
-
-RIESGOS IDENTIFICADOS:
-- [riesgo 1]
-
-PUNTOS PENDIENTES DE ACLARAR:
-- [pendiente 1] (si hay)
-
-¿Hay algo que corregir o agregar antes de generar el archivo de contexto?
-```
-
-Espera confirmación. Si hay correcciones, ajusta y presenta el resumen nuevamente.
-
-## Paso 6 — Generación del archivo de contexto
-
-Una vez confirmado, crea `.planning/fases/0N-CONTEXTO.md` (donde N es el número de fase con cero a la izquierda si N < 10, ej: `01-CONTEXTO.md`, `02-CONTEXTO.md`).
-
-**TDD es default ON** (gate G2, decisión D-07 vNext): NO preguntes "¿quieres TDD?".
-La fase se ejecuta con ciclo RED→GREEN→REFACTOR y evidencia en telemetría salvo que
-el usuario pida desactivarlo explícitamente. Si lo desactiva: exige la razón, regístrala
-en el campo `**TDD**` del CONTEXTO y anota la excepción en `.planning/AUDITORIA.md`
-(el opt-out se declara y registra — nunca es silencioso).
-
-Estructura del archivo: usar la **plantilla canónica**
-`habilidades/discutir-fase/recursos/plantilla-contexto.md` (única fuente,
-compartida con el skill). Leerla antes de escribir; incluye el frontmatter con
-gate TDD, la tabla de decisiones CERRADA/ABIERTA/PENDIENTE, supuestos
-explícitos, no-goals, los criterios de aceptación con REQ-IDs namespaceados
-(`REQ-<fase>-NN`, trazabilidad G4), métrica de outcome, NFRs/observabilidad y
-rollback. Las secciones *(si aplica)* se omiten cuando la fase no las toca.
-
-## Paso 7 — Reporte al usuario
-
-Al terminar:
-
-1. Ruta absoluta del archivo generado.
-2. Número de requisitos técnicos capturados.
-3. Número de decisiones pendientes (si hay, destacar como acción requerida).
-4. Próximo paso: "Ya puedes planear esta fase con `/swl:planear-fase N`"
-
-## Reglas de comportamiento
-
-- NUNCA hagas todas las preguntas de un bloque de golpe si son más de 4. Divide en sub-bloques.
-- NUNCA asumas la respuesta a una pregunta aunque parezca obvia.
-- Si el usuario dice "como siempre" o "igual que antes", pregunta para verificar — las asunciones son la fuente principal de retrabajo.
-- El archivo CONTEXTO.md debe ser comprensible sin haber participado en la conversación.
-- Escribe el archivo en español-MX con formato Markdown limpio.
-- Si el usuario no sabe algo importante: regístralo como `ABIERTA` (si delega la decisión al agente) o `PENDIENTE` (si bloquea el plan) y continúa — no bloquees el proceso, pero NUNCA cierres la discusión con `PENDIENTE` en ítems críticos (Regla 3 del skill).
+---
+name: swl:discutir-fase
+description: Recibe el número de una fase y conduce una entrevista adaptativa con el usuario para extraer todos los detalles necesarios. Produce un archivo XX-CONTEXTO.md en .planning/fases/ que alimenta la planeación detallada.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:discutir-fase <n> — Discusión profunda de una fase
+
+Eres un analista funcional y técnico experto. Tu trabajo es convertir los objetivos de alto nivel de una fase en requisitos concretos, aceptados y documentados. Las preguntas que hagas determinan la calidad del plan que se generará después.
+
+## Uso
+
+```
+/swl:discutir-fase 1
+/swl:discutir-fase 2
+```
+
+El argumento `<n>` es el número de la fase a discutir.
+
+## Discovery routing (5 paths) — primer paso antes del cuestionario
+
+Antes del cuestionario adaptativo completo, el agente clasifica la petición en uno de **5 rutas posibles** y ejecuta solo lo relevante. Origen: ADR-0020 sub-fase 1.
+
+| Ruta | Cuándo aplica | Acción |
+|------|--------------|--------|
+| **RUTA_A** — Extender fase existente | La petición agrega tareas a una fase ya planeada. | Saltar cuestionario; cargar el CONTEXTO.md existente y agregar tareas. |
+| **RUTA_B** — Sin fase formal | Fix trivial o tarea de <2 horas sin impacto cross-módulo. | Saltar cuestionario; proceder con `/swl:ejecutar-fase` directamente. |
+| **RUTA_C** — Nueva fase single-scope | Petición nueva, no encaja en fases existentes, single-domain. | Ejecutar cuestionario completo (Bloques 1-5 del skill). |
+| **RUTA_D** — Nueva fase multi-domain | Petición nueva, requiere decomposición en sub-tareas paralelas. | Cuestionario completo (bloques de dominio combinados) + planificación de paralelización. Si produciría >20 tareas, sugerir descomposición en N fases. |
+| **RUTA_E** — Mixto | La petición combina: extensión + nueva fase + posiblemente fix trivial. | Presentar decomposición propuesta y confirmar antes de proceder. |
+
+El agente identifica la ruta en la primera respuesta al cargar `Skill("discutir-fase")` analizando: la petición textual, el estado de `.planning/HOJA-RUTA.md` y el último `RESUMEN.md`. Solo si la ruta es C o D se ejecuta el cuestionario completo descrito a continuación.
+
+## Paso 0 — Carga de habilidades
+
+```
+Skill("discutir-fase")
+```
+
+Si no existe, intenta `Skill("planear-fase")` o `Skill("api-rest-diseno")`. Documenta qué cargaste.
+
+## Paso 1 — Lectura de contexto previo
+
+Antes de hacer cualquier pregunta, lee el contexto disponible:
+
+1. Lee `.planning/PROYECTO.md` — contexto general del proyecto.
+2. Lee `.planning/HOJA-RUTA.md` — para entender todas las fases y su posición.
+3. Lee `.planning/REQUISITOS.md` — requisitos globales del sistema.
+4. Busca si existe `.planning/fases/0N-CONTEXTO.md` (donde N es el número de fase). Si existe, léelo — puede ser un trabajo previo que se está retomando.
+5. Si la fase N > 1, lee el CONTEXTO.md de la fase anterior para entender dependencias.
+
+Si `.planning/PROYECTO.md` no existe, DETENTE y di:
+```
+No existe .planning/PROYECTO.md. Debes inicializar el proyecto primero con /swl:nuevo-proyecto.
+```
+
+## Paso 2 — Verificación de la fase solicitada
+
+Valida que la fase N existe en el HOJA-RUTA.md:
+
+- Si la fase existe: lee su descripción y objetivos del roadmap.
+- Si la fase NO existe en el roadmap: informa al usuario y pregunta si quiere agregar la fase al roadmap antes de continuar.
+- Si el número de fase es 0 o negativo: error, pide un número válido.
+
+Muestra al usuario el nombre y descripción de la fase según el roadmap:
+```
+Vamos a discutir la Fase N: [nombre de la fase]
+Descripción en el roadmap: [descripción]
+Dependencias declaradas: [fases previas requeridas]
+
+Haré algunas preguntas para entender los detalles. Puedes responder con todo el detalle que quieras.
+```
+
+## Paso 3 — Entrevista adaptativa por bloques
+
+**El cuestionario canónico vive en `Skill("discutir-fase")`** — este comando NO
+define preguntas propias (única fuente, evita deriva). Aplica los 5 bloques del
+skill en orden:
+
+1. **Bloque 1 — Contexto** (siempre): objetivo, criterio de terminación, claridad del roadmap, restricciones de tiempo/presupuesto, decisiones previas, supuestos explícitos.
+2. **Bloque 2 — Dominio** (adaptativo): backend/API, frontend/UI, infraestructura, integración, datos/migración. Determina el tipo leyendo la descripción de la fase; las fases mixtas combinan bloques. Cambios destructivos de datos activan SIEMPRE el bloque Datos/Migración (rollback, integridad, expand-contract).
+3. **Bloque 3 — Calidad, proceso y operación** (si aplica): tests, revisión de seguridad, NFRs, observabilidad, deployment.
+4. **Bloque 4 — Dependencias y riesgos** (siempre).
+5. **Bloque 5 — Criterios de aceptación** (siempre, al final): demostración, pruebas, visto bueno, métrica de outcome.
+
+Respeta las reglas del skill: máximo 4 preguntas por mensaje, clasificar cada
+respuesta como CERRADA / ABIERTA / PENDIENTE al recibirla, no avanzar con
+PENDIENTE en ítems críticos.
+
+## Paso 4 — Preguntas de seguimiento
+
+Después de las respuestas del Bloque de dominio, revisa si hay ambigüedades. Para cada respuesta ambigua, haz UNA pregunta de seguimiento específica. Ejemplos:
+
+- "Mencionaste que los usuarios pueden tener múltiples roles — ¿un usuario puede tener rol A y B al mismo tiempo, o son exclusivos?"
+- "Dijiste que los datos se sincronizan 'frecuentemente' — ¿cada cuánto tiempo exactamente?"
+- "Mencionaste 'validación del lado del cliente' — ¿también se valida en el servidor, o solo en frontend?"
+
+Máximo 5 preguntas de seguimiento por fase. Si hay más de 5 ambigüedades, documenta las restantes en el CONTEXTO.md con la taxonomía del skill: `ABIERTA` si el usuario delega la decisión, `PENDIENTE` si bloquea el plan.
+
+## Paso 5 — Confirmación del entendimiento
+
+Presenta un resumen de lo capturado:
+
+```
+Resumen de lo discutido para la Fase N — [nombre]:
+
+OBJETIVO PRINCIPAL:
+[lo que el usuario dijo]
+
+ENTREGABLES CLAVE:
+- [entregable 1]
+- [entregable 2]
+
+REQUISITOS TÉCNICOS IDENTIFICADOS:
+- [req 1]
+- [req 2]
+
+REGLAS DE NEGOCIO:
+- [regla 1]
+
+CRITERIOS DE ACEPTACIÓN:
+- [criterio 1]
+
+RIESGOS IDENTIFICADOS:
+- [riesgo 1]
+
+PUNTOS PENDIENTES DE ACLARAR:
+- [pendiente 1] (si hay)
+
+¿Hay algo que corregir o agregar antes de generar el archivo de contexto?
+```
+
+Espera confirmación. Si hay correcciones, ajusta y presenta el resumen nuevamente.
+
+## Paso 6 — Generación del archivo de contexto
+
+Una vez confirmado, crea `.planning/fases/0N-CONTEXTO.md` (donde N es el número de fase con cero a la izquierda si N < 10, ej: `01-CONTEXTO.md`, `02-CONTEXTO.md`).
+
+**TDD es default ON** (gate G2, decisión D-07 vNext): NO preguntes "¿quieres TDD?".
+La fase se ejecuta con ciclo RED→GREEN→REFACTOR y evidencia en telemetría salvo que
+el usuario pida desactivarlo explícitamente. Si lo desactiva: exige la razón, regístrala
+en el campo `**TDD**` del CONTEXTO y anota la excepción en `.planning/AUDITORIA.md`
+(el opt-out se declara y registra — nunca es silencioso).
+
+Estructura del archivo: usar la **plantilla canónica**
+`habilidades/discutir-fase/recursos/plantilla-contexto.md` (única fuente,
+compartida con el skill). Leerla antes de escribir; incluye el frontmatter con
+gate TDD, la tabla de decisiones CERRADA/ABIERTA/PENDIENTE, supuestos
+explícitos, no-goals, los criterios de aceptación con REQ-IDs namespaceados
+(`REQ-<fase>-NN`, trazabilidad G4), métrica de outcome, NFRs/observabilidad y
+rollback. Las secciones *(si aplica)* se omiten cuando la fase no las toca.
+
+## Paso 7 — Reporte al usuario
+
+Al terminar:
+
+1. Ruta absoluta del archivo generado.
+2. Número de requisitos técnicos capturados.
+3. Número de decisiones pendientes (si hay, destacar como acción requerida).
+4. Próximo paso: "Ya puedes planear esta fase con `/swl:planear-fase N`"
+
+## Reglas de comportamiento
+
+- NUNCA hagas todas las preguntas de un bloque de golpe si son más de 4. Divide en sub-bloques.
+- NUNCA asumas la respuesta a una pregunta aunque parezca obvia.
+- Si el usuario dice "como siempre" o "igual que antes", pregunta para verificar — las asunciones son la fuente principal de retrabajo.
+- El archivo CONTEXTO.md debe ser comprensible sin haber participado en la conversación.
+- Escribe el archivo en español-MX con formato Markdown limpio.
+- Si el usuario no sabe algo importante: regístralo como `ABIERTA` (si delega la decisión al agente) o `PENDIENTE` (si bloquea el plan) y continúa — no bloquees el proceso, pero NUNCA cierres la discusión con `PENDIENTE` en ítems críticos (Regla 3 del skill).