@saulwade/swl-ses 1.0.0

package/habilidades/verificacion-evidencia/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: verificacion-evidencia
+description: >
+  Gate function que impide afirmar éxito sin evidencia verificada. Obliga a ejecutar
+  el comando de prueba, leer la salida completa y verificar antes de cualquier
+  afirmación positiva. Cargar SIEMPRE al terminar una tarea o slice, antes de
+  reportar éxito al usuario o al orquestador.
+herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
+exclusiones:
+  - "No cargar como sustituto de `verificar-trabajo` — este skill es el gate de afirmaciones puntuales, no la verificación end-to-end de un plan completo."
+  - "No cargar para generar evidencia de métricas de negocio (conversiones, retención); eso requiere datos de analytics, no comandos de build."
+  - "No cargar si el usuario pide solo un resumen del estado del plan — leer ESTADO.md directamente es más eficiente."
+evolvable: true  # default para skill estandar
+---
+# Verificación por Evidencia
+
+Ninguna afirmación de éxito es válida sin evidencia fresca obtenida en esta sesión.
+El silencio no es éxito. La ausencia de error visible no es éxito. La confianza en
+el código no es evidencia. Solo el output del comando ejecutado ahora es evidencia.
+
+## Cuándo cargar este skill
+
+Invoca `Skill("verificacion-evidencia")` cuando:
+
+## Cuándo NO cargar
+
+- Se necesita verificar un plan completo con múltiples artefactos; usar `verificar-trabajo` que aplica los 4 niveles sistemáticamente.
+- El usuario pide reportar el estado del PLAN.md — leer ESTADO.md es suficiente, no se necesita ejecutar comandos de verificación.
+- Se busca validar que el plan tiene buena estructura antes de ejecutarlo; eso es parte de `planear-fase`.
+
+- Se va a reportar al usuario que una tarea está terminada
+- Se va a marcar un slice como completado en el PLAN.md
+- Se va a afirmar que los tests pasan, el build compila o el lint está limpio
+- Se detecta el impulso de escribir "debería funcionar" o "se ve correcto"
+- Un agente termina una fase y va a pasarle el control al siguiente
+
+## La Ley de Hierro
+
+> **NO AFIRMAR ÉXITO SIN EVIDENCIA FRESCA**
+
+Esta ley no tiene excepciones. No importa si:
+- El código "se ve correcto"
+- Funcionó en el último intento hace 10 minutos
+- Es un cambio trivial o de una sola línea
+- El agente tiene alta confianza
+
+La evidencia vence a la confianza. Siempre.
+
+## Protocolo de 5 pasos
+
+Antes de cualquier afirmación positiva, ejecutar este protocolo completo:
+
+### Paso 1 — IDENTIFICAR
+
+Responder: ¿qué comando demuestra que esto funciona?
+
+- Tests: `pytest`, `npm test`, `go test ./...`, `cargo test`
+- Build: `npm run build`, `cargo build --release`, `mvn package`
+- Lint: `ruff check .`, `eslint src/`, `golangci-lint run`
+- Type check: `mypy .`, `npx tsc --noEmit`
+- Servidor: verificar que responde con `curl` o en el navegador
+
+Si no existe un comando que lo demuestre, la tarea no está terminada.
+
+### Paso 2 — EJECUTAR
+
+Correr el comando completo. No:
+- Correr solo un subconjunto de tests
+- Usar resultados cacheados
+- Omitir flags que estuvieron presentes antes (`--coverage`, `--all-features`)
+- Interrumpir el comando antes de que termine
+
+### Paso 3 — LEER
+
+Revisar el output completo:
+- Leer hasta el final, no solo las primeras líneas
+- Verificar el exit code (0 = éxito, cualquier otro = fallo)
+- Buscar WARNINGS que indiquen degradación silenciosa
+- Contar: cuántos tests corrieron, cuántos pasaron, cuántos fallaron
+
+### Paso 4 — VERIFICAR
+
+¿El output confirma lo que se va a afirmar?
+
+| Afirmación | Evidencia requerida |
+|---|---|
+| "Los tests pasan" | Output con `N passed, 0 failed` y exit code 0 |
+| "El build compila" | Output de compilación exitosa y exit code 0 |
+| "No hay errores de lint" | Output vacío o con solo warnings, exit code 0 |
+| "El endpoint responde" | Respuesta HTTP con status 200 y body esperado |
+| "La migración aplicó" | Output confirmando tablas/columnas creadas |
+
+### Paso 5 — SOLO ENTONCES AFIRMAR
+
+Con evidencia en mano, afirmar con precisión:
+
+- Mal: "Los tests pasan"
+- Bien: "Los tests pasan: 47 passed, 0 failed, 0 errors (pytest 3.2s)"
+- Mal: "El build está listo"
+- Bien: "Build exitoso: bundle de 234KB en dist/ (npm run build, 8.4s)"
+
+Incluir siempre: resultado numérico + comando usado + tiempo si es relevante.
+
+## Red flags que activan este skill
+
+Detener y aplicar el protocolo si se detecta cualquiera de estos pensamientos:
+
+- "debería funcionar" -> ejecutar para verificar que funciona
+- "se ve correcto" -> ejecutar para confirmar que es correcto
+- "probablemente pasa" -> ejecutar para saber si pasa
+- "es un cambio trivial" -> los cambios triviales también pueden romper cosas
+- "funcionó antes" -> el estado actual puede ser diferente al de antes
+- "no necesito correr los tests para esto" -> sí necesitas
+
+## Anti-patrones
+
+### Verificación parcial
+
+Correr solo el test del módulo modificado cuando la afirmación es "los tests pasan".
+Si la afirmación es parcial, hacerla explícita: "los tests del módulo X pasan".
+
+### Leer output incompleto
+
+Leer solo las primeras líneas del output. Los errores frecuentemente aparecen al final.
+Siempre leer hasta el final, especialmente la línea de resumen.
+
+### Silencio como éxito
+
+Asumir que la ausencia de output de error significa éxito. Algunos comandos fallan
+silenciosamente. Verificar siempre el exit code.
+
+### Build cacheado
+
+Asumir que el resultado del build anterior sigue siendo válido. Si hubo cambios
+desde el último build, correr el build de nuevo.
+
+### Confianza en el modelo mental
+
+Confiar en que se entiende el código lo suficiente para saber que funciona.
+El modelo mental puede estar incompleto. La ejecución no miente.
+
+## Gotchas / Errores comunes no obvios
+
+- **Exit code ignorado en favor del output textual**: el comando devuelve "OK" en stdout pero el exit code es 1 (fallo). El agente lee "OK" y afirma éxito. Causa: el Paso 3 no incluye verificación explícita del exit code. Solución: verificar el exit code siempre (`echo $?` o capturar en el Bash tool) — el exit code es la fuente de verdad, no el texto del output.
+- **Subset de tests citado como "los tests pasan"**: el agente corre `pytest tests/modulo_nuevo/` y afirma que los tests pasan sin verificar si los tests de otros módulos afectados también pasan. Causa: el Paso 2 dice "no correr solo un subconjunto" pero el agente optimiza por velocidad. Solución: si la afirmación es global ("los tests pasan"), el comando debe ser `pytest` sin filtro de módulo; si es parcial, la afirmación debe ser explícitamente parcial.
+- **Output cacheado de build anterior**: en proyectos TypeScript con `tsc`, el compilador puede usar caché y no detectar el error introducido en la sesión actual. Causa: no se pasó `--force` ni se limpió el caché. Solución: para verificación post-cambio usar `npx tsc --noEmit` sin caché, o `rm -rf dist/ && npm run build`.
+- **Warning elevado a evidencia de éxito**: el agente cita el output de ruff como evidencia de limpieza pero el output contiene 3 warnings de `W503`. Causa: se confundió "sin errores" con "sin warnings". Solución: definir el umbral antes de ejecutar — si el criterio es "sin warnings", el exit code de ruff con warnings es 1 en modo strict.
+
+## Checklist de verificación
+
+Antes de reportar cualquier éxito:
+
+- [ ] Se identificó el comando que demuestra el éxito
+- [ ] El comando se ejecutó completo (no parcial, no cacheado)
+- [ ] Se leyó el output hasta el final
+- [ ] Se verificó el exit code
+- [ ] La afirmación incluye evidencia numérica concreta
+
+---
+*Skill creado con swl:crear-skill el 2026-03-31. Versión 1.0.0.*

