Rules reference

Generated from jevgate rules --format json (jevgate 0.18.0). A rule is named by its ID, its key or its group anywhere a rule is accepted: --rule, --skip-rule, --fail-on TARGET=LEVEL, [rules] and [[scope]].

Maintainability

On by default.

maintainability/file-organization

Question: Would moving some members into a separate module (or tests into a separate test file) make the file easier to navigate and maintain?

• Key: file_organization · Version: 18
• Looks at: application and test files with two or more members and 100 or more lines of member code
• Evidence unit: file outline: member signatures and sizes, callers that import the file, and groups; a test file lists its cases with their suites and subjects; no bodies
• Acceptable: One algorithm, one type and its helpers, one feature, or the tests of one subject

maintainability/function-simplification

Question: Would splitting the function into named functions make it easier to understand? For control flow nested four deep or four-branch chains: would flattening it help?

• Key: function_simplification · Version: 14
• Looks at: functions and methods with bodies of five or more lines
• Evidence unit: one function’s source
• Acceptable: One job whose steps belong together or already call named functions

maintainability/shared-logic

Question: Do the two sites perform the same steps for the same purpose, so one shared implementation would serve both?

• Key: shared_logic · Version: 19
• Looks at: renamed or exact copies of two or more statements across selected files and explicit context
• Evidence unit: one representative pair per clone group, with its renamed names and values
• Acceptable: Different work that only looks alike, or repetition the behavior requires

maintainability/hardcoded-values

Question: Does a value fixed in code change between deployments, need a descriptive name, or special-case one identity?

• Key: hardcoded_values · Version: 4
• Looks at: application functions and module constants that use literal values other than 0, 1, 2 or one-character strings
• Evidence unit: one function’s source with its literal values, or a file’s module-level constants
• Acceptable: Messages, formats, protocol names and values whose meaning the code around them makes clear

Security

Opt-in: --rule security, or a level in [rules].

security/injection

Question: Does a variable that another party controls reach the text of a query, command, code, markup, file path, requested URL or redirect target, or a deserializer, without being bound, escaped or checked?

• Key: injection · Version: 6
• Looks at: application functions with calls, built text or field assignments, and PHP page scripts
• Evidence unit: one function’s source or a PHP file’s top-level code; then its statements as sites, and up to three callers when the origin of its values is unclear
• Acceptable: Bound query parameters, argument lists, escaping templates, and values the program fixes or checks

security/sensitive-data

Question: Does the function log a password, token, key or personal data, or send internal error details to a remote client? Does an error handler send clients more than the program’s own messages and codes?

• Key: sensitive_data · Version: 5
• Looks at: application functions with calls, built text or field assignments, and PHP page scripts
• Evidence unit: one function’s source or a PHP file’s top-level code; then its statements as sites and the message of each error it creates; one question per registered web error handler
• Acceptable: Logging record ids and messages; generic error responses with details kept in server logs

security/unsafe-settings

Question: Does the code turn off a security check or choose a weak setting: certificate verification, password hashing, random tokens, CORS, cookies, or secrets in environment variables the build puts into browser code?

• Key: unsafe_settings · Version: 4
• Looks at: application functions, each file’s top-level statements that call something, the settings objects of next.config files, and PHP page scripts
• Evidence unit: one function’s source or the file’s setup statements; then their statements as sites
• Acceptable: MD5 for cache keys, non-cryptographic random for shuffling, secure defaults

security/access-control

Question: Does a policy let every user it applies to reach other users’ rows, or trust a value users can change? Does a SECURITY DEFINER function leave search_path open or skip checking the caller? Does a grant open writes or private reads to every user? Does a public table hold users’ own data, a view return other users’ rows, or a reducer change rows its arguments choose, or admin-only settings, without checking the caller?

