RIJUDEVx/interrogate

Interrogate (Interrogar)

Gere um revisor por modelo configurado para revisar adversarialmente alterações de código. Cada modelo recebe o mesmo prompt e rubrica. O sinal adversarial vem da diversidade de modelos, não de personas atribuídas.

Uma descoberta sobrevive apenas quando uma execução a prova.

A entrega é um veredito sintetizado. NÃO aplique alterações automaticamente.

Passo 1, Determinar Escopo

Identifique o que revisar a partir do contexto:

• Se o usuário apontar arquivos específicos ou um diff, use isso
• Se estiver em uma branch de funcionalidade, execute git diff main...HEAD (ou a branch base apropriada) para o conjunto completo de alterações
• Se a mensagem do usuário referenciar trabalho recente, reúna os arquivos relevantes

Empacote o diff (ou conteúdo dos arquivos) mais quaisquer arquivos de contexto ao redor que os revisores precisem para entender o código.

Passo 2, Declarar a Intenção

Antes de gerar revisores, declare a intenção explicitamente. Derive isso de:

• A mensagem do usuário
• Mensagens de commit
• Descrição do PR, se existir
• O próprio código

Escreva um parágrafo claro. Se não tiver certeza sobre a intenção, pergunte ao usuário antes de prosseguir.

Passo 3, Gerar Revisores

Lance todos os revisores em uma única mensagem, um por slot, usando a ferramenta de subagente do harness ou delegate_task.

Busque diversidade de modelos: diferentes famílias de modelos pegam bugs diferentes. No T3 Code, escolha 3-4 modelos fortes dos favoritos do usuário, de famílias diferentes, e inicie cada um com delegate_task (o skill t3-tools tem os passos). Em outros lugares, escolha 3-4 modelos distintos de alta capacidade que o harness expõe. Se não puder selecionar um modelo por subagente, gere revisores sem sobrescrita de modelo e obtenha diversidade de contextos independentes.

Subagente	Função
Revisor A	revisor com foco em raciocínio
Revisor B	segunda família de modelo independente
Revisor C	uma terceira família rápida/diferente
Revisor D	revisor adversarial/rigoroso de qualidade de código

Para cada revisor, gere um subagente de propósito geral:

• OpenCode / Codex: subagent_type: general (via a ferramenta task)
• Claude Code: subagent_type: general-purpose
• Outros harnesses: o subagente geral mais próximo que possa ler o repositório

Mantenha os revisores como somente leitura em espírito: eles não devem editar arquivos. Um revisor que precisar de uma reprodução deve executá-la em sua própria cópia de teste ou worktree, nunca no local.

Dê a cada revisor esta breve instrução junto com o modelo preenchido:

Quebre esta alteração. Prove cada descoberta com uma execução contra o código real, como um teste com falha, um script de reprodução ou saída de comando que mostre o comportamento errado. Para um design ou plano, execute um protótipo ou explore a árvore atual. Mantenha as reproduções em seu próprio worktree. Relate cada descoberta com um título, o comando exato, a saída que ele imprimiu e a saída que a intenção exige. Deixe de fora qualquer coisa que você não executou. Isso cobre estilo, nomenclatura, estrutura e riscos que exigem uma alteração futura para importar. Nenhuma descoberta é um resultado válido.

Se um slug de modelo for rejeitado como não resolvível, verifique os slugs válidos na mensagem de erro da ferramenta Task, escolha o equivalente mais próximo (prefira o nível de raciocínio mais alto da mesma família) e gere com o slug válido. Não bloqueie a revisão no problema do slug.

Leia references/reviewer-prompt.md e preencha o modelo com:

1. A intenção declarada
2. O diff ou conteúdo dos arquivos
3. A rubrica de revisão de references/rubric.md
4. A lente de qualidade de código de references/code-quality-review.md

O mesmo modelo preenchido vai para todos os revisores, para que cada modelo aplique a lente de qualidade de código.

Passo 4, Sintetizar

À medida que os resultados chegarem, construa uma imagem unificada:

1. Verifique cada descoberta executando novamente seu comando. Mantenha uma descoberta quando a saída mostrar a falha e a falha quebrar a intenção. Descarte o resto. Mescle descobertas que compartilham uma causa raiz.
2. Analise todas as descobertas dos revisores
3. Identifique consenso. Descobertas levantadas por 2+ modelos independentemente têm o sinal mais forte.
4. Identifique descobertas de modelo único. Ainda vale a pena ler, mas pondere de acordo.
5. Desduplique. Modelos diferentes podem descrever o mesmo problema de forma diferente. Mescle-os e anote quais modelos os levantaram.
6. Observe discordâncias. Se um modelo sinalizar algo e outro disser explicitamente o oposto, isso é contexto útil para o veredito.

Passo 5, Julgamento Final

Você é o revisor principal, um engenheiro sênior pragmático, não um agregador neutro.

Leia references/lead-judgment.md para a estrutura completa.

Categorize cada descoberta usando estes baldes:

• Aja. Problemas reais que afetam correção, segurança ou manutenibilidade dados os objetivos reais. Estes bloqueariam um PR real.
• Considere. Pontos legítimos, mas você não tem certeza se superam o custo de resolvê-los agora. Vale a atenção do usuário.
• Notado. Tecnicamente válido, mas não acionável. Dependente de contexto, otimização prematura ou baixo impacto dado o estágio atual.
• Descartado. Errado, exigente demais ou sem contexto. Breve explicação do porquê.

Para cada descoberta, inclua:

• Qual(is) modelo(s) a levantaram
• A categoria (aja / considere / notado / descartado)
• Uma justificativa de uma linha para a categorização

Formato de Saída

Apresente o veredito nesta estrutura:

Intenção

[O parágrafo de intenção declarada do Passo 2]

Revisores

• Revisor [rótulo]: [nome do modelo], [N descobertas] (um marcador por revisor)

Aja

[Descobertas que devem ser abordadas. Para cada: descrição, quais modelos a levantaram, por que isso importa.]

Considere

[Descobertas que valem a pena considerar. Para cada: descrição, quais modelos a levantaram, trade-off envolvido.]

Notado

[Válido, mas de baixa prioridade. Breve lista.]

Descartado

[Descobertas rejeitadas com breve justificativa, incluindo descobertas que nenhuma execução provou.]

Mapa de Concordância

[Onde os modelos concordaram, onde divergiram e o que o padrão de concordância/discordância nos diz?]

Raio de Explosão

Use este modo quando uma alteração é pequena, mas ainda não confiável, e a pergunta é o que ela quebra além do diff. Listar os chamadores não é o trabalho. grep encontra esses em um segundo. O trabalho é a quebra que grep não mostrará.

Não confie em sua própria descrição

Uma descrição do que uma alteração quebra que soa correta não vale nada. Ela soa convincente seja verdade ou não. Portanto, não entregue a descrição. Encontre o único ou dois fatos dos quais tudo depende e prove-os executando código.

Quão certo você está

Para cada fato do qual a segurança da alteração depende, leve-o o mais longe possível nesta lista e diga onde parou.

1. Você disse. Inútil por si só.
2. Você apontou para a linha. Um arquivo:linha real, ou o código fonte da própria biblioteca.
3. Você mostrou que o caso ruim não pode acontecer. Você percorreu a falha passo a passo e ela não alcança.
4. Você executou. Um script ou teste que chama o código real e falha alto se você estiver errado.
5. Você reproduziu no aplicativo em execução.

Qualquer fato de segurança que você não possa levar ao passo 4, diga. Não escreva como resolvido. O passo 4 geralmente é um pequeno script que importa a mesma biblioteca que o aplicativo usa e chama a função exata sobre a qual você está preocupado.

Passos

1. Leia a alteração. O diff, os símbolos que adiciona, altera e exclui, e o que agora faz de diferente, incluindo a parte que o diff não explicita. Puxe as mensagens do PR e do commit para entender o motivo.
2. Encontre o único fato pelo qual é seguro. A maioria das alterações que parecem arriscadas é segura devido a um único fato, como "esta chamada apenas descarta entradas de cache já mortas e não faz mais nada". Encontre esse fato. Se ele for válido, a maioria dos casos arriscados é eliminada de uma vez. Gaste seu tempo aqui, não em uma longa lista de talvez.
3. Veja onde grep para. Leia o código fonte da biblioteca que você chama e verifique sua versão fixada e qualquer patch local. Descubra quando as coisas executam: microtasks, desmontagem e limpeza, Solid versus React. Siga o que uma busca por símbolos perde: o JSON que uma API retorna, uma coluna de banco de dados, um formato de transmissão, outra linguagem lendo os mesmos bytes, uma flag de funcionalidade, código três hops a jusante.
4. Seja honesto sobre cada risco. Dê a ele uma chance real de acontecer e um custo real se acontecer. Mantenha os riscos que confirmou. Liste aqueles que verificou e limpou separadamente. Cite um arquivo:linha real, uma busca que não encontra nada ainda é uma resposta, e nunca invente um chamador ou uma API.
5. Prove o único fato. Escreva um script ou teste que execute o código real, execute-o e cole o que aconteceu. Se não puder prová-lo de forma barata, marque como não provado. Não exagere.
6. Para uma alteração grande ou ampla, execute-a através da revisão acima com vários modelos. Modelos diferentes pegam bugs reais diferentes.

O que entregar

• O que faz. O que mudou, incluindo a parte que não é óbvia.
• O único fato pelo qual é seguro. Diga, diga em qual passo você o levou e mostre a prova. Se não puder prová-lo, escreva não provado.
• Riscos. Apenas os reais. Cada um nomeia como quebra, o arquivo:linha, quão provável e quão ruim, e como verificar. Cole a prova para aqueles que importam.
• Limpados. O que você verificou e por que está tudo bem.
• Antes de mesclar. O teste ou reprodução mais barato que pega o bug real, incluindo o script que você escreveu.

Escreva através do unslop, cite código real e remova qualquer coisa privada antes de ir a qualquer lugar público.

Resposta: a descrição acima, com o único fato de segurança provado ou marcado como não provado.