.coderabbit.yaml

inheritance: true
language: en-US
early_access: false
reviews:
  path_filters:
    - "!vendor/**"
    - "!go.sum"
  profile: chill
  request_changes_workflow: true
  high_level_summary: true
  poem: false
  review_status: true
  collapse_walkthrough: false
  path_instructions:
    - path: "sippy-ng/**/*.js"
      instructions: |
        Avoid nested ternary expressions in JSX. When there are more than two
        branches, use if/else if chains, early returns, or a lookup object instead.
        A single ternary is fine; nesting ternaries makes code hard to follow.

        Before adding date/time formatting, duration calculations, or string
        utilities inline, check sippy-ng/src/helpers.js for existing functions
        like relativeDuration, safeEncodeURIComponent, etc. Prefer reusing
        existing helpers over reimplementing similar logic.
    - path: "pkg/**/query/**"
      instructions: |
        BigQuery and SQL query-building code should have inline comments
        explaining the purpose of each major query section (CTEs, JOINs,
        window functions, WHERE clauses). Abbreviations like CTE, matview,
        etc. should be expanded on first use. Functions that construct queries
        should ideally stay under 200 lines; extract sub-queries or CTEs into
        helper functions when they grow beyond that.
    - path: "pkg/apis/**/*.go"
      instructions: |
        Structs used with GORM that have fields not backed by database columns
        (e.g., computed fields, custom types, API-only fields) must include
        the `gorm:"-"` tag to explicitly exclude them from GORM operations.
        Similarly, BigQuery struct fields must have `bigquery:"column_name"`
        tags that exactly match the BigQuery table column names.
    - path: "pkg/**/*.go"
      instructions: |
        Check pkg/util/ for existing helper functions before adding inline
        utility logic. Avoid calling the same utility function multiple times
        with identical arguments in the same code path.

        Name each function succinctly but accurately indicating its purpose
        relative to its package or receiver. When adding new functions, types,
        or fields, include a brief godoc if the name alone would not make the
        purpose obvious to someone unfamiliar with the feature.
  tools:
    shellcheck:
      enabled: true
    markdownlint:
      enabled: true
  auto_review:
    enabled: true
    drafts: true
  pre_merge_checks:
    custom_checks:
      - name: "Go Error Handling"
        mode: warning
        instructions: |
          Ensure proper Go error handling patterns:
          - Never ignore returned errors as `_` without clear justification
          - Errors should be wrapped with context using fmt.Errorf with %w
          - Avoid panic() except in init() or fatal conditions
          - Check for nil before dereferencing pointers

      - name: "SQL Injection Prevention"
        mode: error
        instructions: |
          Prevent SQL injection vulnerabilities:
          - NEVER concatenate or format SQL queries with values directly from user input
          - Always use placeholders for parameters in queries, preferably named (@Name)
          - Reuse prepared statements for repeated queries
          - Avoid string concatenation in SQL query construction (valid use cases should be justified)

      - name: "Excessive CSS in React Should Use Styles"
        mode: warning
        instructions: |
          React components with extensive inline CSS should use the useStyles pattern:
          - Flag inline style objects with more than 3-4 style properties
          - Suggest extracting complex styles to useStyles() or styled components
          - Inline styles are acceptable for simple, dynamic values
          - Prefer useStyles for maintainability and reusability

          ❌ Avoid:
          - Large inline style objects in JSX
          - Repeated style definitions across components

          ✅ Prefer:
          - useStyles() hook for complex styling
          - CSS modules or styled components
          - Inline styles only for dynamic values (e.g., width based on props)

      - name: "Test Coverage for New Features"
        mode: warning
        instructions: |
          New or modified functionality should include test coverage where possible:
          - New Go functions and methods should have corresponding unit tests
          - Bug fixes should include a regression test that fails without the fix
          - Pure functions (no DB/external dependencies) should always be tested
          - If a function is hard to test, consider refactoring to separate pure logic from side effects
          - Frontend components with non-trivial logic should have tests

          Exceptions (do not flag):
          - Trivial changes (renaming, formatting, comments)
          - Generated code or configuration-only changes
          - Refactors that are already covered by existing tests

      - name: "Single Responsibility and Clear Naming"
        mode: warning
        instructions: |
          Keep packages, structs, and methods focused on a single clear conceptual "chunk":
          - A package should represent one cohesive concept or purpose
          - A struct should represent a single entity in the scope of its package
          - A method should operate on a single level of abstraction, using other methods to handle more granular details
          - Names should clearly and simply communicate a single concept relative to their context

          ✅ Prefer:
          - Package names or aliases that provide context (e.g. "footypes" not "types" or "v1")
          - Brief names made of descriptive words that evoke a specific concept (e.g., "TestResultAggregator" not "Manager")
          - Methods with clear, action-oriented names (e.g., "CalculatePassRate" not "Calculate")

          ❌ Avoid:
          - Generic names like "Manager", "Handler", "Util" without specific context
          - Method names that don't indicate what they do (e.g., "Process", "Handle", "Do")
          - Repetetive naming; a package with more than a few similarly-named entities suggests refactoring into a sub-package
          - Structs with too many top-level fields (more than about 7); refactor into focused sub-types
          - Methods with more than a few parameters or results, often due to handling too many concepts that should be chunked into a type
          - Overly-broad packages or structs accumulating miscellaneous functionality

chat:
  auto_reply: true