rule-research

Research a rule

Produce a rule contract that rule-writing can implement without guessing.

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:

   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.

Write the contract

Return:

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.