How to distinguish files that share the same extension (e.g. GTK .ui vs Qt .ui) when matching review rules?

[ckappgit]

Hi everyone,
First of all, thank you for building and maintaining open-code-review — it's been really helpful in my workflow. I'm writing as a user who has run into a limitation, and I'd love to hear whether there's a good way to solve it.
From what I understand, review rules are currently matched purely by file name or extension — for example, a rule like *.py applies to all Python files. This works well in most cases, since most file extensions map one-to-one to a file type. However, I've hit a case where this breaks down: the .ui extension is used by both Qt and GTK . Since both match *.ui, there's no way for me to write a rule that applies to Qt UI files but not GTK ones.
I completely understand if this is out of scope or low priority — I just wanted to raise it in case others have run into the same thing. Any thoughts or pointers would be greatly appreciated. Thank you for your time and for all the work on this project!
Best regards,
ckappgit

[stay-foolish-forever]

Hi @ckappgit — thanks for the kind words, and for raising this. It's a great question worth a clear answer.

A small clarification first: OCR's rule matching isn't tied to file extensions. Patterns are matched against the full repo-root-relative path using doublestar glob syntax (**, *, {a,b,c}, ?, [...]), case-insensitively. So as long as your Qt and GTK .ui files differ by directory or filename convention — which is usually the case — you can already give each its own rule today, no code change needed.

The full glob reference and the rule-resolution priority chain are in our docs: https://open-codereview.ai/docs/review-rules

One practical detail: .ui isn't in OCR's built-in extension allowlist, so to review .ui files at all you need an include entry to admit them. From there, list your rules entries most-specific-first so the intended rule wins (first match wins).

Recipe 1 — distinct rules by directory

Say Qt files live under qt/ or forms/, and GTK files under ui/:

{
  "include": ["**/*.ui"],
  "rules": [
    { "path": "**/{qt,forms}/**/*.ui", "rule": "Qt Designer: check widget object names, signal/slot connections, layout margins, .ui version." },
    { "path": "**/ui/**/*.ui",         "rule": "GTK GtkBuilder: check object IDs, signal handlers, accessible roles, translatable strings." }
  ]
}

Recipe 2 — distinct rules by filename convention

If the files share a directory but follow a naming pattern:

{
  "include": ["**/*.ui"],
  "rules": [
    { "path": "**/*_qt.ui",  "rule": "Qt UI rules…" },
    { "path": "**/*_gtk.ui", "rule": "GTK UI rules…" }
  ]
}

Recipe 3 — review only one type, drop the other

include admits the type you want; everything else falls through to the extension allowlist and is excluded:

{
  "include": ["**/qt/**/*.ui"],
  "exclude": ["**/gtk/**/*.ui"]
}

Verify which rule wins

ocr rules check path/to/MainWindow.ui

This prints the layer + pattern that matched, which is the fastest way to confirm your ordering is right.

---

The one case this can't cover: Qt and GTK .ui files sitting in the same directory with no distinguishing filename — there the only reliable signal is file content (Qt root <ui version="…"> vs GTK root <interface>), which would require content-sniffing we don't have today. If that's your situation, let us know and we're happy to track it as a feature request.

[ckappgit]

Hi ,
Thank you for the detailed write-up!
My own case turns out to be simpler than the question implied — I only have GTK .ui files, so one include entry plus a single rule covers me completely.
What I was actually poking at yesterday, though, is whether rules could also match on file content. I went through a few implementation ideas in the codebase — at one point I was seriously weighing an embedded Lua scripting engine for pluggable matchers — before realizing they're all massively over-engineered for what's essentially "look at the first XML tag."
The simplest version I could come up with is just an optional content regex on a rule, like { "path": "**/*.ui", "content": "<interface", ... }. No scripting engine needed, and it would work for any same-extension-different-format case, not just .ui. Anyway, just a thought in case it's ever on the roadmap.
Thanks again, and best regards,
ckappgit

[stay-foolish-forever]

Hi @ckappgit — really appreciate you following up, and even more that you kept digging into the general question after your own case was already solved. That's exactly the kind of thinking that makes a feature request genuinely useful.

For what it's worth, your instinct that a Lua scripting engine is over-engineered is spot-on, and the content regex is the version we'd land on too. It's the right level of abstraction — declarative, no scripting surface to secure, and general enough to cover the whole "same extension, different format" class (.ui is just the obvious one; .xml/.json/.yaml dialects would benefit as well).

We do want to pick this up, but we want to do it properly rather than bolt it on. A few things we'd want to settle in a design pass before committing to a shape:

• When content gets read — eagerly for every file is too costly; ideally content matching only engages when a path glob is ambiguous (several rules could match the same path), so we only pay the I/O when it actually disambiguates.
• How path + content combine — as an AND within a single entry, and where it sits in the first-match-wins ordering next to pure-path rules.
• What gets scanned — full content vs. a bounded header (sniff the first N bytes / first tag), to stay cheap and avoid pulling large or binary blobs into the matcher.
• Regex safety & encoding — guard against catastrophic backtracking, and define behavior for binary / non-UTF-8 files.
• Pipeline fit — today rule resolution only sees the path (the resolver's signature is essentially Resolve(path string)), so threading content through also touches the filter and batching layers; we want that integration to be clean.

That's not a soft "no" — it's a "we want it to be general and robust, so we'll discuss and design before shipping." We'll keep this discussion as the home for that conversation, and I'll circle back when there's a concrete proposal to react to.

For now, the pragmatic recommendation is still the one above: organize files so directory/filename globs can tell them apart. Glad to hear a single include + rule already unblocks you.

Thanks again for the well-reasoned write-up — it genuinely helps us prioritize.

[wu21-web]

What about some files without extensions, like Dockerfile, CODEOWNERS, id_rsa (actually no these are secrets), but how can we setup review rules that don't have one extension? Can I skip the extension entirely and match rules with globs, but they are not allowed actually.

[Parikalp-Bhardwaj]

I checked the current filtering implementation because this question is closely related to the extension collision I encountered while adding HDL support in #1050.

Both review paths reject unsupported files only when the detected extension is non-empty:

• internal/agent/preview.go
• internal/scan/agent.go

For files such as Makefile, Dockerfile, and CODEOWNERS, extFromPath returns an empty string, so they continue through normal filtering. This behavior is also covered by the file without extension test for Makefile in preview_test.go.

Rules can therefore target the complete filename directly:

{
  "rules": [
    {
      "path": "**/Dockerfile",
      "rule": "Review Docker build correctness, caching, image size, and security."
    },
    {
      "path": "**/CODEOWNERS",
      "rule": "Review ownership patterns, ordering, and unintended coverage gaps."
    },
    {
      "path": "**/Makefile",
      "rule": "Review target dependencies, portability, quoting, and error handling."
    }
  ]
}

One caveat is that a rule only selects the review guidance; it does not admit a file that filtering would otherwise reject. This works without include specifically because these files have no extension. A file with an unsupported extension would still require an appropriate include glob.

ocr rules check Dockerfile confirms which rule is selected, while ocr review --preview confirms whether the file survives filtering.

Repositories that may contain sensitive files should also consider explicit exclusions such as **/.ssh/** as defense in depth, although private keys should never be committed in the first place.

Content matching would still be valuable for genuinely ambiguous extensions. I encountered the same limitation with .v, which is treated as Verilog here but is also used by the V programming language.