false-green-tests 是一个针对“测试套件全绿但应用实际已损坏”问题的排查技能，来自 reticlehq/reticle。它围绕一个核心判断展开：绿色测试是关于测试的证据，而不是关于应用的证据。该技能通过实际运行真实应用，并把应用的真实行为与测试所声称的行为进行比对，来区分两者。
主要能力：借助 Reticle 从应用内部观察，涵盖 DOM、网络、控制台、路由和框架状态。它归纳了五类值得按顺序检查的假绿形态。
第一，断言不可能失败。读取用户信任的测试，如果它只断言“不存在”（无控制台错误、无抛出异常、无被拒绝的 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”，就是假绿。
第二，测试驱动的是 mock，而应用驱动的是 API。比较应用实际发出的请求与测试打桩的内容：
reticle_observe({ action: "network", sessionId, since })
测试断言应有请求却没有任何请求，说明套件验证的是 fixture。过期的客户端缓存是同一种失败，只是根本没有请求可看，这也是注册 TanStack Query 重要的原因：缓存是唯一的见证者。
第三，UI 动了但状态没动。这是最强的假绿，且任何 DOM 或截图检查都看不到：
reticle_look({ action: "state", sessionId, store, path })
视图渲染一个值、而 store 保存另一个值，是渲染树无法呈现的 bug。如果这里返回空或 hasCapabilities 为 false，说明没有注册 store：必须说明这一点，因为在注册之前，上述所有状态检查都是空洞的。
第四，没人读取响应。应用从未消费的 2xx 会显示为 verified: "unknown" 且 verifiedReason: "outcome_unread"。这通常是真实的应用 bug，而只对请求做断言的测试会把它当作通过。
第五，整块界面无人触碰。
reticle_run({ tool: "reticle_verify", sessionId, args: { action: "crawl" } }) // 点击扫描，返回异常 reticle_run({ tool: "reticle_verify", sessionId, args: { action: "coverage" } }) // { total, exercised, untouched }
crawl 之所以存在，是因为显而易见的手写扫描（点击每个控件、断言无控制台错误）本身就是第一类形态。
什么才算证据：只有应用与测试矛盾时，假绿才被确认，而不是凭借不安的感觉。Reticle 会直接命名该情况：verified: "no" 且 verifiedReason: "contradicted" 表示某个通道观测到与 UI 声明不兼容的情况，例如屏幕推进的同时请求失败、信号与 DOM 不一致、某个字段回显了没人要求的值。unknown 不是假绿，也不是通过，它表示 Reticle 无法判断，应按 unknown 报告。
随后修测试，而不只是修应用：每确认一个假绿，错过它的那个测试仍然存在，并且会再次错过。应把断言改写为点名应用必须产生的后果（带状态的请求、信号、状态路径），而不是断言“不存在”。永远不要为了让判定变绿而削弱检查，那正是假绿混进来的方式。
获取完整索引可逐页查看：curl https://docs.reticle.sh/llms.txt。如果发现 Reticle 看不到的情况，使用 reticle_session { action: "feedback" } 并设置 kind: "gap"，这正是决定后续构建方向的信号。
使用方式与限制：未安装时先执行 RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init，然后参考 install-and-verify 技能。该技能主要面向测试质量与前端行为验证场景，需要真实运行应用并接入 Reticle 观测能力；关于是否收费、支持平台等细节，资料暂未提供。