@critiq/rules 0.3.0 → 0.4.0

package/rules/ruby/ruby.bug-risk.mixed-regex-captures.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.mixed-regex-captures
+  title: Avoid mixing named and numbered regex captures
+  summary: >-
+    A regex literal contains both named captures (?<name>) and numbered
+    captures (parenthesized groups without names). Mixing these is confusing
+    and can lead to errors.
+  rationale: >-
+    Mixing named captures (?<name>) and numbered captures (parenthesized
+    groups) in the same regex makes it unclear how match data should be
+    accessed. It is better to use one style consistently.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1084
+  tags:
+    - rules-catalog
+    - ruby
+  stability: experimental
+  appliesTo: function
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.mixed-regex-captures
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.7
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` matches
+      `ruby.bug-risk.mixed-regex-captures`."
+  remediation:
+    summary: >-
+      Use only named captures or only numbered captures throughout the regex,
+      not both.

package/rules/ruby/ruby.bug-risk.multiple-rescues-for-same-exception.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.multiple-rescues-for-same-exception
+  title: Avoid multiple rescue clauses for the same exception
+  summary: >-
+    A begin-rescue block rescues the same exception class more than once. The
+    second rescue clause will never match since the first handles it first.
+  rationale: >-
+    Duplicate rescue clauses for the same exception class mean the second
+    rescue is unreachable. This is almost always a copy-paste error.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1091
+  tags:
+    - rules-catalog
+    - ruby
+  stability: experimental
+  appliesTo: function
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.multiple-rescues-for-same-exception
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.7
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` matches
+      `ruby.bug-risk.multiple-rescues-for-same-exception`."
+  remediation:
+    summary: >-
+      Remove the duplicate rescue clause or change it to handle a different
+      exception class.

package/rules/ruby/ruby.bug-risk.non-local-exit-from-iterator.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.non-local-exit-from-iterator
+  title: Non-local exit from iterator without return value
+  summary: >-
+    `return` inside an iterator block exits the enclosing method, not just the
+    block. `break` and `next` without a value return `nil` to the iterator.
+  rationale: >-
+    Using `return` inside an iterator block like `.each` or `.map` exits the
+    entire enclosing method, which is often surprising. Bare `break` and `next`
+    without values also silently return `nil`, hiding bugs.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1040
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: function
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.non-local-exit-from-iterator
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.75
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` matches
+      `ruby.bug-risk.non-local-exit-from-iterator`."
+  remediation:
+    summary: >-
+      Use `next value` to skip with a value, or `break value` to exit with a
+      value. For early return from a method, restructure the logic so `return`
+      is not inside a block.

package/rules/ruby/ruby.bug-risk.non-null-column-without-default.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.non-null-column-without-default
+  title: Non-null column should specify a default
+  summary: >-
+    Column definitions with `null: false` should also specify a `default` value
+    to avoid constraint failures when inserting records without the column.
+  rationale: >-
+    Adding a non-null column without a default causes existing records to fail
+    validation on save. Always provide a sensible default when adding or
+    changing a column to be non-nullable, or ensure all existing rows are
+    backfilled before deploying.
+  aliases:
+    - RB-RL1034
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.non-null-column-without-default
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.75
+    tags:
+      - ruby
+  message:
+    title: Non-null column `${captures.issue.text}` is missing a default
+    summary: >-
+      "`${captures.issue.text}` declares `null: false` but no `default:`.
+      Existing rows will fail to save without the column."
+  remediation:
+    summary: >-
+      Add a `default:` option to the column definition, or backfill existing
+      rows and remove the constraint.

package/rules/ruby/ruby.bug-risk.non-preferred-assert-falseness.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.non-preferred-assert-falseness
+  title: Use `assert_not` over `refute`
+  summary: >-
+    Prefer `assert_not` over `refute` for negative assertions.
+  rationale: >-
+    Rails and Minitest support both `refute` and `assert_not`, but
+    `assert_not` is the preferred and more readable form. Using `refute`
+    is a legacy style that is less consistent with the broader `assert_*`
+    family of test methods.
+  aliases:
+    - RB-RL1045
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.non-preferred-assert-falseness
+    bind: issue
+emit:
+  finding:
+    category: correctness.convention
+    severity: medium
+    confidence: 0.85
+    tags:
+      - ruby
+  message:
+    title: "Use `assert_not` instead of `${captures.issue.text}`"
+    summary: >-
+      "`${captures.issue.text}` uses `refute`. Use `assert_not` for
+      consistency with the `assert_*` family."
+  remediation:
+    summary: >-
+      Replace `refute` with `assert_not`. For example,
+      `refute value.nil?` → `assert_not value.nil?`.

package/rules/ruby/ruby.bug-risk.old-style-validation-macro.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.old-style-validation-macro
+  title: Old-style attribute validation macro detected
+  summary: >-
+    Uses the deprecated `validates_*_of` macro. Prefer the modern `validates`
+    method with options.
+  rationale: >-
+    Rails deprecated the per-attribute validation macros (`validates_presence_of`,
+    `validates_numericality_of`, etc.) in favor of the unified `validates` method.
+    The modern `validates` syntax is more concise and composable.
+  aliases:
+    - RB-RL1057
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+    - rails
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.old-style-validation-macro
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.95
+    tags:
+      - ruby
+  message:
+    title: "Deprecated validation macro `${captures.issue.text}`"
+    summary: "'${captures.issue.text}' uses a deprecated per-attribute validation macro. Use `validates :attr, ...` instead."
+  remediation:
+    summary: >-
+      Replace `validates_presence_of :attr` with `validates :attr, presence: true`,
+      and similarly for other `validates_*_of` macros. See the Rails upgrade guide.

package/rules/ruby/ruby.bug-risk.outer-variable-shadowed.rule.yaml

@@ -0,0 +1,47 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.outer-variable-shadowed
+  title: Outer local variable is shadowed
+  summary: >-
+    A block parameter has the same name as a variable in the outer scope.
+    Inside the block, the outer variable is inaccessible.
+  rationale: >-
+    Shadowing makes the outer variable inaccessible inside the block, which
+    is often unintentional and can lead to subtle bugs or confusing code.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1066
+  tags:
+    - rules-catalog
+    - ruby
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.outer-variable-shadowed
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: medium
+    confidence: 0.65
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}` shadows outer variable
+    summary: >-
+      "`${captures.issue.text}` reuses a name from the enclosing scope."
+  remediation:
+    summary: >-
+      Rename the block parameter to avoid shadowing the outer variable.

