@critiq/rules 0.3.0 → 0.4.0

package/rules/ruby/ruby.bug-risk.redundant-foreign-key.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.redundant-foreign-key
+  title: Redundant `foreign_key` in ActiveRecord association
+  summary: >-
+    Explicit `foreign_key` matches the Rails default convention
+    (`<association_name>_id`). The explicit declaration is redundant.
+  rationale: >-
+    Rails automatically infers the foreign key column from the association name.
+    Declaring an explicit `foreign_key` that matches the default adds noise
+    without changing behavior.
+  aliases:
+    - RB-LI1105
+  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-foreign-key
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.75
+    tags:
+      - ruby
+  message:
+    title: Redundant `foreign_key` on `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` declares an explicit foreign_key that matches
+      the Rails default convention."
+  remediation:
+    summary: >-
+      Remove the explicit `foreign_key` when it matches the Rails default
+      convention (`<association_name>_id`).

package/rules/ruby/ruby.bug-risk.redundant-with-options-receiver.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.redundant-with-options-receiver
+  title: Redundant with_options receiver references
+  summary: >-
+    Inside a `with_options` block, use implicit method calls instead of
+    explicitly calling methods on the block variable.
+  rationale: >-
+    The `with_options` method yields a block variable that shadows the
+    receiver. Calling methods on the block variable (e.g. `assoc.has_many`)
+    instead of using implicit receiver (`has_many`) defeats the purpose
+    of `with_options` and is redundant.
+  aliases:
+    - RB-RL1043
+  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-with-options-receiver
+    bind: issue
+emit:
+  finding:
+    category: correctness.framework
+    severity: medium
+    confidence: 0.85
+    tags:
+      - ruby
+      - rails
+  message:
+    title: "`${captures.issue.text}` uses redundant receiver inside with_options"
+    summary: >-
+      "`${captures.issue.text}` calls a method on the `with_options` block
+      variable. Call it implicitly instead."
+  remediation:
+    summary: >-
+      Remove the block variable receiver and call the method directly.
+      For example, replace `|assoc| assoc.has_many :x` with `do; has_many :x; end`.

package/rules/ruby/ruby.bug-risk.regex-literal-in-condition.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.regex-literal-in-condition
+  title: Regex literal used as condition
+  summary: >-
+    A regex literal is used directly as a condition expression. Without
+    `=~` or `.match?` the regex is always truthy, making the condition
+    behave unexpectedly.
+  rationale: >-
+    Regex literals in Ruby are always truthy. Using `/pattern/` directly in
+    an `if` or `unless` without `=~` or `.match?` means the condition is
+    always true, which is likely a bug.
+  aliases:
+    - RB-LI1054
+  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.regex-literal-in-condition
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.9
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` matches
+      `ruby.bug-risk.regex-literal-in-condition`."
+  remediation:
+    summary: >-
+      Use `string =~ /pattern/` or `/pattern/.match?(string)` to actually
+      test the regex against a value.

package/rules/ruby/ruby.bug-risk.relative-date-as-constant.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.relative-date-as-constant
+  title: Relative date/time assigned to a constant
+  summary: >-
+    Constants should not be assigned relative date/time expressions
+    because they are evaluated at load time, not at runtime.
+  rationale: >-
+    A constant like `EXPIRES = 1.week.since` is evaluated when the file
+    is loaded, not when the constant is referenced. This means the value
+    is frozen at load time and will be stale. Use a method or lambda
+    instead for dynamic date/time values.
+  aliases:
+    - RB-RL1046
+  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.relative-date-as-constant
+    bind: issue
+emit:
+  finding:
+    category: correctness.framework
+    severity: high
+    confidence: 0.85
+    tags:
+      - ruby
+  message:
+    title: "`${captures.issue.text}` assigns a relative date to a constant"
+    summary: >-
+      "`${captures.issue.text}` assigns a dynamic date/time value to a
+      constant. This will be frozen at load time."
+  remediation:
+    summary: >-
+      Replace the constant with a method call, or use a lambda:
+      `EXPIRES = -> { 1.week.since }`.

package/rules/ruby/ruby.bug-risk.renamed-column-accessed.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.renamed-column-accessed
+  title: Renamed column accessed from ActiveRecord model
+  summary: >-
+    A migration renames a database column. Model files may still reference the
+    old column name.
+  rationale: >-
+    After a rename_column migration, the old column name may still be used in
+    model queries. This rule flags the rename operation so you can verify
+    model code is updated.
+  aliases:
+    - RB-E1012
+  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.renamed-column-accessed
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.75
+    tags:
+      - ruby
+  message:
+    title: Verify model references for renamed column
+    summary: >-
+      "`${captures.issue.text}` renames a column. Check model files for
+      references to the old column name."
+  remediation:
+    summary: >-
+      Update model files to reference the new column name instead of the
+      renamed one.

package/rules/ruby/ruby.bug-risk.rescue-exception.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.rescue-exception
+  title: Avoid rescuing Exception
+  summary: >-
+    Rescuing Exception also catches signals and system exits that should not be swallowed.
+  rationale: >-
+    Rescuing Exception also catches signals and system exits that should not be swallowed.
+  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.rescue-exception
+    bind: issue
+emit:
+  finding:
+    category: correctness.exceptions
+    severity: high
+    confidence: 0.9
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: "`${captures.issue.text}` matches `ruby.bug-risk.rescue-exception`."
+  remediation:
+    summary: >-
+      Rescuing Exception also catches signals and system exits that should not be swallowed.

package/rules/ruby/ruby.bug-risk.return-in-ensure.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.return-in-ensure
+  title: Avoid `return` inside `ensure` blocks
+  summary: >-
+    A `return` inside an `ensure` block discards any exception that was raised,
+    silently swallowing errors.
+  rationale: >-
+    The ensure block runs regardless of whether an exception was raised. A
+    return statement in ensure overrides the exception, making it disappear.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1021
+  tags:
+    - rules-catalog
+    - ruby
+  stability: stable
+  appliesTo: function
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.return-in-ensure
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.9
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}`
+    summary: >-
+      "`${captures.issue.text}` matches
+      `ruby.bug-risk.return-in-ensure`."
+  remediation:
+    summary: >-
+      Remove the `return` from the `ensure` block. Use the `rescue` block for
+      exception handling instead.

