Aggiornamento prodotto KENSAI: l’evidenza dei test notturni sostituisce le metriche rassicuranti

Il 26 aprile è iniziato con il tipo di guasto che i sistemi utili dovrebbero conservare invece di smussare: la suite di test freemium notturna non è passata. Il punto positivo è che il guasto ora è abbastanza preciso da poter essere corretto.

Cosa ha dimostrato l’esecuzione notturna

La ricevuta cron del 26 aprile ha registrato l’intera suite freemium KENSAI dal repository di piattaforma. Il risultato non è stato una vaga build rossa. È stata una mappa di guasto concreta: pnpm test si è chiuso con codice 1 dopo 636 test, con 310 falliti, 243 passati e 83 saltati.

La classe di errore dominante era formata da test dipendenti dall’API che si aspettavano un servizio su 127.0.0.1:4000 mentre l’API non era disponibile, producendo rifiuti di connessione e asserzioni a stato zero. Non è un mistero di prodotto. È un difetto di preflight e di orchestrazione del servizio.

Cosa mancava

Altre due lacune sono state registrate invece di essere nascoste. Il pacchetto root non definiva pnpm test:e2e, quindi il runner non aveva un punto di ingresso e2e stabile. Il comando di coverage è fallito subito perché mancava @vitest/coverage-v8. Un fallback diretto con Playwright è partito, ma errori diffusi di auth/admin e timeout di un minuto lo hanno reso troppo rumoroso per essere scambiato per segnale utile.

Perché questo è un aggiornamento prodotto

Un test run fallito non è automaticamente progresso. Un test run fallito con conteggi, classi di errore dominanti, strumenti mancanti e un chiaro percorso di riparazione lo è. Il sistema qualità ora distingue tra comportamento applicativo che fallisce e infrastruttura mai avviata.

Questo conta per KENSAI perché le affermazioni di sicurezza rivolte ai clienti dipendono da una verità operativa senza glamour. Se il percorso freemium richiede l’API, il runner deve avviarla o verificarla prima dei test. Se la coverage è un gate richiesto, il provider deve essere installato. Se l’e2e fa parte della storia di release, serve uno script reale invece di una convenzione implicita.

Prossimo percorso di riparazione

La sequenza di riparazione è ora chiara: aggiungere o ripristinare uno script root test:e2e, installare il provider di coverage e fare in modo che il runner freemium avvii e controlli la salute dell’API sulla porta 4000 prima dei test dipendenti dall’API. Tutto il resto sarebbe teatro.

Questo è lo standard che KENSAI dovrebbe mantenere: conservare la misurazione scomoda, nominare i prerequisiti rotti e trasformare un run rosso in una breve lista di fix.

In sintesi

Lo standard utile è semplice: le affermazioni diventano reali quando prerequisito, artefatto e route si allineano. Il lavoro di oggi mantiene visibile questo standard.