KENSAI Produktupdate: Nightly-Test-Belege ersetzen Beruhigungsmetriken

Der 26. April begann mit genau der Art von Fehler, die nützliche Systeme nicht glätten, sondern konservieren sollten: Die nächtliche Freemium-Testsuite lief nicht grün. Der Gewinn ist, dass der Fehler jetzt präzise genug ist, um ihn gezielt zu beheben.

Was der Nightly-Run bewiesen hat

Die Cron-Quittung vom 26. April hielt die komplette KENSAI-Freemium-Suite aus dem Plattform-Repository fest. Das Ergebnis war kein vager roter Build, sondern eine konkrete Fehlerkarte: pnpm test endete nach 636 Tests mit Exit-Code 1, davon 310 fehlgeschlagen, 243 bestanden und 83 übersprungen.

Die dominante Fehlerklasse waren API-gebundene Tests, die einen Dienst auf 127.0.0.1:4000 erwarteten, während die API gar nicht verfügbar war. Daraus entstanden Verbindungsabbrüche und Status-0-Assertions. Das ist kein Produktmysterium, sondern ein fehlender Preflight und ein Orchestrierungsfehler.

Was gefehlt hat

Zwei weitere Lücken wurden dokumentiert statt versteckt. Das Root-Paket definierte kein pnpm test:e2e, also hatte der Runner keinen stabilen E2E-Einstiegspunkt. Der Coverage-Befehl scheiterte sofort, weil @vitest/coverage-v8 fehlte. Ein direkter Playwright-Fallback startete zwar, war wegen breiter Auth- und Admin-Fehler plus einminütiger Timeouts aber so verrauscht, dass ein Abbruch ehrlicher war als ein falsches Signal.

Warum das ein Produktupdate ist

Ein fehlschlagender Testlauf ist nicht automatisch Fortschritt. Ein fehlschlagender Lauf mit Zählwerten, dominanten Fehlerklassen, fehlenden Tools und klarem Reparaturpfad ist Fortschritt. Das Qualitätssystem kennt jetzt den Unterschied zwischen kaputtem Produktverhalten und nie gestarteter Infrastruktur.

Das ist für KENSAI wichtig, weil kundenseitige Sicherheitsbehauptungen auf langweiliger operativer Wahrheit beruhen. Wenn der Freemium-Pfad die API braucht, muss der Runner sie starten oder vorab verifizieren. Wenn Coverage ein Pflicht-Gate ist, muss der Provider installiert sein. Wenn E2E Teil der Release-Story ist, braucht es ein echtes Skript statt stiller Annahmen.

Nächster Reparaturpfad

Die Reihenfolge ist jetzt klar: ein Root-test:e2e-Skript hinzufügen oder wiederherstellen, den Coverage-Provider installieren und den Freemium-Runner so umbauen, dass er die API auf Port 4000 startet und health-checkt, bevor API-abhängige Tests laufen. Alles andere wäre Theater.

Genau diesen Standard sollte KENSAI halten: die unbequeme Messung erhalten, die gebrochenen Voraussetzungen benennen und einen roten Lauf in eine kurze Fix-Liste verwandeln.

Bottom line

Der nützliche Standard ist simpel: Behauptungen werden erst real, wenn Voraussetzung, Artefakt und Route zusammenpassen. Die heutige Arbeit hält diesen Standard sichtbar.