package/rules/ruby/ruby.bug-risk.routes-match-single-verb.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.routes-match-single-verb
+  title: Use of `match` in routes with single request type
+  summary: >-
+    `match` in Rails routes should be used only when multiple HTTP verbs are
+    handled. Prefer the specific verb helper (`get`, `post`, etc.) for single-verb
+    routes.
+  rationale: >-
+    Using `match` with a single verb is unnecessary and masks intent. The
+    specific helpers (`get`, `post`, `put`, `patch`, `delete`) are clearer and
+    avoid accidental verb exposure if the route is later modified.
+  aliases:
+    - RB-LI1104
+  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.routes-match-single-verb
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.75
+    tags:
+      - ruby
+  message:
+    title: Replace `match` with specific HTTP verb helper
+    summary: >-
+      "`${captures.issue.text}` uses `match` with a single request type. Replace
+      with `get`, `post`, `put`, `patch`, or `delete`."
+  remediation:
+    summary: >-
+      Replace `match` with the specific HTTP verb helper (`get`, `post`, etc.)
+      when only one request type is handled.

package/rules/ruby/ruby.bug-risk.safe-navigation-with-blank.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.safe-navigation-with-blank
+  title: Safe navigation `&.` combined with `blank?` is redundant
+  summary: >-
+    The safe navigation operator `&.` already handles nil, making `blank?`
+    redundant when used with it.
+  rationale: >-
+    `foo&.blank?` calls `blank?` only when `foo` is not nil, and `blank?`
+    returns `true` for nil objects already. Using `&.blank?` is redundant —
+    `.blank?` alone on a nil-safe receiver is sufficient. Prefer
+    `foo.blank?` or `foo.nil?` for clarity.
+  aliases:
+    - RB-RL1050
+  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.safe-navigation-with-blank
+    bind: issue
+emit:
+  finding:
+    category: correctness.framework
+    severity: high
+    confidence: 0.9
+    tags:
+      - ruby
+  message:
+    title: "`${captures.issue.text}` — `&.` is redundant with `blank?`"
+    summary: >-
+      "`${captures.issue.text}` uses `&.blank?`. Since `.blank?` already
+      returns `true` for nil, the safe navigation is redundant."
+  remediation:
+    summary: >-
+      Replace `foo&.blank?` with `foo.blank?`.

