Concilium — Revisão Adversarial Entre Modelos

O que Concilium — Revisão Adversarial Entre Modelos faz?

Um segundo modelo, diferente, revisa as afirmações do usuário (ou suas) de forma adversarial. Linhagens de modelos diferentes significam pontos cegos diferentes — esse é o valor. O revisor PROPÕE; a sessão de chamada RATIFICA. Nunca deixe a confiança de nenhum dos lados substituir a evidência.

Projetado para ser orquestrado a partir do Claude Code — Opus 5 e Fable 5 são ambos assentos de ratificação de primeira classe (medidos com paridade de cadeira em um benchmark cego de previsão de resultados; qualquer modelo Claude pode conduzir o loop, mas o ratificador deve ser um dos dois). O lado GPT (sol/terra/5.5 via codex) realiza a sondagem independente e a execução mecânica — e esse assento entre famílias é estrutural: ele captura, de forma mensurável, o que cadeiras da mesma família perdem juntas.

Pré-requisitos (verificar uma vez por ambiente)

1. codex login status → deve exibir "Logged in using ChatGPT" (OAuth de assinatura — uma chave de API NÃO é necessária e uma assinatura NÃO pode ser usada como tal; não tente bridges proxy/roteador).

2. Descubra os modelos disponíveis: codex debug models ou ~/.codex/models_cache.json. Se um modelo apresentar erro "requires a newer version of Codex", execute codex update e tente novamente.

3. Na primeira vez em um novo ambiente, execute a calibração de inicialização (references/setup.md) antes de confiar em vereditos: um teste de raciocínio de verdade conhecida, depois uma tarefa real simples e, opcionalmente, um confronto direto para escolher modelos de nível.

4. Assento Kimi — EXPERIMENTAL e opt-in; nunca parte de uma rodada padrão. Adicione-o apenas quando o usuário solicitar explicitamente uma terceira família. Dois transportes, cada um com seu próprio wrapper aqui:

   • Kimi Desktop (Windows). scripts/concilium-review-kimi.ps1 aciona o runner daimon integrado do aplicativo em seu próprio Electron. Requer o aplicativo de desktop instalado e conectado.
   • Kimi Code CLI (Linux/macOS/Windows). scripts/concilium-review-kimi.sh aciona a CLI de plataforma cruzada e licenciada sob MIT — kimi -p headless mais OAuth de código de dispositivo, adequado para um contêiner ou uma VM descartável (exemplo prático: references/isolated-guest-vmware.md). ⚠ O modo de impressão aprova automaticamente toda chamada de ferramenta por construção, então o isolamento ali é uma pré-condição, não uma precaução. ⚠ Sempre passe --model: o padrão interno da CLI é uma geração mais antiga que o carro-chefe e nada na saída o nomeia.

   Calibrado, mas mais instável que o codex, e mais fraco em isolamento: caminhos, modelos, sandbox e as ressalvas estão em references/setup.md e nas armadilhas #18–21.

Matriz de níveis (padrões são modelos atuais — substitua por instalação)

Nível	Padrão	Esforço	Usar para
Pesquisa	carro-chefe (ex.: gpt-5.6-sol)	máximo	rodadas de revisão abertas, verificação adversarial
Mecânico	carro-chefe anterior (ex.: gpt-5.5)	médio	verificar uma afirmação conhecida com uma sonda
Executor	nível barato (ex.: gpt-5.6-terra)	baixo	executar e relatar: rodar um script, babysitear uma importação

Os wrappers de nível de pesquisa usam máximo em todos os assentos por padrão. Vocabulários de esforço diferem e vale a pena conhecê-los exatamente: codex aceita none · minimal · low · medium · high · xhigh · max (medido — a API rejeita qualquer outra coisa e nomeia o enum); o assento kimi aceita low · high · max.

Esforço não substitui uma segunda família — medido, com o controle. Seis execuções de um assento (gpt-5.6-sol) sobre o mesmo pacote de 14 itens de previsão, em esforço baixo/médio/alto/xalto/máximo mais uma réplica de mesmo esforço: duas execuções no MESMO esforço cobriram 10/14, enquanto pares de esforços diferentes tiveram média de 8,9 e nunca superaram isso; o ensemble completo de seis execuções também alcançou apenas 10/14, igual ao piso de ruído de duas execuções e igual a um par codex+kimi. A precisão não foi monotônica em esforço (alto 9, máximo 9, xalto 7, médio 7, baixo 7) enquanto o tempo de parede cresceu 8× (21s → 166s). Quatro itens foram perdidos por todas as execuções em todos os esforços — e o assento entre famílias capturou dois deles. Variar o esforço reamostra os mesmos pontos cegos; uma linhagem diferente é o que os move. Se você quer cobertura, adicione uma família, não poder computacional. -Mechanical é a redução deliberada e permanece em medium.

