chore: optimize CodeRabbit configuration for Go project

- Removed irrelevant language instructions (Python, Solidity, JS/TS, HTML, CSS)
- Removed unused linters (eslint, phpstan, detekt, etc.)
- Added specific instructions for Go source code (error handling, concurrency, idiomatic code)
- Added specific instructions for Go test files
- Configured path filters to ignore Go vendor and SQLite data directories

Author: Atharva0506

.coderabbit.yaml

@@ -7,20 +7,6 @@ language: en
 # Enable experimental features (currently not using any specific early_access features)
 early_access: true
 
-# Multi-repo analysis: lets CodeRabbit use other repositories as context when reviewing PRs.
-# Most useful when linking tightly coupled repos, e.g.:
-#   - Frontend ↔ backend (API contract changes)
-#   - Service ↔ shared library (ripple-effect on consumers)
-#   - Microservices sharing a database schema
-# Avoid configuring this at org level — link only the repos relevant to this project.
-# See: https://docs.coderabbit.ai/knowledge-base/multi-repo-analysis
-#
-# To enable, uncomment the block below and replace the example values with your repos.
-# knowledge_base:
-#   linked_repositories:
-#     - repository: "AOSSIE-Org/backend-api"
-#       instructions: "Contains REST API endpoints and database models"
-
 chat:
   # CodeRabbit will automatically respond to @coderabbitai mentions in PR comments
   auto_reply: true
@@ -92,19 +78,14 @@ reviews:
 
   # Exclude these paths from reviews (build artifacts and dependencies)
   path_filters:
-    - "!**/node_modules/**" # npm dependencies
-    - "!**/android/**" # Native Android build files
-    - "!**/ios/**" # Native iOS build files
-    - "!**/.expo/**" # Expo build cache
-    - "!**/.expo-shared/**" # Expo shared config
+    - "!**/vendor/**" # Go dependencies
     - "!**/dist/**" # Build output
+    - "!**/data/**" # SQLite database volume
 
   # Use the following tools when reviewing
   tools:
     shellcheck:
       enabled: true
-    ruff:
-      enabled: true
     markdownlint:
       enabled: true
     github-checks:
@@ -114,38 +95,17 @@ reviews:
       enabled: true
       enabled_only: false
       level: default
-    biome:
-      enabled: true
-    hadolint:
-      enabled: true
-    swiftlint:
-      enabled: true
-    phpstan:
-      enabled: true
-      level: default
     golangci-lint:
       enabled: true
     yamllint:
       enabled: true
     gitleaks:
       enabled: true
-    checkov:
-      enabled: true
-    detekt:
-      enabled: true
-    eslint:
-      enabled: true
 
   # Apply the following labels to PRs
   labeling_instructions:
-    - label: Python Lang
-      instructions: Apply when the PR/MR contains changes to python source-code
-    - label: Solidity Lang
-      instructions: Apply when the PR/MR contains changes to solidity source-code
-    - label: Typescript Lang
-      instructions: Apply when the PR/MR contains changes to javascript or typescript source-code
-    - label: Ergoscript Lang
-      instructions: Apply when the PR/MR contains changes to ergoscript source-code
+    - label: Go Lang
+      instructions: Apply when the PR/MR contains changes to go source-code
     - label: Bash Lang
       instructions: >-
         Apply when the PR/MR contains changes to shell-scripts or BASH code
@@ -172,130 +132,34 @@ reviews:
     - Confirm that copyright years are up-to date whenever a file is changed
     - Point out redundant obvious comments that do not add clarity to the code
     - Ensure that comments are concise and suggest more concise comment statements if possible
-    - Discourage usage of verbose comment styles such as NatSpec
     - Look for code duplication
     - Suggest code completions when:
         - seeing a TODO comment
         - seeing a FIXME comment
 
   # Custom review instructions for specific file patterns
   path_instructions:
