.coderabbit.yaml

# CodeRabbit Configuration for SOLID Principles & Clean Code
# Reference: https://docs.coderabbit.ai/reference/configuration

language: en-US
tone_instructions: "Focus on SOLID principles, clean code practices, and maintainable architecture. Be thorough but constructive in feedback."

reviews:
  profile: chill
  high_level_summary: true
  poem: true
  auto_review:
    enabled: true
    drafts: false
    base_branches:
      - main
      - test

  # Pre-merge checks for SOLID principles and clean code
  pre_merge_checks:
    docstrings:
      mode: "off"
    title:
      mode: "off"
    description:
      mode: "off"
    custom_checks:
      - mode: "warning" # Change to "error" to block merges on violations
        name: "SOLID & Clean Code"
        instructions: |
          ## Single Responsibility Principle (SRP)
          - Each class/function should have only one reason to change
          - Functions should do one thing and do it well
          - Avoid god classes or functions with multiple responsibilities
          - Look for functions longer than 20 lines or classes with >200 lines
          - File-function name match: each file must export ONE primary function, and the file name must match that function's name. If a new function is added to an existing file and its name does not match the file name, flag it. The developer must create a new file named after the function instead of adding it to an existing file. Example: a function called `buildAuthConfigs` must live in `buildAuthConfigs.ts`, NOT in `getConnectors.ts`.

          ## Open/Closed Principle (OCP)
          - Classes should be open for extension but closed for modification
          - Prefer composition over inheritance
          - Use interfaces and abstract classes for extensibility
          - Avoid modifying existing code when adding new features

          ## DRY Principle (Don't Repeat Yourself)
          - Eliminate code duplication by extracting common functionality
          - Create reusable functions, components, and utilities
          - Use constants for repeated values
          - Consolidate similar logic into shared modules
          - Avoid copy-paste programming
          - Extract repeated patterns into abstractions
          - Use configuration objects instead of hardcoded values

          ## KISS Principle (Keep It Simple, Stupid)
          - Prefer simple solutions over complex ones
          - Avoid over-engineering and premature optimization
          - Use clear, readable code over clever code
          - Choose straightforward algorithms over complex ones
          - Avoid unnecessary abstractions and layers
          - Write code that's easy to understand and maintain
          - Prefer explicit over implicit behavior

          ## Clean Code Practices
          - Use descriptive names for variables, functions, and classes
          - Keep functions small and focused
          - Avoid deep nesting (max 3 levels)
          - Use meaningful comments, not obvious ones
          - Follow consistent naming conventions
          - Handle errors gracefully
          - Write self-documenting code

  # Path-specific instructions for different file types
  path_instructions:
    # API Routes
    - path: "app/api/**/*.ts"
      instructions: |
        For API routes, ensure:
        - Single responsibility per route handler
        - Proper error handling and validation
        - Use dependency injection for services
        - Follow RESTful principles
        - Validate input parameters using Zod schemas
        - Return consistent response formats
        - Use validateAuthContext() for authentication (supports both API keys and Bearer tokens)
        - DRY: Extract common validation and error handling logic
        - KISS: Use simple, straightforward request/response patterns

    # Domain Logic
    - path: "lib/**/*.ts"
      instructions: |
        For domain functions, ensure:
        - Pure functions when possible
        - Single responsibility per function
        - **File naming rule: The file name MUST match the exported function name.** If a new function is defined in a file whose name does not match, leave a review comment telling the developer to create a new file named after the function. For example, `buildAuthConfigs` must be in `buildAuthConfigs.ts`, not added to `getConnectors.ts`.
        - Proper error handling
        - Use TypeScript for type safety
        - Avoid side effects
        - Keep functions under 50 lines
        - DRY: Consolidate similar logic into shared utilities
        - KISS: Prefer simple, readable implementations over clever optimizations

    # Supabase Database Operations
    - path: "lib/supabase/**/*.ts"
      instructions: |
        For Supabase operations, ensure:
        - Follow naming convention: select*, insert*, update*, delete*, get* (for complex queries)
        - One exported function per file — the file name MUST match the exported function name
        - Import serverClient only within lib/supabase/
        - Return typed results using Tables<"table_name">
        - Handle errors gracefully
        - Use proper query building patterns

    # MCP Tools
    - path: "lib/mcp/tools/**/*.ts"
      instructions: |
        For MCP tools, ensure:
        - Use Zod schemas for input validation
        - Use resolveAccountId() for authentication
        - Use getToolResultSuccess/getToolResultError for responses
        - Share domain logic with API routes (DRY)
        - Follow registration pattern in register*Tool.ts files

    # Validation Functions
    - path: "lib/**/validate*.ts"
      instructions: |
        For validation functions, ensure:
        - Use Zod for schema validation
        - Return NextResponse on error or validated data on success
        - Export inferred types for validated data
        - Follow naming: validate<EndpointName>Body.ts or validate<EndpointName>Query.ts

    # Utils folder restrictions
    - path: "utils/**"
      instructions: |
        NEVER use the utils folder!
        - This folder is deprecated and should not be used
        - Instead, organize utilities by domain: lib/[domain]/[functionName].ts
        - Example: lib/auth/validateToken.ts instead of utils/auth.ts
        - This provides better organization and discoverability

    # Generic lib/utils restrictions
    - path: "lib/utils/**"
      instructions: |
        NEVER use a generic utils folder in lib!
        - Avoid lib/utils/ as it creates a catch-all dumping ground
        - Instead, organize by domain: lib/[domain]/[functionName].ts
        - Example: lib/validation/emailValidator.ts instead of lib/utils/validation.ts
        - Example: lib/formatting/dateFormatter.ts instead of lib/utils/formatters.ts
        - This makes code more discoverable and maintainable

  # File patterns to include/exclude
  path_filters:
    - "lib/**"
    - "app/**"
    - "!**/*.test.*"
    - "!**/*.spec.*"
    - "!**/node_modules/**"
    - "!**/dist/**"
    - "!**/build/**"
    - "!**/__tests__/**"
    - "!**/evals/**"

  # Additional checks
  commit_status: true
  review_status: true
  changed_files_summary: true
  sequence_diagrams: true
  estimate_code_review_effort: true
  assess_linked_issues: true
  related_issues: true
  related_prs: true
  suggested_labels: true
  suggested_reviewers: true

# Knowledge base configuration
knowledge_base:
  learnings:
    scope: auto
  issues:
    scope: auto
  pull_requests:
    scope: auto

# Global settings
early_access: false
enable_free_tier: true