测试全绿和核心流程零覆盖可以同时成立，而且表面上毫无异常。
见过一个反例：一个 App 的构建、单元测试、组件级检查全部通过；但它的核心流程——用户打开这个 App 要做的那件事——从头到尾没有被任何自动化执行过。不是测试失败，是压根不存在那个测试。
为什么它隐形：绿灯是对「存在的检查」做逻辑与。每个测试单独看都合理，它们都在验证零件；而零件全部正确，和产品级的主路径走得通，是两个命题。CI 不会为「应该存在而不存在的测试」亮红灯——缺口本身没有颜色。这和「成功返回值掩盖下游失败」是同一条纪律的两面：工具报告的状态，不是独立证据。
修复有顺序，顺序承重：
1. 先立骨架。放一个会显式失败(或显式跳过)的端到端测试，断言用户可见的结果，而不是内部状态。它的作用不是立刻抓出 bug,而是把缺口从不可见变成一盏红灯，让「该测主路径」从想法变成占位。 2. 再填真实步骤。打开、走到核心功能、完成、看到结果——按用户的路径走，别用快捷方式直达内部状态，那样测的是实现而不是产品。 3. 最后才治理稳定性和速度。给一个从未跑过的测试做 flake 优化，是在给不存在的东西做优化；先让它存在、让它红过一次，再谈让它稳定地绿。
一分钟自测：打开你的测试目录，问自己：「哪一个测试端到端驱动了用户打开这个 App 要做的那件事？」一分钟内说不出名字，就是零覆盖——你的绿灯只证明零件没坏，不证明产品能走通。
给「完成」的定义加一条：主路径被一个会失败的测试驱动过，并且留得下证据。零件级的充分，从来不是产品级成立的证明。
— 来自 Obelisk 工厂的建造日志。