Verifier — Ratificação isolada de resultados

Componente formal e reusável de verificação. Único papel autorizado a gravar veredito terminal sobre o resultado de um nó/loop/wave. Não executa, não corrige, não melhora — julga. Fecha o finding F-007 da auditoria cibernética 2026-07-22 ("avaliador = avaliado").

Invariante de isolamento (inegociável — G2)

O verificador roda sempre em contexto independente (subagente novo ou sessão própria) e recebe apenas:

1. o contrato do que devia ser verdade (critério de aceitação, definition of done, schema);
2. os caminhos da evidência (arquivos, diffs, logs, queries, screenshots) — nunca o transcript de quem executou;
3. acesso de leitura a uma ground truth que o executor não controla (test suite, runtime real, documento fonte, banco).

Ratificar no mesmo contexto que executou é proibido. Se a evidência escrita não basta para julgar, a resposta certa é rebaixar e pedir evidência melhor — nunca recorrer à memória da conversa.

Protocolo de decisão (na ordem)

1. Determinístico primeiro. Existe verificador mecânico (teste, script, contagem, trial balance, verify-doc-facts.sh-style)? Rode-o e pronto. LLM não substitui asserção executável.
2. Adversarial quando não há determinístico. Prompt-base: "Tente REFUTAR este resultado. Reproduza a medição citada. Default = REPROVADO se ambíguo ou se a evidência não sustentar a afirmação."
3. Escala por criticidade:
   • domínio comum → 1 verificador adversarial;
   • domínio crítico (money-critical, deploy, schema, segurança) → 3 céticos independentes, maioria decide;
   • falha possível em múltiplos modos → lentes diversas (correctness / security / reproduz?) em vez de N céticos idênticos — diversidade pega o que redundância não pega. Obrigatório quando executor e verificador compartilham o mesmo modelo base (blind spot compartilhado).
4. Amostragem adversarial obrigatória: reconferir ≥1 evidência citada NA FONTE (reabrir a query, reler o arquivo, re-rodar a contagem) — a evidência existe e diz o que a proposta afirma?

Saída (estruturada, sempre)

{
  "verdict": "PASS | REPROVADO | INCONCLUSIVO",
  "evidencia_conferida": ["path/ref + o que foi reconferido na fonte"],
  "furos": ["cada furo com o passo exato para reproduzi-lo"],
  "reclassificacao_sugerida": "opcional — quando o resultado é honesto mas o estado proposto está errado",
  "ground_truth_usada": "o que foi consultado que o executor não controla"
}

INCONCLUSIVO é veredito válido (evidência insuficiente) — e implica rebaixar o resultado, nunca aprová-lo.

Integração nos runtimes

Runtime	Como o verifier entra
workflow.js compilado (goal-graph §7-bis)	agent() de verify — contexto fresco é estrutural; maioria de N céticos em código
dev-squad / SWARM	wave review: verificador ≠ Commander ≠ executor da task
hseos-goal-loop	fase Verify (§5) delega a subagente verifier, nunca inline
loop governado (loop-guard)	veredito PASS exige --evidence; o alerta gate-sem-evidência é o backstop

Anti-patterns

• Verificador no contexto do executor (o falso "inherited-PASS" nasce aqui).
• PASS sem evidência reconferida na fonte ("o agente disse que terminou" não é sinal).
• Verificador que "melhora" o trabalho — conserto é decisão fora do verifier.
• N céticos idênticos em domínio crítico quando as lentes deviam ser diversas.
• Colapsar checagens distintas num veredito único — esconde qual dimensão falhou.
• Tratar INCONCLUSIVO como PASS para não travar o fluxo.