• Key: access_control · Version: 2
• Looks at: SQL files: row-level security policies, SECURITY DEFINER functions and grants, in their final state across migrations; SpacetimeDB TypeScript modules: public tables, views and reducers
• Evidence unit: one policy with its table and the functions it calls, one SECURITY DEFINER function, or one grant; one SpacetimeDB public table with its user columns, or one view or reducer with the functions it calls and the framework version
• Acceptable: Policies tied to the user, account or membership; role checks; restrictive policies; public data; grants narrowed by row-level security; reducers that check the caller through ctx.sender, the module owner, an admin or a trusted service identity, or run only on a schedule

security/workflows

Question: Can a run script execute text that people outside the repository write? Does a job run pull request code while it has secrets or a write token?

• Key: workflows · Version: 1
• Looks at: GitHub Actions jobs in .github/workflows
• Evidence unit: one job with the workflow’s triggers and permissions, and the ${{ }} expressions in its run scripts
• Acceptable: Untrusted text passed through env variables; pull_request workflows; jobs that run only the base branch’s code

Tests

On by default; judged with --include-tests or include_tests = true.

tests/value

Question: Does the test check only its mocks, recompute the expected value with the code’s own logic, assert internal details, or mix unrelated behaviors?

• Key: test_value · Version: 5 · Needs tests: yes
• Looks at: test cases, with –include-tests
• Evidence unit: one test’s source and the signatures it calls
• Acceptable: A test that checks a result or effect a caller can observe

tests/redundancy

Question: Do the two tests check the same behavior, with different or equivalent inputs?

• Key: test_redundancy · Version: 3 · Needs tests: yes
• Looks at: similar tests of one function, with –include-tests
• Evidence unit: one candidate pair of tests and their shared subject
• Acceptable: Tests of different behaviors of one function

Documentation

Opt-in: --rule documentation, or a level in [rules].

documentation/agent-context

Question: Does a section restate what the repository’s files show, give generic advice, repeat what linters check, or record past work?

• Key: agent_context · Version: 3
• Looks at: agent instruction files that a harness loads: AGENTS.md, CLAUDE.md, GEMINI.md, and Claude, Cursor, Copilot, Windsurf and Cline rules
• Evidence unit: one file’s heading sections, with the repository’s manifests, linters and directories
• Acceptable: Project-specific commands, constraints, decisions and workflows the code does not show

documentation/large-docs

Question: Would splitting the document make it easier to find and maintain, or does it mainly record past work?

• Key: large_docs · Version: 2
• Looks at: project Markdown of 300 or more lines: root files, README and CONTRIBUTING anywhere, docs/ and doc/ (read even when ignored)
• Evidence unit: one document’s headings in order, without its text
• Acceptable: One long guide, reference or concept, and living procedures

documentation/staleness

Question: Is the document a plan whose work is finished, or does a section tell the reader to use a path or script that no longer exists?

• Key: doc_staleness · Version: 3
• Looks at: agent instruction files and project docs that name paths or scripts the repository lacks, or a released version
• Evidence unit: a document’s headings when Git shows its release tagged or its paths deleted; then each section naming missing paths or scripts, with what Git shows about them
• Acceptable: Outputs a command writes, local or ignored files, examples, and paths named as removed

documentation/duplication

Question: Does one section state everything the other states, or do the two give different values or instructions for the same thing?

• Key: doc_duplication · Version: 3
• Looks at: sections of different agent instruction files and project docs that share much of their wording
• Evidence unit: one candidate pair of sections
• Acceptable: Sections on the same subject where each adds something

documentation/comments

Question: Does a comment only repeat its code, hold sentences that add nothing, narrate an edit instead of the code as it is, or hold code turned off?

• Key: comments · Version: 2
• Looks at: comments and docstrings of application code, except license headers, tool directives and type annotations
• Evidence unit: one comment with the code it is about: the declaration it documents, the lines below it or the line it ends; then the whole definition it sits in
• Acceptable: Reasons, constraints, caveats, references, and documentation of what a definition returns or guarantees beyond its signature

Decision policy

Answers become findings in code, at the same thresholds for every rule: