@critiq/rules 0.3.0 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@critiq/rules",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "private": false,
   "description": "Public OSS Critiq rule catalog with catalog metadata, shipped rule YAML files, and preset membership.",
   "license": "Apache-2.0",

package/rules/go/go.bug-risk.compound-assignment-misuse.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.compound-assignment-misuse
+  title: "Audit: Possibly odd compound assignment operators '+=' or '-='"
+  summary: >-
+    The expression uses the same variable on both sides of a compound
+    assignment (e.g. `x += x + y`), which simplifies to a non-obvious
+    result (`2x + y`). This may indicate a typo or unintentional logic.
+  rationale: >-
+    Patterns like `x += x + y` effectively compute `x = 2x + y`, which is
+    likely unintended. The developer probably meant `x += y`. Similarly
+    `x -= x - y` computes `x = y` instead of a simple decrement. These
+    patterns warrant manual review.
+  aliases:
+    - GO-E1009
+  tags:
+    - bug-risk
+    - go
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.compound-assignment-misuse
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: critical
+    confidence: 0.7
+    tags:
+      - bug-risk
+      - go
+  message:
+    title: Suspicious compound assignment found
+    summary: >-
+      ${captures.issue.text} repeats the same variable on both sides of a
+      compound assignment — please review.
+  remediation:
+    summary: >-
+      Simplify to the intended expression. For example, `x += y` instead of
+      `x += x + y`, or `x -= y` instead of `x -= x - y`.

package/rules/go/go.bug-risk.deprecated-redis-methods.rule.yaml

@@ -0,0 +1,57 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.deprecated-redis-methods
+  title: "Use of deprecated Redis methods"
+  summary: >-
+    Call to deprecated go-redis method (XTrim, XTrimApprox, ZAddCh, ZAddNXCh,
+    ZAddXXCh, ZIncr, ZIncrNX, ZIncrXX). These methods have been removed or
+    replaced in newer versions of the library.
+  rationale: >-
+    Deprecated Redis methods like XTrim, XTrimApprox, ZAddCh, ZAddNXCh,
+    ZAddXXCh, ZIncr, ZIncrNX, and ZIncrXX have been removed in newer go-redis
+    versions. Calling them will cause a compilation error or runtime panic.
+    Use their replacements (XTrimMaxLen, ZAddArgs, etc.) instead.
+  aliases:
+    - GO-W1000
+  tags:
+    - bug-risk
+    - go
+    - redis
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.deprecated-redis-methods
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.82
+    tags:
+      - bug-risk
+      - go
+      - redis
+  message:
+    title: Deprecated Redis method called
+    summary: >-
+      ${captures.issue.text} calls a deprecated go-redis method. Use the
+      replacement method instead.
+  remediation:
+    summary: >-
+      Use the modern go-redis API. Replace `XTrim` with `XTrimMaxLen`,
+      `XTrimApprox` with `XTrimMaxLenApprox`, `ZAddCh`/`ZAddNXCh`/`ZAddXXCh`
+      with `ZAddArgs`, and `ZIncr`/`ZIncrNX`/`ZIncrXX` with `ZAddArgs`.

package/rules/go/go.bug-risk.etcd-getlogger-misuse.rule.yaml

@@ -0,0 +1,59 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.etcd-getlogger-misuse
+  title: "etcd client GetLogger used as general-purpose logger"
+  summary: >-
+    GetLogger is an internal method on etcd's client type. Using it as a
+    general-purpose application logger is a misuse pattern; the returned
+    logger is configured for etcd's internal use.
+  rationale: >-
+    The etcd client v3 exposes a `GetLogger()` method that returns the
+    client's internal logger. This logger is configured for etcd's diagnostics,
+    not for application-level logging. Using it may produce unexpected output
+    format, miss application-level log levels, or break if the etcd client
+    changes its internal logging. Use a proper application-level logging
+    framework instead.
+  aliases:
+    - GO-W1003
+  tags:
+    - bug-risk
+    - go
+    - etcd
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.etcd-getlogger-misuse
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - etcd
+  message:
+    title: etcd GetLogger should not be used as application logger
+    summary: >-
+      ${captures.issue.text} calls the etcd client's internal `GetLogger()`.
+      Use a dedicated application logging framework instead.
+  remediation:
+    summary: >-
+      Replace `client.GetLogger()` with an application-level logging framework
+      such as `log/slog`, `logrus`, or `zap`. The etcd client's logger is
+      intended for etcd's internal diagnostics only.