-    # TypeScript/JavaScript files
-    - path: "**/*.{ts,tsx,js,jsx}"
-      instructions: |
-        NextJS:
-        - Ensure that "use client" is being used
-        - Ensure that only features that allow pure client-side rendering are used
-        - NextJS best practices (including file structure, API routes, and static generation methods) are used.
-      
-        TypeScript:
-        - Avoid 'any', use explicit types
-        - Prefer 'import type' for type imports
-        - Review for significant deviations from Google JavaScript style guide. Minor style issues are not a priority
-        - The code adheres to best practices associated with React
-        - The code adheres to best practices associated with React PWA
-        - The code adheres to best practices associated with SPA
-        - The code adheres to best practices recommended by lighthouse or similar tools for performance
-        - The code adheres to best practices associated with Node.js
-        - The code adheres to best practices recommended for performance
-
-        Security:
-        - No exposed API keys or sensitive data
-        - Use expo-secure-store for sensitive storage
-        - Validate deep linking configurations
-        - Check for common security vulnerabilities such as:
-          - SQL Injection
-          - XSS (Cross-Site Scripting)
-          - CSRF (Cross-Site Request Forgery)
-          - Insecure dependencies
-          - Sensitive data exposure
-
-        Internationalization:
-        - User-visible strings should be externalized to resource files (i18n)
-
-    # HTML files
-    - path: "**/*.html"
+    # Go files
+    - path: "**/*.go"
       instructions: |
-        Review the HTML code against the google html style guide and point out any mismatches. Ensure that:
-        - The code adheres to best practices recommended by lighthouse or similar tools for performance
-
-    # CSS files
-    - path: "**/*.css"
-      instructions: |
-        Review the CSS code against the google css style guide and point out any mismatches. Ensure that:
-        - The code adheres to best practices associated with CSS.
-        - The code adheres to best practices recommended by lighthouse or similar tools for performance.
-        - The code adheres to similar naming conventions for classes, ids.
-
-    # Python files
-    - path: "**/*.{py}"
-      instructions: |
-        Python:
-        - Check for major PEP 8 violations and Python best practices. 
-
-    # Solidity Smart Contract files
-    - path: "**/*.sol"
-      instructions: |
-        Solidity:
-        - Review the Solidity contracts for security vulnerabilities and adherence to best practices.
-        - Ensure immutability is used appropriately (e.g., `immutable` and `constant` where applicable).
-        - Ensure there are no unbounded loops that could lead to gas exhaustion.
-        - Verify correct and explicit visibility modifiers for all state variables and functions.
-        - Flag variables that are declared but used only once or are unnecessary.
-        - Identify potential gas optimization opportunities without compromising readability or security.
-        - Verify that any modification to contract logic includes corresponding updates to automated tests.
-        - Ensure failure paths and revert scenarios are explicitly handled and validated.
-        - Validate proper access control enforcement (e.g., Ownable, RBAC, role checks).
-        - Ensure consistent and correct event emission for all state-changing operations.
-        - Confirm architectural consistency with existing contracts (no unintended storage layout changes unless clearly documented).
-        - Flag major feature additions or architectural changes that were implemented without prior design discussion (if applicable).
-        - Flag pull requests that mix unrelated changes or multiple concerns in a single submission.
-        - Ensure security-sensitive logic changes are not introduced without adequate test coverage.
-        - Review for common smart contract vulnerabilities, including but not limited to:
-            - Reentrancy
-            - Improper input validation
-            - Access control bypass
-            - Integer overflows/underflows (if using unchecked blocks)
-            - Front-running risks where applicable
-
-
-    # Javascript/Typescript test files
-    - path: "**/*.test.{ts,tsx,js,jsx}"
+        Go:
+        - Check for idiomatic Go code and adherence to Effective Go principles.
+        - Ensure proper error handling is performed (no ignored errors).
+        - Validate concurrency safety (proper use of goroutines, channels, sync package).
+        - Ensure data persistence queries (e.g. SQLite) use parameterized queries to prevent SQL injection.
+        - Verify that context is propagated through function calls, especially for database operations and outgoing requests.
+        - Check that API handlers handle edge cases and send proper HTTP status codes.
+
+    # Go test files
+    - path: "**/*_test.go"
       instructions: |
         Review test files for:
