Back to Details

rule-research

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Research a rule

研究规则

Produce a rule contract that 
rule-writing
can implement without guessing.
生成一份
rule-writing
无需猜测即可实现的规则契约。

Define the behavior

定义行为

Resolve only questions that affect correctness:
  • Which code pattern should report?
  • Which runtime behavior makes it harmful?
  • Which similar code must stay quiet?
  • Does detection need syntax, scope, or path analysis?
  • Which imported, dynamic, type-driven, or interprocedural cases stay out of scope?
If the user requested implementation, make the contract concise and continue.
仅解决影响正确性的问题：
  • 哪些代码模式需要上报？
  • 哪些运行时行为会造成危害？
  • 哪些相似代码无需上报？
  • 检测是否需要语法、作用域或路径分析？
  • 哪些导入、动态、类型驱动或过程间的情况不属于范围？
如果用户要求实现，请简化契约并继续。

Collect evidence

收集证据

  1. Define the rule in one sentence: 
    This rule catches <pattern> that causes <problem>.
  2. Explain the runtime reason.
  3. Inspect nearby rules, tests, utilities, and the generated registry.
  4. Use 
    truffler
    before proposing a new detector or helper:
    sh
    bunx @rayhanadev/truffler "<symbol-or-behavior>" \
  packages/oxlint-plugin-react-doctor/src/plugin \
  --kind function,interface,type,constant --limit 20
  5. Gather official documentation, implementation notes, related linter behavior, and open-source examples.
  6. Separate strong positives, adjacent patterns, valid traps, and unsupported cases.
  7. Choose syntax-only, scope-aware, or path-aware detection.
Use 
rde-eval
when a bounded open-source sample could change the contract. Leave final pull request parity to 
rule-validate
.
  1. 用一句话定义规则：
    This rule catches <pattern> that causes <problem>.
  2. 解释运行时原因。
  3. 查看相关规则、测试、工具及生成的注册表。
  4. 在提议新的检测器或辅助工具前使用
    truffler
    ：
    sh
    bunx @rayhanadev/truffler "<symbol-or-behavior>" \
  packages/oxlint-plugin-react-doctor/src/plugin \
  --kind function,interface,type,constant --limit 20
  5. 收集官方文档、实现说明、相关检查器行为及开源示例。
  6. 区分明确上报项、相似模式、有效陷阱及不支持的情况。
  7. 选择仅语法检测、感知作用域或感知路径的检测方式。
当有限的开源样本可能改变契约时，使用
rde-eval
。将最终的拉取请求一致性验证交给
rule-validate
。

Write the contract

编写契约

Return:
md
Rule definition:
<pattern and specific problem>

Runtime reason:
<short explanation>

Detector precision:
<syntax-only, scope-aware, or path-aware>

Evidence:

- <source and implication>

Strong positives:

- <reportable examples>

False-positive traps:

- <valid examples>

In scope:

- <supported cases>

Out of scope:

- <explicit boundaries>

Test seeds:

- <invalid and valid fixtures>

Open questions:

- <correctness blockers only>
Treat false positives as correctness bugs. Keep the diagnostic narrower than or equal to the proven behavior. Split adjacent ideas into separate rules.
返回：
md
Rule definition:
<pattern and specific problem>

Runtime reason:
<short explanation>

Detector precision:
<syntax-only, scope-aware, or path-aware>

Evidence:

- <source and implication>

Strong positives:

- <reportable examples>

False-positive traps:

- <valid examples>

In scope:

- <supported cases>

Out of scope:

- <explicit boundaries>

Test seeds:

- <invalid and valid fixtures>

Open questions:

- <correctness blockers only>
将误报视为正确性缺陷。确保诊断范围不超过已验证的行为范围。将相似的构想拆分为独立规则。