claude-code-pilot 2.0.0 → 3.0.0

package/src/available-rules/rust/patterns.md

@@ -0,0 +1,168 @@
+---
+paths:
+  - "**/*.rs"
+---
+# Rust Patterns
+
+> This file extends [common/patterns.md](../common/patterns.md) with Rust-specific content.
+
+## Repository Pattern with Traits
+
+Encapsulate data access behind a trait:
+
+```rust
+pub trait OrderRepository: Send + Sync {
+    fn find_by_id(&self, id: u64) -> Result<Option<Order>, StorageError>;
+    fn find_all(&self) -> Result<Vec<Order>, StorageError>;
+    fn save(&self, order: &Order) -> Result<Order, StorageError>;
+    fn delete(&self, id: u64) -> Result<(), StorageError>;
+}
+```
+
+Concrete implementations handle storage details (Postgres, SQLite, in-memory for tests).
+
+## Service Layer
+
+Business logic in service structs; inject dependencies via constructor:
+
+```rust
+pub struct OrderService {
+    repo: Box<dyn OrderRepository>,
+    payment: Box<dyn PaymentGateway>,
+}
+
+impl OrderService {
+    pub fn new(repo: Box<dyn OrderRepository>, payment: Box<dyn PaymentGateway>) -> Self {
+        Self { repo, payment }
+    }
+
+    pub fn place_order(&self, request: CreateOrderRequest) -> anyhow::Result<OrderSummary> {
+        let order = Order::from(request);
+        self.payment.charge(order.total())?;
+        let saved = self.repo.save(&order)?;
+        Ok(OrderSummary::from(saved))
+    }
+}
+```
+
+## Newtype Pattern for Type Safety
+
+Prevent argument mix-ups with distinct wrapper types:
+
+```rust
+struct UserId(u64);
+struct OrderId(u64);
+
+fn get_order(user: UserId, order: OrderId) -> anyhow::Result<Order> {
+    // Can't accidentally swap user and order IDs at call sites
+    todo!()
+}
+```
+
+## Enum State Machines
+
+Model states as enums — make illegal states unrepresentable:
+
+```rust
+enum ConnectionState {
+    Disconnected,
+    Connecting { attempt: u32 },
+    Connected { session_id: String },
+    Failed { reason: String, retries: u32 },
+}
+
+fn handle(state: &ConnectionState) {
+    match state {
+        ConnectionState::Disconnected => connect(),
+        ConnectionState::Connecting { attempt } if *attempt > 3 => abort(),
+        ConnectionState::Connecting { .. } => wait(),
+        ConnectionState::Connected { session_id } => use_session(session_id),
+        ConnectionState::Failed { retries, .. } if *retries < 5 => retry(),
+        ConnectionState::Failed { reason, .. } => log_failure(reason),
+    }
+}
+```
+
+Always match exhaustively — no wildcard `_` for business-critical enums.
+
+## Builder Pattern
+
+Use for structs with many optional parameters:
+
+```rust
+pub struct ServerConfig {
+    host: String,
+    port: u16,
+    max_connections: usize,
+}
+
+impl ServerConfig {
+    pub fn builder(host: impl Into<String>, port: u16) -> ServerConfigBuilder {
+        ServerConfigBuilder {
+            host: host.into(),
+            port,
+            max_connections: 100,
+        }
+    }
+}
+
+pub struct ServerConfigBuilder {
+    host: String,
+    port: u16,
+    max_connections: usize,
+}
+
+impl ServerConfigBuilder {
+    pub fn max_connections(mut self, n: usize) -> Self {
+        self.max_connections = n;
+        self
+    }
+
+    pub fn build(self) -> ServerConfig {
+        ServerConfig {
+            host: self.host,
+            port: self.port,
+            max_connections: self.max_connections,
+        }
+    }
+}
+```
+
+## Sealed Traits for Extensibility Control
+
+Use a private module to seal a trait, preventing external implementations:
+
+```rust
+mod private {
+    pub trait Sealed {}
+}
+
+pub trait Format: private::Sealed {
+    fn encode(&self, data: &[u8]) -> Vec<u8>;
+}
+
+pub struct Json;
+impl private::Sealed for Json {}
+impl Format for Json {
+    fn encode(&self, data: &[u8]) -> Vec<u8> { todo!() }
+}
+```
+
+## API Response Envelope
+
+Consistent API responses using a generic enum:
+
+```rust
+#[derive(Debug, serde::Serialize)]
+#[serde(tag = "status")]
+pub enum ApiResponse<T: serde::Serialize> {
+    #[serde(rename = "ok")]
+    Ok { data: T },
+    #[serde(rename = "error")]
+    Error { message: String },
+}
+```
+
+## References
+
+See skill: `rust-patterns` for comprehensive patterns including ownership, traits, generics, concurrency, and async.

