.coderabbit.yaml

# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
language: en-US

reviews:
  request_changes_workflow: false
  high_level_summary: true
  poem: false

  path_instructions:
    - path: "**/*.go"
      instructions: |
        Scan for hardcoded occurrences of the string literals `Thunder` or `ThunderID` in this file.
        For each occurrence, flag it and ask: **"Is this hardcoded brand name intentional?"**
        If it can be replaced, suggest using a named constant or a value sourced from runtime config
        (e.g., an environment variable or a config struct field) rather than a raw string literal.
        Do not flag occurrences inside comments or import paths.

        Check whether this change introduces or modifies any of the following:
        - Public REST/OAuth2/OIDC API endpoints (new routes, changed request/response schemas, new query/path/header parameters)
        - Configuration options (YAML/TOML keys, environment variables, deployment settings)
        - Authentication or authorization flows (new grant types, new authenticators, changed flow steps)
        - User-facing behavior changes (new features, changed defaults, removed capabilities)
        - SDK-impacting changes (new or changed client-facing interfaces, token formats, scopes)

        If ANY of the above are detected and the PR does NOT include corresponding updates
        under `docs/` (content pages in `docs/content/`, API references in `docs/content/apis.mdx`,
        guide updates in `docs/content/guides/`, or SDK docs in `docs/content/sdks/`),
        flag this as a **major issue** with the following message:

        "🔴 **Documentation Required**: This PR introduces a user-facing change
        (e.g., new/modified API endpoint, configuration option, authentication flow, or SDK behavior)
        but does not include corresponding documentation updates under `docs/`.
        Please update the relevant documentation before merging."

        Be specific about WHAT documentation is missing — name the endpoint, config key,
        or feature that needs to be documented and suggest which doc file should be updated or created.

    - path: "**/*.ts"
      instructions: |
        Scan for hardcoded occurrences of the string literals `Thunder` or `ThunderID` in this file.
        For each occurrence, flag it and ask: **"Is this hardcoded brand name intentional?"**
        If it can be replaced, suggest reading the value from the app's config system using the
        `useConfig` hook (e.g., `const { productName } = useConfig();`) rather than a raw string literal.
        Do not flag occurrences inside comments, type names, or import paths.

    - path: "**/*.tsx"
      instructions: |
        Scan for hardcoded occurrences of the string literals `Thunder` or `ThunderID` in this file.
        For each occurrence, flag it and ask: **"Is this hardcoded brand name intentional?"**
        If it can be replaced, suggest reading the value from the app's config system using the
        `useConfig` hook (e.g., `const { productName } = useConfig();`) rather than a raw string literal.
        For JSX string content, prefer the `<ProductName />` component if it is available in this context.
        Do not flag occurrences inside comments, type names, or import paths.

    - path: "docs/**"
      instructions: |
        Scan for hardcoded occurrences of the string literals `Thunder` or `ThunderID` in prose, headings,
        code callouts, or link text.
        For each occurrence, flag it and ask: **"Is this hardcoded brand name intentional?"**
        If it refers to the product name, suggest replacing it with the `<ProductName />` MDX component.
        If it appears in a repository URL or link, suggest replacing it with the `<RepoLink />` MDX component.
        Do not flag occurrences inside fenced code blocks that demonstrate real command-line output or
        literal configuration values where the exact string is required.

        Review documentation changes for:
        - Technical accuracy: do code examples and parameter descriptions match the actual implementation in this PR?
        - Completeness: are all new endpoints, config keys, and behavioral changes covered?
        - Consistency: does the style match existing documentation?
        - Broken links or references to renamed/removed entities.

  auto_review:
    enabled: true
    ignore_title_keywords:
      - "WIP"
      - "DO NOT MERGE"
    base_branches:
      - main

  path_filters:
    - "!**/*_mock.go"
    - "!**/mock_*.go"
    - "!**/*.pb.go"
    - "!**/node_modules/**"
    - "!docs/__backup__/**"