rule-validate

验证规则

检查实现是否符合其 rule-research 合约，包括测试和真实代码。

审查实现

检查以下内容：

• 误报以及遗漏的声称行为
• 错误的导入、别名或被遮蔽的绑定
• 不可能的控制流路径合并
• 被视为立即执行的嵌套函数
• 被视为静态名称的动态属性
• 遗漏的透明包装器
• 不受支持的导入值
• 夸大检测能力的消息
• 缺少有效和无效测试

接受新的辅助函数前，先使用 truffler：

bunx @rayhanadev/truffler "<helper-name>" packages \
  --kind function,method,interface,type,constant --limit 20

针对每个实现缺陷，添加一项有针对性的回归测试。

运行验证

运行有针对性的测试、软件包类型检查，以及必需的 lint 和格式检查。如果更改影响共享行为，则运行更全面的检查。

使用 rde-eval 对目标规则进行范围有限的本地检查。命中数量较少时，检查所有命中；数量较多时，检查有代表性的样本。将每个已确认的误报都添加到规则测试和 fuzz 语料库中。

每项新规则或检测行为变更，都要在推送拉取请求最新提交后运行 run-parity。仅文档或仅测试变更可跳过。如果无法运行 parity，请报告确切的阻碍。

除非两次 Vercel Sandbox 运行都已完成，否则不要声称 parity 已通过。分别比较仓库和项目根目录的计数。对目标规则的差异进行检查后，再对其归类。

准备发布产物

对于已发布软件包中面向用户的更改，运行 nr changeset。除非发布影响需要更高版本，否则规则、缺陷修复、误报修复和诊断优化都使用 patch changeset。仅私有、文档、测试或工具链变更可跳过，并说明原因。

验证完成后编写拉取请求说明：

## Why

<specific runtime problem>

## What changed

- <detector behavior>
- <valid patterns preserved>
- <tests added>

## Eval results

| Check             | Result                |
| ----------------- | --------------------- |
| Projects compared | `<count>`             |
| Skipped projects  | `<count>`             |
| Added / removed   | `<added> / <removed>` |
| Target rule delta | `<added> / <removed>` |
| False positives   | `<count>`             |
| Artifacts         | `<paths>`             |

## Test plan

- `<command and result>`

如果未运行 parity，则省略评估表，并说明原因。

处理审查意见

修复正确性缺陷、重复的辅助函数、误导性的名称和令人困惑的代码。只有当不受支持的控制流不属于合约范围时，才可暂缓处理。拒绝会扩大消息范围或增加误报的请求。

修复或说明已在拉取请求中落实后，解决相应的审查讨论串。

报告验证结果

报告运行的命令、审查发现、本地 RDE 证据、parity 结果或阻碍、修复的误报、回归测试、changeset、拉取请求说明以及剩余的非目标。