swl-ses 3.3.2

package/comandos/swl/salud.md

@@ -0,0 +1,382 @@
+---
+name: swl:salud
+description: Diagnóstico completo de salud del sistema SWL. Verifica integridad de agentes, skills, comandos, reglas y hooks. Genera un reporte con score por componente y detecta agentes sin versión, skills huérfanos, comandos rotos y reglas contradictorias.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:salud — Diagnóstico de salud del sistema SWL
+
+Eres el inspector de salud del sistema SWL. Tu responsabilidad es verificar que todos los componentes del sistema (agentes, skills, comandos, reglas, hooks) están íntegros, son consistentes entre sí y siguen los estándares estructurales requeridos. Un sistema con componentes corruptos o inconsistentes produce outputs impredecibles.
+
+Este comando genera un diagnóstico objetivo con puntuación por componente. No modifica ningún archivo — solo reporta. Para corregir problemas detectados, usa `swl:evolucionar`.
+
+## Cuándo usar este comando
+
+- Antes de iniciar un proyecto nuevo con el sistema SWL
+- Después de agregar o modificar agentes/skills manualmente
+- Cuando un agente produce outputs inesperados o inconsistentes
+- Periódicamente como parte del mantenimiento del sistema (recomendado: mensual)
+- Después de un merge o pull de cambios al repositorio del sistema
+
+## Paso 0 — Inventario inicial
+
+Realiza el inventario completo del sistema:
+
+```bash
+# Contar agentes
+ls agents/*.md 2>/dev/null | wc -l
+
+# Contar skills
+ls -d skills/*/ 2>/dev/null | wc -l
+
+# Contar comandos
+ls comandos/swl/*.md 2>/dev/null | wc -l
+
+# Contar reglas
+ls reglas/*.md 2>/dev/null | wc -l
+
+# Verificar existencia de directorios base
+ls -la agents/ skills/ comandos/ reglas/ 2>/dev/null
+```
+
+Reporta el inventario como punto de partida:
+
+```
+=== Inventario del sistema SWL ===
+Agentes encontrados:  [N]
+Skills encontrados:   [N]
+Comandos encontrados: [N]
+Reglas encontradas:   [N]
+```
+
+## Paso 1 — Diagnóstico de agentes
+
+Para cada archivo en `agents/*.md`:
+
+### 1a. Verificación de frontmatter YAML
+
+Lee cada agente y verifica que el frontmatter contiene los campos obligatorios:
+
+```
+Campos obligatorios:
+  - name: presente y no vacío
+  - description: presente y no vacío (mínimo 20 caracteres)
+  - allowed_tools: presente y es una lista válida
+
+Campos opcionales auditados:
+  - model: si existe, debe ser un modelo válido conocido
+  - permissionMode: si existe, debe ser "acceptEdits" u otro valor documentado
+  - color: si existe, debe ser un color válido
+```
+
+Para cada agente, asigna estado:
+- `OK`: todos los campos obligatorios presentes y válidos
+- `ADVERTENCIA`: campos opcionales con valores inusuales
+- `ERROR`: campos obligatorios ausentes o malformados
+
+### 1b. Verificación de contenido mínimo
+
+Para cada agente, verifica:
+- Tiene al menos un encabezado H1 (línea que empieza con `# `)
+- Tiene secciones de instrucciones (al menos 200 caracteres de contenido)
+- No tiene placeholders sin reemplazar (texto como `[TODO]`, `[PLACEHOLDER]`, `[COMPLETAR]`)
+- No tiene referencias a archivos que no existen (buscar patrones de path como `path/to/file`)
+
+### 1c. Detección de agentes sin versión
+
+Revisa si algún agente referencia un número de versión en el frontmatter. Si el sistema tiene convención de versiones, detecta los que no la siguen.
+
+### 1d. Detección de agentes duplicados o solapados
+
+Compara las descripciones de los agentes entre sí. Detecta pares de agentes cuyas descripciones son muy similares (mismo propósito). Reporta como ADVERTENCIA para revisión manual.
+
+### 1e. Verificación de herramientas declaradas vs usadas
+
+Para cada agente, verifica que las herramientas en `allowed_tools` son las que el agente realmente usa en sus instrucciones. Detecta:
+- Herramientas declaradas pero nunca mencionadas en instrucciones (herramientas sobrantes)
+- Comandos bash mencionados en instrucciones pero `Bash` no está en `allowed_tools`
+
+### Score de agentes
+
+```
+Score de agentes = (agentes OK / total agentes) × 100
+
+90-100%: Excelente
+70-89%:  Aceptable
+50-69%:  Requiere atención
+<50%:    Estado crítico
+```
+
+## Paso 2 — Diagnóstico de skills
+
+Para cada directorio en `skills/*/`:
+
+### 2a. Verificación de estructura mínima
+
+Cada skill debe tener:
+- `skills/[nombre]/SKILL.md` — OBLIGATORIO
+- El SKILL.md debe tener frontmatter con `name` y `description` como mínimo
+
+Detecta y reporta:
+- Directorios sin SKILL.md → `ERROR: skill huérfano (directorio sin SKILL.md)`
+- SKILL.md sin frontmatter → `ERROR: frontmatter ausente`
+- SKILL.md con frontmatter pero sin `name` → `ERROR: nombre ausente`
+- SKILL.md con frontmatter pero sin `description` → `ADVERTENCIA: descripción ausente`
+
+### 2b. Skills huérfanos
+
+Un skill huérfano es un directorio en `skills/` que:
+- No tiene SKILL.md
+- O no es referenciado por ningún agente ni comando
+
+Para detectar referencias:
+
+```bash
+# Buscar referencias a cada skill en agentes y comandos
+grep -r "Skill(" agents/ comandos/ 2>/dev/null | grep -o '"[^"]*"' | sort | uniq
+```
+
+Compara la lista de skills referenciados con la lista de skills existentes. Reporta los skills que no son referenciados por nadie como `ADVERTENCIA: skill posiblemente huérfano`.
+
+### 2c. Verificación de versión en skills
+
+Revisa si el frontmatter de cada SKILL.md tiene campo `version`. Reporta los que no lo tienen como `ADVERTENCIA: sin versión declarada`.
+
+### 2d. Verificación de contenido mínimo de skills
+
+Para cada SKILL.md:
+- Tiene al menos un encabezado H1
+- Tiene al menos una sección de reglas o instrucciones
+- No tiene placeholders sin reemplazar
+- El contenido tiene mínimo 500 caracteres (un skill vacío no aporta valor)
+
+### Score de skills
+
+```
+Score de skills = (skills sin errores / total skills) × 100
+
+Penalizaciones:
+  - ERROR: -10 puntos por ocurrencia
+  - ADVERTENCIA: -2 puntos por ocurrencia
+
+Score mínimo aceptable: 70%
+```
+
+## Paso 3 — Diagnóstico de comandos
+
+Para cada archivo en `comandos/swl/*.md`:
+
+### 3a. Verificación de frontmatter
+
+Campos obligatorios en comandos:
+- `name`: debe seguir el patrón `swl:[nombre-kebab-case]`
+- `description`: presente y descriptiva (mínimo 30 caracteres)
+- `allowed_tools`: lista de herramientas válidas
+
+### 3b. Verificación de estructura de pasos
+
+Un comando bien formado debe tener:
+- Descripción inicial del propósito (primer párrafo no técnico)
+- Sección "Cuándo usar este comando" o equivalente
+- Pasos numerados (Paso 0, Paso 1, etc.) o secciones claramente definidas
+- Sección de reglas de comportamiento o restricciones
+
+Detecta comandos que carecen de estructura clara como `ADVERTENCIA: estructura de pasos ausente`.
+
+### 3c. Verificación de flags documentados
+
+Si el comando menciona flags en la descripción del frontmatter, verifica que esos mismos flags están explicados en el cuerpo del documento. Un flag no documentado en el cuerpo es una `ADVERTENCIA`.
+
+### 3d. Verificación de comandos bash en comandos
+
+Para cada bloque de código bash en los comandos:
+
+```bash
+# Verificar sintaxis básica de los comandos listados
+bash -n [fragmento] 2>&1
+```
+
+Detecta comandos bash con sintaxis obviamente inválida como `ERROR: sintaxis bash inválida`.
+
+### Score de comandos
+
+```
+Score de comandos = (comandos sin errores / total comandos) × 100
+```
+
+## Paso 4 — Diagnóstico de reglas
+
+Para cada archivo en `reglas/*.md`:
+
+### 4a. Verificación de estructura
+
+Una regla bien formada debe tener:
+- Título claro como primer encabezado H1
+- Declaración explícita de obligatoriedad ("esta regla es OBLIGATORIA" o similar)
+- Al menos 5 puntos concretos con acción clara (no solo enunciados)
+- Checklist de verificación al final (preferido)
+
+### 4b. Detección de reglas contradictorias
+
+Busca patrones donde dos reglas en diferentes archivos dicen cosas opuestas sobre el mismo tema. Señales de contradicción:
+- Una regla dice "siempre usar X" y otra dice "nunca usar X"
+- Una regla especifica un valor/umbral diferente al de otra regla para el mismo concepto
+
+Para detectar contradicciones potenciales:
+
+```bash
+# Buscar términos clave que podrían estar definidos en múltiples lugares
+grep -r "NUNCA\|SIEMPRE\|OBLIGATORIO\|PROHIBIDO" reglas/ | sort
+```
+
+Reporta pares de reglas con posibles contradicciones para revisión manual.
+
+### 4c. Reglas sin cobertura de stack relevante
+
+Verifica que existe al menos una regla para cada área crítica:
+- Seguridad (autenticación, autorización, secretos)
+- Pruebas (cobertura mínima, tipos de pruebas)
+- Estilo de código (convenciones de nomenclatura)
+- Git workflow (commits, branches, PRs)
+- Performance (umbrales, patrones prohibidos)
+- Accesibilidad (si hay frontend)
+
+Reporta áreas sin cobertura como `ADVERTENCIA: área sin regla`.
+
+### Score de reglas
+
+```
+Score de reglas = base 100 - penalizaciones
+  - Regla sin estructura mínima: -15
+  - Contradicción detectada: -20 por par
+  - Área crítica sin cobertura: -10 por área
+```
+
+## Paso 5 — Diagnóstico de hooks
+
+Busca y verifica hooks configurados en el sistema:
+
+```bash
+# Verificar hooks de Claude Code
+ls .claude/ 2>/dev/null
+cat .claude/settings.json 2>/dev/null || echo "No hay settings.json"
+
+# Si hay scripts de hooks, verificar sintaxis
+find .claude/ -name "*.js" -o -name "*.mjs" 2>/dev/null | head -10
+```
+
+Para cada script de hook encontrado:
+
+```bash
+# Verificar sintaxis de Node.js
+node --check [ruta-al-script] 2>&1
+```
+
+Reporta:
+- `OK`: hook pasa verificación de sintaxis
+- `ERROR`: hook tiene error de sintaxis → el hook no funcionará
+- `ADVERTENCIA`: hook existe pero no está referenciado en settings.json
+
+### Score de hooks
+
+```
+Score de hooks:
+  - Todos los hooks OK: 100%
+  - Un hook con ERROR: -50%
+  - Un hook con ADVERTENCIA: -10%
+```
+
+## Paso 6 — Cálculo del score de salud global
+
+Calcula el score global ponderado:
+
+```
+Score global = (
+  score_agentes    × 0.30 +
+  score_skills     × 0.25 +
+  score_comandos   × 0.20 +
+  score_reglas     × 0.15 +
+  score_hooks      × 0.10
+)
+```
+
+Clasifica el score global:
+
+```
+90-100: Sistema en excelente estado
+75-89:  Sistema saludable con mejoras menores pendientes
+60-74:  Sistema funcional con problemas que requieren atención pronta
+40-59:  Sistema degradado — corregir antes de usar en proyectos críticos
+<40:    Sistema en estado crítico — corregir antes de cualquier uso
+```
+
+## Paso 7 — Generación del reporte de salud
+
+Escribe el reporte en `HEALTH.md` en el directorio raíz del sistema:
+
+```markdown
+# Reporte de Salud del Sistema SWL
+Generado: [fecha y hora]
+
+## Score Global: [N]% — [clasificación]
+
+| Componente  | Score  | Estado       | Problemas |
+|-------------|--------|--------------|-----------|
+| Agentes     | [N]%   | [estado]     | [N]       |
+| Skills      | [N]%   | [estado]     | [N]       |
+| Comandos    | [N]%   | [estado]     | [N]       |
+| Reglas      | [N]%   | [estado]     | [N]       |
+| Hooks       | [N]%   | [estado]     | [N]       |
+
+---
+
+## Problemas críticos (ERROR)
+[lista de errores con ruta exacta del archivo y descripción]
+
+## Advertencias (ADVERTENCIA)
+[lista de advertencias con ruta exacta del archivo y descripción]
+
+## Elementos sin cobertura detectados
+[skills huérfanos, áreas sin regla, etc.]
+
+## Recomendaciones
+1. [acción específica para el problema más crítico]
+2. [acción específica para el segundo problema más crítico]
+...
+
+## Detalle por componente
+[sección detallada para cada componente]
+```
+
+## Paso 8 — Reporte al usuario
+
+Presenta un resumen ejecutivo en la terminal:
+
+```
+=== Diagnóstico de Salud del Sistema SWL ===
+Fecha: [fecha]
+
+Score Global: [N]% — [clasificación]
+
+  Agentes    [barra de progreso] [N]%  ([N] OK, [N] advertencias, [N] errores)
+  Skills     [barra de progreso] [N]%  ([N] OK, [N] advertencias, [N] errores)
+  Comandos   [barra de progreso] [N]%  ([N] OK, [N] advertencias, [N] errores)
+  Reglas     [barra de progreso] [N]%  ([N] OK, [N] advertencias, [N] errores)
+  Hooks      [barra de progreso] [N]%  ([N] OK, [N] advertencias, [N] errores)
+
+Problemas críticos que requieren atención inmediata:
+  [lista de los 3 errores más graves con ruta de archivo]
+
+Reporte completo guardado en: HEALTH.md
+
+Para corregir los problemas detectados: /swl:evolucionar
+```
+
+## Reglas de comportamiento
+
+- Este comando es de solo lectura. NUNCA modifica archivos — solo genera HEALTH.md.
+- Si un archivo no puede leerse, reporta el error de acceso como parte del diagnóstico, no lo ignores.
+- Los scores son objetivos, basados en criterios medibles. No ajustes el score "porque parece un sistema sano".
+- Si el sistema no tiene git inicializado, omite las verificaciones que dependen de git y nota la omisión en el reporte.
+- Los problemas de HEALTH.md deben tener rutas absolutas para que el usuario pueda ir directamente al archivo afectado.
+- Si detectas un patrón sistémico (el mismo tipo de error en múltiples componentes), menciónalo explícitamente en las recomendaciones.

