Atualização do produto KENSAI: a evidência dos testes noturnos substitui métricas de conforto

26 de abril começou com o tipo de falha que sistemas úteis devem preservar em vez de suavizar: a suíte freemium noturna não passou. O ganho é que agora a falha está precisa o bastante para ser corrigida.

O que a execução noturna provou

O recibo cron de 26 de abril registrou a suíte freemium completa da KENSAI a partir do repositório da plataforma. O resultado não foi um build vermelho vago. Foi um mapa de falha concreto: pnpm test terminou com código 1 depois de 636 testes, com 310 falhas, 243 aprovações e 83 ignorados.

A classe de falha dominante foram testes apoiados em API esperando um serviço em 127.0.0.1:4000 enquanto a API não estava disponível, gerando recusas de conexão e assertions de status zero. Isso não é um mistério de produto. É um defeito de preflight e de orquestração de serviço.

O que estava faltando

Mais duas lacunas foram registradas em vez de escondidas. O pacote raiz não definia pnpm test:e2e, então o runner não tinha um ponto de entrada e2e estável. O comando de cobertura falhou imediatamente porque @vitest/coverage-v8 estava ausente. Um fallback direto com Playwright até começou, mas erros amplos de auth/admin e timeouts de um minuto o tornaram barulhento demais para ser tratado como sinal útil.

Por que isso é uma atualização de produto

Uma execução de testes com falha não é progresso automaticamente. Uma execução com falha, mas com contagens, classes de erro dominantes, ferramentas ausentes e próximo caminho de reparo, é progresso. O sistema de qualidade agora conhece a diferença entre comportamento da aplicação falhando e infraestrutura que nunca foi iniciada.

Isso importa para a KENSAI porque as alegações de segurança voltadas ao cliente dependem de verdade operacional sem glamour. Se o caminho freemium precisa da API, o runner deve iniciá-la ou verificá-la antes do início. Se cobertura é um gate obrigatório, o provider precisa estar instalado. Se e2e faz parte da história de release, ele precisa de um script real em vez de uma convenção implícita.

Próximo caminho de reparo

A sequência de reparo agora está clara: adicionar ou restaurar um script raiz test:e2e, instalar o provider de cobertura e fazer o runner freemium iniciar e checar a saúde da API na porta 4000 antes da execução dos testes dependentes da API. Todo o resto seria teatro.

Esse é o padrão que a KENSAI deve manter: preservar a medição desconfortável, nomear as precondições quebradas e transformar uma execução vermelha em uma lista curta de correções.

Resumo

O padrão útil é simples: alegações se tornam reais quando pré-requisito, artefato e rota se alinham. O trabalho de hoje mantém esse padrão visível.