Add custom coderabbit instructions (#4)

* Add custom coderabbit instructions

Author: guill

.coderabbit.yaml

@@ -0,0 +1,81 @@
+# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
+inheritance: true
+
+
+reviews:
+  sequence_diagrams: true
+  changed_files_summary: true
+  labeling_instructions: []
+  path_filters: []
+  path_instructions:
+    - path: "**/*.py"
+      instructions: |
+        ## pyisolate Core Library Guidelines
+
+        - Independence
+          - While this library is primarily created for use with ComfyUI, it MUST NOT depend on ComfyUI or any of its packages.
+          - ComfyUI and 'comfy' should ONLY be referenced in the context of documenting the motivation behind certain design decisions (e.g. what we optimize for). The assumption should be that this library could be used for other purposes.
+          - Code specific to ComfyUI does NOT belong in this repository.
+
+        - Documentation
+          - It is VERY important that this library should be well-documented and usable by people without them understanding internal implementation details.
+          - Documentation should NEVER include references to internal implementation details unless absolutely necessary for understanding the public API. This includes communication between host and extension processes and environment variables used internally to pass information.
+          - Identify preconditions or unhandled cases that are lacking documentation.
+          - Documentation is generated via Sphinx from docstrings. Ensure docstrings use supported Sphinx markup.
+          - Inline comments should be used when code may be non-obvious.
+
+        - Type Hints
+          - All public functions and classes MUST have complete type hints (enforced by mypy with `disallow_untyped_defs`)
+          - NEVER use `Any` unless absolutely necessary and justified
+          - NEVER use `# type: ignore` or cast to `Any` unless absolutely necessary and justified
+          - Use `TypeVar`, `Generic`, `TypedDict`, `Literal`, `Union` appropriately
+
+        - Architecture
+          - Public API goes in `pyisolate/` root modules (`__init__.py`, `host.py`, `config.py`, `shared.py`)
+          - Internal implementation goes in `pyisolate/_internal/`
+          - Maintain zero runtime dependencies - this is a pure Python library
+          - All RPC-callable methods in ProxiedSingleton subclasses must be `async`
+
+        - Error Handling
+          - Never use empty `except:` or `except Exception:` without re-raising or logging
+          - Propagate errors with meaningful context across RPC boundaries
+          - Use specific exception types when possible
+
+        - Fail Loudly
+          - When this library is used incorrectly, it MUST fail loudly with clear error messages or exceptions rather than trying to silently guess what the caller intended.
+
+        - Backwards Compatibility
+          - Changes to the public API MUST be backwards compatible unless the major version is incremented (or the major version is zero and the minor version is incremented).
+          - If the major version is incremented (or the minor version is incremented when major is zero), backward compatibility of the public API is NOT required, but changes MUST be documented.
+          - In all cases, changes to the private/internal code does NOT require backward compatibility. Simplicity should be preferred.
+          - Changes to the RPC protocol do NOT need to be backwards compatible. We can always assume that both the host process and client processes use the exact same version of pyisolate.
+
+    - path: "tests/**/*.py"
+      instructions: |
+        ## Test Guidelines
+
+        - Use `pytest` fixtures from `conftest.py`
+        - Integration tests that create real venvs are slow - mark appropriately
+        - Mock sparingly - prefer real integration tests where feasible
+        - Test edge cases and error conditions, not just happy paths
+        - Assert statements are allowed in tests (`S101` is ignored)
+        - Print statements are allowed in tests for debugging (`T201` is ignored)
+
+    - path: "example/**/*.py"
+      instructions: |
+        ## Example Code Guidelines
+
+        - Examples should be clear and educational
+        - Comments explaining "why" are encouraged here
+        - Must actually work - these are tested in CI
+        - Demonstrate real use cases, not contrived examples
+
+    - path: "benchmarks/**/*.py"
+      instructions: |
+        ## Benchmark Guidelines
+
+        - Benchmarks must be reproducible
+        - Include warm-up iterations to avoid JIT/cache effects
+        - Report statistical measures (mean, std dev, min, max)
+        - Document what is being measured and why
+        - GPU benchmarks should handle CUDA OOM gracefully