package/rules/go/go.bug-risk.etcd-invalid-compare-operator.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.etcd-invalid-compare-operator
+  title: Invalid result operator in etcd Compare
+  summary: >-
+    `clientv3.Compare()` with a result operator other than `=`, `!=`, `>`,
+    or `<` causes a runtime panic.
+  rationale: >-
+    The `clientv3.Compare` function accepts exactly four result operators:
+    `=`, `!=`, `>`, `<`. Any other operator string causes an internal panic
+    in the etcd client. Verify the operator argument is one of the four
+    allowed values.
+  aliases:
+    - GO-E1003
+  tags:
+    - bug-risk
+    - go
+    - etcd
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.etcd-invalid-compare-operator
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - etcd
+  message:
+    title: etcd Compare may use an invalid result operator
+    summary: "`${captures.issue.text}` uses a Compare operator — only `=`, `!=`, `>`, `<` are valid"
+  remediation:
+    summary: >-
+      Replace the operator with one of the four valid values: `clientv3.CmpEq`,
+      `clientv3.CmpNotEq`, `clientv3.CmpGreater`, or `clientv3.CmpLess`.

package/rules/go/go.bug-risk.gin-loadhtmlglob-ill-formed.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.gin-loadhtmlglob-ill-formed
+  title: gin.LoadHTMLGlob with ill-formed pattern may panic
+  summary: >-
+    `gin.LoadHTMLGlob()` with an ill-formed glob pattern silently matches zero
+    files and causes a runtime panic when rendering templates.
+  rationale: >-
+    `gin.LoadHTMLGlob` uses `filepath.Match` internally. Patterns with
+    unmatched brackets, invalid metacharacters, or unintended literal characters
+    will match zero files and panic at render time. Pre-validate the pattern
+    with `filepath.Match` before passing it.
+  aliases:
+    - GO-E1000
+  tags:
+    - bug-risk
+    - go
+    - gin
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.gin-loadhtmlglob-ill-formed
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - gin
+  message:
+    title: Gin LoadHTMLGlob may silently match no files
+    summary: "`${captures.issue.text}` passes an ill-formed glob pattern that may match zero template files"
+  remediation:
+    summary: >-
+      Validate the glob pattern with `filepath.Match(pattern, "")` before
+      passing to `LoadHTMLGlob`, or use `LoadHTMLFiles` with explicit file paths.

package/rules/go/go.bug-risk.gorm-dry-run-enabled.rule.yaml

@@ -0,0 +1,58 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.gorm-dry-run-enabled
+  title: "GORM DryRun is enabled"
+  summary: >-
+    `DryRun` is set to `true` in gorm.Config. When DryRun is enabled, GORM
+    generates SQL statements without executing them. If actual execution is
+    needed, DryRun should be disabled.
+  rationale: >-
+    GORM's `DryRun` mode generates SQL statements and returns them without
+    sending them to the database. This is useful for debugging or logging but
+    should not be enabled in production code that actually writes to the
+    database. If `DryRun: true` is set accidentally, all write operations will
+    silently be no-ops.
+  aliases:
+    - GO-W1005
+  tags:
+    - bug-risk
+    - go
+    - gorm
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.gorm-dry-run-enabled
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.88
+    tags:
+      - bug-risk
+      - go
+      - gorm
+  message:
+    title: GORM DryRun is enabled
+    summary: >-
+      ${captures.issue.text} enables DryRun mode — SQL will be generated but
+      not executed.
+  remediation:
+    summary: >-
+      If database execution is needed, set `DryRun: false` or remove the
+      `DryRun` field to use the default. Keep `DryRun: true` only for debug
+      or logging-only scenarios.

