false-green-tests

测试套件全绿，应用却出了问题

测试通过，只能证明测试本身通过了，不能证明应用没问题。此技能会将两者区分开：运行真正的应用，并对比它_实际做了什么_与测试_声称了什么_。

它使用 Reticle，从应用内部观察正在运行的应用：DOM、网络、控制台、路由和框架状态。还没设置？请按照 reticle 技能操作：它会安装 Reticle，在 init 更改应用文件前征求用户同意，并验证一个工作流。

五种情况，按值得检查的优先顺序排列

1. 断言不可能失败。 阅读用户信任的测试。如果它只断言某种情况不存在（没有控制台错误、没有抛出异常、没有被拒绝的 Promise），那即使控件什么都没连接，它也会通过。失效的按钮不会抛出任何内容、触发任何操作，也不会改变任何状态。请在应用中验证这一点：

reticle_act_and_wait({ sessionId, ref, action: "click", until: { kind: "allOf", predicates: [
  { kind: "net",    method: "POST", urlContains: "/api/...", status: 200 },
  { kind: "signal", name: "..." },
]}})

如果测试套件全绿，而这里的判定是 no，那就是虚假通过。

2. 测试驱动了模拟对象，而应用调用的是 API。 对比应用实际发出的请求与测试模拟的内容：

reticle_observe({ action: "network", sessionId, since })

测试断言有请求，却没有实际请求，说明测试套件验证的只是测试数据。客户端缓存过期也是同一种问题，只不过完全没有请求可供检查。这就是为什么注册 TanStack Query 很重要：缓存是唯一的见证。

3. UI 变了，状态却没变。 这是最严重的虚假通过，也是任何 DOM 或截图检查都无法发现的问题：

reticle_look({ action: "state", sessionId, store, path })

视图显示一个值，存储中却保存着另一个值，这是渲染树无法揭示的错误。如果这里返回空结果或 hasCapabilities 为 false，说明没有注册存储：请明确指出这一点，因为在此之前，所有状态检查都没有意义。

4. 没有人读取响应。 应用从未使用过的 2xx 响应会显示为 verified: "unknown"，并带有 verifiedReason: "outcome_unread"。这通常是应用中的真实错误，而只断言请求的测试却会把它判为通过。

5. 有人完全没测试过的整片功能区域。

reticle_run({ tool: "reticle_verify", sessionId, args: { action: "crawl" } })      // click sweep, returns anomalies
reticle_run({ tool: "reticle_verify", sessionId, args: { action: "coverage" } })   // { total, exercised, untouched }

提供 crawl 是因为，显而易见的手动遍历方式（逐个点击控件，并断言没有控制台错误）本身就属于情况 1。

什么才算证据

只有当应用与测试的说法相矛盾时，才能确认是虚假通过；仅仅感到不放心还不够。Reticle 会直接标记这种情况：verified: "no" 且 verifiedReason: "contradicted"，表示某个通道观察到了与 UI 声称不一致的内容：屏幕已切换，但请求失败；信号与 DOM 不一致；字段返回了无人请求的值。

unknown 既不代表虚假通过，也不代表通过。它表示 Reticle 无法判断。请报告为未知。

接着修复测试，而不只是修复应用

每次确认虚假通过后，漏掉问题的测试仍然存在，下次还会再次漏掉。请重写断言，明确指出应用必须产生的结果（带有状态码的请求、信号、状态路径），而不是仅仅断言某种情况不存在。绝不要为了让判定变绿而弱化检查；虚假通过就是这样产生的。

一页一页查看完整索引：curl https://docs.reticle.sh/llms.txt。发现 Reticle 看不到的问题？使用 reticle_session { action: "feedback" }，并设置 kind: "gap"：这项反馈会决定接下来构建什么。