Create Recurse ML rules

.recurseml.yaml

@@ -0,0 +1 @@
+rules: .rules/

.rules/effective_comments.mdc

@@ -0,0 +1,23 @@
+---
+description: Effective Code Comments
+globs: "*"
+alwaysApply: true
+---
+
+
+For more context read: https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/
+
+- NEVER write comments for code that can be understood from the code itself
+- Avoid redundant comments that restate the obvious
+- Use comments to clarify the intent behind complex logic or decisions
+- Use comments when non-obvious assumptions are made
+- Keep TODO comments specific with assignees when possible
+- ALWAYS update comments when the underlying code changes
+
+
+SCOPE: this only applies to code comments blocks NOT executable code (such as logging statements)
+
+# Solution
+
+Fix redundant comments by removing them completely.
+Never attempt to add additional clarification to the comments.

.rules/exhaustive_pattern_matching.mdc

@@ -0,0 +1,48 @@
+---
+description: Exhaustive Pattern Matching with match
+globs: "**/*.rs"
+alwaysApply: true
+---
+
+For more context read: https://doc.rust-lang.org/book/ch06-02-match.html
+
+- ALWAYS use `match` instead of nested `if-else` chains for enum handling
+- Use `match` for exhaustive pattern matching to prevent runtime panics
+- Add match guards (`if` conditions) for conditional patterns within matches
+- Handle all variants explicitly - avoid catch-all patterns when possible
+- Use `match` for HTTP methods, response types, and middleware returns in Robyn
+- Pattern match on `Option` and `Result` types instead of using `unwrap()`
+
+SCOPE: This applies to Rust enum handling, especially for HttpMethod, ResponseType, and MiddlewareReturn types in the Robyn codebase.
+
+# Solution
+
+Replace nested if-else chains with match statements:
+
+```rust
+// Instead of:
+if method == HttpMethod::GET {
+    handle_get()
+} else if method == HttpMethod::POST {
+    handle_post()
+} else {
+    handle_other()
+}
+
+// Use:
+match method {
+    HttpMethod::GET => handle_get(),
+    HttpMethod::POST => handle_post(),
+    _ => handle_other(),
+}
+```
+
+Use match guards for conditional logic:
+
+```rust
+match response_type {
+    ResponseType::Standard(resp) if resp.status_code >= 400 => handle_error(resp),
+    ResponseType::Standard(resp) => handle_success(resp),
+    ResponseType::Streaming(stream) => handle_stream(stream),
+}
+```

.rules/proper_error_handling.mdc

@@ -0,0 +1,64 @@
+---
+description: Proper Error Handling with Result and ? Operator
+globs: "**/*.rs"
+alwaysApply: true
+---
+
+For more context read: https://doc.rust-lang.org/book/ch09-00-error-handling.html
+
+- NEVER use `unwrap()` or `expect()` in production code without clear justification
+- Use the `?` operator for error propagation in functions returning `Result`
+- Handle `Result` and `Option` types explicitly with `match` or combinators
+- Create custom error types for domain-specific errors in Robyn
+- Use `map_err()` to transform errors when interfacing with PyO3
+- Log errors at appropriate levels before returning them
+- Return meaningful error messages for HTTP endpoints
+
+WHY THIS MATTERS IN ROBYN:
+Robyn is a high-performance web framework that interfaces between Python and Rust. Poor error handling can:
+- Crash the entire web server with a single panic
+- Lose critical error information when interfacing with Python
+- Provide unhelpful error messages to API consumers
+- Make debugging production issues nearly impossible
+- Break the Python-Rust bridge unexpectedly
+
+SCOPE: This applies to all Rust error handling, especially PyO3 integration, file I/O, and HTTP request processing in the Robyn codebase.
+
+# Solution
+
+Replace unwrap() with proper error handling:
+
+```rust
+// Instead of:
+let value = some_operation().unwrap();
+
+// Use:
+let value = some_operation()?;
+// Or handle explicitly:
+let value = match some_operation() {
+    Ok(val) => val,
+    Err(e) => {
+        log::error!("Operation failed: {}", e);
+        return Err(format!("Operation failed: {}", e));
+    }
+};
+```
+
+Use map_err for PyO3 integration:
+
+```rust
+// Transform errors when interfacing with Python
+let result = python_operation()
+    .map_err(|e| format!("Python operation failed: {}", e))?;
+```
+
+Handle file operations safely:
+
+```rust
+// Instead of:
+let content = std::fs::read_to_string(path).unwrap();
+
+// Use:
+let content = std::fs::read_to_string(path)
+    .map_err(|e| format!("Failed to read file {}: {}", path, e))?;
+```