KENSAI उत्पाद अपडेट: रात भर के टेस्ट सबूत ने comfort metrics को बदल दिया

26 अप्रैल की शुरुआत उसी तरह की failure से हुई जिसे किसी useful system को छिपाना नहीं बल्कि बचाकर रखना चाहिए: nightly freemium test suite पास नहीं हुई। अच्छी बात यह है कि अब यह failure इतना precise है कि इसे ठीक किया जा सके।

Nightly run ने क्या साबित किया

26 अप्रैल की cron receipt ने platform repository से पूरी KENSAI freemium suite रिकॉर्ड की। नतीजा कोई vague red build नहीं था। यह एक concrete failure map था: pnpm test 636 tests के बाद code 1 के साथ रुका, जिनमें 310 failed, 243 passed और 83 skipped थे।

सबसे बड़ी failure class उन API-backed tests की थी जो 127.0.0.1:4000 पर service expect कर रहे थे जबकि API उपलब्ध ही नहीं थी। इससे connection refusals और status-zero assertions आए। यह कोई product mystery नहीं है। यह missing preflight और service orchestration defect है।

क्या missing था

दो और gaps छिपाए नहीं गए बल्कि record किए गए। Root package में pnpm test:e2e defined नहीं था, इसलिए runner के पास stable e2e entry point नहीं था। Coverage command तुरंत fail हुई क्योंकि @vitest/coverage-v8 missing था। Direct Playwright fallback शुरू तो हुआ, लेकिन broad auth/admin failures और one-minute validation timeouts ने उसे इतना noisy बना दिया कि उसे useful signal मानना गलत होता।

यह product update क्यों है

Failing test run अपने आप progress नहीं होती। लेकिन failing run अगर counts, dominant error classes, missing tools और next repair path के साथ आए, तो वह progress है। Quality system अब यह समझता है कि application behavior fail हुआ या infrastructure कभी start ही नहीं हुई।

यह KENSAI के लिए इसलिए मायने रखता है क्योंकि customer-facing security claims boring operational truth पर टिकती हैं। अगर freemium path को API चाहिए, तो runner को उसे start करना होगा या tests शुरू होने से पहले verify करना होगा। अगर coverage required gate है, तो provider install होना चाहिए। अगर e2e release story का हिस्सा है, तो real script चाहिए, implied convention नहीं।

अगला repair path

अब sequence साफ है: root test:e2e script add या restore करो, coverage provider install करो, और freemium runner को इस तरह बदलो कि वह API-dependent tests चलाने से पहले port 4000 पर API start और health-check करे। बाकी सब theatre होगा।

KENSAI को यही standard रखना चाहिए: uncomfortable measurement बचाकर रखो, broken preconditions को नाम दो, और red run को short fix list में बदलो।

Bottom line

Useful standard सीधा है: claim तभी real बनती है जब prerequisite, artifact और route एक साथ align हों। आज का काम उसी standard को visible रखता है।