package/rules/go/go.bug-risk.gorm-skip-default-transaction.rule.yaml

@@ -0,0 +1,57 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.gorm-skip-default-transaction
+  title: "GORM SkipDefaultTransaction set to false"
+  summary: >-
+    Setting `SkipDefaultTransaction` to `false` in gorm.Config causes GORM to
+    wrap every operation in a transaction. Audit if this is intentional.
+  rationale: >-
+    GORM's default behavior is to wrap every `Create`, `Update`, `Delete`
+    operation in a transaction. Setting `SkipDefaultTransaction: false`
+    explicitly enables this default, which may cause unintended performance
+    overhead for batch or read-heavy workloads. The setting should be
+    intentionally reviewed.
+  aliases:
+    - GO-W1004
+  tags:
+    - bug-risk
+    - go
+    - gorm
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.gorm-skip-default-transaction
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.88
+    tags:
+      - bug-risk
+      - go
+      - gorm
+  message:
+    title: GORM SkipDefaultTransaction set to false
+    summary: >-
+      ${captures.issue.text} explicitly enables default transactions.
+      Verify this is intentional for your workload.
+  remediation:
+    summary: >-
+      If per-operation transactions are not needed, set
+      `SkipDefaultTransaction: true` to improve performance. Otherwise, keep
+      the explicit setting with an explanatory comment.

package/rules/go/go.bug-risk.gorm-updates-zero-values.rule.yaml

@@ -0,0 +1,55 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.gorm-updates-zero-values
+  title: GORM Updates with struct silently excludes zero-value fields
+  summary: >-
+    `db.Updates(Struct{...})` or `db.Model(...).Updates(Struct{...})`
+    silently skips zero-value fields (0, "", false, nil), potentially
+    leaving stale data in the database.
+  rationale: >-
+    GORM's `Updates()` with a struct argument omits zero-value fields from
+    the UPDATE statement. For example `db.Model(&user).Updates(&User{Name: ""})`
+    will NOT clear the Name column. Use map arguments or `Select` to explicitly
+    specify which columns to update.
+  aliases:
+    - GO-E1005
+  tags:
+    - bug-risk
+    - go
+    - gorm
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.gorm-updates-zero-values
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - gorm
+  message:
+    title: GORM Updates with struct skips zero-value fields
+    summary: "`${captures.issue.text}` passes a struct to `Updates()` — zero-value fields will not be updated"
+  remediation:
+    summary: >-
+      Use `db.Model(&user).Select("*").Updates(map[string]interface{}{...})`
+      or use a map argument to include zero values. Alternatively, use pointer
+      fields in your model to distinguish nil from zero.

package/rules/go/go.bug-risk.gorm-where-zero-values.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.gorm-where-zero-values
+  title: GORM Where with struct silently excludes zero-value fields
+  summary: >-
+    `db.Where(&Struct{...})` silently ignores zero-value fields (0, "",
+    false, nil) in the WHERE clause, leading to unintended broader queries.
+  rationale: >-
+    GORM's `Where()` with a struct argument omits zero-value fields from the
+    generated SQL. For example `db.Where(&User{Name: "", Age: 0})` produces
+    an empty WHERE clause. Use map arguments or pointer fields to include
+    zero values intentionally.
+  aliases:
+    - GO-E1004
+  tags:
+    - bug-risk
+    - go
+    - gorm
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.gorm-where-zero-values
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - gorm
+  message:
+    title: GORM Where with struct ignores zero-value fields
+    summary: "`${captures.issue.text}` passes a struct to `Where()` — zero-value fields will be silently dropped"
+  remediation:
+    summary: >-
+      Use a `map[string]interface{}` argument instead of a struct, or use
+      pointer fields in your struct so nil vs zero can be distinguished.

package/rules/go/go.bug-risk.poorly-formed-nilness-guards.rule.yaml