package/habilidades/verificar-trabajo/SKILL.md

@@ -0,0 +1,303 @@
+---
+name: verificar-trabajo
+description: Verificación goal-backward del trabajo ejecutado en 4 niveles progresivos — EXISTE, SUSTANTIVO, CONECTADO, DATOS_FLUYEN. Detecta stubs, componentes huérfanos, integraciones rotas y flujos incompletos. Produce veredictos estructurados JSON con clasificación de riesgo (Low/Medium/High) y evidencia verificable. Soporta loop de reparación cuando el veredicto es Fail.
+version: "1.1.0"
+herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
+exclusiones:
+  - "No cargar durante la implementación activa de una tarea; la verificación es posterior a la implementación, no concurrente."
+  - "No cargar para revisar calidad de código estático (style, naming, SOLID); eso es `checklist-calidad` o el revisor de lenguaje correspondiente."
+  - "No cargar para validar que el PLAN.md está bien estructurado antes de ejecutar; eso es parte de `planear-fase`."
+  - "No cargar como único mecanismo de QA en producción — es verificación de entregables del plan, no monitoreo de sistemas en vivo."
+evolvable: true  # default para skill estandar
+---
+# Habilidad: Verificar Trabajo Ejecutado
+
+## Propósito
+
+El verificador no confía en que el código existe porque el desarrollador lo dice.
+Verifica activamente, nivel por nivel, que cada entregable del plan está presente,
+tiene implementación real (no stub), está conectado al sistema y los datos fluyen
+a través de él de extremo a extremo.
+
+## Cuándo activar
+
+- Después de ejecutar una fase completa
+- Antes de marcar una fase como "lista para producción"
+- Cuando el usuario pide revisión o QA de trabajo entregado
+- Como segunda opinión después de auto-reporte del desarrollador
+
+## Cuándo NO cargar
+
+- La tarea está en medio de la implementación — la verificación ocurre después de que el ejecutor declara que terminó.
+- Se busca revisión de calidad de código (nombres, estructura, patrones); usar `checklist-calidad` o un skill de lenguaje específico.
+- Se quiere auditar seguridad del código; usar `checklist-seguridad` o `threat-model-lite`.
+- El objetivo es verificar el estado del sistema en producción en tiempo real; este skill verifica artefactos del plan, no métricas de runtime.
+
+---
+
+## Gate Function (verificacion micro)
+
+Antes de CUALQUIER afirmacion de exito, aplicar este protocolo de 5 pasos:
+
+1. IDENTIFICAR: que comando prueba esta afirmacion?
+2. EJECUTAR: correr el comando COMPLETO (no parcial, no cached)
+3. LEER: revisar output completo Y exit code
+4. VERIFICAR: el output confirma la afirmacion?
+5. AFIRMAR: solo entonces, con la evidencia
+
+Red flags que activan el gate:
+- "deberia funcionar", "se ve correcto", "probablemente pasa"
+- Afirmaciones sin haber ejecutado verificacion
+- "Los tests pasan" sin output de test runner
+
+Este gate aplica en CADA afirmacion, no solo al final de una fase.
+El skill `verificacion-evidencia` tiene el detalle completo de este protocolo.
+
+---
+
+## Los 4 niveles de verificación
+
+### Nivel 1 — EXISTE
+
+**Pregunta**: ¿El artefacto prometido existe en el sistema de archivos / codebase?
+
+Verificaciones:
+- El archivo existe en la ruta esperada
+- La clase / función / componente declarado está presente
+- La migración de BD está en la carpeta correcta
+- El endpoint está registrado en el router
+
+Señal de falla: el archivo no existe, o existe pero está vacío, o existe pero
+tiene solo el esqueleto generado automáticamente sin contenido real.
+
+```bash
+# Verificación de existencia
+ls -la [ruta esperada]
+grep -r "class [NombreEsperado]" .
+grep -r "router\.[get|post|put|delete].*[ruta esperada]" .
+```
+
+### Nivel 2 — SUSTANTIVO
+
+**Pregunta**: ¿La implementación tiene contenido real, no es un stub?
+
+Un stub es cualquiera de:
+- Función que solo tiene `pass` / `return null` / `throw new Error("not implemented")`
+- Componente que solo renderiza un placeholder pendiente
+- Service que solo tiene la firma pero no lógica
+- Test que solo tiene `assert True` / `expect(true).toBe(true)`
+
+Verificaciones por tipo:
+
+| Tipo de artefacto | Señal de stub | Verificación real |
+|------------------|--------------|------------------|
+| Función Python | Solo `pass` o `return None` | Tiene lógica de negocio |
+| Endpoint FastAPI | Solo `return {}` | Llama a un service |
+| Componente Angular | Solo `<div>pendiente</div>` | Tiene template con datos reales |
+| Test | Solo `assert True` | Tiene assert sobre comportamiento real |
+| Migración SQL | Archivo vacío | Tiene operaciones DDL |
+
+### Nivel 3 — CONECTADO
+
+**Pregunta**: ¿El artefacto está integrado con los demás componentes del sistema?
+
+Verificaciones:
+- El endpoint está importado y registrado en el router principal
+- El service es llamado desde el endpoint (no implementado en paralelo sin uso)
+- El componente Angular está declarado en el módulo o importado en el componente padre
+- La migración está en la secuencia correcta (no rompe la cadena de alembic/flyway)
+- El modelo ORM está importado donde se usa
+
+```bash
+# Verificar que endpoint está registrado
+grep -r "include_router\|app.include" . --include="*.py"
+
+# Verificar que service es importado
+grep -r "from.*service import\|import.*Service" . --include="*.py" --include="*.ts"
+
+# Verificar cadena de migraciones (Alembic)
+alembic history | head -20
+```
+
+Señal de "orphan": el artefacto existe y tiene contenido, pero nadie lo llama.
+Un componente huérfano es código muerto desde el día uno.
+
+### Nivel 4 — DATOS_FLUYEN
+
+**Pregunta**: Si envío datos reales al sistema, llegan al destino correcto?
+
+Este es el nivel más importante y el más difícil de falsear. Requiere ejecutar
+el sistema o correr tests de integración.
+
+Estrategias de verificación:
+
+**Para APIs REST**:
+```bash
+# Llamada real al endpoint y verificar respuesta
+curl -X POST http://localhost:8000/api/v1/[recurso] \
+  -H "Content-Type: application/json" \
+  -d '{"campo": "valor"}' | jq .
+
+# Verificar que el dato llegó a la BD
+psql -c "SELECT * FROM [tabla] ORDER BY created_at DESC LIMIT 1;"
+```
+
+**Para componentes Angular**:
+- El componente renderiza datos de la API (no mocks hardcodeados)
+- Los formularios envían datos al service correcto
+- Los errores de la API se muestran al usuario
+
+**Para jobs y cron**:
+- El job se ejecuta y produce el output esperado
+- Los logs muestran la ejecución correcta
+
+---
+
+## Detección de antipatrones comunes
+
+### Hollow Component
+Un componente Angular que:
+- Tiene template pero no usa señales/variables del componente
+- Tiene métodos declarados pero no llamados desde el template
+- Recibe `@Input()` pero nunca lo renderiza
+
+### Endpoint Stub
+Un endpoint FastAPI que:
+- Devuelve datos hardcodeados sin consultar la BD
+- No valida el body (acepta cualquier cosa)
+- No usa el `db: AsyncSession` declarado en la firma
+
+### Test sin Valor
+Un test que:
+- No tiene ningún `assert` o `expect`
+- Hace assert sobre un valor hardcodeado que siempre es true
+- Prueba el mock en lugar del código real
+
+### Migración Fantasma
+Una migración que:
+- Está en la carpeta pero no en la cadena de Alembic
+- Tiene `upgrade()` vacío
+- No corresponde con los modelos ORM actuales
+
+---
+
+## Veredicto estructurado (JSON)
+
+Toda verificación DEBE producir un veredicto en formato JSON estructurado además
+del reporte VERIFICACION.md legible. El veredicto es consumible por el orquestador
+y por hooks de automatización.
+
+### Schema del veredicto
+
+```json
+{
+  "verdict": "Pass | Fail",
+  "risk": "Low | Medium | High",
+  "score": 0.85,
+  "evidence": [
+    {
+      "level": "EXISTE | SUSTANTIVO | CONECTADO | DATOS_FLUYEN",
+      "artifact": "src/api/endpoints.py",
+      "status": "Pass | Fail",
+      "detail": "Endpoint registrado en router principal línea 42"
+    }
+  ],
+  "failures": [
+    {
+      "artifact": "src/services/pago_service.py",
+      "level": "SUSTANTIVO",
+      "reason": "Función procesar_pago() solo contiene pass"
+    }
+  ],
+  "nextStep": {
+    "action": "Continue | Fix | Escalate",
+    "instructions": [
+      "Implementar lógica real en procesar_pago()",
+      "Agregar test de integración para flujo de pago"
+    ]
+  }
+}
+```
+
+### Reglas del veredicto
+
+- `verdict`: **Pass** solo si TODOS los artefactos pasan los 4 niveles. Un solo Fail → Fail.
+- `score`: proporción de (artefactos × niveles) que pasaron. Rango 0.0 a 1.0.
+- `evidence`: al menos una entrada por artefacto verificado. Sin evidencia = sin veredicto.
+- `failures`: vacío si verdict es Pass. Obligatorio si es Fail.
+- `nextStep.action`: **Continue** (pasar a siguiente fase), **Fix** (reparar y re-verificar),
+  **Escalate** (requiere decisión humana — checkpoint `decision`).
+
+### Loop de reparación
+
+Cuando el veredicto es **Fail** con `nextStep.action: "Fix"`:
+
+1. El verificador emite el veredicto con instrucciones concretas en `nextStep.instructions`.
+2. El ejecutor aplica las correcciones indicadas (NO inventa correcciones adicionales).
+3. El verificador re-ejecuta la verificación COMPLETA (no solo los items fallidos).
+4. Si el veredicto sigue siendo Fail tras 2 intentos → escalar a `nextStep.action: "Escalate"`.
+
+El ejecutor NUNCA se auto-verifica — el verificador es siempre un agente distinto
+o una segunda invocación independiente.
+
+---
+
+## Clasificación de riesgo del cambio
+
+El campo `risk` del veredicto se determina automáticamente según las características
+del cambio verificado:
+
+| Señal | Riesgo | Justificación |
+|-------|--------|---------------|
+| Eliminaciones de archivos o renombramientos | **High** | Puede romper imports y referencias |
+| Migraciones de BD (DDL) | **High** | Irreversible en producción |
+| Cambios en ≥12 archivos | **High** | Blast radius amplio |
+| Cambios en ≥6 archivos o toca backend | **Medium** | Impacto moderado |
+| Cambios en archivos de configuración (.env, CI) | **Medium** | Afecta infraestructura |
+| Cambios en <6 archivos solo frontend | **Low** | Impacto contenido |
+| Cambios solo en tests o documentación | **Low** | Sin impacto en producción |
+
+### Verificaciones dinámicas por riesgo
+
+El verificador ajusta su profundidad según el riesgo detectado:
+
+- **Low**: Niveles 1-3 obligatorios. Nivel 4 recomendado.
+- **Medium**: Los 4 niveles obligatorios. Ejecutar linter y type-checker si existen.
+- **High**: Los 4 niveles obligatorios. Ejecutar tests completos. Verificar que
+  `package.json` scripts (test, typecheck, lint) pasan. Revisar diff contra main.
+
+Detección automática de scripts disponibles:
+```bash
+# Detectar qué verificaciones están disponibles
+node -e "const p=require('./package.json');console.log(JSON.stringify(p.scripts||{}))" 2>/dev/null
+# Ejecutar condicionalmente
+npm run typecheck 2>/dev/null && echo "TYPECHECK_OK" || echo "TYPECHECK_FAIL"
+npm test 2>/dev/null && echo "TESTS_OK" || echo "TESTS_FAIL"
+```
+
+---
+
+## Plantilla de salida: `VERIFICACION.md`
+
+Para la plantilla completa con todos los campos incluyendo el bloque de veredicto
+estructurado JSON, ver [recursos/plantilla-verificacion.md](recursos/plantilla-verificacion.md).
+
+---
+
+## Gotchas / Errores comunes no obvios
+
+- **Verificación parcial elevada a veredicto Pass**: el agente verifica solo los Niveles 1-2 para un cambio de riesgo High y reporta Pass porque esos dos niveles pasaron. Causa: no se aplicaron las verificaciones dinámicas por riesgo. Solución: para cambios High, los 4 niveles son obligatorios y además se ejecutan los scripts `test`, `typecheck` y `lint` de `package.json`.
+- **Score del veredicto calculado solo sobre artefactos verificados, no sobre todos los prometidos**: si el plan prometía 8 entregables pero solo se verificaron 5, el score 1.0 sobre los 5 no es evidencia de que los 8 están correctos. Causa: el agente omite entregables del plan en la lista de artefactos. Solución: antes de verificar, listar todos los artefactos del PLAN.md y verificar cada uno explícitamente — un artefacto no verificado es un Fail implícito.
+- **Loop de reparación sin re-verificación completa**: tras el fix, el agente re-verifica solo el item que falló en lugar del veredicto completo. Causa: optimización incorrecta para ahorrar tiempo. Solución: el paso 3 del loop de reparación dice explícitamente "re-ejecutar la verificación COMPLETA" — un fix puede resolver un fallo pero introducir otro.
+- **Hollow Component no detectado en Nivel 2**: el componente Angular tiene template pero no usa ninguna señal del componente. El agente verifica que el archivo existe (Nivel 1) y que tiene contenido (Nivel 2), pero no detecta que el contenido es decorativo. Causa: la definición de "stub" en Nivel 2 no se aplicó al caso de templates sin binding. Solución: verificar explícitamente que el template usa al menos una variable/señal del componente.
+
+## Regla de oro del verificador
+
+**"Si no puedes mostrar evidencia, no puedes decir que pasa."**
+
+Cada nivel PASS debe tener evidencia adjunta en el reporte. Un "creo que funciona"
+o "debería estar conectado" no es evidencia. La evidencia es:
+- Output de un comando
+- Línea de código específica
+- Output de un test
+- Screenshot o log de ejecución