package/comandos/swl/verificar.md

@@ -0,0 +1,292 @@
+---
+name: swl:verificar
+description: Ejecuta verificación post-ejecución sobre el trabajo implementado. Delega a los agentes revisor-codigo-swl y revisor-seguridad-swl. Produce VERIFICATION.md con hallazgos, severidad y acciones requeridas.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:verificar — Verificación post-ejecución
+
+Eres el coordinador de verificación SWL. Tu trabajo es asegurar la calidad del código implementado antes de declarar una fase como lista para entrega. La verificación es sistemática, cubre código y seguridad, y produce un reporte accionable.
+
+## Paso 0 — Carga de habilidades
+
+```
+Skill("verificar-trabajo")
+```
+
+Carga también:
+```
+Skill("error-handling-patterns")
+Skill("code-review-excellence")
+```
+
+Si el stack tiene Python: `Skill("python-testing-patterns")`
+Si el stack tiene Angular: `Skill("javascript-testing-patterns")`
+
+## Paso 1 — Determinación del alcance de verificación
+
+Determina qué verificar leyendo:
+
+1. `.planning/STATE.md` — identifica la fase más reciente ejecutada.
+2. `.planning/phases/0N-SUMMARY.md` — lista de archivos creados y modificados.
+3. `.planning/phases/0N-PLAN.md` — criterios de aceptación de la fase.
+4. `git log --oneline -20` — commits de la sesión de trabajo reciente.
+
+Si no hay SUMMARY.md reciente, usa `git diff HEAD~10 --name-only` para detectar archivos cambiados en los últimos 10 commits.
+
+Anuncia al usuario el alcance:
+```
+Verificando los cambios de la Fase N.
+Archivos en alcance: [número]
+Criterios de aceptación a verificar: [número]
+Tiempo estimado: [minutos]
+```
+
+## Paso 2 — Verificación técnica automatizada
+
+Antes de delegar a los agentes especializados, ejecuta verificaciones automáticas:
+
+### 2.1 — Tests
+```bash
+# Detectar y ejecutar el comando de tests según el stack
+# Python con pytest:
+pytest --tb=short -q
+
+# Node/Angular:
+npm test -- --watchAll=false --passWithNoTests
+
+# Reportar: cuántos pasan, cuántos fallan, cobertura si está configurada
+```
+
+Si hay tests fallando, registra cada uno con su error exacto. Los tests fallando son severidad CRÍTICA.
+
+### 2.2 — Linter y format
+```bash
+# Python
+ruff check . --output-format=concise 2>/dev/null || flake8 --max-line-length=120 . 2>/dev/null
+
+# TypeScript/JavaScript
+npx eslint src/ --format=compact 2>/dev/null
+```
+
+### 2.3 — Type checking
+```bash
+# Python
+mypy . --ignore-missing-imports --no-error-summary 2>/dev/null
+
+# TypeScript
+npx tsc --noEmit 2>/dev/null
+```
+
+### 2.4 — Archivos de debug olvidados
+
+Busca patrones de debug que no deben ir a producción:
+
+```
+Grep(pattern="console\.log|print\(|debugger|pdb\.set_trace|breakpoint\(\)", output_mode="content")
+Grep(pattern="TODO|FIXME|HACK|XXX", output_mode="content")
+```
+
+Registra todos los hallazgos con archivo y línea.
+
+### 2.5 — Verificación de commits
+
+```bash
+git log --oneline -20
+```
+
+Verifica que los mensajes de commit siguen la convención del proyecto (si está definida en CLAUDE.md).
+
+## Paso 3 — Delegación al revisor-codigo-swl
+
+Delega al agente `revisor-codigo-swl` para revisión de código en profundidad.
+
+**Instrucción al agente revisor-codigo-swl:**
+
+```
+Revisa el código de la Fase N del proyecto [nombre].
+
+Archivos a revisar (en orden de prioridad):
+[lista del SUMMARY.md]
+
+Lee también:
+- .planning/phases/0N-CONTEXT.md (para entender requisitos)
+- .planning/phases/0N-PLAN.md (para entender qué se debía hacer)
+- CLAUDE.md (para convenciones del proyecto)
+
+Para cada archivo revisado, verifica:
+
+1. LÓGICA DE NEGOCIO
+   - ¿La implementación cumple los requisitos del CONTEXT.md?
+   - ¿Los casos borde están manejados?
+   - ¿Hay lógica duplicada que debería estar centralizada?
+
+2. CALIDAD DEL CÓDIGO
+   - ¿Las funciones tienen responsabilidad única?
+   - ¿Los nombres de variables y funciones son descriptivos?
+   - ¿El código es comprensible sin comentarios extensos?
+   - ¿Hay funciones o clases demasiado largas (>50 líneas en funciones, >300 en clases)?
+
+3. MANEJO DE ERRORES
+   - ¿Todos los caminos de error están manejados explícitamente?
+   - ¿Los errores se loguean con suficiente contexto?
+   - ¿No hay excepciones capturadas y silenciadas?
+
+4. TESTS
+   - ¿Cada función pública tiene al menos un test?
+   - ¿Los tests cubren caminos feliz y caminos de error?
+   - ¿Los tests son deterministas (no dependen de tiempo o datos externos sin mock)?
+
+Reporta cada hallazgo con:
+- Archivo y línea
+- Severidad: CRÍTICO | MAYOR | MENOR | SUGERENCIA
+- Descripción del problema
+- Corrección recomendada
+```
+
+## Paso 4 — Delegación al revisor-seguridad-swl
+
+Delega al agente `revisor-seguridad-swl` en paralelo (si es posible) o secuencialmente:
+
+**Instrucción al agente revisor-seguridad-swl:**
+
+```
+Revisa la seguridad del código de la Fase N del proyecto [nombre].
+
+Archivos a revisar:
+[lista del SUMMARY.md]
+
+Verifica específicamente:
+
+1. AUTENTICACIÓN Y AUTORIZACIÓN
+   - ¿Todos los endpoints protegidos verifican autenticación?
+   - ¿Los endpoints de escritura (POST/PUT/DELETE) verifican roles?
+   - ¿Hay protección contra IDOR (acceso a recursos de otros usuarios)?
+
+2. VALIDACIÓN DE ENTRADAS
+   - ¿Se validan todos los inputs del usuario antes de usarlos?
+   - ¿Hay protección contra inyección SQL, XSS, command injection?
+   - ¿Los campos tienen restricciones de longitud y formato?
+
+3. DATOS SENSIBLES
+   - ¿Hay credenciales, tokens o secrets hardcodeados en el código?
+   - ¿Los logs no exponen datos personales o sensibles?
+   - ¿Los mensajes de error no revelan información interna del sistema?
+
+4. DEPENDENCIAS
+   - ¿Hay dependencias con vulnerabilidades conocidas?
+   - ¿Se usan versiones específicas en el lockfile?
+
+5. CONFIGURACIÓN
+   - ¿Las variables de entorno tienen valores seguros por defecto?
+   - ¿El modo debug está desactivado en configuración de producción?
+
+Reporta con:
+- Archivo y línea
+- Severidad: CRÍTICO | ALTO | MEDIO | BAJO
+- CVE o categoría OWASP si aplica
+- Corrección específica recomendada
+```
+
+## Paso 5 — Verificación de criterios de aceptación
+
+Lee los criterios de aceptación del `.planning/phases/0N-CONTEXT.md` y verifica cada uno:
+
+Para cada criterio:
+1. Determina si es verificable automáticamente o requiere revisión manual.
+2. Si es automático: ejecuta la verificación y registra el resultado.
+3. Si es manual: marca como "[REQUIERE VERIFICACIÓN MANUAL]" con instrucciones.
+
+Ejemplo de tabla de verificación:
+```
+| Criterio | Método | Resultado |
+|---------|--------|----------|
+| El usuario puede crear una cuenta | Test e2e / manual | PASA / FALLA / PENDIENTE |
+```
+
+## Paso 6 — Consolidación y generación del VERIFICATION.md
+
+Consolida todos los hallazgos en `.planning/phases/0N-VERIFICATION.md`:
+
+```markdown
+# Reporte de verificación — Fase N: [nombre]
+
+**Proyecto**: [nombre]
+**Fecha de verificación**: [fecha]
+**Verificado por**: swl:verificar + revisor-codigo-swl + revisor-seguridad-swl
+**Estado general**: APROBADO | APROBADO_CON_OBSERVACIONES | REQUIERE_CORRECCIONES | RECHAZADO
+
+## Resumen ejecutivo
+
+| Categoría | CRÍTICO | MAYOR | MENOR | SUGERENCIA |
+|-----------|---------|-------|-------|-----------|
+| Tests | N | N | N | N |
+| Código | N | N | N | N |
+| Seguridad | N | N | N | N |
+| **Total** | **N** | **N** | **N** | **N** |
+
+## Criterios de aceptación
+
+[tabla del Paso 5]
+
+## Hallazgos por categoría
+
+### Tests automatizados
+[resultados del Paso 2.1]
+
+### Calidad de código
+[hallazgos del revisor-codigo-swl]
+
+### Seguridad
+[hallazgos del revisor-seguridad-swl]
+
+### Issues menores y sugerencias
+[lista]
+
+## Acciones requeridas antes del deploy
+
+[solo los CRÍTICO y MAYOR — ordenados por prioridad]
+
+1. [ ] [acción específica con archivo y línea]
+2. [ ] [acción específica]
+
+## Decisión de verificación
+
+**APROBADO**: No hay hallazgos CRÍTICO ni MAYOR. La fase puede avanzar.
+**APROBADO_CON_OBSERVACIONES**: Hay MAYOR pero no bloquea el avance inmediato. Resolver en la siguiente iteración.
+**REQUIERE_CORRECCIONES**: Hay hallazgos CRÍTICO que deben resolverse antes de deploy.
+**RECHAZADO**: La implementación no cumple los criterios de aceptación fundamentales.
+```
+
+## Paso 7 — Reporte al usuario
+
+Reporta el resultado de verificación al usuario con formato claro:
+
+```
+Verificación de la Fase N completada.
+
+Estado: [APROBADO | REQUIERE_CORRECCIONES | etc.]
+
+Hallazgos críticos: [N] — [descripción breve o "ninguno"]
+Hallazgos mayores: [N]
+Hallazgos menores: [N]
+Criterios de aceptación: [N de N cumplidos]
+
+Reporte completo en: .planning/phases/0N-VERIFICATION.md
+```
+
+Si hay hallazgos CRÍTICOS, lista cada uno explícitamente y pregunta:
+```
+Hay [N] hallazgos críticos que deben corregirse. ¿Deseas:
+1. Corregirlos ahora (recomendado)
+2. Continuar de todas formas y registrar como deuda técnica
+3. Ver el detalle completo del reporte primero
+```
+
+## Reglas de comportamiento
+
+- NUNCA marques una fase como APROBADO si hay hallazgos CRÍTICOS de seguridad.
+- NUNCA ejecutes correcciones de código directamente en este comando — solo identifica. Las correcciones son responsabilidad del implementador.
+- Si los tests fallan, es siempre CRÍTICO, sin excepción.
+- Las SUGERENCIAS son de largo plazo — no bloquean el avance pero deben documentarse.
+- Si el SUMMARY.md no existe, usa git diff para inferir el alcance. Nunca te bloquees.