keyz182/revisão-adversarial

Revisão adversarial

Encontre as razões pelas quais uma proposta falhará antes que alguém aja sobre ela. Produza preocupações classificadas e acionáveis e um veredito. Nunca implemente nada. Nunca ultrapasse o limite de rodadas.

0. Configuração

1. Escolha o modo. relatório quando o solicitante disser (por exemplo "revisão-adversarial em modo relatório"), ou quando estiver sendo executado dentro de um subagente, trabalhador ou execução headless sem um humano para responder. Sinais: a tarefa chegou como um prompt delegado, não há ferramenta de pergunta, ou o solicitante pediu um arquivo ou um resumo com limite de palavras. interativo em todos os outros casos.
2. Encontre o artefato. É um de: um caminho de arquivo, um intervalo de diff, um plano colado, ou "a coisa que acabou de ser produzida nesta conversa". Se mais de um candidato se encaixar, nomeie o escolhido na primeira linha da saída. Se nenhum foi dado e nada recente é um candidato óbvio: em modo interativo, pergunte qual artefato é pretendido, oferecendo a saída mais recente nesta conversa, um arquivo ou diff que o usuário nomeie, ou uma abordagem que o usuário descreva. Em modo relatório, pare e diga que nenhum artefato foi fornecido.
3. Defina a criticalidade: protótipo, ferramenta interna, produção, ou caminho de dinheiro ou segurança. Interativo: se não estiver claro e isso mudar o quão agressivamente pressionar, pergunte uma vez. Relatório: assuma produção e diga isso. A criticalidade define a profundidade da varredura de categorias. Nunca move a barra de gravidade.
4. Verifique se há um razão. Descubra o caminho do razão (veja seção 11). Se um razão existir para este artefato, leia references/ledger-format.md.
   • Se a linha mais recente para qualquer ID na rodada mais nova for pendente, uma revisão foi interrompida. Retome-a: pule as seções 1 a 5, leia os registros armazenados e continue a seção 8 a partir da primeira preocupação pendente. Não reexecute as lentes nem reclassifique. Modo relatório as lista em APENAS DECISÕES EM ABERTO.
   • Caso contrário, esta é uma rodada posterior. Siga a seção 11.

1. Faça o melhor caso primeiro

Antes de qualquer preocupação, escreva duas ou três frases sobre por que a proposta é razoável: o problema que ela resolve e as restrições que respeita. Se não for possível escrever isso, a proposta ainda não foi compreendida. Leia mais primeiro.

2. Gere preocupações candidatas

Carregue o arquivo de referência de uma lente quando você chegar nessa lente. Execute L12 por último.

#	Lente	Uso	Referência
L1	Falha no retrospecto: foi lançada e causou uma interrupção; rastreie de volta	Sempre	references/lens-questions.md
L2	Inverta o objetivo: liste o que garantiria a falha; verifique quais estão presentes	Sempre	references/lens-questions.md
L3	Suposições ocultas: nomeie cada uma; pergunte o que acontece se for falsa	Sempre	references/lens-questions.md
L4	Varredura de categorias de áreas comumente negligenciadas	Sempre	references/category-checklist.md
L5	Varredura de saída de IA para falhas típicas de IA	Sempre, quando foi produzida por IA	references/ai-output-checklist.md
L6	Fixe a afirmação: torne palavras vagas verificáveis	Por tipo	references/lens-questions-extended.md
L7	Peça a evidência: medida, lida ou assumida?	Por tipo	references/lens-questions-extended.md
L8	Outras perspectivas: plantão, segurança, novato, usuário pesado, atacante	Por tipo	references/lens-questions-extended.md
L9	Siga-a adiante dois ou três passos	Sempre	references/lens-questions-extended.md
L10	Questione o enquadramento: problema certo, mudança menor?	Sempre	references/lens-questions-extended.md
L11	Passagens separadas: fatos, riscos, alternativas, qualidade da revisão	Por tipo	references/lens-questions-extended.md
L12	Cadeia de causas do pior fracasso até sua escolha de design raiz	Por tipo	references/lens-questions-extended.md

Lentes "Por tipo", por tipo de artefato:

Tipo de artefato	Adicione estas lentes
Diff pequeno ou correção de bug	Nenhuma
Diff de funcionalidade ou plano de várias etapas	L6, L7, L12
Design, RFC ou decisão entre opções	L6, L7, L8, L11, L12
Saída de outra habilidade ou agente	Use a linha para o que foi produzido

Leia o código real, config ou linhas do plano das quais uma preocupação depende. Uma preocupação baseada em um palpite sobre o código não é evidência.

3. Filtro

Aplique todos os quatro testes a cada candidato. Descarte um candidato que falhe em qualquer um.

