Python stub (.pyi) files fall back to generic review rules

[DreamZhongJu]

OpenCodeReview Version

Current main at 24edcbd3b7d0e10adf7f7277aaeaa6374869235a.

Operating System

Windows

Installation Method

Built from source

LLM Provider

Not applicable. This happens during built-in rule resolution before any LLM request.

Bug Description

OpenCodeReview accepts .pyi files through supported_file_types.json, but the built-in Python rule mapping only covers .py and .ipynb:

"**/*.{py,ipynb}": "python.md"

As a result, Python stub files are reviewable but silently fall back to default.md instead of receiving language-specific guidance.

Steps to Reproduce

With no custom, project, or global review rules configured, run:

ocr rules check stubs/example.pyi

The result is:

File: stubs/example.pyi
Source: System built-in
Pattern: default

For comparison, a .py file resolves through the Python mapping and loads python.md.

Expected Behavior

The built-in behavior for .pyi files should be explicit and appropriate for Python type stubs.

Two possible directions are:

1. Include .pyi in the existing Python mapping:

   "**/*.{py,pyi,ipynb}": "python.md"

2. Add a dedicated rule for Python stub files if their review requirements should differ from regular Python source.

Would the maintainers prefer .pyi to reuse python.md, or to have a separate stub-specific rule?

Additional Context

.pyi is already part of the supported extension allowlist, so this does not require changing file eligibility.

A similar routing gap for .mjs and .cjs was fixed in #1122. This report is limited to .pyi; other extensions that currently use the generic fallback may require separate language rules or have ambiguous semantics.

[wu21-web]

@DreamZhongJu Thank you for posting this issue, one question: Why do you want to hook a python interface doc extension to the review? They basically do nothing, they are basically documentation that don't run at all. Almost the same as .md (which nevers get reviewed)

[DreamZhongJu]

Thanks for pointing this out. I noticed this while checking how OCR resolves rules for supported file extensions.
Since .pyi is listed in supported_file_types.json but resolves to the default rules, I initially assumed this mismatch was unintended and reported it as a bug.
I understand now that being allowlisted does not necessarily mean a file type should have dedicated language rules, and .pyi files do not contain runtime implementation. If the current generic handling is intentional, please feel free to close the issue. Sorry for the confusion.