Add Code Rabbit AI config

[mvandeberg]

Summary by CodeRabbit

• Chores
  • Added internal configuration file for development tooling and automation settings.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

A new configuration file .coderabbit.yaml has been added to specify CodeRabbit settings including language preferences, review automation features, visualization options for code review reports, pre-merge validation rules with docstring coverage requirements, path-based exclusion filters, and C++ header-specific documentation standards.

Changes

Cohort / File(s)	Summary
CodeRabbit Configuration \.coderabbit\.yaml	Introduces configuration file with review automation settings, visualization preferences (summaries, sequence diagrams, poems), pre-merge checks for docstring coverage, path exclusions for common non-review directories, and C++ header documentation requirements

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 ✨ A config file hops into place,
With settings that bring joy and grace,
C++ headers now shine so bright,
Docstrings dance through the night,
CodeRabbit's vision takes flight! 📋

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a CodeRabbit configuration file (.coderabbit.yaml) with AI settings and pre-merge checks.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @.coderabbit.yaml:
- Around line 48-58: Reword the documentation guidance under the
"**/*.{cpp,hpp}" instructions to improve clarity: change "which gives a high
level overview of how the implementation works." to "Provide a high-level
overview of the implementation."; tighten the next sentence to "Use single-line
// comments sparingly to explain the why (not the what or how) when it is
non-obvious." and clarify the final sentence to "Docstrings are required for all
classes in public headers within non-detail namespaces; warn when a class or
function lacks a docstring or has an insufficient one." Ensure these phrases
replace the current lines in the instructions block so the intent and grammar
are clearer.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Minor grammatical improvement in instructions.

Line 51 has awkward phrasing that could be clarified for better readability.

Suggested fix

  path_instructions:
    - path: "**/*.{cpp,hpp}"
      instructions: |
        Documentation Best Practices
-        - The top of the file after the includes, put a nice /* */ section
+        - At the top of the file after the includes, put a nice /* */ section
          which gives a high level overview of how the implementation works.
        - Single line // comments are to be used sparingly and judiciously
          which explain the why (not the what or how) when it is non-obvious.
        - Docstrings are required for all classes in public headers in
          non detail namespaces. They are used for generating the Documentation
          website. Please give warnings for any class or function that does
          not have a docstring or has an insufficient docstring.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	- path: "**/*.{cpp,hpp}"
	instructions: |
	Documentation Best Practices
	- The top of the file after the includes, put a nice /* */ section
	which gives a high level overview of how the implementation works.
	- Single line // comments are to be used sparingly and judiciously
	which explain the why (not the what or how) when it is non-obvious.
	- Docstrings are required for all classes in public headers in
	non detail namespaces. They are used for generating the Documentation
	website. Please give warnings for any class or function that does
	not have a docstring or has an insufficient docstring.
	- path: "**/*.{cpp,hpp}"
	instructions: |
	Documentation Best Practices
	- At the top of the file after the includes, put a nice /* */ section
	which gives a high level overview of how the implementation works.
	- Single line // comments are to be used sparingly and judiciously
	which explain the why (not the what or how) when it is non-obvious.
	- Docstrings are required for all classes in public headers in
	non detail namespaces. They are used for generating the Documentation
	website. Please give warnings for any class or function that does
	not have a docstring or has an insufficient docstring.

🤖 Prompt for AI Agents

In @.coderabbit.yaml around lines 48 - 58, Reword the documentation guidance
under the "**/*.{cpp,hpp}" instructions to improve clarity: change "which gives
a high level overview of how the implementation works." to "Provide a high-level
overview of the implementation."; tighten the next sentence to "Use single-line
// comments sparingly to explain the why (not the what or how) when it is
non-obvious." and clarify the final sentence to "Docstrings are required for all
classes in public headers within non-detail namespaces; warn when a class or
function lacks a docstring or has an insufficient one." Ensure these phrases
replace the current lines in the instructions block so the intent and grammar
are clearer.