KENSAI 製品アップデート：夜間テストの証拠が安心メトリクスを置き換える

4月26日は、便利なシステムなら隠すのではなく保存すべき種類の失敗から始まりました。nightly freemium test suite は通りませんでした。でも良い点は、その失敗がいまは修正できるだけの精度で残っていることです。

Nightly run が証明したこと

4月26日の cron receipt は、platform repository にある KENSAI freemium suite 全体を記録しました。結果は曖昧な red build ではなく、具体的な 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 がある前提で動いていたのに、実際には API が起動していませんでした。その結果、connection refusals と status-zero assertions が出ました。これは product mystery ではなく、missing preflight と service orchestration defect です。

何が欠けていたか

さらに二つの gap も隠されずに記録されました。root package には pnpm test:e2e が定義されておらず、runner に stable な e2e entry point がありませんでした。coverage command は @vitest/coverage-v8 が missing のため即失敗しました。Playwright fallback は起動したものの、広い auth/admin failures と 1 分の validation timeouts により、有用な signal と呼ぶには noisy すぎました。

なぜこれが製品アップデートなのか

失敗した test run だけでは progress ではありません。しかし counts、dominant error classes、missing tools、next repair path まで揃えば progress です。quality system は今、application behavior が壊れているのか、infrastructure が最初から無かったのかを区別できます。

これは KENSAI にとって重要です。customer-facing security claims は、地味でも運用上の truth に支えられるからです。freemium path が API を必要とするなら、runner は tests 前にそれを起動するか verify しなければいけません。coverage が required gate なら provider を入れるべきです。e2e が release story の一部なら、implied convention ではなく real script が必要です。

次の repair path

修復順序は明確です。root の test:e2e script を追加または復元し、coverage provider を導入し、API-dependent tests の前に freemium runner が port 4000 の API を起動して health-check するようにすること。それ以外は theatre です。

これが KENSAI が守るべき standard です。不快な measurement を残し、壊れた preconditions に名前を付け、red run を短い fix list に変えることです。

Bottom line

Useful standard は単純です。prerequisite、artifact、route が揃ったときにだけ claim は real になります。今日の作業はその standard を見える形で保っています。