feat: Add custom CodeRabbit instructions for examples (#1189)

Signed-off-by: Adityarya11 <[email protected]>
Signed-off-by: prishajaiswal75 <[email protected]>

Author: Adityarya11

.coderabbit.yaml

@@ -19,8 +19,8 @@ reviews:
   poem: false # Do not write a literal poem (spammy)
   enable_prompt_for_ai_agents: false # Disable prompts for AI agents (spammy)
 
+  # --- CUSTOM INSTRUCTIONS FOR EXAMPLES DIRECTORY ---
   path_instructions:
-    # --- CUSTOM INSTRUCTIONS FOR EXAMPLES DIRECTORY ---
     - path: "examples/**/*"
       instructions: |
         You are acting as a senior maintainer reviewing SDK examples. Your goal is to ensure examples work verbatim for users who copy-paste them.
@@ -63,352 +63,6 @@ reviews:
         - Be concise, technical, and opinionated.
         - Flag out-of-scope improvements as potential new issues rather than blocking.
 
-    # --- UNIT TESTS REVIEW INSTRUCTIONS ---
-    - path: "tests/unit/**/*"
-      instructions: |
-        You are acting as a senior maintainer reviewing unit tests for the hiero-sdk-python project.  Your goal is to ensure tests are extensive, deterministic, and protect against breaking changes.
-
-        **CRITICAL PRINCIPLES - Tests Must Fail Loudly & Deterministically**:
-        - Tests must provide useful error messages when they fail for future debugging.
-        - No `print()` statements - use assertions with descriptive messages.
-        - No timing-dependent or unseeded random assertions.
-        - No network calls or external dependencies (unit tests are isolated).
-        - No unjustified TODOs or skipped tests without tracking issues.
-
-        **PRIORITY 1 - Protect Against Breaking Changes**:
-        - Assert public attributes exist (e.g., `assert hasattr(obj, 'account_id')`).
-        - Assert return types where relevant (e.g., `assert isinstance(result, AccountId)`).
-        - Assert fluent setters return `self` (e.g., `assert tx.set_memo("test") is tx`).
-        - Assert backward-compatible defaults are maintained. 
-        - If a breaking change is introduced, tests must assert deprecation behavior and test old behavior until removal.
-
-        **PRIORITY 2 - Constructor & Setter Behavior**:
-        - Test constructor behavior with valid inputs, edge cases, and invalid inputs.
-        - Test setter behavior including method chaining (fluent interface).
-        - Verify that setters validate input and raise appropriate exceptions.
-        - Test that getters return expected values after construction/setting.
-
-        **PRIORITY 3 - Comprehensive Coverage**: 
-        - Unit tests should be extensive - test even if we don't expect users to use it currently.
-        - Cover happy paths AND unhappy paths/edge cases.
-        - Test boundary conditions, null/None values, empty collections, etc.
-        - Avoid brittle ordering assertions unless order is part of the contract. 
-
-        **PRIORITY 4 - No Mocks for Non-Existent Modules**:
-        - All imports must reference actual SDK modules - no hallucinated paths.
-        - Validate import paths against the actual `src/hiero_sdk_python` structure.
-        - Mocks should only be used for external dependencies, not SDK internals.
-
-        **PRIORITY 5 - Test Framework Philosophy**:
-        - Prefer repetitive but clear tests over abstracted helper functions.
-        - Some core functionality may warrant helper files (considered an exception).
-        - Discourage custom helper functions; prefer pytest fixtures when shared setup is needed. 
-        - Prefer testing real functionality over mocked behavior.
-
-        **AVOID**:
-        - Linter or formatting feedback (leave that to ruff/pre-commit).
-        - Nitpicking minor stylistic issues unless they impact maintainability.
-        - Overly abstracted test helpers that obscure what's being tested. 
-
-        **PHILOSOPHY**:  
-        - Unit tests protect our future selves - be defensive and forward-looking.
-        - Tests should be readable by SDK developers:  clear names, brief docstrings, key inline comments.
-        - When tests fail, we should immediately know what broke and why.
-
-    # --- INTEGRATION TESTS REVIEW INSTRUCTIONS ---
-    - path: "tests/integration/**/*"
-      instructions: |
-        You are acting as a senior maintainer reviewing integration tests for the hiero-sdk-python project. Your goal is to ensure end-to-end tests validate real network behavior safely and deterministically.
-
-        **CRITICAL PRINCIPLES - Safety & Diagnosability**:
-        - **Prioritize safety**: No implicit or default mainnet usage.
-        - Secrets and credentials must be injected safely (env vars, not hardcoded).
-        - Test failures must be diagnosable with clear error messages.
-        - Tests must assert observable network behavior, not just `SUCCESS`.
-        - Failure-path tests must assert specific `ResponseCode` values (e.g., `TOKEN_HAS_NO_PAUSE_KEY`).
-
-        **PRIORITY 1 - End-to-End Behavior**:
-        - Tests should be end-to-end:  construct → freeze → sign → execute → verify.
-        - Validate resulting balances, ownership, and state changes (not just transaction success).
-        - Assert transaction receipts contain expected data (IDs, serial numbers, etc.).
-        - Verify network state after operations (e.g., account balance changed, token transferred).
-
-        **PRIORITY 2 - Test Structure & Maintainability**:
-        - One major behavior per test (clear focus).
-        - Tests should be readable:  clear names, brief docstrings, key inline comments.
-        - Minimal abstraction layers - prefer clarity over DRY.
-        - Is the file too monolithic? Flag if tests should be split into smaller modules. 
-        - Are helper functions good candidates for pytest fixtures or shared utilities?
-
-        **PRIORITY 3 - Isolation & Cleanup**:
-        - Local account creation over operator reuse (avoid state pollution).
-        - Are accounts, tokens, and allowances properly cleaned up to avoid state leakage?
-        - Recommend teardown strategies or fixture scoping improvements. 
-        - Tests should not depend on execution order (avoid brittle assumptions).
-
-        **PRIORITY 4 - Assertions & Coverage**:
-        - Do tests validate only success/failure, or also assert resulting state? 
-        - Suggest additional assertions that would strengthen correctness (balances, allowances, ownership).
-        - Cover happy paths AND unhappy paths (e.g., invalid spender, revoked allowance, insufficient balance).
-        - Avoid timing-based or flaky assumptions.
-
-        **PRIORITY 5 - Observability & Debugging**:
-        - Could structured logging or transaction metadata improve debugging?
-        - Suggest capturing allowance values, transaction IDs, and balances in logs.
-        - Ensure error messages provide context for failure diagnosis. 
-
-        **AVOID**:
-        - Linter or formatting feedback.
-        - Overly abstracted helpers that obscure what's being tested.
-        - Timing-dependent assertions (use explicit waits or retries if needed).
-
-        **PHILOSOPHY**: 
-        - Integration tests validate real network behavior - they must be reliable and safe.
-        - Tests should protect against regressions while being maintainable.
-        - When tests fail in CI, developers should immediately understand what broke. 
-        - Redundant setup code should be refactored, but clarity trumps abstraction.
-
-    # --- DOCUMENTATION REVIEW INSTRUCTIONS ---
-    - path: "docs/**"
-      instructions: |
-        You are reviewing documentation for the Hiero Python SDK. These pages serve both SDK users and SDK developers.
-
-        Priority 1 - Correctness (code, commands, links)
-        1. Verify code snippets conceptually run and match the current SDK API.
-        2. Check shell commands and workflow steps against actual project tooling.
-        3. Validate URLs and cross-references; flag broken or misleading links.
-
-        Priority 2 - Clarity and completeness
-        1. Ensure each page states its purpose and expected outcome early.
-        2. Prefer concrete, step-wise explanations over vague descriptions.
-        3. Highlight missing prerequisites that would block a reader.
-        4. For larger gaps, suggest filing a follow-up issue instead of blocking.
-
-        Priority 3 - Consistency and navigation
-        1. Encourage consistent terminology with the SDK and examples.
-        2. Check headings form a logical reading path.
-        3. Confirm each page makes clear which audience it serves.
-
-        PHILOSOPHY
-        - Treat docs as work-in-progress: optimize for correctness and clarity over perfection.
-        - Keep feedback concise, action-oriented, and focused on reader success.
-        - Do not request large-scale restructures unless current structure blocks understanding.
-
-        AVOID
-        - Avoid lint-style feedback on Markdown formatting or minor wording.
-        - Avoid proposing new conventions without clear benefit.
-        - Avoid turning every high-level gap into a blocker.
-
-    - path: "docs/sdk_users/**"
-      instructions: |
-        These documents are for SDK users who want to USE the Hiero Python SDK quickly and correctly.
-
-        Priority 1 - High-level guidance
-        1. Ensure explanations are conceptual and point to `/examples` for runnable code.
-        2. Check that required environment variables and network choices are clearly stated.
-
-        Priority 2 - No hidden assumptions
-        1. Assume zero prior knowledge of this SDK and minimal Hedera background.
-        2. Avoid requiring knowledge of repository layout or contribution workflow.
-
-        PHILOSOPHY
-        - Keep explanations high-level and conceptual; defer runnable examples to `/examples`.
-        - Focus on what users need to know before diving into code examples.
-
-    - path: "docs/sdk_developers/**"
-      instructions: |
-        These documents are for SDK developers and contributors, including `docs/sdk_developers/training/**`.
-
-        Priority 1 - Workflow accuracy
-        1. Ensure contribution, branching, rebasing, signing (DCO, GPG), CI, linting, and testing instructions match the repo.
-        2. Verify `git` and GitHub flows agree with CONTRIBUTING.md and current practice.
-        3. Flag outdated references to scripts, directories, or configuration files.
-
-        Priority 2 - Training flow
-        1. For training docs, ensure logical progression and clear prerequisites.
-        2. Check that cross-links between training files are coherent.
-
-        PHILOSOPHY
-        - Treat these docs as a training ground for future maintainers and regular contributors.
-        - Help readers move from "I cloned the repo" to "I can safely extend and debug the SDK".
-        - Balance approachability for beginners with enough depth for experts.
-
-    # --- CUSTOM INSTRUCTIONS FOR .GITHUB DIRECTORY ---
-    - path: ".github/workflows/**/*"
-      instructions: |
-        Review workflows as security-sensitive infrastructure.
-
-        A good workflow is small, focused, and boring.
-        If a workflow is clever, generic, or overly flexible, it is a risk.
-
-        ---------------------------------------------------------
-        PRIORITY 0 — ABSOLUTE REQUIREMENTS 
-        ---------------------------------------------------------
-        - All third-party actions MUST be pinned to full commit SHAs, similar to other workflows.
-        - `permissions:` MUST be explicitly declared and minimally scoped.
-        - Workflows MUST behave safely when executed from forks.
-        - YAML MUST orchestrate steps, not implement business logic.
-        - Any workflow that mutates GitHub state MUST support dry-run mode.
-        - Dry-run behavior must be explicit and visible in logs.
-        - Workflows MUST NOT modify repository source code outside `.github/`.
-
-        ---------------------------------------------------------
-        PRIORITY 1 — SCOPE, FOCUS & RESTRAINT
-        ---------------------------------------------------------
-        - The title of each workflow must be relevant, match similar naming schemes, and match its script filename.
-        - Each workflow MUST have a single, clearly defined objective and SHOULD document this in a top-level comment.
-        - Flag workflows that:
-          - Attempt to be generic “frameworks”
-          - Include speculative or future-facing logic
-          - Perform actions unrelated to the stated goal
-        - Over-abstraction and excess flexibility are maintenance risks.
-
-        ---------------------------------------------------------
-        PRIORITY 2 — INPUT HARDENING
-        ---------------------------------------------------------
-        - Treat ALL GitHub event data as potentially hostile input, including:
-          - issue titles, bodies, and comments
-          - labels, usernames, branch names
-        - Free-form user input MUST NOT be passed directly into:
-          - shell commands
-          - gh CLI arguments
-          - Node.js exec / spawn calls
-        - Require strict allowlists or exact string matches.
-        - Flag any use of:
-          - eval or bash -c
-          - backticks or $(...) with user-controlled input
-
-        ---------------------------------------------------------
-        PRIORITY 3 — DRY-RUN & SAFE OPERATION
-        ---------------------------------------------------------
-        - Workflows that mutate state MUST expose:
-          workflow_dispatch:
-            inputs:
-              dry_run:
-                default: "true"
-        - When dry_run=true, workflows MUST:
-          - Log dry mode is active
-          - Function on dry run: never post, comment, label, assign or edit
-          - Be easy to expand in the future
-          - Exit successfully
-
-        ---------------------------------------------------------
-        PRIORITY 4 — SCRIPT EXTRACTION & CODE TRIM
-        ---------------------------------------------------------
-        - YAML should orchestrate execution only.
-        - All non-trivial logic MUST live in:
-          - `.github/scripts/*.sh`
-          - `.github/scripts/*.js`
-        - Workflow filenames and their primary scripts SHOULD share a clear, matching name.
-        - Scripts MUST remain:
-          - Purpose-built
-          - Trim and readable
-          - Easy to maintain
-        - Flag:
-          - Large `run: |` blocks
-          - Inline loops, conditionals, or API calls in YAML
-          - Overly generic helper scripts for narrow tasks
-
-        ---------------------------------------------------------
-        PRIORITY 5 — API EFFICIENCY & DISCIPLINE
-        ---------------------------------------------------------
-        - GitHub API usage must be intentional and minimal.
-        - Prefer:
-          - Aggregated queries over per-entity loops
-          - Server-side filtering over client-side iteration
-          - Reusing data already present in the event payload
-        - Pagination MUST:
-          - Be considered and justified
-          - Enforce hard upper bounds
-        - Flag:
-          - Repeated API calls inside loops
-          - Unbounded pagination
-          - Fetching data already available in context
-
-        ---------------------------------------------------------
-        PRIORITY 6 — CONCURRENCY & IDEMPOTENCY
-        ---------------------------------------------------------
-        - Workflows that mutate state MUST:
-          - Define a deterministic concurrency group
-          - Be safe under retries and parallel execution
-        - Duplicate prevention is REQUIRED:
-          - Marker-based comment detection
-          - Check-before-create logic for labels and assignments
-        - Assume workflows may:
-          - Run multiple times
-          - Be retried automatically
-          - Execute concurrently with other automations
-        - Workflows should avoid logic that duplicates or causes conflicts.
-
-        ---------------------------------------------------------
-        PRIORITY 7 — PERMISSION CORRECTNESS
-        ---------------------------------------------------------
-        - Requested permissions MUST exactly match behavior.
-        - Explicitly validate common cases:
-          - issues: write → comments, labels, assignments
-          - contents: read → repository checkout
-          - pull-requests: write → PR mutations
-        - Flag:
-          - Over-permissioned workflows
-          - Under-permissioned workflows that would fail at runtime
-          - Reliance on default permissions
-
-        ---------------------------------------------------------
-        PRIORITY 8 — LOGGING & OPERABILITY
-        ---------------------------------------------------------
-        - Logs should include, where applicable:
-          - repository
-          - workflow name
-          - issue or PR number
-          - triggering actor
-          - dry-run status
-          - decisions made (performed vs skipped)
-        - Avoid:
-          - Silent success or silent skips
-          - Raw payload dumps
-          - Any secret or token leakage
-
-    # ============================================================
-    # SHELL SCRIPTS
-    # ============================================================
-    - path: ".github/scripts/**/*.sh"
-      instructions: |
-        Treat shell scripts as production-grade automation.
-
-        Scripts should be small, focused, and explicit.
-        Avoid “do-everything” or overly generic scripts.
-
-        - MUST use: `set -euo pipefail`
-        - MUST validate all required environment variables
-        - MUST defensively quote variables
-        - MUST validate all untrusted input
-        - MUST have bounded loops and pagination
-        - MUST support dry-run mode if state is mutated
-        - MUST log key decisions and early exits
-
-    # ============================================================
-    # JAVASCRIPT SCRIPTS
-    # ============================================================
-    - path: ".github/scripts/**/*.js"
-      instructions: |
-        Review JavaScript scripts as long-lived automation code.
-
-        Scripts must remain:
-        - Focused
-        - Readable
-        - Purpose-built
-
-        - All `context.payload` fields MUST be validated
-        - Free-form text MUST NOT be trusted
-        - Dynamic code execution is prohibited
-        - Avoid `child_process.exec`; prefer `execFile` if needed
-        - All async operations MUST be wrapped in try/catch
-        - Errors MUST include contextual metadata
-        - Duplicate API calls MUST be avoided
-        - Marker-based deduplication is required
-        - Scripts MUST NOT assume write access
-        - Permission failures MUST be handled gracefully
-
 chat:
   art: false # Don't draw ASCII art (false)
-  auto_reply: false # Don't allow bot to converse (spammy)
+  auto_reply: false # Don't allow bot to converse (spammy)