| name | sf-verify |
| description | Verificación adversarial. Intenta refutar las inferencias del SYSTEM-MAP antes de presentarlas al usuario, y hace la pasada anti-contradicciones del spec completo antes de emitir. Úsala tras sf-map (modo inferencias) y al entrar en fase de cierre (modo spec completo). |
sf-verify — Refutar antes de cementar
Ejecuta el sub-agente Verificador (../../agents/verifier.md). Su postura es adversarial: busca el contraejemplo, no la confirmación. Una inferencia errónea que el usuario confirme por descuido queda cementada en el spec y envenena todo lo que se genere después.
Modo 1 — Verificar inferencias (tras sf-map)
- Toma las afirmaciones
[inferido] del SYSTEM-MAP.md.
- Lanza verificadores (en paralelo si el entorno lo permite; agrupa afirmaciones afines por lote para no lanzar uno por trivialidad). Cada verificador:
- Relee la evidencia citada: ¿de verdad sostiene la afirmación?
- Busca activamente el contraejemplo en el material.
- Devuelve veredicto: verificado ✅ (con la evidencia adicional que descarta el contraejemplo) · refutado ❌ (con el contraejemplo
archivo:línea y la afirmación corregida) · indecidible ⚠️ (→ pregunta de entrevista).
- Actualiza el
SYSTEM-MAP.md con los veredictos y registra el resultado en el journal.
- Regla: ante la duda, indecidible. Un falso "verificado" es peor que una pregunta de más.
Modo 2 — Pasada del spec completo (fase de cierre, antes de emitir)
Con SPEC.draft.md + CONTEXT.draft.md + adr/ completos, busca en este orden:
- Violaciones del glosario (sinónimos de Evitar usados, términos sin definir, definidos y no usados).
- Flujos (S4) imposibles con la arquitectura (S5).
- NFR (S6) inalcanzables con la arquitectura — casi siempre un ADR faltante o una corrección.
- Prioridades incoherentes (P1 que depende de P3; flujo crítico sobre módulo P3).
- Criterios de éxito no medibles o que ninguna funcionalidad satisface.
- Contradicciones entre secciones y contra los ADRs.
Salida: hallazgos con severidad (bloquea-emisión | advertencia) y corrección propuesta. Los bloqueantes se resuelven con el usuario ANTES de sf-emit. Registra la pasada en el journal.
Reglas
- Solo lectura; el Verificador propone, el hilo principal decide con el usuario.
- Toda refutación lleva contraejemplo con evidencia; sin evidencia es opinión.
- Si no hay hallazgos, decláralo con las comprobaciones realizadas (no un "todo bien" vacío).