-        - Comprehensive coverage of component behavior
-        - Proper use of @testing-library/react-native
-        - Async behavior is properly tested
-        - Accessibility testing is included
-        - Test descriptions are sufficiently detailed to clarify the purpose of each test
-        - The tests are not tautological 
-
-    # Solidity test files
-    - path: "**/*.test.{sol}"
-      instructions: |
-        Review test files for:
-        - Comprehensive coverage of contract behavior.
-        - Coverage of success paths, edge cases, and failure/revert scenarios.
-        - Proper validation of access control restrictions.
-        - Verification of event emissions where applicable.
-        - Explicit validation of state changes after each relevant function call.
-        - Adequate test updates whenever contract logic is modified.
-        - Deterministic behavior (tests should not rely on implicit execution order or shared mutable state).
-        - Clear and descriptive test names that reflect the intended behavior being validated.
-
-
-    # Asset files (images, fonts, etc.)
-    - path: "assets/**/*"
-      instructions: |
-        Review asset files for:
-        - Image optimization (appropriate size and format)
-        - Proper @2x and @3x variants for different screen densities
-        - SVG assets are optimized
-        - Font files are licensed and optimized
+        - Comprehensive coverage of expected behavior and failure scenarios.
+        - Use of table-driven tests where appropriate.
+        - Proper mocking of external dependencies like the SQLite store.
 
     # Dependency manifest and lock files (e.g. updated by Dependabot, Renovate)
-    - path: >-
-        **/{package.json,package-lock.json,yarn.lock,pnpm-lock.yaml,npm-shrinkwrap.json,requirements.txt,Pipfile,Pipfile.lock,pyproject.toml,poetry.lock,go.mod,go.sum,Cargo.toml,Cargo.lock,pom.xml,build.gradle,build.gradle.kts,gradle.lockfile,*.gemspec,Gemfile,Gemfile.lock}
+    - path: "**/{go.mod,go.sum}"
       instructions: |
         This file may be modified by a dependency bot (e.g., Dependabot, Renovate).
         Perform a structured dependency upgrade analysis:
@@ -306,32 +170,10 @@ reviews:
 
         **2. Breaking Change Detection**
         - Breaking changes: removed or renamed APIs, changed function signatures, altered behavior.
-        - Deprecated APIs: warn if the codebase uses anything deprecated in the new version.
-        - Configuration changes: new required env vars, config keys, or file structure changes.
         - Security fixes: highlight CVE patches and confirm they address known vulnerabilities.
 
         **3. Codebase Compatibility Check**
         - Locate all files in the repo that import or use the upgraded dependency.
-        - For each usage, verify:
-          - No removed or renamed imports/functions are referenced.
-          - Constructor/function call signatures are compatible.
-          - Any default behavior changes do not silently break existing logic.
-
-        **4. Risk Analysis**
-        - Runtime errors: type mismatches, missing attributes, changed return types.
-        - API incompatibility: breaking interface/type changes (critical for TypeScript).
-        - Logical bugs: subtle behavior changes that don't throw errors but alter outcomes.
-        - Performance regressions: flag if release notes mention perf impacts.
-
-        **5. Edge Cases to Verify**
-        - Backward compatibility with currently pinned peer dependencies.
-        - Changes in default behavior or environment assumptions.
-        - Peer requirement conflicts introduced by the new version.
-        - For TypeScript: type/interface changes that may require type assertion updates.
-
-        **6. Migration Guidance**
-        - If official docs provide migration steps, summarize the required changes and flag
-          specific files in this repo that need updates.
-        - If no migration is required, confirm this explicitly.
+        - For each usage, verify that changes do not silently break existing logic.
 
         Conclude with a **risk level**: Low / Medium / High, with justification.