package/habilidades/verificar-trabajo/recursos/plantilla-verificacion.md

@@ -0,0 +1,60 @@
+# Plantilla: VERIFICACION.md
+
+Usar esta plantilla al generar el reporte de verificación de una fase.
+
+```markdown
+# VERIFICACION.md — Fase [N]: [Nombre]
+**Fecha**: [fecha]
+**Verificador**: [agente/persona]
+
+## Resumen ejecutivo
+- Artefactos verificados: N
+- Pasaron los 4 niveles: M
+- Con problemas: K
+- Score general: [M/N * 100]%
+
+## Verificación por artefacto
+
+### [Nombre del artefacto]
+| Nivel | Estado | Evidencia |
+|-------|--------|-----------|
+| EXISTE | PASS / FAIL | [ruta del archivo o grep result] |
+| SUSTANTIVO | PASS / FAIL | [líneas de código relevantes] |
+| CONECTADO | PASS / FAIL | [dónde se importa/registra] |
+| DATOS_FLUYEN | PASS / FAIL | [output del test o curl] |
+
+**Problemas encontrados**:
+- [descripción con archivo y línea]
+
+**Veredicto**: APROBADO / REQUIERE CORRECCIÓN
+
+[Repetir para cada artefacto]
+
+---
+
+## Hallazgos críticos (si los hay)
+1. [Descripción, archivo, línea, impacto]
+
+## Hallazgos menores
+1. [Descripción, archivo, línea]
+
+## Decisión final
+[ ] APROBADO — listo para siguiente fase
+[ ] APROBADO CON OBSERVACIONES — continuar pero resolver hallazgos menores
+[ ] RECHAZADO — requiere correcciones antes de avanzar
+
+## Veredicto estructurado
+```json
+{
+  "verdict": "Pass|Fail",
+  "risk": "Low|Medium|High",
+  "score": 0.0,
+  "evidence": [],
+  "failures": [],
+  "nextStep": { "action": "Continue|Fix|Escalate", "instructions": [] }
+}
+```
+
+## Acciones requeridas (si hay rechazos)
+- [ ] [Acción concreta con responsable y deadline]
+```