package/rules/ruby/ruby.bug-risk.safe-navigation-with-empty.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.safe-navigation-with-empty
+  title: Safe navigation with empty? in conditional
+  summary: >-
+    `&.empty?`, `&.blank?`, or `&.present?` is used in a conditional
+    context. When the receiver is nil, the safe navigation returns nil,
+    which is falsy regardless of the predicate result.
+  rationale: >-
+    `foo&.empty?` returns `nil` when `foo` is nil, and `nil` is falsy.
+    This means `if foo&.empty?` will behave as `false` for both
+    "foo is nil" and "foo is empty". Use `.empty?` only after a nil
+    check.
+  aliases:
+    - RB-LI1061
+  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.safe-navigation-with-empty
+    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.safe-navigation-with-empty`."
+  remediation:
+    summary: >-
+      Check for nil explicitly: `if foo && foo.empty?`, or use a safe
+      alternative that handles nil separately.

package/rules/ruby/ruby.bug-risk.self-assignment.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.self-assignment
+  title: Self assignment detected
+  summary: >-
+    A variable, constant, or multi-assignment is assigned to itself. This
+    is likely a copy-paste error that makes the assignment a no-op.
+  rationale: >-
+    Self-assignment (`foo = foo`) is redundant and indicates the developer
+    likely intended to assign from a different source. Constant
+    self-assignment (`FOO = FOO`) and multi-variable self-assignment
+    (`a, b = a, b`) are similarly suspicious.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1092
+  tags:
+    - rules-catalog
+    - ruby
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.self-assignment
+    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.self-assignment`."
+  remediation:
+    summary: >-
+      Review the assignment. If the intent was to assign a computed value,
+      verify the source operand is correct. Otherwise, remove the
+      redundant assignment.

package/rules/ruby/ruby.bug-risk.skip-filter-conditional.rule.yaml

@@ -0,0 +1,55 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.skip-filter-conditional
+  title: if used with only or except in skip_* filter
+  summary: >-
+    Combining `only:`/`except:` with `if:`/`unless:` on a skip filter
+    creates confusing conditional logic.
+  rationale: >-
+    Using both `only:` (or `except:`) and `if:` (or `unless:`) on
+    `skip_before_action`, `skip_after_action`, or `skip_around_action`
+    produces hard-to-reason-about conditional semantics. Prefer using
+    only one conditional mechanism to keep filter logic understandable.
+  aliases:
+    - RB-RL1030
+  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.skip-filter-conditional
+    bind: issue
+emit:
+  finding:
+    category: correctness.framework
+    severity: high
+    confidence: 0.85
+    tags:
+      - ruby
+      - rails
+  message:
+    title: "Skip filter uses both only/except and if/unless"
+    summary: >-
+      This skip filter uses both `only:`/`except:` and `if:`/`unless:`
+      options simultaneously, making the skipping logic difficult to
+      understand.
+  remediation:
+    summary: >-
+      Remove one of the conditional mechanisms. Prefer `only:`/`except:`
+      for action-based filtering or `if:`/`unless:` for dynamic conditions,
+      but not both.

package/rules/ruby/ruby.bug-risk.suppressed-exceptions.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ruby.bug-risk.suppressed-exceptions
+  title: Suppressed exceptions detected
+  summary: >-
+    A rescue block has no body, silently swallowing all exceptions. Every
+    rescue should at minimum log the error or re-raise.
+  rationale: >-
+    An empty rescue body silently suppresses all exceptions of the rescued
+    type, making debugging and failure detection impossible.
+  detection:
+    kind: pattern
+  aliases:
+    - RB-LI1067
+  tags:
+    - rules-catalog
+    - ruby
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - ruby
+  paths:
+    include:
+      - "**/*.rb"
+    exclude:
+      - "**/vendor/**"
+      - "**/node_modules/**"
+match:
+  fact:
+    kind: ruby.bug-risk.suppressed-exceptions
+    bind: issue
+emit:
+  finding:
+    category: correctness.language
+    severity: high
+    confidence: 0.9
+    tags:
+      - ruby
+  message:
+    title: Review `${captures.issue.text}` swallows exceptions
+    summary: >-
+      "`${captures.issue.text}` has no body and silently suppresses
+      exceptions."
+  remediation:
+    summary: >-
+      Add a body to the rescue clause that logs the error, handles it, or
+      re-raises. Use the `=>` syntax to capture the exception.