✅ Verificação e relato fiel

Você acabou de mudar uma linha do prompt, ou pedir uma correção, e ela parece certa. Pare aí: parecer certo não é evidência de nada. Uma edição é só um palpite com aparência de solução — uma hipótese. A pergunta que importa não é "ficou bom?", é "como eu sei que ficou bom?". E a resposta é sempre a mesma: porque um check de verdade passou.

"An edit is a hypothesis. A passing check is the evidence."

Aqui está o erro mais comum, e o mais invisível: rodar um check que parece verificação, mas não verifica nada. Um ls que confirma que o arquivo existe. Um echo que imprime "ok". Um comando qualquer que saiu com código zero. Nada disso prova que a sua mudança funcionou. O check real é o teste, o build, o lint ou o typecheck que o projeto de fato usa — e rodar a coisa de verdade, não um substituto reconfortante.

Verificar é sobre o que já aconteceu. Confirmar é sobre o que ainda vai acontecer — e é especialmente importante quando a ação é difícil de desfazer ou sai pra fora. Deletar, sobrescrever, publicar, enviar um e-mail, chamar um serviço externo: nessas, o certo é checar antes. Um "pode?" curto custa um segundo; um e-mail enviado por engano custa um relacionamento.

<seguranca>
Para ações difíceis de reverter ou voltadas para fora (deletar, sobrescrever,
publicar, enviar a serviço externo): confirme antes, a menos que duravelmente
autorizado ou mandado prosseguir.
Aprovação num contexto não se estende ao próximo.
Antes de deletar/sobrescrever, olhe o alvo: se o que achar contradiz como foi
descrito, ou você não o criou, levante isso em vez de prosseguir.
</seguranca>

Verificou? Agora conte a verdade do que aconteceu. Se o teste falhou, diga que falhou e mostre a saída. Se você pulou uma etapa, diga que pulou. Se está feito e verificado, afirme sem rodeios, sem "acho que", sem "provavelmente". Confiança se constrói com relato preciso — não com relato otimista. A IA que enfeita um resultado não verificado como pronto está corroendo a única coisa que a torna útil: você poder acreditar no que ela diz.

"Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging."

Erro é normal — o que separa disciplina de sorte é a resposta ao erro. O reflexo ruim é rodar o mesmo comando de novo, igualzinho, torcendo por um resultado diferente. Isso é tatear no escuro. O reflexo bom é um loop curto: diagnosticar → corrigir → re-verificar. Você lê o erro, entende o estado, forma uma correção informada e só então tenta de novo. Olhe o diagrama lá em cima: é exatamente esse o caminho de baixo.

<recuperacao>
Quando um comando falha: não repita igual esperando resultado diferente.
Leia o erro → inspecione o arquivo/estado → forme a correção → corrija → re-verifique.
Nunca largue um turno que falhou em silêncio. Se não resolver, diga claramente, com a evidência.
</recuperacao>

A última regra, e a mais simples de cumprir: não suma. Se uma tarefa travou e você não conseguiu resolver, isso não é desculpa pra terminar o turno fingindo que deu certo, nem pra ir embora sem dizer nada. Diga claramente o que aconteceu, mostre a evidência, e seja honesto sobre onde parou. Um "não consegui, e foi por isto" vale infinitamente mais que um silêncio que deixa você descobrir o estrago depois.