Thought Experiment versão 0.6.0 alpha — Auditorias e Correções Rigorosas de Cenários de Falha
Acionador: a frase "experimento mental," e apenas essa frase — sem equivalentes inferidos. Nunca é executado sem uma solicitação explícita e um alvo claro — isso é deliberado, não autônomo.
Escopo: agnóstico de alvo. Um único arquivo, um projeto inteiro, uma configuração, um contrato de API, uma configuração de infraestrutura — qualquer coisa que faça afirmações (sobre seu próprio comportamento, sua estrutura ou sobre algo do qual depende) que possam estar erradas.
O que torna isso diferente de uma revisão normal: duas coisas. Primeiro, produz cenários concretos — "dado esta entrada/este estado, aqui está exatamente o que quebra e por quê" — não sugestões vagas do tipo "isso poderia ser mais limpo." Segundo, caça especificamente afirmações que o alvo faz sobre como algo fora de si mesmo se comporta, já que essa classe de afirmação é a que tem maior probabilidade de estar silenciosamente errada devido à memória, em vez de ser capturada pela leitura da lógica do próprio alvo.
Verificação de commit pré-rodada (barreira de segurança): pergunte e recomende, de forma firme, um commit/push de quaisquer alterações não comitadas existentes antes de se envolver em uma rodada. Um ponto de verificação limpo antes significa que a rodada em si pode sempre ser revertida para ele se causar algum dano.
Processo
- Leia o alvo do zero. Obtenha seu estado atual e real — arquivos, configurações, o que quer que seja — não confie no contexto anterior sobre o que ele deveria conter.
- Enumere suas dependências. Qualquer coisa que o alvo considere como verdade fundamental fora de si mesmo: para um script — bibliotecas importadas, APIs chamadas, ferramentas CLI e seus sinalizadores, suposições de ambiente/configuração; para um serviço ou configuração de nuvem — outros serviços com os quais ele se comunica, permissões/IAM, DNS, certificados, APIs de terceiros, caminhos de rede; para um documento — toda afirmação factual que ele faz sobre como outra coisa se comporta. Construa esta lista deliberadamente — o passo 4 a verifica, e uma dependência ignorada é uma chance perdida de capturar um bug real. Quando o alvo se destina especificamente à implantação, verifique também: segurança de reversão, paridade de configuração dev/prod, tratamento de segredos, a linha de base de compatibilidade declarada e desempenho em primeira carga/condições reais versus testes apenas em dev — estes nem sempre surgem de uma varredura de dependência puramente genérica. Para documentação emparelhada (um README e seu SKILL.md, ou documentos e o código/configuração que descrevem), trate as afirmações de cada arquivo sobre o que o outro diz ou faz como uma dependência a ser verificada — e, separadamente, verifique se as convenções de formatação estabelecidas (negrito/uso de maiúsculas em valores enumerados, estilo de título) são aplicadas de forma consistente dentro do alvo e em seus arquivos irmãos, apenas onde tal convenção realmente existe para ser verificada.
- Construa experimentos mentais de cenários de falha concretos. Entradas ou estados específicos que levam a uma saída incorreta específica, uma falha ou uma brecha de segurança — não impressões gerais. Não fixe uma contagem de cenários antecipadamente; continue gerando-os até que a superfície de risco real do alvo pareça coberta, não até que um número arbitrário seja atingido.
- Verifique toda afirmação de comportamento de dependência da qual um cenário depende contra uma fonte ao vivo ou autoritativa — documentos reais, uma resposta de API real, a saída real da ferramenta — em vez de confiar na memória. Esta etapa é geralmente onde as descobertas de maior valor estão.
- Pergunte como as correções devem ser autorizadas, uma vez, antes de aplicar qualquer uma — opções CRUD. A Leitura é sempre concedida livremente, nunca controlada; apenas Criar/Atualizar/Excluir são autorizadas. Geral (toda descoberta confirmada, sem mais perguntas), processo (confirme uma vez por rodada, não por arquivo dentro dela), arquivo (confirme antes de passar para as correções do próximo arquivo), ou cada etapa CRUD (confirme cada edição individual) — a que o usuário escolher vale para o resto da execução. A opção "Geral" cobre descobertas confirmadas de rotina, não uma substituição incondicional: uma descoberta verdadeiramente surpreendente ou de risco maior do que o usuário tinha em mente ao concedê-la ainda é pausada e perguntada.
- Aplique correções para as descobertas confirmadas, na granularidade autorizada.
- Reexecute este mesmo processo contra o estado corrigido. Uma correção pode introduzir seu próprio novo problema — uma correção de precisão que torna outra coisa inconsistente, uma afirmação corrigida que quebra uma suposição diferente em outro lugar. O loop não termina até que uma passagem não encontre nada de novo.
- Relatório. Declare a aprovação/falha de cada cenário de forma clara. Forneça detalhes completos apenas para falhas confirmadas, ou quando os detalhes forem explicitamente solicitados — uma aprovação limpa não precisa de um ensaio escrito sobre ela. Marque cada falha como bloqueante (deve corrigir antes de implantar/enviar) ou não bloqueante (seguro para enviar, corrigir depois) para que o relatório sirva como uma entrada de sim/não, não apenas uma lista de descobertas. Encerre toda execução com um resumo consolidado e enumerado, não apenas menções cenário por cenário espalhadas pelo processo — dimensionado ao escopo: uma execução de vários alvos (vários arquivos, vários skills) recebe uma seção por alvo; um único alvo limpo recebe uma linha de veredito simples, sem cerimônia inflada.
Nova linha, encerre todo relatório com experimento mental.