1. Consequência: se ninguém agir sobre ela, o que realmente acontece? "Nada demais" significa descartá-la.
2. Contra-argumento: escreva a razão mais forte de que não é um problema real (o código já cobre isso, está fora desta mudança, ou não causa dano). Se essa razão se mantiver, descarte-a. Se a preocupação sobreviver, mantenha o contra-argumento e declare por que ele falha.
3. Acionável: deve haver uma ação concreta. Sem ação significa descartá-la.
4. Não é uma duplicata: descarte qualquer coisa já relatada por outra etapa de revisão nesta conversa, pelo resumo do solicitante, ou no razão.

4. Classifique a gravidade

A barra é fixa. Modo, criticalidade, rodada e pressão de tempo não a movem.

• Crítico: declare um evento de falha concreto: o gatilho, como falha, e até onde o dano se espalha. O gatilho deve ser atingível na proposta como escrita. Se nenhum gatilho atingível puder ser nomeado, a preocupação é no máximo Alta. Veja references/severity-downgrade-example.md.
• Alto: um cenário nomeado e realista no qual causa dano.
• Médio: vale a pena corrigir. Nenhum evento de falha é necessário.

Marque cada preocupação como bloqueadora (deve ser corrigida antes do trabalho prosseguir) ou item de monitoramento (acompanhe, não segure o trabalho por ela).

5. Orçamento

• Relate cada Crítico e cada Alto na íntegra.
• Relate os três primeiros Médios na íntegra. Liste quaisquer outros Médios em uma linha: a contagem, então um rótulo curto para cada um. Nunca descarte um Médio silenciosamente.
• Se Crítico mais Alto for mais que cinco, pare a revisão detalhada. O veredito é REPENSE, com uma recomendação de dividir a proposta em partes menores. Liste apenas os títulos dos Críticos e Altos.

6. Registro de preocupação

Cada preocupação relatada tem todos estes campos:

### H1: <título de uma linha>
- Gravidade: Alto | Evento de falha: <gatilho> -> <como falha> -> <raio de explosão>
- Lente: L3 Suposições ocultas
- Contra-argumento: <caso mais forte contra a preocupação>. Falha porque <razão>.
- Evidência: <arquivo:linha | etapa do plano | decisão citada>
- Se ignorada: <o que acontece>
- Ação: <a mudança concreta>
- Status: bloqueadora | item de monitoramento

IDs usam a letra da gravidade e um número: C1, H1, M1. Um ID nunca muda, em qualquer rodada. Registros Médios podem escrever Evento de falha: n/a.

7. Veredito

Termine toda revisão com exatamente um veredito:

• PROSSIGA: nenhuma preocupação bloqueadora. Notas podem seguir.
• ALTERE: a abordagem é sólida; corrija as preocupações bloqueadoras listadas primeiro.
• REPENSE: uma falha fundamental, ou o orçamento na seção 5 foi excedido.

Abaixo do veredito, adicione um cabeçalho Riscos conhecidos. Liste cada preocupação cuja linha mais recente do razão é risco-aceito, de qualquer rodada, com seu ID, título e rodada. Se não houver nenhuma, escreva "Riscos conhecidos: nenhum". Elas nunca bloqueiam.

8. Modo interativo

1. Mostre o melhor caso (seção 1).
2. Antes da primeira pergunta, escreva os registros de preocupação e uma linha pendente do razão para cada preocupação a ser analisada (veja a referência do razão).
3. Levante uma única preocupação por turno, a mais grave primeiro. O usuário escolhe aceitar, rejeitar, modificar, aceitar-risco ou adiar.
   • Se existir uma ferramenta de pergunta estruturada (AskUserQuestion no Claude Code, question no OpenCode), use-a, uma preocupação por pergunta, com todo o registro no texto da pergunta para que permaneça na tela. Se a ferramenta limitar as opções, ofereça aceitar, rejeitar, aceitar-risco e adiar, e aceite modificar como texto livre.
   • Modificar: aceite a alteração do usuário, depois trate a preocupação como aceita em sua nova forma. Rejeitar: a preocupação não se aplica. Aceitar-risco: a preocupação é real, o usuário convive com ela, ninguém a corrige agora; não bloqueadora. Adiar: um item de monitoramento, para corrigir depois.
   • Anexe a linha do razão imediatamente após cada resposta, antes da próxima pergunta. Não espere pelo veredito.
4. Quando cada preocupação tiver uma resolução, execute a re-verificação (seção 11) na rodada 2 e posteriores. Então dê o veredito e Riscos conhecidos (seção 7).
5. Se pelo menos uma preocupação foi aceita ou modificada, escreva o plano revisado (seção 10), qualquer que seja o veredito.
6. Anexe a linha do veredito ao razão. Pare e aguarde um sinal explícito para prosseguir.

9. Modo relatório

Sem perguntas. Sem espera. Saída nesta ordem:

1. A suposição de criticalidade, se alguma foi feita.
2. O melhor caso.
3. Todos os registros de preocupação, classificados por gravidade, dentro do orçamento.
4. O veredito, com Riscos conhecidos do razão.
5. DECISÕES EM ABERTO: uma lista numerada. Formule cada item como uma decisão que um humano pode responder, depois a opção recomendada e sua contrapartida: 1. <pergunta> (ref. C1) Recomendar: <opção>. Contrapartida: <custo ou risco>.

Se o solicitante forneceu um caminho de arquivo, escreva o relatório completo lá. Retorne apenas um resumo de 200 palavras ou menos: o veredito, contagens por gravidade, e os títulos das DECISÕES EM ABERTO. Anexe os registros e linhas com resolução aberta (veja a referência do razão). Então pare. Modo relatório nunca revisa o plano.

10. Plano revisado

Apenas modo interativo, depois que cada preocupação tiver uma resolução. Escreva-o sempre que pelo menos uma preocupação foi aceita ou modificada, qualquer que seja o veredito. Pule-o apenas para PROSSIGA com nada aceito ou modificado.

1. Reafirme todo o plano com as alterações aceitas incorporadas. Não apenas liste as resoluções.

2. Adicione uma tabela de integração. Marque qualquer preocupação aceita ou modificada sem uma linha correspondente como AUSENTE, e diga isso acima da tabela.

   Preocupação	Resolução	Linha do plano que a aborda
   C1	aceita	Etapa 3: adicionar chave de idempotência
   H2	modificada	AUSENTE

3. Pare. Aguarde um sinal explícito para prosseguir. Esta habilidade nunca implementa.

11. Rodadas e término

• Caminho do razão: ${XDG_STATE_HOME:-~/.local/state}/adversarial-review/<slug>.md. Leia references/ledger-format.md para o slug e formato da linha antes da primeira escrita.
• O razão é apenas para anexação. Nunca edite ou exclua uma linha anterior.
• Uma preocupação é resolvida apenas se seu artefato de resolução (SHA de commit ou linha do plano) existir e alterações posteriores não o tocaram.
• Inicie cada rodada posterior com uma linha de cabeçalho: Rodada N | herdadas abertas: C2, H1 | novas última rodada: 1 Crítico, 2 Alto
• A rodada 2 e posteriores revisam apenas o que mudou desde a última rodada e o que essa mudança poderia afetar. Um novo Crítico ou Alto lá deve ser um novo comportamento, em material alterado, que realmente dispararia.
• Não levante uma preocupação registrada novamente a menos que a mudança tenha tocado a coisa que a resolveu, ou uma re-verificação a encontre pior.
• Re-verificação de fim de rodada (rodada 2 e posteriores). Antes do veredito, verifique cada preocupação cuja linha mais recente é adiada, risco-aceito, pendente ou aberta contra o artefato e código atuais. Anexe uma linha cada: ainda se aplica, não se aplica mais (com a razão), ou piorou (aumente a gravidade e diga por quê). Uma preocupação que piorou precisa de uma nova decisão: analise-a (interativo) ou liste-a em DECISÕES EM ABERTO (relatório). Nunca altere linhas antigas.

Regras de saída (rígidas)

Estas regras substituem todo o resto nesta habilidade.

1. Uma rodada posterior que não adiciona nenhum novo Crítico ou Alto encerra o loop. O veredito é PROSSIGA. Médios abertos tornam-se itens de monitoramento. Críticos ou Altos herdados que ainda estão abertos não são novos, mas ainda bloqueiam: resolva-os nesta rodada (interativo) ou liste-os em DECISÕES EM ABERTO (relatório) antes de dar o veredito.
2. Se a rodada 3 ainda encontrar um novo Crítico, desafie como o trabalho está dividido, não o código. Recomende uma divisão diferente.
3. Nunca execute mais de quatro rodadas. Após a rodada 4, entregue cada bloqueador restante ao usuário como uma lista de decisões numerada e pare.

12. Tom

• Direto e específico. Escreva "Isso falha quando ...", não "isso pode potencialmente causar problemas". Lidere com a preocupação mais importante.
• Nomeie a lente em cada preocupação, para que os leitores aprendam o método.
• Se a proposta for boa, diga isso claramente e dê PROSSIGA.
• Não invente preocupações para parecer completo. Cada preocupação nomeia um arquivo, linha ou etapa do plano; um risco genérico sem lugar é descartado.
• Não reescreva o código sob revisão. Descreva a mudança; deixe a escrita para quem agir sobre ela.