remove files which is not needed.

.coderabbit.yaml

@@ -30,11 +30,11 @@ issue_enrichment:
     auto_apply_labels: true
     labeling_instructions:
       - label: bug
-        instructions: Issues reporting bugs, errors, crashes, incorrect behavior, or unexpected results. This includes runtime errors, logic errors, broken functionality, regressions, and any deviation from expected or documented behavior.
+        instructions: Issues reporting configuration bugs, broken policy settings, YAML syntax errors, or workflow execution failures.
       - label: enhancement
-        instructions: Feature requests, improvements to existing functionality, performance optimizations, refactoring suggestions, UI/UX enhancements, and any suggestions to make the project better or add new capabilities.
+        instructions: Requests to add new sub-org policies, refine branch protections, update rulesets, or enhance automated sync workflows.
       - label: documentation
-        instructions: Documentation updates, additions, corrections, or clarifications needed. This includes missing docs, outdated information, unclear instructions, API documentation, code examples, README improvements, and any requests for better explanations or guides.
+        instructions: Updates to README.md, policy manuals, setup guides, or best practices documentation.
   planning:
     enabled: true
     auto_planning:
@@ -58,7 +58,6 @@ reviews:
     # Only auto-review PRs targeting these branches
     base_branches:
       - main
-      - develop
 
   # Include a high-level summary at the start of each review
   high_level_summary: true
@@ -92,246 +91,47 @@ 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
-    - "!**/dist/**" # Build output
+    - "!**/node_modules/**"
+    - "!**/dist/**"
 
-  # Use the following tools when reviewing
   tools:
-    shellcheck:
-      enabled: true
-    ruff:
+    yamllint:
       enabled: true
     markdownlint:
       enabled: true
-    github-checks:
-      enabled: true
-      timeout_ms: 90000
-    languagetool:
-      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:
+    shellcheck:
       enabled: true
-    detekt:
+    github-checks:
       enabled: true
+      timeout_ms: 90000
     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: Bash Lang
-      instructions: >-
-        Apply when the PR/MR contains changes to shell-scripts or BASH code
-        snippets
-    - label: Make Lang
-      instructions: >-
-        Apply when the PR/MR contains changes to the file `Makefile` or makefile
-        code snippets
+    - label: Safe-Settings Policy
+      instructions: Apply when PR modifies .github/settings.yml, .github/suborgs/, .github/repos/, or deployment-settings.yml
+    - label: Workflow
+      instructions: Apply when PR modifies files inside .github/workflows/
     - label: Documentation
-      instructions: >-
-        Apply whenever project documentation (namely markdown source-code) is
-        updated by the PR/MR
-    - label: Linter
-      instructions: >-
-        Apply when the purpose of the PR/MR is related to fixing the feedback
-        from a linter
+      instructions: Apply whenever README.md or project markdown docs are updated
 
-  # Review instructions that apply to all files
-  instructions: >-
-    - Verify that documentation and comments are free of spelling mistakes
-    - Ensure that test code is automated, comprehensive, and follows testing best practices
-    - Verify that all critical functionality is covered by tests
-    - Confirm that the code meets the project's requirements and objectives
-    - 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
+  instructions:
+    - Verify that all YAML safe-settings files follow valid safe-settings schema syntax
+    - Confirm that sub-organization mappings under .github/suborgs/ contain valid repo lists
+    - Check that secret references in GitHub Action workflows use secret masks (e.g. secrets.SAFE_SETTINGS_PRIVATE_KEY)
+    - Ensure documentation is accurate, clear, and up-to-date
 
-  # Custom review instructions for specific file patterns
   path_instructions:
-    # TypeScript/JavaScript files
-    - path: "**/*.{ts,tsx,js,jsx}"
+    - path: "**/*.yml"
       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"
-      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"
+        Safe-Settings & Workflow YAMLs:
+        - Ensure strict indentation (2 spaces)
+        - Validate key names against safe-settings specification (repository, branches, labels, suborgrepos, restrictedRepos)
+        - Verify environment variable substitutions use standard GitHub Actions syntax
+    - path: "**/*.md"
       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}"
-      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
-
-    # 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}
-      instructions: |
-        This file may be modified by a dependency bot (e.g., Dependabot, Renovate).
-        Perform a structured dependency upgrade analysis:
-
-        **1. Version Change Assessment**
-        - Identify all version bumps (major, minor, patch) and flag major/minor upgrades explicitly.
-        - Check the official release notes, changelog, or migration guide for each upgraded package.
-
-        **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.
-
-        Conclude with a **risk level**: Low / Medium / High, with justification.
+        Markdown Documentation:
+        - Check for broken relative links and clear markdown hierarchy (h1, h2, h3)
+        - Ensure clean formatting without trailing whitespace