package/rules/ruby/ruby.bug-risk.plain-method-instead-of-proc.rule.yaml

@@ -0,0 +1,48 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.plain-method-instead-of-proc
+  title: Use lambda/proc instead of a plain method call
+  summary: >-
+    A `method(:name)` call is passed directly to a block-accepting method.
+    Use `&method(:name)` or an explicit block/lambda instead.
+  rationale: >-
+    When `method(:name)` is passed as a bare argument to an enumerable method,
+    it does not behave as a block reference. Use `&method(:name)` to convert
+    the method into a Proc, which is the idiomatic way to pass methods as blocks.
+  aliases:
+    - RB-RL1052
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.plain-method-instead-of-proc
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.85
+    tags:
+      - ruby
+  message:
+    title: "Use `&method(:...)` instead of bare `method(:...)`"
+    summary: "'${captures.issue.text}' passes a bare method reference. Use the `&method(:name)` syntax to convert it to a block."
+  remediation:
+    summary: >-
+      Replace `method(:name)` with `&method(:name)` to properly convert the
+      method into a block reference.

package/rules/ruby/ruby.bug-risk.predicate-method-without-parentheses.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.predicate-method-without-parentheses
+  title: Predicate method called without parentheses
+  summary: >-
+    A predicate method ending in `?` is called with an argument but
+    without parentheses. Ruby may parse this differently than intended
+    in compound expressions.
+  rationale: >-
+    In Ruby, `foo.nil? bar && baz` is parsed as
+    `(foo.nil?(bar)) && baz`, not `foo.nil?(bar && baz)`. Adding
+    parentheses makes the call unambiguous.
+  aliases:
+    - RB-LI1055
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.predicate-method-without-parentheses
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.85
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` matches
+      `ruby.bug-risk.predicate-method-without-parentheses`."
+  remediation:
+    summary: >-
+      Add parentheses around the argument: `foo.pred?(arg)` to avoid
+      ambiguity with operator precedence.

package/rules/ruby/ruby.bug-risk.rails-env-equality.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.rails-env-equality
+  title: Bad comparison of Rails.env value
+  summary: >-
+    `Rails.env` should be compared using predicate methods
+    (`Rails.env.production?`) instead of equality operators.
+  rationale: >-
+    Comparing `Rails.env` with `==`, `!=`, or `.eql?` is fragile and less
+    idiomatic than using the built-in predicate methods like
+    `Rails.env.production?`, `Rails.env.development?`, or
+    `Rails.env.test?`.
+  aliases:
+    - RB-RL1020
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+    - rails
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.rails-env-equality
+    bind: issue
+emit:
+  finding:
+    category: correctness.convention
+    severity: medium
+    confidence: 0.85
+    tags:
+      - ruby
+      - rails
+  message:
+    title: "Use `Rails.env.{predicate}?` instead of `${captures.issue.text}`"
+    summary: >-
+      "`${captures.issue.text}` compares `Rails.env` with an operator. Use
+      the corresponding predicate method instead."
+  remediation:
+    summary: >-
+      Replace `Rails.env == "production"` with
+      `Rails.env.production?` and similar predicate forms for other envs.

package/rules/ruby/ruby.bug-risk.rails-root-join.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.rails-root-join
+  title: Use Rails.root.join instead of path concatenation
+  summary: >-
+    Path concatenation with `Rails.root` using `+` or `File.join` is
+    less idiomatic than using `Rails.root.join`.
+  rationale: >-
+    `Rails.root.join('dir', 'file')` returns a `Pathname` object with
+    cross-platform path separators and is the idiomatic Rails way to build
+    absolute paths. String concatenation with `Rails.root.to_s +` or
+    `File.join(Rails.root, ...)` works but is less clean.
+  aliases:
+    - RB-RL1022
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+    - rails
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.rails-root-join
+    bind: issue
+emit:
+  finding:
+    category: correctness.convention
+    severity: low
+    confidence: 0.85
+    tags:
+      - ruby
+      - rails
+  message:
+    title: "Use `Rails.root.join(...)` instead of `${captures.issue.text}`"
+    summary: >-
+      "`${captures.issue.text}` builds a path with string concatenation or
+      `File.join`. Use `Rails.root.join(...)` for cross-platform paths."
+  remediation:
+    summary: >-
+      Replace `Rails.root + '/public'` with
+      `Rails.root.join('public')` or `Rails.root.join('app', 'models')`.

package/rules/ruby/ruby.bug-risk.rake-task-missing-environment.rule.yaml

@@ -0,0 +1,46 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.rake-task-missing-environment
+  title: Rake task found without `:environment` task dependency
+  summary: >-
+    Rake tasks that load application code should declare `:environment` as a
+    dependency to ensure Rails is loaded before execution.
+  rationale: >-
+    Rake tasks that reference models, routes, or other Rails components will
+    fail if `:environment` is not declared as a dependency. Declaring
+    `:environment` loads the Rails application before the task body runs.
+  aliases:
+    - RB-RL1040
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rake"
+match:
+  fact:
+    kind: ruby.bug-risk.rake-task-missing-environment
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.8
+    tags:
+      - ruby
+  message:
+    title: Task `${captures.issue.text}` is missing `:environment` dependency
+    summary: >-
+      "Rake tasks loading Rails components should declare `:environment` as
+      a dependency."
+  remediation:
+    summary: >-
+      Add `:environment` as a dependency, e.g. `task my_task: :environment do`.

package/rules/ruby/ruby.bug-risk.redundant-allow-nil.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.redundant-allow-nil
+  title: Redundant `allow_nil` detected
+  summary: >-
+    A `validates` declaration includes both `allow_nil: true` and
+    `allow_blank: true`. Since `allow_blank: true` already permits `nil`
+    values, the `allow_nil` option is redundant.
+  rationale: >-
+    In ActiveModel validations, `allow_blank: true` implicitly allows `nil`
+    values (since `nil.blank?` returns `true`). Specifying both
+    `allow_nil: true` and `allow_blank: true` is redundant. Only
+    `allow_blank: true` is needed.
+  aliases:
+    - RB-RL1042
+  detection:
+    kind: pattern
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.redundant-allow-nil
+    bind: issue
+emit:
+  finding:
+    category: maintainability
+    severity: medium
+    confidence: 0.85
+    tags:
+      - ruby
+  message:
+    title: "Redundant allow_nil: true with allow_blank: true"
+    summary: >-
+      "allow_nil: true is redundant when allow_blank: true is already
+      specified, since allow_blank covers nil values."
+  remediation:
+    summary: >-
+      Remove allow_nil: true from the validation. allow_blank: true
+      already permits nil values.