Documentation
¶
Index ¶
- Variables
- type Finding
- type Registry
- type Rule
- type SLP001
- type SLP002
- type SLP003
- type SLP005
- type SLP006
- type SLP007
- type SLP008
- type SLP009
- type SLP010
- type SLP011
- type SLP012
- type SLP013
- type SLP014
- type SLP015
- type SLP016
- type SLP017
- type SLP018
- type SLP019
- type SLP020
- type SLP021
- type SLP022
- type SLP023
- type SLP024
- type SLP025
- type SLP026
- type SLP027
- type SLP030
- type SLP031
- type SLP032
- type SLP033
- type SLP034
- type SLP035
- type SLP036
- type SLP037
- type SLP038
- type SLP039
- type SLP040
- type SLP041
- type SLP042
- type SLP043
- type SLP044
- type SLP045
- type SLP046
- type SLP047
- type SLP048
- type SLP049
- type SLP050
- type SLP051
- type SLP052
- type SLP053
- type SLP054
- type SLP055
- type SLP056
- type SLP057
- type SLP058
- type SLP059
- type SLP060
- type SLP061
- type SLP062
- type SLP063
- type SLP064
- type SLP065
- type SLP066
- type SLP067
- type SLP068
- type SLP069
- type SLP070
- type SLP071
- type SLP072
- type SLP073
- type SLP074
- type SLP075
- type SLP076
- type SLP077
- type SLP078
- type SLP079
- type SLP080
- type SLP081
- type SLP082
- type SLP083
- type SLP084
- type SLP085
- type SLP086
- type SLP087
- type SLP088
- type SLP089
- type SLP090
- type SLP091
- type SLP092
- type SLP093
- type SLP094
- type SLP095
- type SLP096
- type SLP097
- type SLP098
- type SLP099
- type SLP100
- type SLP101
- type SLP102
- type SLP103
- type SLP104
- type SLP106
- type SLP107
- type SLP108
- type SLP109
- type SLP110
- type SLP111
- type SLP112
- type SLP113
- type SLP114
- type SLP115
- type SLP116
- type SLP117
- type SLP118
- type SLP119
- type SLP120
- type SLP121
- type SLP122
- type SLP123
- type SLP124
- type SLP125
- type SLP126
- type SLP127
- type SLP128
- type SLP129
- type SLP130
- type SLP131
- type SLP132
- type SLP133
- type SLP134
- type SLP135
- type SLP136
- type SLP137
- type SLP138
- type SLP139
- type SLP140
- type SLP141
- type SLP142
- type SLP143
- type SLP144
- type SLP145
- type SLP146
- type SLP147
- type SLP148
- type SLP151
- type SLP152
- type SLP155
- type SLP156
- type SLP202
- type SLP203
- type SLP204
- type SLP205
- type SLP207
- type SLP208
- type SLP209
- type SemanticRule
- type Severity
Constants ¶
This section is empty.
Variables ¶
var LibraryAssertTokens = []string{
"assert.", "require.",
"Expect(", "Eventually(", "Consistently(",
"So(",
"is.",
"qt.",
"c.Check(", "c.Assert(",
}
LibraryAssertTokens are assertion tokens that come from third-party test libraries and do not depend on the testing.T parameter name. Exported so other rules (e.g. SLP064) can reuse the same list.
Functions ¶
This section is empty.
Types ¶
type Finding ¶
type Finding struct {
RuleID string
Severity Severity
File string
Line int // 1-indexed line in the new file; 0 if not applicable
Message string // one-line explanation
Snippet string // the offending source line, unmodified
}
Finding is a single slop detection reported by a rule.
type Registry ¶
type Registry struct {
// contains filtered or unexported fields
}
Registry is an ordered collection of rules. Order matters: the reporter walks findings in registration order so output is deterministic.
func Default ¶
func Default() *Registry
Default returns a Registry pre-populated with every rule shipped in the current slopgate version. The CLI calls this; tests that need custom rule sets should use NewRegistry directly.
func (*Registry) AllSemantic ¶ added in v0.0.21
func (r *Registry) AllSemantic() []SemanticRule
AllSemantic returns the registered semantic rules in registration order.
func (*Registry) HasSemanticRules ¶ added in v0.0.21
HasSemanticRules returns true if any semantic rules are registered.
func (*Registry) Register ¶
Register adds a rule to the registry. Panics on duplicate ID to catch configuration mistakes at startup rather than silently masking rules.
func (*Registry) RegisterSemantic ¶ added in v0.0.21
func (r *Registry) RegisterSemantic(rule SemanticRule)
RegisterSemantic adds a semantic (AST-aware) rule to the registry. Panics on duplicate ID.
func (*Registry) Run ¶
Run applies every registered rule to the diff and returns the concatenated findings. If cfg is non-nil, per-rule severity overrides, ignores, and path ignores are applied. A nil cfg means all rules run with their defaults.
Run also processes semantic rules if AST analysis is available and semantic rules are registered.
type Rule ¶
type Rule interface {
// ID returns the stable rule identifier, e.g. "SLP012".
ID() string
// Description returns a human-readable one-liner.
Description() string
// DefaultSeverity is the severity used when config does not override it.
DefaultSeverity() Severity
// Check runs the rule against the parsed diff and returns any findings.
Check(d *diff.Diff) []Finding
}
Rule is the interface every detection must implement. This is the original rule interface for regex-on-diff rules.
type SLP001 ¶
type SLP001 struct{}
SLP001 flags test functions added wholesale in the current diff that contain no assertion token anywhere in their body.
Rationale: AI agents asked to "write a test for X" often produce functions that call X, collect the result into `_`, and stop. The test compiles, contributes to coverage, and asserts nothing — the worst kind of test, because it convinces everyone the function is covered.
Languages: Go, JS/TS, Python, Java, Rust.
Scope: only test functions whose entire body was added in this diff.
func (SLP001) DefaultSeverity ¶
func (SLP001) Description ¶
type SLP002 ¶
type SLP002 struct{}
SLP002 flags tautological assertions in test files — assertions that compare a value to itself, always passing regardless of actual behaviour. This is a common AI slop pattern: the model fills in both sides of an assertion with the same placeholder variable.
Detected patterns:
- Go/testify: assert.Equal(t, x, x), require.Equal(t, x, x), assert.True(t, true), assert.False(t, false)
- JS/TS: expect(x).toBe(x), expect(x).toEqual(x), assert.strictEqual(x, x)
- Python: self.assertEqual(a, a), self.assertIs(a, a)
- Java/JUnit: assertEquals(x, x), assertTrue(true), assertFalse(false), assertThat(x).isEqualTo(x)
- Rust: assert_eq!(x, x), assert!(true)
func (SLP002) DefaultSeverity ¶
func (SLP002) Description ¶
type SLP003 ¶
type SLP003 struct{}
SLP003 flags catch/except blocks that swallow errors silently — empty error handlers where the error is neither logged, wrapped, nor re-raised.
Languages: Go, JS/TS, Python, Java, Rust.
Rationale: AI agents often write `if err != nil { return nil }` or `except: pass` to satisfy the type checker without actually handling the error. Real error handlers should at minimum log, wrap, or propagate the error.
func (SLP003) DefaultSeverity ¶
func (SLP003) Description ¶
type SLP005 ¶
type SLP005 struct{}
SLP005 flags test-runner exclusivity markers (it.only, describe.only, fdescribe, fit, test.only) and test-disabling annotations (@Disabled, @Ignore) committed on added lines. These markers are harmless in a local workflow but catastrophic if merged: .only silently skips the rest of the suite, while @Disabled/@Ignore silently skips the test.
AI-generated tests commonly emit .only during focused iteration and leave the marker in when the task was "get this test passing". AI agents also add @Disabled to skip failing tests instead of fixing them.
func (SLP005) DefaultSeverity ¶
func (SLP005) Description ¶
type SLP006 ¶
type SLP006 struct{}
SLP006 flags panic/throw/raise stub bodies that signal unimplemented code. These are common when an AI agent generates a skeleton and leaves the real logic unwritten — the panic or throw is a sentinel that will crash at runtime if the code path is ever hit.
Detected patterns (on ADDED lines only):
- Go: panic("not implemented"), panic("TODO"), panic(fmt.Sprintf("TODO: ..."))
- JS/TS: throw new Error("not implemented"), throw new Error("TODO")
- Python: raise NotImplementedError, raise NotImplementedError("msg")
- Java: throw new UnsupportedOperationException("not implemented")
- Rust: todo!("..."), unimplemented!("..."), panic!("TODO")
Non-stub panics like panic(err) or panic("buffer too small") are deliberately excluded — they don't contain a stub keyword.
func (SLP006) DefaultSeverity ¶
func (SLP006) Description ¶
type SLP007 ¶
type SLP007 struct{}
SLP007 flags imports that are added in a diff but never referenced in any other added line of the same file. This catches the classic AI "just in case" import slop where an agent adds an import but never uses the package.
Supported languages:
- Go: import "pkg" / import alias "pkg" / import ( ... ) groups
- JS/TS: import { X } from 'y' / import X from 'y'
- Python: import X / from Y import X
- Java: import com.foo.Bar;
- Rust: use crate::foo::Bar; / use std::foo::Bar;
Exempt:
- Go blank imports: import _ "pkg" (side-effect imports)
- Go dot imports: import . "pkg" (too ambiguous)
- Java wildcard imports: import com.foo.*; (too ambiguous)
- Rust glob imports: use foo::*; (too ambiguous)
- Pre-existing imports (only newly added import lines are checked)
func (SLP007) DefaultSeverity ¶
func (SLP007) Description ¶
type SLP008 ¶
type SLP008 struct{}
SLP008 flags error handlers that log the error but then silently return without recovery — the error is acknowledged but never acted on.
Languages: Go, JS/TS, Python, Java, Rust.
Rationale: AI code generators frequently produce error-handling blocks that log.Printf/slog.Error the error and then return nil (or bare return). This swallows the error: the caller has no idea anything went wrong, and no recovery has been attempted. The correct pattern is either to return the error to the caller (so they can decide what to do) or to handle it locally. Logging-and-returning-nil is the worst of both worlds.
func (SLP008) DefaultSeverity ¶
func (SLP008) Description ¶
type SLP009 ¶
type SLP009 struct{}
SLP009 flags env-var lookups that are added in the diff where no corresponding env-var setup (os.Setenv / process.env.X = ...) exists in any added line across the entire diff. This is a "drift" pattern: the code reads an env var that nothing in this change writes, making the new code fragile and dependent on external state that may not exist.
Languages: Go, JS/TS, Python, Java, Rust.
Scope: this rule only looks within the diff itself. It does NOT check .env files, CI config, or pre-existing code.
func (SLP009) DefaultSeverity ¶
func (SLP009) Description ¶
type SLP010 ¶
type SLP010 struct{}
SLP010 flags pre-existing test functions where the ADDED lines contain no assertion. Unlike SLP001 (which catches entirely-new test functions with no assertions), SLP010 handles the incremental case: the AI edited an existing test and added setup/arrange code without adding a corresponding assertion.
Languages: Go (full function-span tracking), JS/TS, Python, Java, Rust (simpler per-hunk assertion check).
Example: an existing TestFoo gets a new line `result := Foo()` added, but no line checks the result. The test still compiles, coverage goes up, but nothing new is actually verified.
func (SLP010) DefaultSeverity ¶
func (SLP010) Description ¶
type SLP011 ¶
type SLP011 struct{}
SLP011 flags test functions whose body is entirely assertion calls with no meaningful arrange/logic. This catches AI-generated tests that look like "assert.Equal(t, 1, 1)" with no actual test logic.
Languages: Go only. Non-Go languages don't have the same function-span detection needed for assert-only test body analysis.
The key distinction from SLP010 (incremental no-assertion):
- SLP010: AI edited an existing test, added setup but no assertion
- SLP011: Entire test body is only assertions (assert-only test body)
The one exception is a single variable assignment for the "arrange" value, e.g. "got := Foo()" followed by an assertion - that pattern is OK.
SLP011 complements SLP001 (new test with no assertion):
- SLP001: New test that calls something but asserts nothing
- SLP011: New test that only has assertion calls with no arrange
func (SLP011) DefaultSeverity ¶
func (SLP011) Description ¶
type SLP012 ¶
type SLP012 struct{}
SLP012 flags TODO / FIXME / HACK / XXX comments added in the current diff. Pre-existing markers in the file are ignored — only the lines the diff *adds* count. Markdown / text / docs are excluded.
Rationale: TODO comments in backlog docs or pre-existing code are fine. TODO comments in freshly generated code are a tell that an AI agent stopped before finishing the job and committed the stub anyway.
func (SLP012) DefaultSeverity ¶
func (SLP012) Description ¶
type SLP013 ¶
type SLP013 struct{}
SLP013 flags runs of three or more consecutive added lines that look like commented-out code (as opposed to ordinary prose comments).
Rationale: AI agents often leave their previous attempt commented out "just in case" when they rewrite a block. Committed dead code is slop that rots the file and confuses the next reader. Ordinary multi-line prose comments are exempt.
func (SLP013) DefaultSeverity ¶
func (SLP013) Description ¶
type SLP014 ¶
type SLP014 struct{}
SLP014 flags debug prints (fmt.Println, console.log, print(, etc.) added in non-test, non-main, non-doc files.
Rationale: print-to-stdout for debugging is the oldest AI-coding failure mode. The model adds a `fmt.Println("here")` to figure out why something broke, then commits it without cleanup. In tests and CLI entrypoints prints are legitimate; everywhere else they are slop.
func (SLP014) DefaultSeverity ¶
func (SLP014) Description ¶
type SLP015 ¶ added in v0.0.8
type SLP015 struct{}
SLP015 flags linter-suppression comments added in the current diff. These are comments that suppress linting or type-checking warnings, which AI agents frequently add to silence legitimate errors instead of fixing the underlying issue.
This is distinct from SLP013 (commented-out code) — SLP015 specifically targets directives that tell tools to ignore problems.
Detected patterns:
- Go: //nolint, //nolint:..., //lint:ignore
- JS/TS: // eslint-disable, // @ts-ignore, // @ts-nocheck, /* eslint-disable */
- Python: # noqa, # type: ignore, # pylint: disable
- Java: @SuppressWarnings(...), // NOPMD
- Rust: #[allow(...)], #[allow(dead_code)], etc.
func (SLP015) DefaultSeverity ¶ added in v0.0.8
func (SLP015) Description ¶ added in v0.0.8
type SLP016 ¶ added in v0.0.8
type SLP016 struct{}
SLP016 flags variable shadowing — when an inner scope declares a variable with the same name as one already seen in an outer scope. AI agents frequently shadow outer variables unintentionally, causing subtle bugs.
Single order-sensitive pass over hunk lines: context lines seed outerNames first; then each added line is checked against outerNames before its own names are added.
Exempt: single-letter loop iterators (i, j, k, _); Go's err at info level only; test files; doc files.
func (SLP016) DefaultSeverity ¶ added in v0.0.8
func (SLP016) Description ¶ added in v0.0.8
type SLP017 ¶ added in v0.0.8
type SLP017 struct{}
SLP017 flags magic numbers — unexplained numeric literals in public API, configuration, or business-domain contexts. AI agents frequently sprinkle raw literals (tax rates, thresholds, policy values) instead of defining named constants, making code fragile and hard to review.
Exempt: 0, 1, 2; hex/octal literals; array index patterns [N]; constant/define declarations; ALL_CAPS assignments; test files; doc files.
func (SLP017) DefaultSeverity ¶ added in v0.0.8
func (SLP017) Description ¶ added in v0.0.8
type SLP018 ¶ added in v0.0.8
type SLP018 struct{}
SLP018 flags overly broad exception catch clauses. AI agents default to the broadest catch to "handle all cases" instead of catching specific exception types. This masks bugs by swallowing unexpected errors that should propagate.
Java patterns: catch (Exception e), catch (Throwable t), catch (RuntimeException e) Python patterns: except:, except Exception:, except BaseException:
Exempt: test files.
func (SLP018) DefaultSeverity ¶ added in v0.0.8
func (SLP018) Description ¶ added in v0.0.8
type SLP019 ¶ added in v0.0.8
type SLP019 struct{}
SLP019 flags unreachable code — lines that appear immediately after a terminator (return, throw, panic, break, continue) at the same or deeper indentation level within the same hunk. AI agents frequently generate dead code after terminators.
Exempt: closing braces/parens; blank lines; lines at shallower indentation (new scope); test files; doc files.
func (SLP019) DefaultSeverity ¶ added in v0.0.8
func (SLP019) Description ¶ added in v0.0.8
type SLP020 ¶ added in v0.0.8
type SLP020 struct{}
SLP020 flags use of insecure random number generators and weak hash functions. AI agents frequently use non-cryptographic PRNGs and weak hashes when security context demands strong ones.
Two tiers:
- warn: when security-context keywords appear nearby (password, token, secret, key, session, nonce, salt, credential, auth)
- info: otherwise
Patterns flagged:
- Insecure random: math/rand import (Go), random. (Python, not secrets.), Math.random() (JS), java.util.Random (Java)
- Insecure hash: md5/sha1 (Go, Python, JS, Java)
Exempt: test files; doc files; Python secrets module; Go crypto/rand.
func (SLP020) DefaultSeverity ¶ added in v0.0.8
func (SLP020) Description ¶ added in v0.0.8
type SLP021 ¶ added in v0.0.8
type SLP021 struct{}
SLP021 flags inconsistent naming style — when both camelCase and snake_case identifiers appear in the same hunk. AI agents often mix naming conventions (e.g. userName + user_name) because they don't internalize project style.
Exempt: SCREAMING_SNAKE (constants); single-char names; test files; doc files.
func (SLP021) DefaultSeverity ¶ added in v0.0.8
func (SLP021) Description ¶ added in v0.0.8
type SLP022 ¶ added in v0.0.8
type SLP022 struct{}
SLP022 flags Go error wrapping that uses %v or %s instead of %w in fmt.Errorf calls. AI agents frequently write
fmt.Errorf("something failed: %v", err)
instead of the correct
fmt.Errorf("something failed: %w", err)
The %v form compiles and returns an error, but breaks error chain unwrapping with errors.Is/errors.As.
Exempt: lines already using %w; errors.Wrap/errors.Wrapf; test files.
func (SLP022) DefaultSeverity ¶ added in v0.0.8
func (SLP022) Description ¶ added in v0.0.8
type SLP023 ¶ added in v0.0.8
type SLP023 struct{}
SLP023 flags Go bare type assertions without the comma-ok guard. AI agents frequently write
s := v.(string)
which panics if the assertion fails, instead of the safe form:
s, ok := v.(string)
Exempt: comma-ok assignments; type switches (v.(type)); test files.
func (SLP023) DefaultSeverity ¶ added in v0.0.8
func (SLP023) Description ¶ added in v0.0.8
type SLP024 ¶ added in v0.0.8
type SLP024 struct{}
SLP024 flags HTTP handlers that return 2xx status codes in catch blocks after logging errors. This is a critical bug pattern where catch blocks log an error then return res.status(200), preventing webhook retries.
Pattern: catch block containing both error logging AND 2xx return.
Exempt: test files, docs.
func (SLP024) DefaultSeverity ¶ added in v0.0.8
func (SLP024) Description ¶ added in v0.0.8
type SLP025 ¶ added in v0.0.8
type SLP025 struct{}
SLP025 flags URL-building by string concatenation without validation. Pattern: `${URL}${path}` or `${BASE_URL}${...}` without path validation.
Exempt: test files, docs.
func (SLP025) DefaultSeverity ¶ added in v0.0.8
func (SLP025) Description ¶ added in v0.0.8
type SLP026 ¶ added in v0.0.8
type SLP026 struct{}
SLP026 flags SQL queries checking for NULL without excluding sentinel values. Pattern: WHERE hash IS NOT NULL without AND hash != 'marker' exclusion.
Exempt: test files, docs.
func (SLP026) DefaultSeverity ¶ added in v0.0.8
func (SLP026) Description ¶ added in v0.0.8
type SLP027 ¶ added in v0.0.8
type SLP027 struct{}
SLP027 flags async functions that throw synchronously instead of returning Promise.reject. Mixed error semantics force callers to handle both try/catch and .catch().
Pattern: async function with throw before return Promise.
Exempt: test files, docs.
func (SLP027) DefaultSeverity ¶ added in v0.0.8
func (SLP027) Description ¶ added in v0.0.8
type SLP030 ¶ added in v0.0.8
type SLP030 struct{}
SLP030 flags ORM/query methods that select single records without excluding sentinel values. AI-generated queries often do:
File.query().only() // missing .where('hash', '!=', 'folder-marker')
User.find().first() // could return placeholder user
Record.findOne().last() // missing sentinel filter
This is a semantic bug: the query returns the first/last/only record, which might be a sentinel placeholder like 'folder-marker' or 'null-string'.
Exempt: test files, docs, explicit sentinel exclusion present.
func (SLP030) DefaultSeverity ¶ added in v0.0.8
func (SLP030) Description ¶ added in v0.0.8
type SLP031 ¶ added in v0.0.8
type SLP031 struct{}
SLP031 flags documentation files that indicate direct code intake from external sources without proper license validation.
Pattern: Files mentioning "direct-code intake", "upstream repo", "Lovable-generated", or similar patterns that suggest external code without explicit license review.
Rationale: External code intake without proper license validation can introduce legal risks. Files should have proper attribution and license compatibility verification.
func (SLP031) DefaultSeverity ¶ added in v0.0.8
func (SLP031) Description ¶ added in v0.0.8
type SLP032 ¶ added in v0.0.8
type SLP032 struct{}
SLP032 flags React/TypeScript component issues that relate to missing type imports, accessibility concerns, or improper patterns.
Pattern: TSX files with React components that lack proper type imports or have common React anti-patterns.
Rationale: React components without proper typing or with accessibility issues can cause runtime errors and poor user experience.
func (SLP032) DefaultSeverity ¶ added in v0.0.8
func (SLP032) Description ¶ added in v0.0.8
type SLP033 ¶ added in v0.0.8
type SLP033 struct{}
SLP033 flags missing or improper import statements in TypeScript/JavaScript files.
Pattern: Files using types/functions without proper imports.
Rationale: Missing imports cause runtime errors and type checking failures.
func (SLP033) DefaultSeverity ¶ added in v0.0.8
func (SLP033) Description ¶ added in v0.0.8
type SLP034 ¶ added in v0.0.8
type SLP034 struct{}
SLP034 flags potential state management anti-patterns in React components and other stateful implementations.
Pattern: Complex state update patterns that could lead to race conditions or inconsistent state.
Rationale: Improper state management can lead to race conditions, inconsistent UI states, and difficult-to-debug issues.
func (SLP034) DefaultSeverity ¶ added in v0.0.8
func (SLP034) Description ¶ added in v0.0.8
type SLP035 ¶ added in v0.0.8
type SLP035 struct{}
SLP035 flags common code quality and style issues.
Pattern: Console statements, debugger statements, TODOs without ticket references, trailing whitespace, and overly long lines.
Rationale: Code quality issues can lead to maintenance problems and potential runtime errors.
func (SLP035) DefaultSeverity ¶ added in v0.0.8
func (SLP035) Description ¶ added in v0.0.8
type SLP036 ¶ added in v0.0.9
type SLP036 struct{}
SLP036 flags suspiciously large required lists in OpenAPI/YAML schemas that often indicate copy-paste errors or misunderstanding of which fields are actually required by the backend handler.
Rationale: AI agents generating or modifying OpenAPI specs sometimes include fields like `size`, `saved_at`, or `generated_at` in the `required` list when the handler does not actually require them (they may be optional or server-generated). This leads to contract mismatches.
Languages: YAML (primarily OpenAPI).
Scope: only added or modified lines that look like a `required:` field in a YAML map.
func (SLP036) DefaultSeverity ¶ added in v0.0.9
func (SLP036) Description ¶ added in v0.0.9
type SLP037 ¶ added in v0.0.9
type SLP037 struct{}
SLP037 flags INSERT or UPDATE statements in Go files that are not wrapped in a transaction, when there is no evidence of transaction handling (BeginTx, Commit, Rollback) in the added lines.
Rationale: AI agents generating database code might forget to wrap write operations in transactions, leading to potential race conditions or inconsistent state when concurrent writers are present.
Languages: Go.
Scope: only added lines in Go files.
func (SLP037) DefaultSeverity ¶ added in v0.0.9
func (SLP037) Description ¶ added in v0.0.9
type SLP038 ¶ added in v0.0.9
type SLP038 struct{}
SLP038 flags SQL queries using a pr_number/PR identifier parameter without also scoping by repo and branch.
Rationale: PR numbers are not globally unique across repositories. A query that filters only by PR number can return data from the wrong repo if multiple repos have PRs with the same number. CodeRabbit often flags this as a cross-repo data leakage vulnerability.
Languages: Go.
Scope: only added lines in Go files.
func (SLP038) DefaultSeverity ¶ added in v0.0.9
func (SLP038) Description ¶ added in v0.0.9
type SLP039 ¶ added in v0.0.9
type SLP039 struct{}
SLP039 flags when pagination Total/Len returns page size instead of total matches.
Rationale: When implementing pagination, returning len(page) as Total is a common mistake. The total should reflect all matching records, not just the current page. AI agents often make this mistake.
Languages: Go.
Scope: only added lines in Go files.
func (SLP039) DefaultSeverity ¶ added in v0.0.9
func (SLP039) Description ¶ added in v0.0.9
type SLP040 ¶ added in v0.0.9
type SLP040 struct{}
SLP040 flags HTTP handlers that read request bodies without validating for empty content.
Rationale: Reading request bodies without checking for empty content can lead to issues when clients send empty bodies. AI agents often forget to check for empty body after reading it.
Languages: Go.
Scope: only added lines in Go files.
func (SLP040) DefaultSeverity ¶ added in v0.0.9
func (SLP040) Description ¶ added in v0.0.9
type SLP041 ¶ added in v0.0.9
type SLP041 struct{}
SLP041 flags SQL queries without LIMIT clause.
Rationale: Queries without LIMIT can return unbounded result sets, leading to memory exhaustion and performance issues. AI agents often forget to add LIMIT to queries.
Languages: Go.
Scope: only added lines in Go files.
func (SLP041) DefaultSeverity ¶ added in v0.0.9
func (SLP041) Description ¶ added in v0.0.9
type SLP042 ¶ added in v0.0.9
type SLP042 struct{}
SLP042 flags JSON struct fields without json tags.
Rationale: JSON struct fields without explicit json tags rely on Go's default field naming, which can cause API contract issues when field names change. AI agents often forget json tags.
Languages: Go.
Scope: only added lines in Go files with new struct definitions.
func (SLP042) DefaultSeverity ¶ added in v0.0.9
func (SLP042) Description ¶ added in v0.0.9
type SLP043 ¶ added in v0.0.9
type SLP043 struct{}
SLP043 flags response structs with duplicate key fields.
Rationale: When composing responses from embedded structs or adding duplicate fields, AI agents may accidentally create response shapes with duplicate keys (e.g., both embedded and explicit fields for the same data).
Languages: Go.
Scope: only added lines in Go files.
func (SLP043) DefaultSeverity ¶ added in v0.0.9
func (SLP043) Description ¶ added in v0.0.9
type SLP044 ¶ added in v0.0.9
type SLP044 struct{}
SLP044 flags errors ignored with _ in Go.
Rationale: Ignoring errors with _ (blank identifier) can hide important error conditions. AI agents often use _ to suppress errors they don't want to handle.
Languages: Go.
Scope: only added lines in Go files.
func (SLP044) DefaultSeverity ¶ added in v0.0.9
func (SLP044) Description ¶ added in v0.0.9
type SLP045 ¶ added in v0.0.9
type SLP045 struct{}
SLP045 flags HTTP handlers that call DB functions without passing context.
Rationale: Database operations should receive a context for proper timeout and cancellation handling. AI agents often forget to pass context from r.Context() to DB functions.
Languages: Go.
Scope: only added lines in Go files.
func (SLP045) DefaultSeverity ¶ added in v0.0.9
func (SLP045) Description ¶ added in v0.0.9
type SLP046 ¶ added in v0.0.21
type SLP046 struct{}
SLP046 flags when related functions (one calls another) are scattered across different packages in the same diff.
Rationale: Functions that call each other should be colocated in the same package when possible. Splitting them across packages increases coupling and makes the code harder to understand and maintain.
func (SLP046) DefaultSeverity ¶ added in v0.0.21
func (SLP046) Description ¶ added in v0.0.21
type SLP047 ¶ added in v0.0.21
type SLP047 struct{}
SLP047 flags comments that just restate the code immediately below them.
Rationale: "What" comments waste space and become stale. Explain *why*, not what — comments that describe obvious behaviour add noise and quickly drift.
func (SLP047) DefaultSeverity ¶ added in v0.0.21
func (SLP047) Description ¶ added in v0.0.21
type SLP048 ¶ added in v0.0.21
type SLP048 struct{}
SLP048 flags inconsistent error-handling patterns within the same Go package.
Rationale: In a single package, all files should follow the same style for error checks. Mixing "if err != nil { return err }" with silent error swallowing makes the code unpredictable and harder to review.
func (SLP048) DefaultSeverity ¶ added in v0.0.21
func (SLP048) Description ¶ added in v0.0.21
type SLP049 ¶ added in v0.0.21
type SLP049 struct{}
SLP049 flags vacuous test assertions that compare an input parameter to the output without testing any real transformation logic.
Rationale: Such tests provide no value and give false confidence. Asserting that `input == result` when result is just the input parameter means the implementation was never actually exercised.
func (SLP049) DefaultSeverity ¶ added in v0.0.21
func (SLP049) Description ¶ added in v0.0.21
type SLP050 ¶ added in v0.0.21
type SLP050 struct{}
SLP050 flags Go functions that accept pointer, slice, map, interface, or string parameters without performing any nil/empty validation.
Rationale: Missing validation leads to runtime panics. If a function receives a `*T` or `[]T` and never checks it before use, it will crash on nil input. AI-generated code often omits these guards.
func (SLP050) DefaultSeverity ¶ added in v0.0.21
func (SLP050) Description ¶ added in v0.0.21
type SLP051 ¶ added in v0.0.21
type SLP051 struct{}
SLP051 flags bare function calls in added code that may be undefined. We look for identifier(arg...) patterns and skip builtins, keywords, and method calls (which come from imported packages).
func (SLP051) DefaultSeverity ¶ added in v0.0.21
func (SLP051) Description ¶ added in v0.0.21
type SLP052 ¶ added in v0.0.21
type SLP052 struct{}
SLP052 flags diffs that delete production code while also modifying tests. This heuristic catches the case where features are removed to make failing tests pass.
func (SLP052) DefaultSeverity ¶ added in v0.0.21
func (SLP052) Description ¶ added in v0.0.21
type SLP053 ¶ added in v0.0.21
type SLP053 struct{}
SLP053 flags numeric config values (timeouts, limits, etc.) added without an explanatory comment on the same or immediately preceding added line.
func (SLP053) DefaultSeverity ¶ added in v0.0.21
func (SLP053) Description ¶ added in v0.0.21
type SLP054 ¶ added in v0.0.21
type SLP054 struct{}
SLP054 flags Go files whose package declaration does not match the containing directory name, with exceptions for _test packages and package main in cmd/ directories.
func (SLP054) DefaultSeverity ¶ added in v0.0.21
func (SLP054) Description ¶ added in v0.0.21
type SLP055 ¶ added in v0.0.21
type SLP055 struct{}
SLP055 flags Go functions with more than 3 conditionals (if/for/select/switch) and zero comment lines added inside the function body.
func (SLP055) DefaultSeverity ¶ added in v0.0.21
func (SLP055) Description ¶ added in v0.0.21
type SLP056 ¶ added in v0.0.21
type SLP056 struct{}
SLP056 flags hardcoded secrets in added lines across any file type.
func (SLP056) Check ¶ added in v0.0.21
Check scans added lines for hardcoded secrets while skipping generated OpenAPI artifacts.
func (SLP056) DefaultSeverity ¶ added in v0.0.21
func (SLP056) Description ¶ added in v0.0.21
type SLP057 ¶ added in v0.0.21
type SLP057 struct{}
SLP057 flags dynamic code execution patterns in added lines.
func (SLP057) DefaultSeverity ¶ added in v0.0.21
func (SLP057) Description ¶ added in v0.0.21
type SLP058 ¶ added in v0.0.21
type SLP058 struct{}
SLP058 flags SQL strings built with string concatenation or interpolation.
func (SLP058) Check ¶ added in v0.0.21
Check implements the diff-aware SLP058 rule for SQL string concatenation.
func (SLP058) DefaultSeverity ¶ added in v0.0.21
DefaultSeverity returns this rule's default severity.
func (SLP058) Description ¶ added in v0.0.21
Description returns a short description of the SLP058 rule.
type SLP059 ¶ added in v0.0.21
type SLP059 struct{}
SLP059 flags unsanitized exec.Command usage in Go files.
func (SLP059) DefaultSeverity ¶ added in v0.0.21
func (SLP059) Description ¶ added in v0.0.21
type SLP060 ¶ added in v0.0.21
type SLP060 struct{}
SLP060 flags interfaces with only one struct declaration (or none) added in the same file. This is a heuristic, not a verified implementation count.
func (SLP060) DefaultSeverity ¶ added in v0.0.21
func (SLP060) Description ¶ added in v0.0.21
type SLP061 ¶ added in v0.0.21
type SLP061 struct{}
SLP061 flags factory/builder functions for structs with fewer than 3 fields, which is over-engineering — a struct literal is simpler.
Scope: Go files only.
func (SLP061) DefaultSeverity ¶ added in v0.0.21
func (SLP061) Description ¶ added in v0.0.21
type SLP062 ¶ added in v0.0.21
type SLP062 struct{}
SLP062 flags functions longer than 50 added lines or Go files with more than 500 added lines.
Scope: Go files only.
func (SLP062) DefaultSeverity ¶ added in v0.0.21
func (SLP062) Description ¶ added in v0.0.21
type SLP063 ¶ added in v0.0.21
type SLP063 struct{}
SLP063 flags struct definitions with more than 15 fields — the God Object anti-pattern.
Scope: Go files only.
func (SLP063) DefaultSeverity ¶ added in v0.0.21
func (SLP063) Description ¶ added in v0.0.21
type SLP064 ¶ added in v0.0.21
type SLP064 struct{}
SLP064 flags test files that set up mocks but contain no behavioural assertions — verifying mock calls is not enough.
Reuses assertion token detection from SLP001.
func (SLP064) DefaultSeverity ¶ added in v0.0.21
func (SLP064) Description ¶ added in v0.0.21
type SLP065 ¶ added in v0.0.21
type SLP065 struct{}
SLP065 flags ignored error returns in Go. If a function call returns an error but the next added line does not check it, we flag.
Heuristics:
- `_ = ...`, `_ := ...`, or `_, _ = ...` on the LHS of a function call.
- `err` assigned but not followed by `if err != nil` in the same hunk.
- Inline `if err := doSomething(); err != nil { ... }` is treated as handled.
- `_, err := doSomething()` where `err` is named on LHS is treated as handled.
Scope: Go files only.
func (SLP065) DefaultSeverity ¶ added in v0.0.21
func (SLP065) Description ¶ added in v0.0.21
type SLP066 ¶ added in v0.0.21
type SLP066 struct{}
SLP066 flags concurrent map access without mutex protection in Go files.
Heuristic: if the diff contains goroutines or WaitGroup usage and also contains map index/read/write operations, flag each indexed map identifier unless a sync.Mutex/sync.RWMutex or sync.Map guard is associated with it. "Associated" means the mutex variable name contains the map variable name (e.g., "cacheMu" guards "cache") or a mutex declaration appears in the same block as the map declaration (within 5 lines).
This is intentionally coarse — precisely matching mutex guards to specific map variables requires full AST analysis which is out of scope for diff-based linting.
func (SLP066) DefaultSeverity ¶ added in v0.0.21
func (SLP066) Description ¶ added in v0.0.21
type SLP067 ¶ added in v0.0.21
type SLP067 struct{}
SLP067 flags resource acquisitions without deferred or explicit close.
func (SLP067) DefaultSeverity ¶ added in v0.0.21
func (SLP067) Description ¶ added in v0.0.21
type SLP068 ¶ added in v0.0.21
type SLP068 struct{}
SLP068 flags duplicate 8-line code blocks within the same file.
func (SLP068) Check ¶ added in v0.0.21
Check reports duplicate code blocks while collapsing overlapping windows into a single finding.
func (SLP068) DefaultSeverity ¶ added in v0.0.21
func (SLP068) Description ¶ added in v0.0.21
type SLP069 ¶ added in v0.0.21
type SLP069 struct{}
SLP069 flags mixed naming conventions (snake_case and CamelCase) in the same package.
func (SLP069) DefaultSeverity ¶ added in v0.0.21
func (SLP069) Description ¶ added in v0.0.21
type SLP070 ¶ added in v0.0.21
type SLP070 struct{}
SLP070 flags diffs that touch too many top-level directories.
func (SLP070) DefaultSeverity ¶ added in v0.0.21
func (SLP070) Description ¶ added in v0.0.21
type SLP071 ¶ added in v0.0.21
type SLP071 struct{}
SLP071 detects type assertions without the comma-ok idiom. This can cause panics when the type assertion fails.
func (SLP071) DefaultSeverity ¶ added in v0.0.21
func (SLP071) Description ¶ added in v0.0.21
type SLP072 ¶ added in v0.0.21
type SLP072 struct{}
SLP072 detects potential nil pointer dereferences. While we can't do full data flow analysis, we can detect common patterns like method calls on potentially nil interface values.
func (SLP072) DefaultSeverity ¶ added in v0.0.21
func (SLP072) Description ¶ added in v0.0.21
type SLP073 ¶ added in v0.0.21
type SLP073 struct{}
SLP073 detects missing defer for resource cleanup patterns. Common patterns like os.File, sql.Rows that should be deferred.
func (SLP073) DefaultSeverity ¶ added in v0.0.21
func (SLP073) Description ¶ added in v0.0.21
type SLP074 ¶ added in v0.0.21
type SLP074 struct{}
SLP074 detects loop variables that escape into goroutines. This is a common race condition bug.
func (SLP074) DefaultSeverity ¶ added in v0.0.21
func (SLP074) Description ¶ added in v0.0.21
type SLP075 ¶ added in v0.0.21
type SLP075 struct{}
SLP075 detects usage of weak cryptographic functions.
func (SLP075) DefaultSeverity ¶ added in v0.0.21
func (SLP075) Description ¶ added in v0.0.21
type SLP076 ¶ added in v0.0.21
type SLP076 struct{}
SLP076 detects potential SQL injection via string concatenation.
func (SLP076) DefaultSeverity ¶ added in v0.0.21
func (SLP076) Description ¶ added in v0.0.21
type SLP077 ¶ added in v0.0.21
type SLP077 struct{}
SLP077 detects hardcoded credentials detected via AST analysis.
func (SLP077) DefaultSeverity ¶ added in v0.0.21
func (SLP077) Description ¶ added in v0.0.21
type SLP078 ¶ added in v0.0.21
type SLP078 struct{}
SLP078 detects select statements on closed channels, which can cause panics.
func (SLP078) DefaultSeverity ¶ added in v0.0.21
func (SLP078) Description ¶ added in v0.0.21
type SLP079 ¶ added in v0.0.21
type SLP079 struct{}
SLP079 detects missing error handling for known dangerous functions.
func (SLP079) DefaultSeverity ¶ added in v0.0.21
func (SLP079) Description ¶ added in v0.0.21
type SLP080 ¶ added in v0.0.21
type SLP080 struct{}
SLP080 detects interface with only one implementation.
func (SLP080) DefaultSeverity ¶ added in v0.0.21
func (SLP080) Description ¶ added in v0.0.21
type SLP081 ¶ added in v0.0.21
type SLP081 struct{}
SLP081 flags TSX/JSX files that use the React namespace without importing it. Plain JSX is valid under the automatic runtime, but direct React.* references still need an in-scope React binding.
func (SLP081) DefaultSeverity ¶ added in v0.0.21
func (SLP081) Description ¶ added in v0.0.21
type SLP082 ¶ added in v0.0.21
type SLP082 struct{}
SLP082 flags JSX array mappings that are missing the key prop. This causes React warnings and can lead to rendering issues.
func (SLP082) DefaultSeverity ¶ added in v0.0.21
func (SLP082) Description ¶ added in v0.0.21
type SLP083 ¶ added in v0.0.21
type SLP083 struct{}
SLP083 flags useCallback and useMemo hooks that are missing dependencies array. This can cause stale closures and performance issues. Note: This rule monitors for missing dependency arrays in React hooks, not hardcoded API keys. The naming follows the SLP convention for specific rule IDs, not advertised detection purposes. To fix false positives for valid hook calls with semicolons or multiline formatting, ensure dependency arrays end on the same line (e.g., `[]);`).
func (SLP083) DefaultSeverity ¶ added in v0.0.21
func (SLP083) Description ¶ added in v0.0.21
type SLP084 ¶ added in v0.0.21
type SLP084 struct{}
SLP084 flags useEffect hooks that need cleanup but don't have one. This can cause memory leaks from event listeners, timers, etc. Note: This rule monitors for useEffect cleanup patterns, not hardcoded AWS credentials. The ID SLP084 was assigned to this React hook rule during implementation; for AWS credential detection, see SLP088. The PR description may have listed incorrect detection capabilities. To detect event listeners or timers, ensure you add cleanup functions.
func (SLP084) DefaultSeverity ¶ added in v0.0.21
func (SLP084) Description ¶ added in v0.0.21
type SLP085 ¶ added in v0.0.21
type SLP085 struct{}
SLP085 flags potential SQL injection via string concatenation in queries. This is a critical security issue that can lead to data breaches.
func (SLP085) Check ¶ added in v0.0.21
Check scans for SQL queries built via string concatenation or template literals.
func (SLP085) DefaultSeverity ¶ added in v0.0.21
func (SLP085) Description ¶ added in v0.0.21
type SLP086 ¶ added in v0.0.21
type SLP086 struct{}
SLP086 flags potential missing authorization checks on sensitive endpoints. This can lead to privilege escalation and unauthorized access. Note: Auth checking is route-scoped - only lines within a specific route's body are considered when determining if a route has authorization. Note: The auth patterns have been tightened to only match auth-relevant negations (e.g., !user.isAdmin) to avoid false positives from generic checks.
func (SLP086) Check ¶ added in v0.0.21
Check scans for sensitive API routes without authorization checks. Auth checking is route-scoped: only lines within a specific route's body are considered when determining if that route has authorization.
func (SLP086) DefaultSeverity ¶ added in v0.0.21
func (SLP086) Description ¶ added in v0.0.21
type SLP087 ¶ added in v0.0.21
type SLP087 struct{}
SLP087 flags webhook handlers that don't have timeout configurations. This can cause hanging requests and resource exhaustion. Note: Timeout checking is file-scoped for simplicity. This means if any line in the file matches a timeout pattern, all webhook code in that file is considered to have timeout coverage. For per-handler timeout checking, the Check method would need route boundary parsing (like SLP086 does).
func (SLP087) Check ¶ added in v0.0.21
Check scans webhook files for missing timeout configurations.
func (SLP087) DefaultSeverity ¶ added in v0.0.21
func (SLP087) Description ¶ added in v0.0.21
type SLP088 ¶ added in v0.0.21
type SLP088 struct{}
SLP088 flags hardcoded secrets, credentials, and API keys in settings files. This is a critical security issue that can lead to data breaches. Note: This rule scans config/settings files (.toml, .yml, .yaml, .json, .env) for hardcoded credentials. Source code files are intentionally skipped to avoid overlap with other rules like SLP081-SLP085 that handle different credential detection scenarios.
func (SLP088) Check ¶ added in v0.0.21
Check scans config files for hardcoded credentials and secrets.
func (SLP088) DefaultSeverity ¶ added in v0.0.21
func (SLP088) Description ¶ added in v0.0.21
type SLP089 ¶ added in v0.0.21
type SLP089 struct{}
SLP089 flags exported functions, classes, and modules that lack documentation. Documentation is critical for maintainability and onboarding.
func (SLP089) DefaultSeverity ¶ added in v0.0.21
func (SLP089) Description ¶ added in v0.0.21
type SLP090 ¶ added in v0.0.21
type SLP090 struct{}
SLP090 flags API endpoints that don't handle error responses properly. This can lead to unhandled exceptions and poor user experience. Note: Error handling detection includes explicit error patterns (try-catch, error middleware) and error status codes (4xx/5xx) or error/fail payloads.
func (SLP090) DefaultSeverity ¶ added in v0.0.21
func (SLP090) Description ¶ added in v0.0.21
type SLP091 ¶ added in v0.0.21
type SLP091 struct{}
SLP091 flags hardcoded date/time literals in test fixtures that will predictably expire and break CI in the future.
Rationale: AI agents frequently generate fixtures with literal dates (new Date("2025-01-01"), expires_at: 2026-06-01). These become time- bombed tests that fail months later with opaque errors.
func (SLP091) DefaultSeverity ¶ added in v0.0.21
func (SLP091) Description ¶ added in v0.0.21
type SLP092 ¶ added in v0.0.21
type SLP092 struct{}
SLP092 detects mock return values that don't match the API envelope shape expected by the consuming code. A common AI slop pattern is mocking an API response as { data: ... } when the actual API wraps in { ok: true, data: ... }, or vice versa.
Heuristic: find mockResolvedValue/mockReturnValue calls, inspect the shape, compare against how the response is destructured in the same hunk or file.
func (SLP092) DefaultSeverity ¶ added in v0.0.21
func (SLP092) Description ¶ added in v0.0.21
type SLP093 ¶ added in v0.0.21
type SLP093 struct{}
SLP093 flags when new mock or stub setup is added to a test file without a corresponding new assertion. This is a common AI slop pattern: adding elaborate mock scaffolding to get tests to compile but forgetting the assertions that verify behavior.
Heuristic: count mock/stub terms vs assertion terms per hunk. Flag when mocks are added but no corresponding assertions are present.
func (SLP093) DefaultSeverity ¶ added in v0.0.21
func (SLP093) Description ¶ added in v0.0.21
type SLP094 ¶ added in v0.0.21
type SLP094 struct{}
SLP094 flags shell commands that suppress failures with || true or || : This is a common anti-pattern where AI agents silence errors instead of handling them, leading to builds that appear green but are actually broken.
func (SLP094) DefaultSeverity ¶ added in v0.0.21
func (SLP094) Description ¶ added in v0.0.21
type SLP095 ¶ added in v0.0.21
type SLP095 struct{}
SLP095 flags try/catch/except blocks where the catch handler returns a sentinel value (null, 0, false, empty collection) without re-throwing or logging. This is the "silent failure" pattern.
func (SLP095) DefaultSeverity ¶ added in v0.0.21
func (SLP095) Description ¶ added in v0.0.21
type SLP096 ¶ added in v0.0.21
type SLP096 struct{}
SLP096 flags new shell scripts that don't contain set -e, set -o pipefail, or set -o errexit in the first 20 lines. Shell scripts without error propagation continue execution after command failures, leading to masked errors and corrupted state.
func (SLP096) DefaultSeverity ¶ added in v0.0.21
func (SLP096) Description ¶ added in v0.0.21
type SLP097 ¶ added in v0.0.21
type SLP097 struct{}
SLP097 flags response destructuring patterns that may not match the API envelope. Common AI slop: frontend destructures { data } from response but the API wraps everything in { ok: true, data: { ... } }, requiring res.data.data.X instead of res.data.X.
func (SLP097) DefaultSeverity ¶ added in v0.0.21
func (SLP097) Description ¶ added in v0.0.21
type SLP098 ¶ added in v0.0.21
type SLP098 struct{}
SLP098 flags new API routes or handlers added without any corresponding test changes in the same diff. This is a common AI slop pattern: adding route handlers without tests.
func (SLP098) DefaultSeverity ¶ added in v0.0.21
func (SLP098) Description ¶ added in v0.0.21
type SLP099 ¶ added in v0.0.21
type SLP099 struct{}
SLP099 detects when a response struct/type field is added, renamed, or retyped in a non-test file without corresponding test file changes in the same diff. This is a common AI slop pattern: the agent changes a response shape but doesn't update the tests, causing test drift.
func (SLP099) DefaultSeverity ¶ added in v0.0.21
func (SLP099) Description ¶ added in v0.0.21
type SLP100 ¶ added in v0.0.21
type SLP100 struct{}
SLP100 flags functions that return a zero value with no side effects. These are stubs that were likely generated by an AI agent and left unfinished.
func (SLP100) DefaultSeverity ¶ added in v0.0.21
func (SLP100) Description ¶ added in v0.0.21
type SLP101 ¶ added in v0.0.21
type SLP101 struct{}
SLP101 flags feature-flag conditionals and empty alternate branches. This is a common AI slop pattern: scaffolding a gated branch without clarifying whether the divergence is intentional.
func (SLP101) DefaultSeverity ¶ added in v0.0.21
func (SLP101) Description ¶ added in v0.0.21
type SLP102 ¶ added in v0.0.21
type SLP102 struct{}
SLP102 flags async functions that contain no await expression. These are likely stubs where an AI agent declared the function async but never added the async work.
func (SLP102) DefaultSeverity ¶ added in v0.0.21
func (SLP102) Description ¶ added in v0.0.21
type SLP103 ¶ added in v0.0.21
type SLP103 struct{}
SLP103 flags hardcoded timeout/duration values that should be named constants. AI agents frequently write time.Second * 30 or setTimeout(fn, 5000) instead of referencing a configuration constant or named value.
func (SLP103) DefaultSeverity ¶ added in v0.0.21
func (SLP103) Description ¶ added in v0.0.21
type SLP104 ¶ added in v0.0.21
type SLP104 struct{}
SLP104 flags hardcoded buffer sizes, capacity limits, or pre-allocations that should be named constants or configuration values.
func (SLP104) DefaultSeverity ¶ added in v0.0.21
func (SLP104) Description ¶ added in v0.0.21
type SLP106 ¶ added in v0.0.21
type SLP106 struct{}
SLP106 flags resource acquisition functions (Open, Connect, Acquire, Listen, Dial) without a corresponding release/close/defer in the same hunk. alenAI slop pattern: agents open connections but forget cleanup.
func (SLP106) DefaultSeverity ¶ added in v0.0.21
func (SLP106) Description ¶ added in v0.0.21
type SLP107 ¶ added in v0.0.21
type SLP107 struct{}
SLP107 flags cleanup/destroy/close operations that appear only inside an error block (catch/except/if err) but are missing from the success path. Resources must be cleaned up on ALL code paths.
func (SLP107) DefaultSeverity ¶ added in v0.0.21
func (SLP107) Description ¶ added in v0.0.21
type SLP108 ¶ added in v0.0.21
type SLP108 struct{}
SLP108 flags Open/Connect calls without a preceding or following defer close or timeout/deadline setup. Connection management without guaranteed cleanup is a common AI slop pattern.
Known limitation: uses hunk-level correlation — any defer in the same hunk suppresses findings for all opens, even if they refer to different variables.
func (SLP108) DefaultSeverity ¶ added in v0.0.21
func (SLP108) Description ¶ added in v0.0.21
type SLP109 ¶ added in v0.0.21
type SLP109 struct{}
SLP109 flags two or more functions added in the same file with highly similar bodies (>60% identical). This is a common AI slop pattern: copy-pasting entire functions with minor changes instead of extracting shared logic.
func (SLP109) DefaultSeverity ¶ added in v0.0.21
func (SLP109) Description ¶ added in v0.0.21
type SLP110 ¶ added in v0.0.21
type SLP110 struct{}
SLP110 flags new files added in the same diff that have highly similar import structures, suggesting copy-paste file duplication.
func (SLP110) DefaultSeverity ¶ added in v0.0.21
func (SLP110) Description ¶ added in v0.0.21
type SLP111 ¶ added in v0.0.21
type SLP111 struct{}
SLP111 flags binary or executable files committed to the repository. This catches a common AI slop pattern where agents commit compiled outputs, binaries, or object files.
func (SLP111) DefaultSeverity ¶ added in v0.0.21
func (SLP111) Description ¶ added in v0.0.21
type SLP112 ¶ added in v0.0.21
type SLP112 struct{}
SLP112 flags generated files committed without their corresponding source files. This catches common AI slop patterns like committing .pb.go, .min.js, or _generated.ts files without the .proto, .js source in the same commit.
func (SLP112) DefaultSeverity ¶ added in v0.0.21
func (SLP112) Description ¶ added in v0.0.21
type SLP113 ¶ added in v0.0.21
type SLP113 struct{}
SLP113 checks for source files changed without a corresponding test update.
func (SLP113) DefaultSeverity ¶ added in v0.0.21
func (SLP113) Description ¶ added in v0.0.21
type SLP114 ¶ added in v0.0.21
type SLP114 struct{}
SLP114 checks for error-returning function calls used as statements without error handling.
func (SLP114) DefaultSeverity ¶ added in v0.0.21
func (SLP114) Description ¶ added in v0.0.21
type SLP115 ¶ added in v0.0.21
type SLP115 struct{}
SLP115 checks for narrow file extension usage without broader related extension coverage.
func (SLP115) DefaultSeverity ¶ added in v0.0.21
func (SLP115) Description ¶ added in v0.0.21
type SLP116 ¶ added in v0.0.21
type SLP116 struct{}
SLP116 checks for regex patterns with nested quantifiers that could cause ReDoS.
func (SLP116) DefaultSeverity ¶ added in v0.0.21
func (SLP116) Description ¶ added in v0.0.21
type SLP117 ¶ added in v0.0.21
type SLP117 struct{}
SLP117 checks for unanchored regex patterns that could match unintended substrings.
func (SLP117) DefaultSeverity ¶ added in v0.0.21
func (SLP117) Description ¶ added in v0.0.21
type SLP118 ¶ added in v0.0.21
type SLP118 struct{}
SLP118 checks for numeric index access without a length guard that may panic on empty collections.
func (SLP118) DefaultSeverity ¶ added in v0.0.21
func (SLP118) Description ¶ added in v0.0.21
type SLP119 ¶ added in v0.0.21
type SLP119 struct{}
SLP119 checks for TrimSuffix/TrimPrefix results used without verifying the suffix/prefix was present.
func (SLP119) DefaultSeverity ¶ added in v0.0.21
func (SLP119) Description ¶ added in v0.0.21
type SLP120 ¶ added in v0.0.21
type SLP120 struct{}
SLP120 checks for discarded values using the blank identifier in assignments.
func (SLP120) DefaultSeverity ¶ added in v0.0.21
func (SLP120) Description ¶ added in v0.0.21
type SLP121 ¶ added in v0.0.21
type SLP121 struct{}
SLP121 flags sensitive access/share/role mutations that appear to be missing explicit tenant/membership/authorization guard checks in nearby code.
func (SLP121) DefaultSeverity ¶ added in v0.0.21
func (SLP121) Description ¶ added in v0.0.21
type SLP122 ¶ added in v0.0.21
type SLP122 struct{}
SLP122 flags async polling/retry patterns without nearby cancellation or in-flight guard logic. This catches common UI/task-loop race patterns.
func (SLP122) DefaultSeverity ¶ added in v0.0.21
func (SLP122) Description ¶ added in v0.0.21
type SLP123 ¶ added in v0.0.21
type SLP123 struct{}
SLP123 flags offset pagination on mutable time ordering when no cursor/keyset signal is present nearby. This pattern often drifts under concurrent writes.
func (SLP123) DefaultSeverity ¶ added in v0.0.21
func (SLP123) Description ¶ added in v0.0.21
type SLP124 ¶ added in v0.0.21
type SLP124 struct{}
SLP124 flags external API/client calls that consume request/input payloads without nearby validation checks.
func (SLP124) DefaultSeverity ¶ added in v0.0.21
func (SLP124) Description ¶ added in v0.0.21
type SLP125 ¶ added in v0.0.21
type SLP125 struct{}
SLP125 flags role/share/access mutations that lack nearby audit logging.
func (SLP125) DefaultSeverity ¶ added in v0.0.21
func (SLP125) Description ¶ added in v0.0.21
type SLP126 ¶ added in v0.0.21
type SLP126 struct{}
SLP126 flags migration SQL that introduces FK/reference columns without a matching CREATE INDEX in the same diff. Checks are table-scoped so that an index on column X in table A does not suppress a warning about column X in table B.
func (SLP126) DefaultSeverity ¶ added in v0.0.21
func (SLP126) Description ¶ added in v0.0.21
type SLP127 ¶ added in v0.0.21
type SLP127 struct{}
SLP127 flags slopgate rule implementation changes without matching test-file updates in the same diff.
func (SLP127) DefaultSeverity ¶ added in v0.0.21
func (SLP127) Description ¶ added in v0.0.21
type SLP128 ¶ added in v0.0.21
type SLP128 struct{}
SLP128 flags interactive bot jobs that are enqueued with a positive BullMQ priority. BullMQ treats lower numeric values as higher priority, so priority: 1 can accidentally delay user-facing jobs behind default jobs.
func (SLP128) DefaultSeverity ¶ added in v0.0.21
func (SLP128) Description ¶ added in v0.0.21
type SLP129 ¶ added in v0.0.21
type SLP129 struct{}
SLP129 flags live secrets/config committed in tracked .env files.
func (SLP129) DefaultSeverity ¶ added in v0.0.21
func (SLP129) Description ¶ added in v0.0.21
type SLP130 ¶ added in v0.0.21
type SLP130 struct{}
SLP130 flags production-origin navigation hardcoded into app code.
func (SLP130) DefaultSeverity ¶ added in v0.0.21
func (SLP130) Description ¶ added in v0.0.21
type SLP131 ¶ added in v0.0.21
type SLP131 struct{}
SLP131 flags nested React links/anchors, which produce invalid interactive markup and can break routing/accessibility.
func (SLP131) DefaultSeverity ¶ added in v0.0.21
func (SLP131) Description ¶ added in v0.0.21
type SLP132 ¶ added in v0.0.21
type SLP132 struct{}
SLP132 flags global keyboard shortcuts that do not guard editable targets.
func (SLP132) DefaultSeverity ¶ added in v0.0.21
func (SLP132) Description ¶ added in v0.0.21
type SLP133 ¶ added in v0.0.21
type SLP133 struct{}
SLP133 flags Express router-level body parsers that commonly duplicate the app-level parser used for signature verification routes.
func (SLP133) DefaultSeverity ¶ added in v0.0.21
func (SLP133) Description ¶ added in v0.0.21
type SLP134 ¶ added in v0.0.21
type SLP134 struct{}
SLP134 flags full transfer/failure arrays persisted into metadata or audit rows instead of bounded summaries.
func (SLP134) DefaultSeverity ¶ added in v0.0.21
func (SLP134) Description ¶ added in v0.0.21
type SLP135 ¶ added in v0.0.21
type SLP135 struct{}
SLP135 flags raw provider error messages persisted into summaries/audits.
func (SLP135) DefaultSeverity ¶ added in v0.0.21
func (SLP135) Description ¶ added in v0.0.21
type SLP136 ¶ added in v0.0.21
type SLP136 struct{}
SLP136 flags catch blocks that wrap a caught error in AppError without preserving the original cause. This is especially important when the code also logs or captures the original error for Sentry-style diagnostics.
func (SLP136) DefaultSeverity ¶ added in v0.0.21
func (SLP136) Description ¶ added in v0.0.21
type SLP137 ¶ added in v0.0.21
type SLP137 struct{}
SLP137 flags explicit BullMQ bot priorities introduced while sibling call-sites in the repo still enqueue equivalent bot jobs with default priority. That mixture caused real CodeRabbit findings because BullMQ v5 processes default-priority jobs ahead of positive priorities.
func (SLP137) DefaultSeverity ¶ added in v0.0.21
func (SLP137) Description ¶ added in v0.0.21
type SLP138 ¶ added in v0.0.21
type SLP138 struct{}
SLP138 flags provider operations that forward only token auth even though surrounding context shows credential-based auth is available too.
func (SLP138) DefaultSeverity ¶ added in v0.0.21
func (SLP138) Description ¶ added in v0.0.21
type SLP139 ¶ added in v0.0.21
type SLP139 struct{}
SLP139 flags partial S3 hardening rollouts: a helper is added in one path while sibling repo call-sites still parse raw S3 credential blobs and create S3 clients directly.
func (SLP139) DefaultSeverity ¶ added in v0.0.21
func (SLP139) Description ¶ added in v0.0.21
type SLP140 ¶ added in v0.0.21
type SLP140 struct{}
SLP140 flags hardening helpers that are applied to generic token variables without a provider-family or JSON-blob guard.
func (SLP140) DefaultSeverity ¶ added in v0.0.21
func (SLP140) Description ¶ added in v0.0.21
type SLP141 ¶ added in v0.0.21
type SLP141 struct{}
SLP141 detects missing guards in async logic triggered by React effects. High-signal pattern: useEffect calling an async function without checking a loading/mounted state or using an AbortController.
func (SLP141) DefaultSeverity ¶ added in v0.0.21
func (SLP141) Description ¶ added in v0.0.21
type SLP142 ¶ added in v0.0.21
type SLP142 struct{}
SLP142 flags unsafe path construction where filepath.Join or path.Join is used to access files without subsequent symlink evaluation and containment checks. This catches potential path traversal and symlink escape vulnerabilities.
func (SLP142) DefaultSeverity ¶ added in v0.0.21
func (SLP142) Description ¶ added in v0.0.21
type SLP143 ¶ added in v0.0.21
type SLP143 struct{}
SLP143 flags direct env var access without validation in critical sections. This catches patterns like:
- process.env.KEY (unchecked)
- process.env["KEY"] (bracket access)
- import.meta.env.KEY (vite)
- import.meta.env['KEY'] (bracket access)
- Deno.env.get() (less common)
The rule is context-sensitive: it allows env var usage in test files, config files with explicit validation patterns, and files named config/env/constants.
Languages: JavaScript, TypeScript, JSX, TSX
Scope: production source files only (excludes tests, config setup)
func (SLP143) DefaultSeverity ¶ added in v0.0.21
func (SLP143) Description ¶ added in v0.0.21
type SLP144 ¶ added in v0.0.21
type SLP144 struct{}
SLP144 flags inconsistent error handling patterns within the same file or route handler group. Mixing res.fail(), next(err), and throw err creates confusion and can lead to unhandled errors.
Note: res.status/res.json/res.send are success-path response methods and are NOT treated as error handlers. Standard try/catch patterns using res.json in try + next(err) in catch are not flagged.
Detected patterns:
- Express route handlers mixing res.fail and next(err)
- Mixing throw err with res.error patterns in same file
Languages: JavaScript, TypeScript
Scope: files with Express/Koa-style route handlers
func (SLP144) DefaultSeverity ¶ added in v0.0.21
func (SLP144) Description ¶ added in v0.0.21
type SLP145 ¶ added in v0.0.21
type SLP145 struct{}
SLP145 flags hardcoded timeout values that lack contextual justification via comments. Timeouts that are too short (under 1s) or too long (over 30s) should have an explanation of why those values are chosen.
Detected patterns:
- setTimeout, setInterval with numeric literals (ms)
- fetch/axios/timeout options with ms values
- database/connection timeouts (ms)
- HTTP client timeouts (ms)
- Go: context.WithTimeout, time.After, time.NewTimer (seconds)
- Python: time.sleep (seconds)
- Java: Thread.sleep (ms)
Languages: JavaScript, TypeScript, Go, Python, Java
Scope: all source files
func (SLP145) DefaultSeverity ¶ added in v0.0.21
func (SLP145) Description ¶ added in v0.0.21
type SLP146 ¶ added in v0.0.21
type SLP146 struct{}
SLP146 flags unawaited promises in loops or array iteration methods. This catches patterns where async operations are started but not properly awaited, leading to race conditions and unhandled rejections.
Detected patterns:
- array.map(async item => {...}) without Promise.all wrapper
- array.forEach with async callback without await
- for...of loops with async calls but missing await
Languages: JavaScript, TypeScript
Scope: all source files
func (SLP146) DefaultSeverity ¶ added in v0.0.21
func (SLP146) Description ¶ added in v0.0.21
type SLP147 ¶ added in v0.0.21
type SLP147 struct{}
SLP147 flags object destructuring that may access properties of null or undefined values without defensive defaults or existence checks.
Detected patterns:
- const {prop} = possiblyUndefinedExpr;
- let {x, y} = maybeNull without if-check preceding it
- var {field} = obj where obj might be undefined
Languages: JavaScript, TypeScript
Scope: all source files
func (SLP147) DefaultSeverity ¶ added in v0.0.21
func (SLP147) Description ¶ added in v0.0.21
type SLP148 ¶ added in v0.0.21
type SLP148 struct{}
SLP148 detects when different variables representing the same conceptual entity use inconsistent naming conventions across modified modules/files. This catches patterns like userId vs userID vs user_id for the same concept.
Detection strategy:
- Extract all variable/constant declarations from added lines
- Normalize names (lowercase, strip underscores, etc.)
- Group by semantic similarity (Levenshtein distance, shared prefixes/suffixes)
- Flag groups with multiple naming conventions
Languages: JavaScript, TypeScript, Go, Python
Scope: exported / module-boundary declarations across files. A naming inconsistency in a public symbol crosses module lines and is worth flagging; a local variable's casing is noise.
func (SLP148) DefaultSeverity ¶ added in v0.0.21
func (SLP148) Description ¶ added in v0.0.21
type SLP151 ¶ added in v0.0.21
type SLP151 struct{}
SLP151 flags an orphaned test: a test file that still calls a function, method, or class which the same diff removed from a non-test source file and did not re-add or rename in place.
Rationale: when an AI agent renames or deletes a symbol it often leaves behind the test that exercised it, producing a test that no longer compiles or references dead code.
func (SLP151) DefaultSeverity ¶ added in v0.0.21
func (SLP151) Description ¶ added in v0.0.21
type SLP152 ¶ added in v0.0.21
type SLP152 struct{}
SLP152 flags unreachable code that follows an if/else chain in which every branch — including a terminal else — ends with a control-flow terminator. SLP019 already flags code after a single terminator; SLP152 extends that to a fully-terminating conditional, a common artifact of an AI agent appending code after an if/else that always returns.
Restricted to brace languages: there, a terminator nested inside a branch is always followed by a closing brace, so a branch's last line is a terminator only when the branch unconditionally exits.
func (SLP152) DefaultSeverity ¶ added in v0.0.21
func (SLP152) Description ¶ added in v0.0.21
type SLP155 ¶ added in v0.0.21
type SLP155 struct{}
SLP155 flags ALTER TABLE … ADD COLUMN statements that declare a column NOT NULL without a DEFAULT value. Adding a NOT NULL column to a non-empty table without a DEFAULT causes an immediate error in PostgreSQL and most other databases, because existing rows have no value to fill in.
Safe patterns that are NOT flagged:
- ADD COLUMN … NOT NULL DEFAULT <value>
- ADD COLUMN … NOT NULL (when the column is created on a brand-new table in the same diff — detected by the presence of a CREATE TABLE for the same table name earlier in the file)
Languages: SQL migration files (.sql in a migrations/ directory).
func (SLP155) DefaultSeverity ¶ added in v0.0.21
func (SLP155) Description ¶ added in v0.0.21
type SLP156 ¶ added in v0.0.21
type SLP156 struct{}
SLP156 detects the redundant JavaScript/TypeScript double-guard pattern where the same variable is checked against both `=== null` and `=== undefined` (in either order) using an `||` or `&&` operator.
The idiomatic replacement is the abstract equality check (`== null`) or the nullish coalescing operator (`?? defaultValue`), both of which cover null and undefined simultaneously and are less error-prone.
Flagged patterns:
- x === null || x === undefined
- x === undefined || x === null
- x !== null && x !== undefined
- x !== undefined && x !== null
Not flagged (already idiomatic or different variable):
- x == null
- x != null
- x === null || y === undefined (different variables)
func (SLP156) DefaultSeverity ¶ added in v0.0.21
func (SLP156) Description ¶ added in v0.0.21
type SLP202 ¶ added in v0.0.21
type SLP202 struct{}
SLP202 flags accesses that may dereference a nil/null pointer.
Primary pattern (high signal): a nil/sentinel check for variable X is removed in the diff while X is still dereferenced in newly added code at the same or shallower indentation level (i.e. outside the old guard).
Languages: Go, JS/TS, Python, Java, Rust.
Scope: diff only — looks at added/deleted lines within the same file hunk.
func (SLP202) Check ¶ added in v0.0.21
Check implements the diff-aware SLP202 rule for nil-deref guard detection.
func (SLP202) DefaultSeverity ¶ added in v0.0.21
DefaultSeverity returns this rule's default severity.
func (SLP202) Description ¶ added in v0.0.21
Description returns a short description of the SLP202 rule.
type SLP203 ¶ added in v0.0.21
type SLP203 struct{}
SLP203 flags SQL INSERT statements that lack conflict-handling clauses.
Primary pattern (high signal): an INSERT INTO ... VALUES statement is added in the diff without an ON CONFLICT / ON DUPLICATE KEY / INSERT OR REPLACE|IGNORE / MERGE / UPSERT clause. This commonly causes unique- constraint violations in production (Sentry crashes).
Languages: Go, Python, Java, JS/TS. Scope: diff only — scans added lines within each file hunk.
func (SLP203) Check ¶ added in v0.0.21
Check implements the diff-aware SLP203 rule for INSERT without conflict handling.
func (SLP203) DefaultSeverity ¶ added in v0.0.21
DefaultSeverity returns this rule's default severity.
func (SLP203) Description ¶ added in v0.0.21
Description returns a short description of the SLP203 rule.
type SLP204 ¶ added in v0.0.21
type SLP204 struct{}
SLP204 flags code paths where an error variable is assigned from a function call but the enclosing function returns success without checking or propagating that error.
Primary pattern (high signal): an added line assigns an error (err := ..., const err = ..., let err = ...) and a subsequent added line returns a success value (nil, true, None, null, { ok: true }) without checking the error in between.
Languages: Go, Python, Java, JS/TS. Scope: diff only — scans added lines within each file hunk.
func (SLP204) Check ¶ added in v0.0.21
Check implements the diff-aware SLP204 rule for unchecked errors before success returns.
func (SLP204) DefaultSeverity ¶ added in v0.0.21
DefaultSeverity returns this rule's default severity.
func (SLP204) Description ¶ added in v0.0.21
Description returns a short description of the SLP204 rule.
type SLP205 ¶ added in v0.0.21
type SLP205 struct{}
SLP205 flags OpenAPI path merge order that lets generated or hardcoded path maps override richer JSDoc-derived spec.paths annotations.
func (SLP205) Check ¶ added in v0.0.21
Check scans JS/TS OpenAPI assembly diffs for unsafe path map spread order.
func (SLP205) DefaultSeverity ¶ added in v0.0.21
DefaultSeverity returns the default finding severity.
func (SLP205) Description ¶ added in v0.0.21
Description returns a short rule summary for rule catalogs.
type SLP207 ¶ added in v0.0.21
type SLP207 struct{}
SLP207 flags code paths where a database transaction is started but no explicit rollback is present on error return paths.
Primary pattern (high signal): a BEGIN / db.Begin() is added but the corresponding ROLLBACK / tx.Rollback() is missing, and an error-return or error-propagation path exists in the same hunk.
This catches the common Sentry bug: a transaction is left open/abandoned when an error occurs before commit, causing connection leaks or inconsistent state.
Languages: Go, Python, Java, JS/TS, SQL. Scope: diff only — scans added lines within each file hunk.
func (SLP207) Check ¶ added in v0.0.21
Check implements the diff-aware SLP207 rule for transaction rollback detection.
Two conditions trigger a finding:
Error-path rollback gap: BEGIN + DB operations + error return, without ROLLBACK. Catches the common Sentry bug where a transaction is started, queries run, and an error is returned without rolling back.
Abandoned transaction: BEGIN without any COMMIT or ROLLBACK in the same hunk. Catches forgotten transactions where no cleanup is attempted at all.
func (SLP207) DefaultSeverity ¶ added in v0.0.21
DefaultSeverity returns this rule's default severity.
func (SLP207) Description ¶ added in v0.0.21
Description returns a short description of the SLP207 rule.
type SLP208 ¶ added in v0.0.21
type SLP208 struct{}
SLP208 detects TypeScript/JavaScript function declarations where a parameter with a default value appears before a required parameter.
In JS/TS, default parameters must come last — otherwise calling the function with positional args becomes ambiguous and TypeScript raises a compile error. This rule catches the pattern in added diff lines.
Flagged patterns:
- function foo(a = 1, b) { ... }
- const foo = (a = 1, b) => { ... }
- function foo(a, b = 1, c) { ... }
Not flagged:
- function foo(a, b = 1) { ... } (default is last)
- function foo(a = 1, b = 2) { ... } (all defaults)
func (SLP208) DefaultSeverity ¶ added in v0.0.21
func (SLP208) Description ¶ added in v0.0.21
type SLP209 ¶ added in v0.0.21
type SLP209 struct{}
SLP209 detects async arrow functions that return a value on some code paths but not on all — typically the last statement before `}` is not a `return`. This catches a common bug: error-handling branches return early but the happy path falls through with `undefined`.
The rule fires when:
- An async arrow function body contains at least one `return` (so it is intended to return a value), AND
- The last non-empty line before the closing `}` is not a `return`, `throw`, `break`, `continue`, or another closing brace.
This is a high-signal heuristic: if the function never returns anything, it is likely a side-effect-only handler (not flagged). But if it returns on *some* paths and misses the fall-through, that is almost always a bug.
Flagged patterns:
const getUser = async (id) => {
const user = await db.find(id)
if (!user) return null
user // missing return — falls through with undefined
}
const getUser = async (id) => {
try {
return await db.find(id)
} catch (e) {
log(e)
}
}
Not flagged:
const handler = async (req, res) => {
const data = await fetch(req.url)
res.json(data)
}
const getUser = async (id) => {
return await db.find(id)
}
func (SLP209) DefaultSeverity ¶ added in v0.0.21
func (SLP209) Description ¶ added in v0.0.21
type SemanticRule ¶ added in v0.0.21
type SemanticRule interface {
// ID returns the stable rule identifier, e.g. "SLP071".
ID() string
// Description returns a human-readable one-liner.
Description() string
// DefaultSeverity is the severity used when config does not override it.
DefaultSeverity() Severity
// Check runs the rule against the AST analysis and returns any findings.
Check(a *diff.AnalysisResult) []Finding
}
SemanticRule is the interface for AST-aware rules that can query cross-function type information and perform semantic analysis. These rules receive the full AST for new Go files, enabling deeper analysis than what's possible with regex alone.
Source Files
¶
- filetype.go
- registry.go
- rule.go
- semantic_rules.go
- slp001.go
- slp002.go
- slp003.go
- slp005.go
- slp006.go
- slp007.go
- slp008.go
- slp009.go
- slp010.go
- slp011.go
- slp012.go
- slp013.go
- slp014.go
- slp015.go
- slp016.go
- slp017.go
- slp018.go
- slp019.go
- slp020.go
- slp021.go
- slp022.go
- slp023.go
- slp024.go
- slp025.go
- slp026.go
- slp027.go
- slp030.go
- slp031.go
- slp032.go
- slp033.go
- slp034.go
- slp035.go
- slp036.go
- slp037.go
- slp038.go
- slp039.go
- slp040.go
- slp041.go
- slp042.go
- slp043.go
- slp044.go
- slp045.go
- slp046.go
- slp047.go
- slp048.go
- slp049.go
- slp050.go
- slp051.go
- slp052.go
- slp053.go
- slp054.go
- slp055.go
- slp056.go
- slp057.go
- slp058.go
- slp059.go
- slp060.go
- slp061.go
- slp062.go
- slp063.go
- slp064.go
- slp065.go
- slp066.go
- slp067.go
- slp068.go
- slp069.go
- slp070.go
- slp081.go
- slp082.go
- slp083.go
- slp084.go
- slp085.go
- slp086.go
- slp087.go
- slp088.go
- slp089.go
- slp090.go
- slp091.go
- slp092.go
- slp093.go
- slp094.go
- slp095.go
- slp096.go
- slp097.go
- slp098.go
- slp099.go
- slp100.go
- slp101.go
- slp102.go
- slp103.go
- slp104.go
- slp106.go
- slp107.go
- slp108.go
- slp109.go
- slp110.go
- slp111.go
- slp112.go
- slp113.go
- slp114.go
- slp115.go
- slp116.go
- slp117.go
- slp118.go
- slp119.go
- slp120.go
- slp121.go
- slp122.go
- slp123.go
- slp124.go
- slp125.go
- slp126.go
- slp127.go
- slp128_135.go
- slp136.go
- slp137_140.go
- slp141.go
- slp142.go
- slp143.go
- slp144.go
- slp145.go
- slp146.go
- slp147.go
- slp148.go
- slp151.go
- slp152.go
- slp155.go
- slp156.go
- slp202.go
- slp203.go
- slp204.go
- slp205.go
- slp207.go
- slp208.go
- slp209.go