audit-my-app

全面检查整个应用并报告故障

无需了解代码库也能进行检查。Reticle 会操作运行中应用里的所有可访问控件，并报告异常。还没配置？请按照 reticle 技能操作：它会安装 Reticle，在 init 修改应用文件前征求用户同意，并验证一个流程。

1. 询问应用能做什么

reticle_run({ tool: "reticle_capabilities", args: { sessionId } })

大约 1 KB，由应用自行描述可测试的范围：所有已注册的 testid、所有领域信号、各个存储，以及包含步骤的已保存流程。这比对 DOM 做快照并从元素名称推断意图更可靠，也是成本最低的了解方式。

2. 点击所有控件

reticle_run({ tool: "reticle_verify", sessionId, args: { action: "crawl", maxSteps: 25 } })

{
  "interactiveFound": 3,
  "stepsRun": 3,
  "anomalies": [],
  "counts": { "consoleErrors": 0, "failedRequests": 0, "deadControls": 0, "contradictions": 0 },
  "visited": ["- textbox \"Email\"", "- button \"Sign in\""],
  "truncated": false
}

deadControls 和 contradictions 是代表真实问题的两个计数。 控制台错误和请求失败值得查看，但繁忙的应用出现这两种情况也可能并无异常。无响应控件是指没有绑定任何操作的按钮；矛盾则是指某个渠道与屏幕显示的内容不一致。

它会点击所有控件，所以请在开发环境中运行。maxSteps 限制操作步数，默认值为 25。想先进行非破坏性检查，看看有哪些控件可访问但不操作？运行 reticle_run({ tool: "reticle_explore", sessionId })。

不要手动编写这类全面检查。最直观的做法（逐个点击控件，并断言没有控制台错误）恰好会漏掉你要检查的 Bug，因为无响应按钮不会抛出任何错误。

3. 对比 API 返回内容与渲染结果

reticle_run({ tool: "reticle_reconcile", sessionId })

API 返回了十行，表格只显示九行，没有任何错误。网络日志和 DOM 单独来看都没有问题。只有对比才能发现这个问题，其他任何可运行的操作都无法进行这种对比。

4. 找出无人检查的部分

reticle_run({ tool: "reticle_verify", sessionId, args: { action: "coverage" } })   // { total, exercised, untouched }

如果项目已经保存了流程，也要问问它们是否能证明什么：

reticle_run({ tool: "reticle_domain", sessionId })
// → { flowCount, coverage: { asserted, presenceOnly, assertionFree }, gaps: { declaredUntestedSignals, … } }

一套有 40 个流程、其中 31 个没有任何断言的测试套件，无论发生什么回归，都可能一直显示通过。这个数字通常是整个审计中最令人担忧的指标，其他任何工具都不会报告它。

5. 报告

先列出计数，然后每个实际问题用一行说明，并附上通过 reticle_look { action: "element" } 获取的 file:line。分类如下：

• 已损坏：无响应控件、矛盾、请求失败，以及检查过程中抛出的错误。
• 未经验证：untouched 控件和 assertionFree 流程。并非已知存在问题，而是已知尚未检查。
• 已有问题：全面检查开始前就存在的控制台错误。请明确说明，避免有人把它们归咎于今天的改动。

不要把未完成的审计报告成检查通过。 如果 truncated 为 true，或 maxSteps 导致检查提前结束，请说明哪些部分尚未检查。静默达到上限，看起来像是“一切正常”，实际上却是“检查到此为止”。

---

完整功能参考：curl https://docs.reticle.sh/capabilities.md。其他内容：curl https://docs.reticle.sh/llms.txt。