package/src/available-rules/rust/security.md

@@ -0,0 +1,141 @@
+---
+paths:
+  - "**/*.rs"
+---
+# Rust Security
+
+> This file extends [common/security.md](../common/security.md) with Rust-specific content.
+
+## Secrets Management
+
+- Never hardcode API keys, tokens, or credentials in source code
+- Use environment variables: `std::env::var("API_KEY")`
+- Fail fast if required secrets are missing at startup
+- Keep `.env` files in `.gitignore`
+
+```rust
+// BAD
+const API_KEY: &str = "sk-abc123...";
+
+// GOOD — environment variable with early validation
+fn load_api_key() -> anyhow::Result<String> {
+    std::env::var("PAYMENT_API_KEY")
+        .context("PAYMENT_API_KEY must be set")
+}
+```
+
+## SQL Injection Prevention
+
+- Always use parameterized queries — never format user input into SQL strings
+- Use query builder or ORM (sqlx, diesel, sea-orm) with bind parameters
+
+```rust
+// BAD — SQL injection via format string
+let query = format!("SELECT * FROM users WHERE name = '{name}'");
+sqlx::query(&query).fetch_one(&pool).await?;
+
+// GOOD — parameterized query with sqlx
+// Placeholder syntax varies by backend: Postgres: $1  |  MySQL: ?  |  SQLite: $1
+sqlx::query("SELECT * FROM users WHERE name = $1")
+    .bind(&name)
+    .fetch_one(&pool)
+    .await?;
+```
+
+## Input Validation
+
+- Validate all user input at system boundaries before processing
+- Use the type system to enforce invariants (newtype pattern)
+- Parse, don't validate — convert unstructured data to typed structs at the boundary
+- Reject invalid input with clear error messages
+
+```rust
+// Parse, don't validate — invalid states are unrepresentable
+pub struct Email(String);
+
+impl Email {
+    pub fn parse(input: &str) -> Result<Self, ValidationError> {
+        let trimmed = input.trim();
+        let at_pos = trimmed.find('@')
+            .filter(|&p| p > 0 && p < trimmed.len() - 1)
+            .ok_or_else(|| ValidationError::InvalidEmail(input.to_string()))?;
+        let domain = &trimmed[at_pos + 1..];
+        if trimmed.len() > 254 || !domain.contains('.') {
+            return Err(ValidationError::InvalidEmail(input.to_string()));
+        }
+        // For production use, prefer a validated email crate (e.g., `email_address`)
+        Ok(Self(trimmed.to_string()))
+    }
+
+    pub fn as_str(&self) -> &str {
+        &self.0
+    }
+}
+```
+
+## Unsafe Code
+
+- Minimize `unsafe` blocks — prefer safe abstractions
+- Every `unsafe` block must have a `// SAFETY:` comment explaining the invariant
+- Never use `unsafe` to bypass the borrow checker for convenience
+- Audit all `unsafe` code during review — it is a red flag without justification
+- Prefer `safe` FFI wrappers around C libraries
+
+```rust
+// GOOD — safety comment documents ALL required invariants
+let widget: &Widget = {
+    // SAFETY: `ptr` is non-null, aligned, points to an initialized Widget,
+    // and no mutable references or mutations exist for its lifetime.
+    unsafe { &*ptr }
+};
+
+// BAD — no safety justification
+unsafe { &*ptr }
+```
+
+## Dependency Security
+
+- Run `cargo audit` to scan for known CVEs in dependencies
+- Run `cargo deny check` for license and advisory compliance
+- Use `cargo tree` to audit transitive dependencies
+- Keep dependencies updated — set up Dependabot or Renovate
+- Minimize dependency count — evaluate before adding new crates
+
+```bash
+# Security audit
+cargo audit
+
+# Deny advisories, duplicate versions, and restricted licenses
+cargo deny check
+
+# Inspect dependency tree
+cargo tree
+cargo tree -d  # Show duplicates only
+```
+
+## Error Messages
+
+- Never expose internal paths, stack traces, or database errors in API responses
+- Log detailed errors server-side; return generic messages to clients
+- Use `tracing` or `log` for structured server-side logging
+
+```rust
+// Map errors to appropriate status codes and generic messages
+// (Example uses axum; adapt the response type to your framework)
+match order_service.find_by_id(id) {
+    Ok(order) => Ok((StatusCode::OK, Json(order))),
+    Err(ServiceError::NotFound(_)) => {
+        tracing::info!(order_id = id, "order not found");
+        Err((StatusCode::NOT_FOUND, "Resource not found"))
+    }
+    Err(e) => {
+        tracing::error!(order_id = id, error = %e, "unexpected error");
+        Err((StatusCode::INTERNAL_SERVER_ERROR, "Internal server error"))
+    }
+}
+```
+
+## References
+
+See skill: `rust-patterns` for unsafe code guidelines and ownership patterns.
+See skill: `security-review` for general security checklists.