Tarefas de executor NÃO são revisões — pule o wrapper e chame o codex diretamente: codex exec -m <modelo-barato> -c model_reasoning_effort=low [-s read-only a menos que escreva] "<tarefa>" < /dev/null Sempre feche stdin em chamadas diretas não interativas (bash < /dev/null; PowerShell $null | codex …) — um stdin aberto não-TTY bloqueia o codex para sempre em "Reading additional input from stdin...", e o processo órfão sobrevive ao timeout do shell pai (armadilha #10; os wrappers são imunes — eles canalizam via stdin).

Executando uma revisão

Use os wrappers fornecidos. Eles carregam o contrato de revisão compartilhado de references/contract.md (fonte única de verdade — sonda de falsificação, explicação alternativa, ressalva, proposta de veredito, regras de esquema/codificação; edite o contrato lá, nunca nos scripts) e adicionam carimbo de proveniência. Ambos os wrappers são funcionalmente idênticos; escolha pela plataforma:

Linux / macOS (bash):

• Afirmação: scripts/concilium-review.sh claim "<afirmação>"
• Diff: scripts/concilium-review.sh diff [branch-base]
• Config via env: MODEL, EFFORT, MECHANICAL=1 (nível mecânico), REPO_DIR, PROJECT_RULES (caminho do arquivo de regras).
• Primeiro uso após clone: chmod +x scripts/concilium-review.sh.

Windows (PowerShell 5.1+):

• Afirmação: powershell -ExecutionPolicy Bypass -File scripts/concilium-review.ps1 -Claim "<afirmação>" [-Mechanical] [-RepoDir <caminho>] [-ProjectRules <arquivo>]
• Diff: ... -Diff [-Base <branch>] — revisa o diff da árvore de trabalho de -RepoDir.

Assento de terceira família Kimi — EXPERIMENTAL, opt-in. Não faz parte de uma rodada padrão; adicione-o apenas quando o usuário solicitar uma terceira família. Dois wrappers, mesmo contrato e mesmos cinco blocos: concilium-review-kimi.sh (CLI multiplataforma, configurado por env — MODEL é obrigatório lá) e concilium-review-kimi.ps1 (runner desktop Windows).

O wrapper desktop aceita a mesma superfície -Claim/-Diff/-RepoDir/-ProjectRules/-PriorRounds, além de -Model (padrão k3-agent), -Effort (low|high|max) e -RawPrompt (sem contrato, para sondas de calibração). Duas diferenças específicas do assento, ambas medidas: a ponte automática CLAUDE.md está DESLIGADA por padrão aqui — a injeção invariavelmente mata a execução com um simples Connection error., portanto é opt-in via -AutoRules; use -ProjectRules <arquivo> para dar contexto ao revisor. E nunca confie no código de saída — ele sai com 0 nessa falha, então verifique os cinco blocos. Prompts multilinha devem passar por este wrapper; um kimi-daimon --prompt direto do bash tem seus argumentos corrompidos (armadilhas #18–19).

Este assento não tem sandbox — dê a ele uma cópia descartável. -SandboxFrom <dir> copia a árvore para um diretório temporário (excluindo .git, virtualenvs e arquivos com formato de segredo), executa o agente lá, imprime exatamente o que foi criado/modificado/excluído e exclui a cópia a menos que -KeepSandbox. Use por padrão. Seja claro sobre o que isso proporciona: workDir não é uma fronteira — um canário fora dele foi lido por caminho absoluto e retornado textualmente (armadilhas #20) — então isso é controle de raio de explosão e trilha de auditoria, não contenção. Se material na máquina não deve chegar ao provedor, isole no nível do SO (conta separada com ACLs, ou uma VM).

Para uma rodada cega, o risco dessa mesma porosidade é contaminação, não dano: um agente que vagueia pela árvore real pode encontrar a resposta, e a rodada silenciosamente deixa de ser cega. Adicione -WatchPaths <a,b,c> — ele captura instantâneos dos tempos de último acesso NTFS para o que deve permanecer não lido (o repositório real, o log de resultados, o gabarito) e relata qualquer coisa lida durante a execução. Validado contra uma fuga conhecida em ambas as direções; leia as armadilhas #21 antes de confiar nele, incluindo por que uma versão baseada em enumeração da mesma verificação relatou "limpo" em uma execução que havia escapado de forma demonstrável.

Regras operacionais (cada uma é uma falha medida — o porquê está em references/pitfalls.md):

• Execute em segundo plano com um timeout total de ~10 min a PARTIR da PRIMEIRA chamada. Revisões reais levam 5–15+ min em esforço alto; um timeout em primeiro plano as mata no meio da sonda.
• Prefira uma sessão nova a retomar uma que expirou. Cadeias longas retomadas atingem compactação de contexto — a leitura cuidadosa inicial do revisor é resumida de forma perde antes da etapa final e consequente.
• Nunca retome diretamente. codex exec resume redefine silenciosamente modelo E sandbox para os padrões do config.toml do usuário. Se precisar retomar (ou quiser trocar de modelos no meio da sessão), redefina tudo: codex exec resume -m <modelo> -c sandbox_mode="read-only" -c model_reasoning_effort=<nivel> <id-da-sessao> - As flags vão ANTES do id posicional da sessão. O importante é sandbox_mode — -c sandbox=... é silenciosamente ignorado, e não há flag -s em resume. A retomada entre modelos preserva o contexto.
• O revisor é um agente completo, não um chatbot — sandbox somente leitura bloqueia gravações de arquivos, não comandos de leitura ou SELECTs de banco. Tudo que ele revisa vai para o provedor do segundo modelo.
• Acompanhe o progresso ao vivo, não espere no escuro — e monitore o fluxo correto. O contrato (regra 9) faz o revisor emitir linhas STATUS: enquanto trabalha, e o codex escreve progressivamente — mas os fluxos se separam (verificado ao vivo): com 1> out 2> err, os cinco blocos finais vão para stdout enquanto a transcrição em streaming (banner, linhas STATUS, chamadas de ferramenta) vai para stderr. Aponte um tail/monitor para stderr para progresso + assinaturas de falha; leia stdout para o veredito. Ressalva: redirecionamentos 1>/2> do PowerShell escrevem UTF-16 — decodifique adequadamente (ou redirecione através de uma etapa de forçar UTF-8) antes de usar grep.
• Uma rodada cega precisa de isolamento estrutural, não uma instrução. Quando a rodada deve ser não preparada (uma avaliação cega, uma passagem cega crítica para o enquadramento por modelo de solicitação), execute o revisor em um diretório limpo com ponte automática de regras DESLIGADA (-NoAutoRules / NO_AUTO_RULES=1): um modelo carregando contexto do projeto e instruído a "responder apenas com base no pacote" ainda usa mensuravelmente esse contexto (armadilhas #16–17).

Protocolo de ratificação (trabalho da sessão de chamada)

O revisor retorna cinco blocos: PROBE / ALT / CAVEAT / VERDICT-PROPOSAL / PHASE-LOG. Antes de repassar ou agir:

1. Leia a sonda real (a consulta/comandos), não apenas o resumo em prosa.
2. Resultados extremos são um gatilho: 0% ou 100% em uma primeira tentativa geralmente significam chave de junção errada, escopo errado ou tabela errada — não uma descoberta. Verifique a etapa crítica da sonda você mesmo antes de aceitá-la.
3. Verifique o escopo em discordâncias: duas sondas podem estar ambas factualmente corretas em escopos diferentes (uma tabela vs. banco inteiro, uma fonte vs. todas as fontes). Nomeie o escopo antes de comparar números.
4. Distinga refutado / desatualizado / incompleto. "Os números diferem hoje" não significa que a afirmação estava errada quando foi escrita — verifique histórico/carimbos de data/hora antes de dizer "refutado".
5. Atribua você mesmo a tag de veredito final: [V-code] (verificado contra fonte, cite arquivo:linha) / [V-db] (consulta somente leitura, cite-a) / [V-probe] (script reexecutável) / [C] (não verificado) / [X] (refutado — nomeie o que o substitui). A proposta é entrada, não a resposta.
6. Pese a concordância pela linhagem. Confirmação da mesma família (uma cadeira Claude concordando com um orquestrador Claude) é evidência fraca — cadeiras da mesma linhagem compartilham mensuravelmente respostas erradas, até produzindo independentemente a mesma inferência errada. Uma confirmação ou refutação entre famílias supera qualquer contagem de votos da mesma linhagem; nunca resolva uma disputa por maioria entre cadeiras que compartilham uma linhagem. Uma terceira família (Moonshot) está disponível como um assento experimental opt-in; um terceiro assento não agrega nada a menos que seja independente, então pese por família, não por contagem de cabeças — e observe que um painel unânime pode simplesmente significar que o item era fácil (setup.md).

O loop concilium (rodadas iterativas)

Uma única passagem de revisão é frequentemente suficiente. Mas quando a sonda do revisor tem uma lacuna, ou você (o orquestrador) discorda da proposta com base em fundamentos defensáveis, uma troca não é um concilium — um conselho delibera. O loop executa rodadas de revisão até que o veredito convirja ou a disputa seja comprovadamente genuína. Este loop é orquestrado por você, a sessão Claude de chamada — é um protocolo, não um script (a etapa de ratificação é seu julgamento; nada pode automatizá-la).

Cada rodada:

1. Execute uma revisão (o wrapper) → obtenha os cinco blocos → ratifique de acordo com o protocolo acima.
2. Decida o resultado da rodada e aja:

Resultado	Condição	Ação
Convergido	Você verificou a etapa crítica da sonda e ela se sustenta	PARE — emita a tag final.
Disputa	A sonda tem uma lacuna, escopo errado, ou você tem uma objeção específica e baseada em evidências	Escreva a PROBE desta rodada + sua objeção em um arquivo de rodadas; execute a próxima rodada com -PriorRounds/PRIOR_ROUNDS apontando para ele.
Esgotado	Uma rodada não adiciona nenhuma nova evidência verificável — o revisor reafirma, ou diz (em CAVEAT) que não tem novo caminho	PARE — escale para o proprietário como [C]/[POLICY] com a questão em aberto. Esta é a proteção anti-oscilação.
Limite	Limite de rodadas atingido (padrão 3) sem convergir	PARE — apresente o estado e escale; uma disputa real é uma descoberta, não uma falha.

Regras de projeto (seguem diretamente das armadilhas):

• Sessão nova por rodada — nunca uma cadeia de retomada. O loop é exatamente a "cadeia longa" contra a qual a armadilha #3 alerta; carregue o contexto adiante via arquivo -PriorRounds, não codex exec resume. Cada rodada começa limpa e vê apenas um resumo compacto do que já foi tentado.
• Toda rodada deve adicionar um NOVO caminho de evidência. O contrato (regra 8) impõe isso no lado do revisor; você impõe no seu — uma objeção só vale uma rodada se for apoiada por evidências ou apontar para uma lacuna concreta e verificável. "Não estou convencido" não é uma rodada.
• O ratificador permanece fixo (você / Fable); o revisor pode reduzir níveis à medida que a disputa se estreita. Rodada 1 no nível de pesquisa; uma vez reduzido a um detalhe mecânico, mude para o nível mecânico — a sonda será mais rápida e estreita, e o viés da mesma linhagem não importa porque você, o ratificador de família diferente, está verificando a etapa. Nunca mude o revisor para um modelo que compartilha linhagem com o ratificador (ou seja, não coloque Claude revisando para um ratificador Claude) — isso derrota o propósito e foi medido como pior do que nenhuma revisão (armadilha #22).

Documentação de referência

Dentro do repositório:

• references/contract.md — O contrato de revisão (fonte única da verdade). Edite isso para alterar o comportamento da sonda/esquema de veredito.
• references/setup.md — Calibração, seleção de modelos, configuração de ambiente e notas para o assento Kimi.
• references/pitfalls.md — Catálogo de falhas medidas que informam cada regra operacional acima.
• references/isolated-guest-vmware.md — Exemplo prático de execução do assento Kimi em uma VM Linux convidada descartável.
• scripts/ — Wrappers de revisão: concilium-review.sh (bash), concilium-review.ps1 (PowerShell), concilium-review-kimi.sh (CLI kimi), concilium-review-kimi.ps1 (desktop kimi).

---

"Um conselho delibera. Uma sonda verifica. Um veredito é ratificado."