Productupdate 26 april 2026 · 4 min leestijd

KENSAI Productupdate: bewijs uit nachttests vervangt schijnmetriek

26 april begon met precies het soort fout dat nuttige systemen niet moeten wegpoetsen maar bewaren: de nachtelijke freemium-testsuite slaagde niet. Het goede nieuws is dat de fout nu precies genoeg is om gericht te repareren.


Wat de nachtrun bewees

Het cron-bewijs van 26 april legde de volledige KENSAI-freemiumsuite uit de platformrepo vast. Het resultaat was geen vage rode build. Het was een concrete faalkaart: pnpm test stopte met code 1 na 636 tests, waarvan 310 faalden, 243 slaagden en 83 werden overgeslagen.

De dominante foutklasse bestond uit API-afhankelijke tests die een service op 127.0.0.1:4000 verwachtten terwijl de API niet beschikbaar was, met connection refusals en status-zero-assertions als gevolg. Dat is geen productmysterie. Het is een ontbrekende preflight en een service-orchestratiefout.

Wat ontbrak

Nog twee gaten zijn vastgelegd in plaats van verstopt. Het rootpakket definieerde geen pnpm test:e2e, dus de runner had geen stabiel e2e-ingangspunt. Het coverage-commando faalde direct omdat @vitest/coverage-v8 ontbrak. Een directe Playwright-fallback startte wel, maar brede auth/admin-fouten en time-outs van een minuut maakten het eerlijker om die run te stoppen dan als nuttig signaal te verkopen.

Waarom dit een productupdate is

Een mislukte testrun is niet automatisch vooruitgang. Een mislukte run met aantallen, dominante foutklassen, ontbrekende tools en een duidelijk reparatiepad is dat wel. Het kwaliteitssysteem weet nu het verschil tussen falend applicatiegedrag en infrastructuur die nooit gestart is.

Dat is belangrijk voor KENSAI omdat klantgerichte securityclaims afhangen van saaie operationele waarheid. Als het freemiumpad de API nodig heeft, moet de runner die starten of vooraf verifiëren. Als coverage een verplichte gate is, moet de provider geïnstalleerd zijn. Als e2e onderdeel is van het releaseverhaal, heeft het een echt script nodig in plaats van een stilzwijgende conventie.

Volgend reparatiepad

De reparatiereeks is nu helder: voeg een root-test:e2e-script toe of herstel het, installeer de coverageprovider en laat de freemiumrunner de API op poort 4000 starten en health-checken voordat API-afhankelijke tests draaien. Alles anders zou theater zijn.

Dat is de norm die KENSAI moet vasthouden: bewaar de ongemakkelijke meting, benoem de kapotte randvoorwaarden en verander een rode run in een korte fixlijst.

Kort samengevat

De nuttige norm is simpel: claims worden echt wanneer voorwaarde, artefact en route op één lijn liggen. Het werk van vandaag houdt die norm zichtbaar.

Laat quality gates hun eigen randvoorwaarden bewijzen

KENSAI wordt sterker wanneer elke rode build uitlegt of het product faalde, de harness faalde of de omgeving nooit bestond.

KENSAI

KENSAI — AI-Powered Security Intelligence