package/src/available-rules/rust/testing.md

@@ -0,0 +1,154 @@
+---
+paths:
+  - "**/*.rs"
+---
+# Rust Testing
+
+> This file extends [common/testing.md](../common/testing.md) with Rust-specific content.
+
+## Test Framework
+
+- **`#[test]`** with `#[cfg(test)]` modules for unit tests
+- **rstest** for parameterized tests and fixtures
+- **proptest** for property-based testing
+- **mockall** for trait-based mocking
+- **`#[tokio::test]`** for async tests
+
+## Test Organization
+
+```text
+my_crate/
+├── src/
+│   ├── lib.rs           # Unit tests in #[cfg(test)] modules
+│   ├── auth/
+│   │   └── mod.rs       # #[cfg(test)] mod tests { ... }
+│   └── orders/
+│       └── service.rs   # #[cfg(test)] mod tests { ... }
+├── tests/               # Integration tests (each file = separate binary)
+│   ├── api_test.rs
+│   ├── db_test.rs
+│   └── common/          # Shared test utilities
+│       └── mod.rs
+└── benches/             # Criterion benchmarks
+    └── benchmark.rs
+```
+
+Unit tests go inside `#[cfg(test)]` modules in the same file. Integration tests go in `tests/`.
+
+## Unit Test Pattern
+
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn creates_user_with_valid_email() {
+        let user = User::new("Alice", "alice@example.com").unwrap();
+        assert_eq!(user.name, "Alice");
+    }
+
+    #[test]
+    fn rejects_invalid_email() {
+        let result = User::new("Bob", "not-an-email");
+        assert!(result.is_err());
+        assert!(result.unwrap_err().to_string().contains("invalid email"));
+    }
+}
+```
+
+## Parameterized Tests
+
+```rust
+use rstest::rstest;
+
+#[rstest]
+#[case("hello", 5)]
+#[case("", 0)]
+#[case("rust", 4)]
+fn test_string_length(#[case] input: &str, #[case] expected: usize) {
+    assert_eq!(input.len(), expected);
+}
+```
+
+## Async Tests
+
+```rust
+#[tokio::test]
+async fn fetches_data_successfully() {
+    let client = TestClient::new().await;
+    let result = client.get("/data").await;
+    assert!(result.is_ok());
+}
+```
+
+## Mocking with mockall
+
+Define traits in production code; generate mocks in test modules:
+
+```rust
+// Production trait — pub so integration tests can import it
+pub trait UserRepository {
+    fn find_by_id(&self, id: u64) -> Option<User>;
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+    use mockall::predicate::eq;
+
+    mockall::mock! {
+        pub Repo {}
+        impl UserRepository for Repo {
+            fn find_by_id(&self, id: u64) -> Option<User>;
+        }
+    }
+
+    #[test]
+    fn service_returns_user_when_found() {
+        let mut mock = MockRepo::new();
+        mock.expect_find_by_id()
+            .with(eq(42))
+            .times(1)
+            .returning(|_| Some(User { id: 42, name: "Alice".into() }));
+
+        let service = UserService::new(Box::new(mock));
+        let user = service.get_user(42).unwrap();
+        assert_eq!(user.name, "Alice");
+    }
+}
+```
+
+## Test Naming
+
+Use descriptive names that explain the scenario:
+- `creates_user_with_valid_email()`
+- `rejects_order_when_insufficient_stock()`
+- `returns_none_when_not_found()`
+
+## Coverage
+
+- Target 80%+ line coverage
+- Use **cargo-llvm-cov** for coverage reporting
+- Focus on business logic — exclude generated code and FFI bindings
+
+```bash
+cargo llvm-cov                       # Summary
+cargo llvm-cov --html                # HTML report
+cargo llvm-cov --fail-under-lines 80 # Fail if below threshold
+```
+
+## Testing Commands
+
+```bash
+cargo test                       # Run all tests
+cargo test -- --nocapture        # Show println output
+cargo test test_name             # Run tests matching pattern
+cargo test --lib                 # Unit tests only
+cargo test --test api_test       # Specific integration test (tests/api_test.rs)
+cargo test --doc                 # Doc tests only
+```
+
+## References
+
+See skill: `rust-testing` for comprehensive testing patterns including property-based testing, fixtures, and benchmarking with Criterion.

package/src/commands/aside.md

@@ -0,0 +1,164 @@
+---
+description: Answer a quick side question without interrupting or losing context from the current task. Resume work automatically after answering.
+---
+
+# Aside Command
+
+Ask a question mid-task and get an immediate, focused answer — then continue right where you left off. The current task, files, and context are never modified.
+
+## When to Use
+
+- You're curious about something while Claude is working and don't want to lose momentum
+- You need a quick explanation of code Claude is currently editing
+- You want a second opinion or clarification on a decision without derailing the task
+- You need to understand an error, concept, or pattern before Claude proceeds
+- You want to ask something unrelated to the current task without starting a new session
+
+## Usage
+
+```
+/aside <your question>
+/aside what does this function actually return?
+/aside is this pattern thread-safe?
+/aside why are we using X instead of Y here?
+/aside what's the difference between foo() and bar()?
+/aside should we be worried about the N+1 query we just added?
+```
+
+## Process
+
+### Step 1: Freeze the current task state
+
+Before answering anything, mentally note:
+- What is the active task? (what file, feature, or problem was being worked on)
+- What step was in progress at the moment `/aside` was invoked?
+- What was about to happen next?
+
+Do NOT touch, edit, create, or delete any files during the aside.
+
+### Step 2: Answer the question directly
+
+Answer the question in the most concise form that is still complete and useful.
+
+- Lead with the answer, not the reasoning
+- Keep it short — if a full explanation is needed, offer to go deeper after the task
+- If the question is about the current file or code being worked on, reference it precisely (file path and line number if relevant)
+- If answering requires reading a file, read it — but read only, never write
+
+Format the response as:
+
+```
+ASIDE: [restate the question briefly]
+
+[Your answer here]
+
+— Back to task: [one-line description of what was being done]
+```
+
+### Step 3: Resume the main task
+
+After delivering the answer, immediately continue the active task from the exact point it was paused. Do not ask for permission to resume unless the aside answer revealed a blocker or a reason to reconsider the current approach (see Edge Cases).
+
+---
+
+## Edge Cases
+
+**No question provided (`/aside` with nothing after it):**
+Respond:
+```
+ASIDE: no question provided
+
+What would you like to know? (ask your question and I'll answer without losing the current task context)
+
+— Back to task: [one-line description of what was being done]
+```
+
+**Question reveals a potential problem with the current task:**
+Flag it clearly before resuming:
+```
+ASIDE: [answer]
+
+⚠️ Note: This answer suggests [issue] with the current approach. Want to address this before continuing, or proceed as planned?
+```
+Wait for the user's decision before resuming.
+
+**Question is actually a task redirect (not a side question):**
+If the question implies changing what is being built (e.g., `/aside actually, let's use Redis instead`), clarify:
+```
+ASIDE: That sounds like a direction change, not just a side question.
+Do you want to:
+  (a) Answer this as information only and keep the current plan
+  (b) Pause the current task and change approach
+```
+Wait for the user's answer — do not make assumptions.
+
+**Question is about the currently open file or code:**
+Answer from the live context. If the file was read earlier in the session, reference it directly. If not, read it now (read-only) and answer with a file:line reference.
+
+**No active task (nothing in progress when `/aside` is invoked):**
+Still use the standard wrapper so the response shape stays consistent:
+```
+ASIDE: [restate the question briefly]
+
+[Your answer here]
+
+— Back to task: no active task to resume
+```
+
+**Question requires a long answer:**
+Give the essential answer concisely, then offer:
+```
+That's the short version. Want a deeper explanation after we finish [current task]?
+```
+
+**Multiple `/aside` questions in a row:**
+Answer each one in sequence. After the last answer, resume the main task. Do not lose task state across a chain of asides.
+
+**Aside answer implies a code change is needed:**
+Note the change needed but do not make it during the aside:
+```
+ASIDE: [answer]
+
+📝 Worth fixing: [what should be changed]. I'll flag this after the current task unless you want to address it now.
+```
+
+**Question is ambiguous or too vague:**
+Ask one clarifying question — the shortest question that gets the information needed to answer. Do not ask multiple questions.
+
+---
+
+## Example Output
+
+```
+User: /aside what does fetchWithRetry() actually do?
+
+ASIDE: what does fetchWithRetry() do?
+
+fetchWithRetry() (src/api/retry.ts:12) attempts the request up to 3 times with
+exponential backoff (250ms → 500ms → 1s). It only retries on 5xx responses and
+network errors — 4xx errors are treated as final and not retried.
+
+— Back to task: refactoring the auth middleware in src/middleware/auth.ts
+```
+
+```
+User: /aside is the approach we're taking thread-safe?
+
+ASIDE: is the current approach thread-safe?
+
+No — the shared cache object in src/cache/store.ts:34 is mutated without locking.
+Under concurrent requests this is a race condition. It's low risk in a single-process
+Node.js server but would be a real problem with worker threads or clustering.
+
+⚠️ Note: This could affect the feature we're building. Want to address this now or continue and fix it in a follow-up?
+```
+
+---
+
+## Notes
+
+- Never modify files during an aside — read-only access only
+- The aside is a conversation pause, not a new task — the original task must always resume
+- Keep answers focused: the goal is to unblock the user quickly, not to deliver a lecture
+- If an aside sparks a larger discussion, finish the current task first unless the aside reveals a blocker
+- Asides are not saved to session files unless explicitly relevant to the task outcome

package/src/commands/build-fix.md

@@ -0,0 +1,62 @@
+# Build and Fix
+
+Incrementally fix build and type errors with minimal, safe changes.
+
+## Step 1: Detect Build System
+
+Identify the project's build tool and run the build:
+
+| Indicator | Build Command |
+|-----------|---------------|
+| `package.json` with `build` script | `npm run build` or `pnpm build` |
+| `tsconfig.json` (TypeScript only) | `npx tsc --noEmit` |
+| `Cargo.toml` | `cargo build 2>&1` |
+| `pom.xml` | `mvn compile` |
+| `build.gradle` | `./gradlew compileJava` |
+| `go.mod` | `go build ./...` |
+| `pyproject.toml` | `python -m compileall -q .` or `mypy .` |
+
+## Step 2: Parse and Group Errors
+
+1. Run the build command and capture stderr
+2. Group errors by file path
+3. Sort by dependency order (fix imports/types before logic errors)
+4. Count total errors for progress tracking
+
+## Step 3: Fix Loop (One Error at a Time)
+
+For each error:
+
+1. **Read the file** — Use Read tool to see error context (10 lines around the error)
+2. **Diagnose** — Identify root cause (missing import, wrong type, syntax error)
+3. **Fix minimally** — Use Edit tool for the smallest change that resolves the error
+4. **Re-run build** — Verify the error is gone and no new errors introduced
+5. **Move to next** — Continue with remaining errors
+
+## Step 4: Guardrails
+
+Stop and ask the user if:
+- A fix introduces **more errors than it resolves**
+- The **same error persists after 3 attempts** (likely a deeper issue)
+- The fix requires **architectural changes** (not just a build fix)
+- Build errors stem from **missing dependencies** (need `npm install`, `cargo add`, etc.)
+
+## Step 5: Summary
+
+Show results:
+- Errors fixed (with file paths)
+- Errors remaining (if any)
+- New errors introduced (should be zero)
+- Suggested next steps for unresolved issues
+
+## Recovery Strategies
+
+| Situation | Action |
+|-----------|--------|
+| Missing module/import | Check if package is installed; suggest install command |
+| Type mismatch | Read both type definitions; fix the narrower type |
+| Circular dependency | Identify cycle with import graph; suggest extraction |
+| Version conflict | Check `package.json` / `Cargo.toml` for version constraints |
+| Build tool misconfiguration | Read config file; compare with working defaults |
+
+Fix one error at a time for safety. Prefer minimal diffs over refactoring.