.coderabbit.yml

# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
language: "en-US"
early_access: false
reviews:
  profile: "chill"
  # When true, CodeRabbit submits a "Request Changes" review on failing
  # checks, which blocks the PR from merging until resolved or overridden.
  request_changes_workflow: true
  high_level_summary: true
  # Place the summary in the walkthrough comment instead of editing the PR description
  # which is pretty invasive
  high_level_summary_in_walkthrough: true
  poem: true
  review_status: true
  collapse_walkthrough: false
  slop_detection:
    enabled: true
    label: "coderabbit/ai-slop"
  auto_review:
    enabled: true
    drafts: false
    # https://docs.coderabbit.ai/configuration/auto-review#auto_pause_after_reviewed_commits
    # Pause automatic reviews after this many reviewed commits on a single PR.
    # The counter resets each time the pause is lifted via "@coderabbitai resume".
    # Set to 0 to disable. Default is 5.
    # NOTE: Keep PRs in draft until they are ready for review to avoid
    # consuming CodeRabbit tokens on work-in-progress commits. Even large PRs
    # should not need more than 7 new commits than original plan if the design is sound.
    # Reviewers: try to provide a complete round of feedback in one pass so
    # the author can address everything in a single push, rather than
    # trickling comments across multiple rounds that each trigger a re-review.
    auto_pause_after_reviewed_commits: 7
  path_instructions:
    - path: "**"
      instructions: |
        - OVN-Kubernetes is a Kubernetes network plugin built on OVN/OVS.
          All Go source lives under go-controller/.
        - Do not approve PRs that add new Go dependencies without
          clear justification in the PR description.
        - Generated code (zz_generated*, vendor/) should not be
          reviewed for style — only verify it was regenerated correctly.
        - Dual-stack (IPv4+IPv6) must always be considered — flag
          changes that only handle single-stack.
        - Every feature or bug fix should include unit tests. Flag PRs
          that modify behavior without corresponding test updates.
        - E2E tests are required whenever feasible — be strict. Flag PRs
          that add or change user-facing behavior without E2E coverage.
          Do not accept "will add E2E later" — push back on the author
          to include them in the same PR.
        - Be strict: docs must be updated in the same PR when relevant.
          Features need user-facing docs, design decisions and non-obvious
          bug fixes need developer-guide updates, process changes need
          contributor-guide updates. "Docs don't exist yet" is not an
          excuse — do not accept "will add docs later"; push back —
          missing docs stall releases.
        - Commit messages should lead with "why", then relevant "what".
          Flag AI-slop commit messages stuffed with implementation details.
        - Flag merge commits (e.g. "Merge branch 'master' into ...") in the
          PR — suggest rebasing without merge commits instead.
        - Flag references to Jira, downstream issues, or product bugs —
          suggest cloning to an upstream GitHub issue and linking that instead.
        - If a PR renames, changes, or removes any code entity (flag,
          config, CRD, API, binary), flag if existing docs become stale.
        - Flag PRs over ~7000 lines (additions + deletions) or
          single-PR full OKEP / large feature implementations touching
          many unrelated components — suggest splitting into smaller,
          component-scoped PRs. Exclude legitimately large but
          tightly-scoped changes (single refactor, codegen, vendor
          update). Flag PRs that mix unrelated changes in a single
          commit.
        - PR description template: "Description", "Additional Information",
          and "How to verify it" sections must be filled — flag if empty.
          "Description" must lead with the Why (the problem being solved)
          before explaining What the PR does — flag if it jumps straight
          into implementation details without motivation.
          For trivial PRs, suggest writing "Not Applicable" in sections
          that genuinely don't apply.
          Checkboxes: for docs, either "requires docs" + "updated docs"
          or "does not require docs" must be checked. Same for tests.
          Ignore "All tests passed" — it is checked after CI completes.
    - path: "docs/**/*.md"
      instructions: |
        - Flag unclear, inaccurate, or incomplete content.
        - Flag deprecated APIs or outdated behavior.
        - Project name must be "OVN-Kubernetes" or "ovn-kubernetes". The binary
          is "ovnkube". Flag variants like "OVN Kubernetes", "ovn-kube",
          "OVNKubernetes", "ovn-k8s", "ovn-k".
        - Complex flows or multi-component interactions without diagrams:
          suggest adding one.
        - New doc page added without corresponding mkdocs.yml nav update: flag it.
        - Flag broken or dead links, wrong anchors, outdated URLs.
        - If a code entity (CRD, field, flag, binary) was renamed or removed,
          flag stale references in docs.
    - path: "go-controller/pkg/crd/**"
      instructions: |
        - k8s.ovn.org CRD API types and generated client code.
        - zz_generated* or apis/ files are codegen output — review correctness
          only, not style.
        - Hand-written types (types.go, spec.go, etc.): verify godoc, JSON tags,
          kubebuilder markers, deepcopy.
        - New/changed fields must have JSON tags and kubebuilder validation markers.
        - Flag unbounded fields: lists/maps without MaxItems, strings
          without MaxLength — these need size limits to prevent abuse.
        - Flag schema changes without Helm CRD manifest update or codegen re-run
          (update-codegen.sh).
        - API changes must always be backwards compatible and must not
          break users — flag removals, type changes, or new required fields.
        - Any API change must include API reference doc update.
        - New API must be added to the API reference index page.
        - CEL validation: flag missing CEL rules where needed, unanchored
          regex, missing enums, absent dual-stack guards, incomplete
          cross-field rules.
        - Flag missing CRD metadata: short names, printer columns, descriptions.
        - API field naming must be finalized before merge — flag ambiguous or
          inconsistent names.
        - Follow kubernetes-sigs/kube-api-linter (KAL) conventions:
          optional/required markers, SSA listType tags, conditions format,
          no raw integers (use resource.Quantity or metav1.Duration).
    - path: "go-controller/**/*_test.go"
      instructions: |
        - Flag time.Sleep in tests — use gomega Eventually/Consistently
          for async assertions instead.
        - Flag os.Setenv — use t.Setenv (auto-restores on cleanup) to
          avoid env pollution across tests.
        - Flag missing cleanup: FakeOVN, fake clients, and other test
          fixtures must be shut down or cleaned up (defer close/stop).
        - Tests requiring root/cap_net_admin must use
          ovntest.OnSupportedPlatformsIt instead of ginkgo.It — flag if missing.
        - Flag shared mutable state between test cases — common source
          of data races with fake clients and concurrent reconcilers.
        - Flag unnecessary deep nesting — tests should be structured
          for easy addition of new cases (prefer table-driven or flat
          ginkgo entries over deeply nested contexts).
        - Flag duplicate tests covering the same scenario.
        - Flag missing edge cases: nil inputs, empty lists, dual-stack,
          error paths, and boundary conditions.
        - Flag test helper/utility duplication — check if similar
          helpers already exist in pkg/testing/ or other test files
          in the same package before adding new ones.
        - Prefer focused It blocks that each test a single piece of logic.
          Suggest breaking complex multi-step unit tests into multiple It
          blocks, unless the setup/teardown cost makes that impractical.
          When an It block must contain multiple steps, suggest using
          ginkgo.By to document each step.
        - If multiple It blocks in the same Describe/Context repeat the
          same setup or teardown logic, suggest extracting it into
          BeforeEach/AfterEach.
        - Prefer reusable helpers for libovsdb nb/sb test fixtures
          (e.g. LogicalRouter, LogicalSwitch) over inline struct
          literals copied across tests — keeps tests concise and
          readable. Some older tests do this; new code should not.
    - path: "go-controller/pkg/**/*.go"
      instructions: |
        - Concurrency is the #1 bug source — scrutinize lock ordering,
          deferred unlocks, deadlock potential, and shared state between
          controllers. Flag unprotected concurrent map/slice access.
        - Flag missing nil checks on OVS/OVN DB results, optional
          Kubernetes fields, and interface type assertions.
        - Flag resource leaks: unclosed channels, namespace handles,
          informer factories, or goroutines without shutdown paths.
        - Use klog for logging (not fmt.Print or log.*). Flag misuse
          of log levels (e.g. klog.Infof for errors instead of klog.Errorf or klog.Warningf,
          klog.V(5) for important events that should be at lower verbosity).
        - Flag bare error returns (return err) without adding
          context. Errors should be wrapped with fmt.Errorf to add
          context. Use %w when the caller should be able to inspect
          the underlying error with errors.Is/errors.As. Use %v
          when the underlying error is an implementation detail that
          should not be exposed as part of the API.
        - Flag hardcoded values — these must come from
          config or constants.
        - Consider performance at scale — flag code that may degrade
          with many nodes, pods, or network policies (e.g. unbounded
          list calls, full resyncs, O(n²) loops, unindexed lookups).
        - Flag err := inside nested blocks that shadow outer err —
          common source of silently lost errors, especially in long
          functions.
        - Verify boolean logic carefully — flag inverted conditions,
          wrong negations, && vs & operator confusion.
        - Controller restart/recreation paths must clean up old state
          (caches, goroutines, watchers) — flag if missing.
        - Flag bare integers passed as time.Duration — must use
          explicit units (e.g. 10*time.Second, not 10).
        - Flag copy-paste code with un-updated variable names,
          duplicated function calls, or stale references.
        - Cleanup/delete paths must continue on partial failures —
          collect errors with kerrors.NewAggregate or errors.Join
          and return them all, not bail on the first error.
        - Utility/helper functions belong in pkg/util/ or the relevant
          package's utils. Flag when helpers are added inline instead
          of to the shared utils package, or when existing utils are
          duplicated.
        - Refactors must clearly state the exact benefits they bring
          to the project in the PR description. Remind the author to
          announce significant refactors in community meetings, Slack,
          or the mailing list.
        - Feature deprecations or removals: same requirement — must
          be announced to the community and documented before merge.
        - Flag comments that merely restate what the code does
          (e.g. "// set a to b" above "a = b", "// return the error"
          above "return err", "// create the pod" above CreatePod()).
          Comments should explain why, not what. Only non-obvious
          intent, trade-offs, or constraints warrant a comment.
    - path: "test/e2e/**"
      instructions: |
        - E2E tests must be backwards compatible — adding tests for
          new features must not break existing tests for users who
          don't use the new feature.
        - Stop overcomplicated ginkgo nesting — prefer flat structure
          with ginkgo DescribeTable/Entry over deeply nested
          Context/When/It blocks.
        - Flag duplicate tests — new tests covering scenarios already
          tested (implicitly or explicitly) elsewhere in the suite.
        - Flag test helpers duplicated across files — shared helpers
          belong in test/e2e/util.go or a dedicated utils file.
        - Adding or refactoring tests must not lose coverage for
          existing scenarios — flag if existing test cases are removed
          or narrowed without justification.
        - Tests must be provider-agnostic — flag hardcoded network
          names, node access methods, container runtime calls, or
          assumptions that only work on KIND. Tests should run on
          any provider. Use the infraprovider API and shared test
          utilities for all infra interactions.
    - path: "go-controller/pkg/ovn/**"
      instructions: |
        - Startup/sync paths: flag changes to Sync*, Start*, or
          reconciliation loops that may delete resources owned by
          another controller or not yet populated.
        - UDN controller lifecycle: flag shared state (address sets,
          LB groups, caches) that assumes a single controller instance
          — UDN recreation can leave stale references.
        - EgressIP: verify both add and remove/failover paths — most
          bugs are stale SNAT/LRP entries persisting after cleanup.
        - Lock ordering: flag inconsistent lock acquisition order
          (node locks, namespace locks) — use deterministic ordering.
        - Channel/goroutine lifecycle: stopChan must be initialized
          before goroutines reference it — flag double-close and
          nil-channel races in Stop() methods.
        - Services/LB: flag changes to serviceNeedsUpdate or LB
          template logic that don't handle protocol set changes.
        - Be strict: OVN DB objects must use proper DbObjectIDs with
          DB indexes for lookups and ownership — flag random or
          ad-hoc external IDs. All objects must have proper ownership
          tracked via ExternalIDs so they can be synced and cleaned.
    - path: "go-controller/pkg/node/**"
      instructions: |
        - Channel and goroutine lifecycle (stopChan, closeChan) are
          repeat sources of panics and deadlocks — scrutinize any
          controller start/stop or attach/detach change.
        - Shared informer cache mutation: always DeepCopy() before
          modifying objects from the cache — flag direct mutation.
        - DPU-mode code paths are routinely missed — new gateway or
          bridge logic needs an explicit "does this apply in DPU
          mode?" check.
        - UDN gateway flows have the highest revert rate — changes to
          nftables, IP rules, or OpenFlow for UDN need strong E2E
          coverage before merge.
        - Netlink resource cleanup: flag missing Close()/defer on
          netns.Get() or netlink.Handle — causes namespace handle
          and VRF leaks.
        - OpenFlow correctness: flag wrong byte extraction, wrong
          protocol prefix (ip vs ip6), wrong port (service port vs
          endpoint port) in flow match/action expressions.
    - path: "go-controller/pkg/libovsdb/**"
      instructions: |
        - Predicates in CreateOrReplace*WithPredicate: flag predicates
          that are too narrow (miss stale objects), too broad (clobber
          unrelated objects), or miss ownership checks.
        - Typed-nil interface trap: flag *Model passed through
          interface{} without nil check on the concrete pointer —
          causes panics inside libovsdb.
        - Context propagation: every libovsdb op that waits for cache
          consistency must have a context with timeout — flag use of
          context.Background() or context.TODO() in production paths.
        - onModelUpdatesAllNonDefault silently drops zero-value fields
          — flag if a field legitimately needs to be reset to its
          zero value (use explicit field lists instead).
        - DB ordering: flag code that assumes ovn-controller has
          processed prior NB/SB changes — require hv_cfg/nb_cfg
          synchronization barriers.
        - Delete/update ops must verify the target object belongs to
          the expected parent (e.g. static route on the right router).
        - Respect OVN schema root/non-root references — non-root
          objects (e.g. address sets) must be unreferenced before
          deletion (e.g. remove from ACLs first). Flag operations
          that delete referenced objects without cleanup.
        - Changes to this package without unit tests: flag it.
  path_filters:
    - "!**/vendor/**"
  # https://docs.coderabbit.ai/pr-reviews/pre-merge-checks
  # NOTE: "@coderabbitai ignore pre-merge checks" overrides ALL failing
  # checks on the PR, not individual ones. There is no per-check override.
  # Authors should fix all fixable checks before using the override, and
  # document justification for each ignored check in the PR description.
  pre_merge_checks:
    # When true, only requested reviewers (not the PR author) can override
    # failing pre-merge checks via the "Ignore" checkbox or the
    # "@coderabbitai ignore pre-merge checks" command. Overrides are logged
    # for auditability. When false, anyone (including the author) can override.
    override_requested_reviewers_only: false
    docstrings:
      mode: "warning"
      threshold: 80
    title:
      mode: "error"
      requirements: >-
        Title should follow the project convention: 'subcomponent: short description'.
        Use imperative mood, as if giving orders to the codebase to change its
        behaviour, e.g. 'make xyzzy do frotz' instead of 'makes xyzzy do frotz'
        or 'changed xyzzy to do frotz'.
        Use lowercase except for proper nouns, acronyms, and code identifiers.
        Keep under 72 characters. Examples: 'networkpolicy: validate ipBlock strictly',
        'egressip: fix frequently rebalancing IPs'.
    description:
      mode: "error"
    issue_assessment:
      mode: "error"
    # https://docs.coderabbit.ai/pr-reviews/custom-checks
    custom_checks:
      - name: "Unit Tests for Go Changes"
        mode: "error"
        instructions: >-
          If Go source files (*.go) under go-controller/pkg/ or
          go-controller/cmd/ are added or modified (excluding files
          under go-controller/vendor/ and *_test.go files), check
          whether corresponding *_test.go files are also added or
          modified in this PR. Exclude documentation-only, CI, or
          script changes.

          Fail if production Go code changed with no test file changes.
          Pass only if no production Go files changed, or if test files
          are included alongside the production changes.

          If failing, advise the author: if there is a valid reason for
          not including tests (e.g. existing tests already cover the
          change, the change is trivial, or testing is infeasible),
          document that justification in the PR description under
          "How to verify it" and then, once all other pre-merge checks
          are also addressed, use "@coderabbitai ignore pre-merge
          checks" to override.
      - name: "E2E Tests for Feature Changes"
        mode: "error"
        instructions: >-
          If Go source files (*.go) under go-controller/pkg/ or
          go-controller/cmd/ are added or modified in a way that adds
          new user-facing behavior or changes existing user-facing
          behavior (excluding vendor/, *_test.go, pure refactors with
          no behavioral change, and internal-only changes), check
          whether files under test/e2e/ are also added or modified in
          this PR.

          Fail if user-facing behavior changed with no E2E test changes.
          Pass only if no user-facing behavior changed, or if E2E test
          files are included.

          If failing, advise the author: if E2E tests are genuinely not
          feasible for this change, document the justification in the
          PR description under "How to verify it" and then, once all
          other pre-merge checks are also addressed, use
          "@coderabbitai ignore pre-merge checks" to override.
      - name: "Docs for Feature and Behavior Changes"
        mode: "error"
        instructions: >-
          If a PR introduces a new feature, implements an OKEP, changes
          user-facing behavior, fixes a significant bug that alters
          expected behavior, or modifies architecture or control flows,
          check whether files under docs/ are also added or modified.

          Pass if the change is a minor bug fix, pure refactor,
          test-only change, CI/infra change, or internal-only change
          that does not affect user-facing behavior or architecture.
          Also pass if docs/ files are included.

          Fail if the PR adds or changes user-facing behavior,
          architecture, or flows without any docs/ changes.

          If the PR establishes a new coding pattern, convention, or
          precedent (e.g. how controllers should be structured, how
          APIs should be designed, how errors should be handled), the
          developer guide (docs/developer-guide/) or contributor guide
          (CONTRIBUTING.md) must be updated to document the new
          convention. Fail if a new pattern is introduced without
          documenting it for future contributors.

          Fail if a new doc page (*.md) is added under docs/ but the
          mkdocs.yml nav section is not updated to include it.

          If failing, advise the author: if docs are genuinely not
          required for this change, document the reasoning in the PR
          description and then use "@coderabbitai ignore pre-merge
          checks" to override.
      - name: "Stale Project Docs and Config"
        mode: "error"
        instructions: >-
          Check whether changes in this PR make any of the following
          project files stale or inaccurate: .coderabbit.yml (path
          instructions, pre-merge checks, global review instructions),
          CONTRIBUTING.md, AGENTS.md, docs/developer-guide/,
          docs/governance/, ARCHITECTURE.md, CODEOWNERS, or mkdocs.yml
          navigation entries.

          Examples of staleness:

          1. A file or directory is renamed, moved, or deleted but is
          still referenced by path in .coderabbit.yml
          path_instructions or CODEOWNERS.

          2. A process described in CONTRIBUTING.md is changed by the
          PR but the doc is not updated.

          3. A code entity (CRD, flag, binary, config key) is renamed
          or removed but still referenced in docs or AGENTS.md.

          4. Architecture or component boundaries change but
          ARCHITECTURE.md is not updated.

          Fail if any project docs or config become stale due to the
          changes. Pass only if the PR does not introduce any such
          staleness, or if the affected docs/config files are also
          updated in this PR.

          If failing, advise the author: update the affected
          docs/config files in this PR, or if the flagged staleness is
          a false positive, explain why in a PR comment and use
          "@coderabbitai ignore pre-merge checks" to override.
      - name: "Test Structure and Quality"
        mode: "warning"
        instructions: >-
          Review test code (go-controller/**/*_test.go and test/e2e/**)
          for these quality requirements:

          1. Single responsibility: each It block should test one
          specific behavior. Flag tests that assert multiple unrelated
          behaviors.

          2. Setup and cleanup: tests should use BeforeEach/AfterEach
          for setup and cleanup. Flag tests that create resources
          without cleanup, especially cluster-scoped resources.
          FakeOVN, fake clients, and test fixtures must be shut down
          or cleaned up.

          3. Timeouts: operations that interact with the cluster must
          include appropriate timeouts. Flag indefinite waits or
          missing timeouts on Eventually/Consistently calls.

          4. Assertion messages: assertions should include meaningful
          failure messages that help diagnose what went wrong.
          Bad: Expect(err).NotTo(HaveOccurred()).
          Good: Expect(err).NotTo(HaveOccurred(), "failed to create
          test pod").

          5. Flag time.Sleep in tests: use gomega
          Eventually/Consistently for async assertions instead.

          6. Flag os.Setenv in tests: use t.Setenv which auto-restores
          on cleanup to avoid env pollution across tests.

          7. Flag bare t.Fatal(err) or t.Fatalf calls that only pass
          the error without describing what operation failed. Must
          include context, e.g. t.Fatalf("failed to create pod: %v",
          err).

          8. Tests requiring root/cap_net_admin must use
          ovntest.OnSupportedPlatformsIt instead of ginkgo.It.

          9. E2E tests must be provider-agnostic: flag hardcoded
          network names, node access methods, container runtime calls,
          or assumptions that only work on KIND.
      - name: "Go Code Quality"
        mode: "warning"
        instructions: >-
          Check new or modified Go code (excluding vendor/ and
          *_test.go) for these objective issues:

          1. Flag use of fmt.Print, fmt.Println, log.Print, log.Fatal,
          or log.* for logging. The project uses klog exclusively.

          2. Flag bare error returns without context wrapping. Errors
          must be wrapped with fmt.Errorf("...: %w", err). Use %w when
          the caller should be able to inspect the underlying error
          with errors.Is/errors.As. Use %v when the underlying error
          is an implementation detail that should not be exposed as
          part of the API.

          3. Flag bare integers passed as time.Duration without
          explicit units. Must use e.g. 10*time.Second, not 10.

          4. Flag err := inside nested blocks that shadow an outer err
          variable, silently losing errors.

          5. Flag changes that only handle IPv4 without considering
          IPv6. Dual-stack (IPv4+IPv6) must always be considered.

          6. Flag unprotected concurrent map or slice access. Shared
          state between goroutines must be guarded by locks.

          7. Flag missing Close()/defer on netns.Get() or
          netlink.Handle which cause namespace handle and VRF leaks.
      - name: "Commit Message Quality"
        mode: "error"
        instructions: >-
          Check commit messages and structure in this PR for quality:

          1. Each commit must be a logical, self-contained unit of
          change. Flag commits that bundle unrelated changes together.

          2. Subject line should be concise and descriptive, under 72
          characters. Use imperative mood, as if giving orders to the
          codebase to change its behaviour, e.g. "make xyzzy do frotz"
          instead of "makes xyzzy do frotz" or "changed xyzzy to do
          frotz". Prefix with the affected component when scoped
          (e.g. "egressip: fix frequently rebalancing IPs",
          "networkpolicy: validate ipBlock strictly").

          3. Body must be present and explain why the change is needed,
          not just what was changed. The code diff already shows what.

          4. Flag vague, uninformative, or generic messages like "fix",
          "update", "wip", "changes", "misc", or "address review
          comments" that provide no meaningful context. Review feedback
          should be squashed into the relevant logical commit, not
          added as a separate "address review comments" commit.

          5. Flag overly verbose commit messages that read like
          AI-generated changelogs — listing every function name,
          variable, or line changed. Commit messages should explain
          intent at a high level, not narrate the diff.

          6. No merge commits (e.g. "Merge branch 'master' into ..."
          or "Merge remote-tracking branch ..."). The author should
          rebase onto the target branch instead. Run "git rebase
          origin/master" to replace merge commits with a linear
          history.

          Fail if any commit violates any of the above points.
          Pass only if all commits satisfy all 6 criteria.
      - name: "No Downstream References"
        mode: "error"
        instructions: >-
          Check the PR title, description, and commit messages for
          references to Jira tickets (e.g. JIRA-1234, OCPBUGS-1234,
          CORENET-1234), downstream issue trackers, or product-specific
          bug IDs.

          Fail if any downstream reference is found without a
          corresponding upstream GitHub issue link. Pass only if no
          downstream references are found, or if an upstream GitHub
          issue is linked alongside.

          The author should clone the issue to an upstream GitHub issue
          and link that instead. If failing, advise the author: create
          a corresponding upstream GitHub issue, link it in the PR,
          and remove or replace the downstream reference. Use
          "@coderabbitai ignore pre-merge checks" only if the
          downstream reference is justified and explained in the PR
          description.
      - name: "Large PR Warning"
        mode: "warning"
        instructions: >-
          Flag PRs that are excessively large or difficult to review.

          Fail if the PR changes more than 7000 lines (additions +
          deletions), or if it implements an entire OKEP or large
          feature end-to-end in a single PR touching many unrelated
          components.

          Pass if the PR is under 7000 lines, or if it is large but
          all changes are tightly related (e.g. a single large
          refactor, codegen output, or vendor update).

          Large PRs are a nightmare for reviewers, lead to shallow
          reviews, and increase the risk of bugs slipping through.
          Advise the author to split the work into smaller, focused
          PRs with functional changes scoped to individual components
          or logical steps. Each PR should be independently reviewable
          and mergeable.
      - name: "AI-Generated Code Smell"
        mode: "error"
        instructions: >-
          Flag signs of AI-generated code that was not properly
          reviewed by the author before submission:

          1. Obvious comment slop: comments that merely restate the
          code they annotate (e.g. "// set a to b" above "a = b",
          "// return the error" above "return err", "// create the
          pod" above "CreatePod()"). These add no value and clutter
          the codebase.

          2. Large blocks of unit tests that appear auto-generated
          and are unrelated to the functional changes in the PR. Flag
          if the PR adds hundreds of lines of tests for code that was
          not modified in this PR.

          3. Overly verbose or boilerplate-heavy code that follows
          repetitive patterns suggesting template expansion rather
          than thoughtful implementation.

          4. Comments or variable names that reference AI tools or
          prompts (e.g. "as suggested by", "generated by", "TODO:
          verify this AI suggestion").

          Fail if any of the above 4 patterns are found in new or
          modified code. Pass only if the code is clean, comments add
          genuine value, and test changes are proportional to the
          functional changes.
      - name: "AI Config Authorship Restriction"
        mode: "error"
        instructions: >-
          If the PR modifies .coderabbit.yml, any **/AGENTS.md, or
          any **/ARCHITECTURE.md file, check whether the PR author's
          GitHub handle is listed in MAINTAINERS.md as a current
          maintainer. These files control AI review behavior, agent
          instructions, and architectural documentation — changes
          from external contributors or non-SMEs risk degrading
          review quality or introducing security issues.

          Fail if the PR author is not listed in MAINTAINERS.md and
          the PR modifies .coderabbit.yml, any **/AGENTS.md, or any
          **/ARCHITECTURE.md file. Advise the author that these
          files may only be changed by recognized maintainers listed
          in MAINTAINERS.md.

          Pass only if none of those files are modified, or the PR
          author is listed in MAINTAINERS.md as a current maintainer.
chat:
  auto_reply: true