---
name: proceso-autoverificacion-evidencias
description: >
  Protocolo de auto-verificación post-implementación basado en las Four
  Questions (tests passing / requirements met / assumptions verified /
  evidence exists) + 7 red flags de alucinación. Cargar al cerrar una
  feature, bugfix o refactor — antes de reportar "completado" al usuario,
  antes del commit final, antes de mergear. Adaptación del SelfCheckProtocol
  de SuperClaude_Framework, accuracy reportada 94% en detección de claims
  no verificadas.
version: "1.0.0"
herramientasPermitidas: [Read, Grep, Glob, Bash]
exclusiones:
  - "No cargar para cambios triviales (typo, formato, comentario) — los checks no aportan valor."
  - "No cargar en mitad de la implementación; este skill aplica al CIERRE. Para verificación pre-implementación usar `proceso-confianza-pre-implementacion`."
  - "No cargar si ya se ejecutó `/swl:verificar` o el revisor de código emitió veredicto APROBADO — esos cubren el rol al nivel de fase/sesión."
  - "No cargar para trabajo de research/discovery donde no hay implementación que cerrar."
evolvable: true
---

# Habilidad: Auto-verificación con evidencias

## Propósito

Cerrar el trabajo con evidencias verificables, no con claims. El material
fuente (SuperClaude_Framework `pm_agent/self_check.py`) reporta 94% de
accuracy detectando los patrones de alucinación más comunes ("tests pass"
sin mostrar output, "implementación completa" con tests rotos, lenguaje
de incertidumbre). En SWL este patrón complementa la regla
`verificar-citas-normativas.md` (que cubre citas durante el trabajo) con
el protocolo de cierre obligatorio.

## Cuándo cargar

- Antes de reportar "completado" al usuario tras una implementación.
- Antes del commit final de una feature/bugfix/refactor.
- Antes de mergear un PR.
- Cuando un sub-agente reporta éxito y el agente padre debe validar.
- Cuando el usuario pregunta "¿está terminado?" y el agente está a punto
  de responder "sí" — pasar por las Four Questions primero.

## Cuándo NO cargar

Listado en el campo `exclusiones` del frontmatter — incluye cambios
triviales, mitad de implementación, casos donde `/swl:verificar` o el
revisor ya emitió veredicto.

---

## Las Four Questions

El protocolo es **mandatorio** — todas las cuatro preguntas se responden
explícitamente. Si una se omite, el trabajo NO está cerrado.

### Pregunta 1 — ¿Pasan todos los tests?

No basta con afirmar "los tests pasan". Hay que **mostrar el output real**
del runner.

- Ejecutar el suite con el runner del proyecto (`npm test`, `pytest`,
  `cargo test`, etc.).
- Mostrar las últimas 20-50 líneas del output que incluyen el resumen
  ("X passed, 0 failed").
- Si hay tests skipped, indicar el conteo y la razón documentada.
- Si los tests aún no se han escrito (TDD inverso, fix urgente), declararlo
  explícitamente con plan de cierre.

**Anti-patrón crítico**: "tests pasan" sin pegar el output. Es la red
flag #1 de alucinación detectada por el patrón Reflexion.

### Pregunta 2 — ¿Se cumplen todos los requisitos?

Comparar requirements vs implementación, item por item:

- Listar los requisitos originales del usuario o del plan.
- Marcar cada uno: ✅ Hecho / ⚠️ Parcial / ❌ Pendiente.
- Si hay parciales o pendientes: declarar por qué y cuándo se cierran.
- No declarar "completo" si quedan ❌ no negociados.

La regla `arreglar-al-detectar.md` prohíbe deuda silenciosa: si algo se
deja para "después", se documenta como DA formal con trigger verificable,
no como "lo dejo pendiente".

### Pregunta 3 — ¿Hay suposiciones sin verificar?

Toda suposición técnica usada durante la implementación debe estar
verificada contra fuente autoritativa:

- Suposiciones sobre APIs internas: verificadas leyendo el módulo, no por
  nombre.
- Suposiciones sobre librerías externas: verificadas en Context7 o doc
  oficial (regla `usar-context7.md`).
- Suposiciones sobre estructura del codebase: verificadas con `Grep`/`Glob`.
- Suposiciones sobre comportamiento esperado del sistema: verificadas con
  test o evidencia de ejecución.

**Anti-patrón**: dejar "probablemente funciona", "debería andar", "creo
que sí". Lenguaje de incertidumbre = red flag #7.

### Pregunta 4 — ¿Hay evidencia?

Evidencia concreta en tres ejes:

- **Test results**: output del runner pegado (no resumen propio).
- **Code changes**: lista de archivos modificados (`git diff --stat`).
- **Validation**: lint, typecheck, build exitosos — output pegado.

Si falta cualquiera de los tres, el trabajo NO está cerrado.

---

## Las 7 Red Flags de alucinación

Patrones que indican que el agente está "cerrando sin verificar". Si el
agente detecta cualquiera de estos en su propio output, debe corregir
ANTES de reportar:

1. **"Tests pass" sin output** — afirmación sin evidencia.
2. **"Everything works" sin evidencia** — claim de completitud sin pruebas.
3. **"Implementation complete" con tests rotos** — contradicción directa.
4. **Saltar mensajes de error** — el runner reportó errores y el agente
   los ignora en el reporte.
5. **Ignorar warnings** — warnings tratados como ruido en lugar de señales
   accionables.
6. **Esconder fallos** — reportar éxitos parciales como totales.
7. **Lenguaje de incertidumbre** — "probably", "should work", "might
   work" en un reporte de cierre.

