KENSAI 产品更新：夜间测试证据取代自我安慰指标

4月26日的开场并不好看：夜间 freemium 测试套件没有通过。但真正的进步在于，这次失败没有被抹平，而是被保留下来，并且已经精确到可以修。

夜间运行证明了什么

4月26日的 cron 回执记录了平台仓库中的整套 KENSAI freemium 测试。结果不是一句模糊的“红了”，而是一张具体的失败地图：pnpm test 在 636 个测试后以 code 1 退出，其中 310 个失败，243 个通过，83 个跳过。

最主要的失败类型是依赖 API 的测试，它们期待 127.0.0.1:4000 上有服务，但当时 API 根本没有起来，于是出现连接拒绝和 status-zero 断言。这不是产品玄学，而是预检缺失和服务编排缺陷。

缺了什么

另外两个缺口也被记录下来，而不是被掩盖。根包没有定义 pnpm test:e2e，所以 runner 没有稳定的 e2e 入口。覆盖率命令也立刻失败，因为缺少 @vitest/coverage-v8。直接用 Playwright 的 fallback 虽然启动了，但大范围 auth/admin 错误和一分钟级超时让它更像噪音，不适合被误读成有效信号。

为什么这属于产品更新

一次失败的测试运行并不会自动变成进展。但如果失败运行附带明确计数、主导错误类型、缺失工具和下一步修复路径，那就是进展。现在质量系统已经能区分“应用真的坏了”和“基础设施根本没启动”。

这对 KENSAI 很重要，因为面对客户的安全承诺依赖的是枯燥但可靠的运营真相。如果 freemium 路径需要 API，runner 就必须先启动它或验证它。如果覆盖率是必过关卡，就必须装好 provider。如果 e2e 是发布故事的一部分，它就需要真实脚本，而不是默认约定。

下一条修复路径

修复顺序已经很清楚：新增或恢复根级 test:e2e 脚本，安装 coverage provider，并让 freemium runner 在执行依赖 API 的测试前先启动并健康检查 4000 端口上的 API。除此之外都是表演。

这就是 KENSAI 应该坚持的标准：保留不舒服的测量结果，点名破损的前置条件，把一次红色运行变成一张简短的修复清单。

结论

真正有用的标准很简单：只有当前置条件、产物和路由同时对齐时，声明才算真实。今天的工作就是把这个标准继续摆在台面上。