@@ -0,0 +1,57 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.poorly-formed-nilness-guards
+  title: Poorly formed nilness guards may cause nil pointer dereference
+  summary: >-
+    The expression uses `== nil &&` (short-circuits to the dereference when
+    the value IS nil) or `!= nil ||` (short-circuits to the dereference when
+    the value IS nil). Both patterns risk a nil pointer dereference.
+  rationale: >-
+    Go's short-circuit evaluation means `x == nil && x.Method()` proceeds to
+    `x.Method()` when `x` is nil (the AND continues because the left operand
+    is true). Similarly `x != nil || x.Method()` proceeds to `x.Method()`
+    when `x` is nil (the OR continues because the left operand is false).
+    The correct guard for dereferencing is `x != nil && x.Method()` or
+    `x == nil || x.Method()`.
+  aliases:
+    - GO-E1008
+  tags:
+    - bug-risk
+    - go
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.poorly-formed-nilness-guards
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: critical
+    confidence: 0.85
+    tags:
+      - bug-risk
+      - go
+  message:
+    title: Poorly formed nilness guard may panic
+    summary: >-
+      ${captures.issue.text} uses a nilness guard pattern that will
+      dereference nil instead of protecting against it.
+  remediation:
+    summary: >-
+      Swap the comparison operator or operand order so the nil check
+      correctly guards the dereference. Use `x != nil && x.method()` or
+      `x == nil || x.method()` instead.

package/rules/go/go.bug-risk.redis-incorrect-arg-count.rule.yaml

@@ -0,0 +1,54 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.redis-incorrect-arg-count
+  title: Redis variadic function called with wrong argument count
+  summary: >-
+    Redis variadic methods such as `MemoryUsage`, `ZPopMax`, `ZPopMin`, and
+    `BitPos` accept a specific number of arguments. Passing too many will
+    cause a runtime panic.
+  rationale: >-
+    go-redis variadic methods have strict argument expectations. For example,
+    `MemoryUsage(key, samples...)` expects a key + up to one extra arg.
+    `ZPopMax(key, count)` expects exactly key + count. Passing extra arguments
+    causes a panic. Audit each call site against the Redis command spec.
+  aliases:
+    - GO-E1001
+  tags:
+    - bug-risk
+    - go
+    - redis
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.redis-incorrect-arg-count
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - redis
+  message:
+    title: Redis variadic method may receive incorrect argument count
+    summary: "`${captures.issue.text}` calls a Redis variadic method — verify the argument count against the spec"
+  remediation:
+    summary: >-
+      Check the Redis command spec for the expected argument count. Remove
+      any extra arguments. Use a linter or code review to audit each call site.

package/rules/go/go.bug-risk.redis-unimplemented-method.rule.yaml

@@ -0,0 +1,53 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.bug-risk.redis-unimplemented-method
+  title: Unimplemented Redis method call would panic
+  summary: >-
+    `Sync(ctx)` and `Quit(ctx)` are listed in the go-redis interface but
+    are not implemented — calling them panics at runtime.
+  rationale: >-
+    The go-redis library provides `Sync()` and `Quit()` as interface methods
+    for compatibility, but their implementations panic with "not implemented".
+    These methods should never be called. Use the standard Redis `CLIENT LIST`
+    or `QUIT` commands through `Do()` instead.
+  aliases:
+    - GO-E1002
+  tags:
+    - bug-risk
+    - go
+    - redis
+    - framework
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.bug-risk.redis-unimplemented-method
+    bind: issue
+emit:
+  finding:
+    category: bug-risk.framework
+    severity: high
+    confidence: 0.75
+    tags:
+      - bug-risk
+      - go
+      - redis
+  message:
+    title: Unimplemented Redis method will panic at runtime
+    summary: "`${captures.issue.text}` calls a Redis method that is not implemented in go-redis"
+  remediation:
+    summary: >-
+      Remove the call to `Sync()` or `Quit()`. Use `redisClient.Do(ctx, "CLIENT LIST")`
+      or `redisClient.Close()` instead.