Cada red flag detectada bloquea el cierre hasta que se resuelva.

---

## Formato de reporte obligatorio

Al cerrar el trabajo, emitir al usuario (o registrar en
`.planning/sessions/`) el siguiente formato:

```
### Auto-verificación de cierre

**Pregunta 1 — Tests passing?**
<output del runner pegado, últimas 20-50 líneas con resumen>
Estado: ✅ N passed / ⚠️ M skipped con razón / ❌ K failed

**Pregunta 2 — Requirements met?**
- ✅ Requisito A: <evidencia / referencia a commit / archivo:línea>
- ✅ Requisito B: <evidencia>
- ⚠️ Requisito C: parcial — <qué falta y cuándo cierra>
- ❌ Requisito D: pendiente — DA formal en `.planning/...` con trigger X

**Pregunta 3 — Assumptions verified?**
- ✅ Suposición X verificada en <fuente>
- ✅ Suposición Y verificada con <comando/test>

**Pregunta 4 — Evidence?**
- Test results: <pegado arriba>
- Code changes: `git diff --stat` →  <output>
- Validation: lint/typecheck/build → <output o "no aplica al proyecto">

**Red flags detectadas**: <lista o "ninguna">

**Veredicto**: ✅ Cerrado con evidencias / ❌ Bloqueado por <razón>
```

Si el veredicto es ❌, el agente NO reporta "completado" al usuario.
Reporta el bloqueo y propone el siguiente paso.

---

## Reglas obligatorias

1. **Evidencia, no claims**: cualquier afirmación de éxito requiere output
   pegado, no resumen propio. **Por qué**: el resumen propio puede ser
   alucinado; el output real del runner no.

2. **Las 4 preguntas son AND, no OR**: las cuatro deben pasar para cerrar.
   No se puede compensar el fallo de una con el éxito de las otras.
   **Por qué**: la regla `arreglar-al-detectar.md` exige resolver todo,
   no esquivar; cerrar con 3 de 4 es deuda silenciosa.

3. **Sin lenguaje de incertidumbre en el reporte**: las palabras
   "probablemente", "creo que", "debería", "tal vez" están prohibidas en
   el output de cierre. Si hay incertidumbre, verificarla; si no se puede
   verificar, declararla explícitamente como gap con plan de cierre.

4. **Re-leer el propio reporte**: antes de enviarlo, escanear las 7 red
   flags. La detección es self-applied — si el agente no se audita, el
   skill no funciona.

5. **Si el cierre falla, NO ocultar**: reportar el fallo al usuario en
   el mismo turno (regla `arreglar-al-detectar.md`). "Detecté que el
   Check N falla porque X — voy a corregir Y" es la respuesta correcta.

---

## Relación con otras herramientas SWL

- **Regla `verificar-citas-normativas.md`**: aplica DURANTE el trabajo a
  cada cita verificable (archivo:línea, artículo de ley, etc.). Este
  skill aplica al CIERRE del trabajo completo.
- **Skill `proceso-confianza-pre-implementacion`**: aplica al INICIO con
  las 5 dimensiones de confianza. Este aplica al CIERRE con las 4
  preguntas. Forman par.
- **Skill `verificar-trabajo`**: el agente Verificador SWL lo usa para
  validación de fase con goal-backward 4 niveles. Si se ejecutó
  `/swl:verificar` y aprobó, este skill no es necesario (cobertura
  redundante).
- **`revisor-codigo-swl`**: emite veredicto APROBADO/RECHAZADO sobre
  código terminado. Si aprobó, este skill no es necesario.
- **Skill `monitor-ci`** (regla global): aplica a CI post-push. Este
  skill aplica antes del push.

---

## Ejemplo de uso

Tras implementar el endpoint POST /facturas/cancelar:

```
### Auto-verificación de cierre

**Pregunta 1 — Tests passing?**

  PASS  tests/api/facturas-cancelar.test.ts
  PASS  tests/services/factura-service.test.ts
  Tests: 23 passed, 0 failed, 1 skipped
  Time: 4.2 s

Estado: ✅ 23 passed, 1 skipped (test de integración E2E pendiente de
fixture de pago — no bloqueante, documentado en TODO.md).

**Pregunta 2 — Requirements met?**
- ✅ Endpoint POST /facturas/{id}/cancelar: implementado en
  `backend/app/api/facturas.py:142`.
- ✅ Validación de estatus permitido (solo "pendiente" o "emitida"):
  implementada en `factura_service.py:88-101`.
- ✅ Auditoría: registro en tabla `factura_historial`: confirmado en
  test `factura-cancelar-audit.test.py:55`.

**Pregunta 3 — Assumptions verified?**
- ✅ Modelo Factura tiene método `puede_cancelarse()`: confirmado leyendo
  `models/factura.py:120-135`.
- ✅ FastAPI `Depends(get_db)` es la inyección estándar del proyecto:
  confirmado en ADR-0008 y 12 endpoints existentes.

**Pregunta 4 — Evidence?**
- Test results: pegado arriba.
- Code changes:
  3 files changed, 84 insertions(+), 2 deletions(-)
  backend/app/api/facturas.py | 32 ++++++++++++++++++--
  backend/app/services/factura_service.py | 18 +++++++++++
  backend/tests/api/facturas-cancelar.test.ts | 36 +++++++++++++++++++
- Validation: `ruff check .` → 0 errors, `mypy backend/` → 0 errors.

**Red flags detectadas**: ninguna.

**Veredicto**: ✅ Cerrado con evidencias.
```
