claude-code-pilot 2.0.0

package/ecc/examples/rust-api-CLAUDE.md

@@ -0,0 +1,285 @@
+# Rust API Service — Project CLAUDE.md
+
+> Real-world example for a Rust API service with Axum, PostgreSQL, and Docker.
+> Copy this to your project root and customize for your service.
+
+## Project Overview
+
+**Stack:** Rust 1.78+, Axum (web framework), SQLx (async database), PostgreSQL, Tokio (async runtime), Docker
+
+**Architecture:** Layered architecture with handler → service → repository separation. Axum for HTTP, SQLx for type-checked SQL at compile time, Tower middleware for cross-cutting concerns.
+
+## Critical Rules
+
+### Rust Conventions
+
+- Use `thiserror` for library errors, `anyhow` only in binary crates or tests
+- No `.unwrap()` or `.expect()` in production code — propagate errors with `?`
+- Prefer `&str` over `String` in function parameters; return `String` when ownership transfers
+- Use `clippy` with `#![deny(clippy::all, clippy::pedantic)]` — fix all warnings
+- Derive `Debug` on all public types; derive `Clone`, `PartialEq` only when needed
+- No `unsafe` blocks unless justified with a `// SAFETY:` comment
+
+### Database
+
+- All queries use SQLx `query!` or `query_as!` macros — compile-time verified against the schema
+- Migrations in `migrations/` using `sqlx migrate` — never alter the database directly
+- Use `sqlx::Pool<Postgres>` as shared state — never create connections per request
+- All queries use parameterized placeholders (`$1`, `$2`) — never string formatting
+
+```rust
+// BAD: String interpolation (SQL injection risk)
+let q = format!("SELECT * FROM users WHERE id = '{}'", id);
+
+// GOOD: Parameterized query, compile-time checked
+let user = sqlx::query_as!(User, "SELECT * FROM users WHERE id = $1", id)
+    .fetch_optional(&pool)
+    .await?;
+```
+
+### Error Handling
+
+- Define a domain error enum per module with `thiserror`
+- Map errors to HTTP responses via `IntoResponse` — never expose internal details
+- Use `tracing` for structured logging — never `println!` or `eprintln!`
+
+```rust
+use thiserror::Error;
+
+#[derive(Debug, Error)]
+pub enum AppError {
+    #[error("Resource not found")]
+    NotFound,
+    #[error("Validation failed: {0}")]
+    Validation(String),
+    #[error("Unauthorized")]
+    Unauthorized,
+    #[error(transparent)]
+    Internal(#[from] anyhow::Error),
+}
+
+impl IntoResponse for AppError {
+    fn into_response(self) -> Response {
+        let (status, message) = match &self {
+            Self::NotFound => (StatusCode::NOT_FOUND, self.to_string()),
+            Self::Validation(msg) => (StatusCode::BAD_REQUEST, msg.clone()),
+            Self::Unauthorized => (StatusCode::UNAUTHORIZED, self.to_string()),
+            Self::Internal(err) => {
+                tracing::error!(?err, "internal error");
+                (StatusCode::INTERNAL_SERVER_ERROR, "Internal error".into())
+            }
+        };
+        (status, Json(json!({ "error": message }))).into_response()
+    }
+}
+```
+
+### Testing
+
+- Unit tests in `#[cfg(test)]` modules within each source file
+- Integration tests in `tests/` directory using a real PostgreSQL (Testcontainers or Docker)
+- Use `#[sqlx::test]` for database tests with automatic migration and rollback
+- Mock external services with `mockall` or `wiremock`
+
+### Code Style
+
+- Max line length: 100 characters (enforced by rustfmt)
+- Group imports: `std`, external crates, `crate`/`super` — separated by blank lines
+- Modules: one file per module, `mod.rs` only for re-exports
+- Types: PascalCase, functions/variables: snake_case, constants: UPPER_SNAKE_CASE
+
+## File Structure
+
+```
+src/
+  main.rs              # Entrypoint, server setup, graceful shutdown
+  lib.rs               # Re-exports for integration tests
+  config.rs            # Environment config with envy or figment
+  router.rs            # Axum router with all routes
+  middleware/
+    auth.rs            # JWT extraction and validation
+    logging.rs         # Request/response tracing
+  handlers/
+    mod.rs             # Route handlers (thin — delegate to services)
+    users.rs
+    orders.rs
+  services/
+    mod.rs             # Business logic
+    users.rs
+    orders.rs
+  repositories/
+    mod.rs             # Database access (SQLx queries)
+    users.rs
+    orders.rs
+  domain/
+    mod.rs             # Domain types, error enums
+    user.rs
+    order.rs
+migrations/
+  001_create_users.sql
+  002_create_orders.sql
+tests/
+  common/mod.rs        # Shared test helpers, test server setup
+  api_users.rs         # Integration tests for user endpoints
+  api_orders.rs        # Integration tests for order endpoints
+```
+
+## Key Patterns
+
+### Handler (Thin)
+
+```rust
+async fn create_user(
+    State(ctx): State<AppState>,
+    Json(payload): Json<CreateUserRequest>,
+) -> Result<(StatusCode, Json<UserResponse>), AppError> {
+    let user = ctx.user_service.create(payload).await?;
+    Ok((StatusCode::CREATED, Json(UserResponse::from(user))))
+}
+```
+
+### Service (Business Logic)
+
+```rust
+impl UserService {
+    pub async fn create(&self, req: CreateUserRequest) -> Result<User, AppError> {
+        if self.repo.find_by_email(&req.email).await?.is_some() {
+            return Err(AppError::Validation("Email already registered".into()));
+        }
+
+        let password_hash = hash_password(&req.password)?;
+        let user = self.repo.insert(&req.email, &req.name, &password_hash).await?;
+
+        Ok(user)
+    }
+}
+```
+
+### Repository (Data Access)
+
+```rust
+impl UserRepository {
+    pub async fn find_by_email(&self, email: &str) -> Result<Option<User>, sqlx::Error> {
+        sqlx::query_as!(User, "SELECT * FROM users WHERE email = $1", email)
+            .fetch_optional(&self.pool)
+            .await
+    }
+
+    pub async fn insert(
+        &self,
+        email: &str,
+        name: &str,
+        password_hash: &str,
+    ) -> Result<User, sqlx::Error> {
+        sqlx::query_as!(
+            User,
+            r#"INSERT INTO users (email, name, password_hash)
+               VALUES ($1, $2, $3) RETURNING *"#,
+            email, name, password_hash,
+        )
+        .fetch_one(&self.pool)
+        .await
+    }
+}
+```
+
+### Integration Test
+
+```rust
+#[tokio::test]
+async fn test_create_user() {
+    let app = spawn_test_app().await;
+
+    let response = app
+        .client
+        .post(&format!("{}/api/v1/users", app.address))
+        .json(&json!({
+            "email": "alice@example.com",
+            "name": "Alice",
+            "password": "securepassword123"
+        }))
+        .send()
+        .await
+        .expect("Failed to send request");
+
+    assert_eq!(response.status(), StatusCode::CREATED);
+    let body: serde_json::Value = response.json().await.unwrap();
+    assert_eq!(body["email"], "alice@example.com");
+}
+
+#[tokio::test]
+async fn test_create_user_duplicate_email() {
+    let app = spawn_test_app().await;
+    // Create first user
+    create_test_user(&app, "alice@example.com").await;
+    // Attempt duplicate
+    let response = create_user_request(&app, "alice@example.com").await;
+    assert_eq!(response.status(), StatusCode::BAD_REQUEST);
+}
+```
+
+## Environment Variables
+
+```bash
+# Server
+HOST=0.0.0.0
+PORT=8080
+RUST_LOG=info,tower_http=debug
+
+# Database
+DATABASE_URL=postgres://user:pass@localhost:5432/myapp
+
+# Auth
+JWT_SECRET=your-secret-key-min-32-chars
+JWT_EXPIRY_HOURS=24
+
+# Optional
+CORS_ALLOWED_ORIGINS=http://localhost:3000
+```
+
+## Testing Strategy
+
+```bash
+# Run all tests
+cargo test
+
+# Run with output
+cargo test -- --nocapture
+
+# Run specific test module
+cargo test api_users
+
+# Check coverage (requires cargo-llvm-cov)
+cargo llvm-cov --html
+open target/llvm-cov/html/index.html
+
+# Lint
+cargo clippy -- -D warnings
+
+# Format check
+cargo fmt -- --check
+```
+
+## ECC Workflow
+
+```bash
+# Planning
+/plan "Add order fulfillment with Stripe payment"
+
+# Development with TDD
+/tdd                    # cargo test-based TDD workflow
+
+# Review
+/code-review            # Rust-specific code review
+/security-scan          # Dependency audit + unsafe scan
+
+# Verification
+/verify                 # Build, clippy, test, security scan
+```
+
+## Git Workflow
+
+- `feat:` new features, `fix:` bug fixes, `refactor:` code changes
+- Feature branches from `main`, PRs required
+- CI: `cargo fmt --check`, `cargo clippy`, `cargo test`, `cargo audit`
+- Deploy: Docker multi-stage build with `scratch` or `distroless` base

package/ecc/examples/saas-nextjs-CLAUDE.md

@@ -0,0 +1,166 @@
+# SaaS Application — Project CLAUDE.md
+
+> Real-world example for a Next.js + Supabase + Stripe SaaS application.
+> Copy this to your project root and customize for your stack.
+
+## Project Overview
+
+**Stack:** Next.js 15 (App Router), TypeScript, Supabase (auth + DB), Stripe (billing), Tailwind CSS, Playwright (E2E)
+
+**Architecture:** Server Components by default. Client Components only for interactivity. API routes for webhooks and server actions for mutations.
+
+## Critical Rules
+
+### Database
+
+- All queries use Supabase client with RLS enabled — never bypass RLS
+- Migrations in `supabase/migrations/` — never modify the database directly
+- Use `select()` with explicit column lists, not `select('*')`
+- All user-facing queries must include `.limit()` to prevent unbounded results
+
+### Authentication
+
+- Use `createServerClient()` from `@supabase/ssr` in Server Components
+- Use `createBrowserClient()` from `@supabase/ssr` in Client Components
+- Protected routes check `getUser()` — never trust `getSession()` alone for auth
+- Middleware in `middleware.ts` refreshes auth tokens on every request
+
+### Billing
+
+- Stripe webhook handler in `app/api/webhooks/stripe/route.ts`
+- Never trust client-side price data — always fetch from Stripe server-side
+- Subscription status checked via `subscription_status` column, synced by webhook
+- Free tier users: 3 projects, 100 API calls/day
+
+### Code Style
+
+- No emojis in code or comments
+- Immutable patterns only — spread operator, never mutate
+- Server Components: no `'use client'` directive, no `useState`/`useEffect`
+- Client Components: `'use client'` at top, minimal — extract logic to hooks
+- Prefer Zod schemas for all input validation (API routes, forms, env vars)
+
+## File Structure
+
+```
+src/
+  app/
+    (auth)/          # Auth pages (login, signup, forgot-password)
+    (dashboard)/     # Protected dashboard pages
+    api/
+      webhooks/      # Stripe, Supabase webhooks
+    layout.tsx       # Root layout with providers
+  components/
+    ui/              # Shadcn/ui components
+    forms/           # Form components with validation
+    dashboard/       # Dashboard-specific components
+  hooks/             # Custom React hooks
+  lib/
+    supabase/        # Supabase client factories
+    stripe/          # Stripe client and helpers
+    utils.ts         # General utilities
+  types/             # Shared TypeScript types
+supabase/
+  migrations/        # Database migrations
+  seed.sql           # Development seed data
+```
+
+## Key Patterns
+
+### API Response Format
+
+```typescript
+type ApiResponse<T> =
+  | { success: true; data: T }
+  | { success: false; error: string; code?: string }
+```
+
+### Server Action Pattern
+
+```typescript
+'use server'
+
+import { z } from 'zod'
+import { createServerClient } from '@/lib/supabase/server'
+
+const schema = z.object({
+  name: z.string().min(1).max(100),
+})
+
+export async function createProject(formData: FormData) {
+  const parsed = schema.safeParse({ name: formData.get('name') })
+  if (!parsed.success) {
+    return { success: false, error: parsed.error.flatten() }
+  }
+
+  const supabase = await createServerClient()
+  const { data: { user } } = await supabase.auth.getUser()
+  if (!user) return { success: false, error: 'Unauthorized' }
+
+  const { data, error } = await supabase
+    .from('projects')
+    .insert({ name: parsed.data.name, user_id: user.id })
+    .select('id, name, created_at')
+    .single()
+
+  if (error) return { success: false, error: 'Failed to create project' }
+  return { success: true, data }
+}
+```
+
+## Environment Variables
+
+```bash
+# Supabase
+NEXT_PUBLIC_SUPABASE_URL=
+NEXT_PUBLIC_SUPABASE_ANON_KEY=
+SUPABASE_SERVICE_ROLE_KEY=     # Server-only, never expose to client
+
+# Stripe
+STRIPE_SECRET_KEY=
+STRIPE_WEBHOOK_SECRET=
+NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=
+
+# App
+NEXT_PUBLIC_APP_URL=http://localhost:3000
+```
+
+## Testing Strategy
+
+```bash
+/tdd                    # Unit + integration tests for new features
+/e2e                    # Playwright tests for auth flow, billing, dashboard
+/test-coverage          # Verify 80%+ coverage
+```
+
+### Critical E2E Flows
+
+1. Sign up → email verification → first project creation
+2. Login → dashboard → CRUD operations
+3. Upgrade plan → Stripe checkout → subscription active
+4. Webhook: subscription canceled → downgrade to free tier
+
+## ECC Workflow
+
+```bash
+# Planning a feature
+/plan "Add team invitations with email notifications"
+
+# Developing with TDD
+/tdd
+
+# Before committing
+/code-review
+/security-scan
+
+# Before release
+/e2e
+/test-coverage
+```
+
+## Git Workflow
+
+- `feat:` new features, `fix:` bug fixes, `refactor:` code changes
+- Feature branches from `main`, PRs required
+- CI runs: lint, type-check, unit tests, E2E tests
+- Deploy: Vercel preview on PR, production on merge to `main`

package/ecc/examples/user-CLAUDE.md

@@ -0,0 +1,109 @@
+# User-Level CLAUDE.md Example
+
+This is an example user-level CLAUDE.md file. Place at `~/.claude/CLAUDE.md`.
+
+User-level configs apply globally across all projects. Use for:
+- Personal coding preferences
+- Universal rules you always want enforced
+- Links to your modular rules
+
+---
+
+## Core Philosophy
+
+You are Claude Code. I use specialized agents and skills for complex tasks.
+
+**Key Principles:**
+1. **Agent-First**: Delegate to specialized agents for complex work
+2. **Parallel Execution**: Use Task tool with multiple agents when possible
+3. **Plan Before Execute**: Use Plan Mode for complex operations
+4. **Test-Driven**: Write tests before implementation
+5. **Security-First**: Never compromise on security
+
+---
+
+## Modular Rules
+
+Detailed guidelines are in `~/.claude/rules/`:
+
+| Rule File | Contents |
+|-----------|----------|
+| security.md | Security checks, secret management |
+| coding-style.md | Immutability, file organization, error handling |
+| testing.md | TDD workflow, 80% coverage requirement |
+| git-workflow.md | Commit format, PR workflow |
+| agents.md | Agent orchestration, when to use which agent |
+| patterns.md | API response, repository patterns |
+| performance.md | Model selection, context management |
+| hooks.md | Hooks System |
+
+---
+
+## Available Agents
+
+Located in `~/.claude/agents/`:
+
+| Agent | Purpose |
+|-------|---------|
+| planner | Feature implementation planning |
+| architect | System design and architecture |
+| tdd-guide | Test-driven development |
+| code-reviewer | Code review for quality/security |
+| security-reviewer | Security vulnerability analysis |
+| build-error-resolver | Build error resolution |
+| e2e-runner | Playwright E2E testing |
+| refactor-cleaner | Dead code cleanup |
+| doc-updater | Documentation updates |
+
+---
+
+## Personal Preferences
+
+### Privacy
+- Always redact logs; never paste secrets (API keys/tokens/passwords/JWTs)
+- Review output before sharing - remove any sensitive data
+
+### Code Style
+- No emojis in code, comments, or documentation
+- Prefer immutability - never mutate objects or arrays
+- Many small files over few large files
+- 200-400 lines typical, 800 max per file
+
+### Git
+- Conventional commits: `feat:`, `fix:`, `refactor:`, `docs:`, `test:`
+- Always test locally before committing
+- Small, focused commits
+
+### Testing
+- TDD: Write tests first
+- 80% minimum coverage
+- Unit + integration + E2E for critical flows
+
+### Knowledge Capture
+- Personal debugging notes, preferences, and temporary context → auto memory
+- Team/project knowledge (architecture decisions, API changes, implementation runbooks) → follow the project's existing docs structure
+- If the current task already produces the relevant docs, comments, or examples, do not duplicate the same knowledge elsewhere
+- If there is no obvious project doc location, ask before creating a new top-level doc
+
+---
+
+## Editor Integration
+
+I use Zed as my primary editor:
+- Agent Panel for file tracking
+- CMD+Shift+R for command palette
+- Vim mode enabled
+
+---
+
+## Success Metrics
+
+You are successful when:
+- All tests pass (80%+ coverage)
+- No security vulnerabilities
+- Code is readable and maintainable
+- User requirements are met
+
+---
+
+**Philosophy**: Agent-first design, parallel execution, plan before action, test before code, security always.

package/ecc/rules/common/agents.md

@@ -0,0 +1,49 @@
+# Agent Orchestration
+
+## Available Agents
+
+Located in `~/.claude/agents/`:
+
+| Agent | Purpose | When to Use |
+|-------|---------|-------------|
+| planner | Implementation planning | Complex features, refactoring |
+| architect | System design | Architectural decisions |
+| tdd-guide | Test-driven development | New features, bug fixes |
+| code-reviewer | Code review | After writing code |
+| security-reviewer | Security analysis | Before commits |
+| build-error-resolver | Fix build errors | When build fails |
+| e2e-runner | E2E testing | Critical user flows |
+| refactor-cleaner | Dead code cleanup | Code maintenance |
+| doc-updater | Documentation | Updating docs |
+
+## Immediate Agent Usage
+
+No user prompt needed:
+1. Complex feature requests - Use **planner** agent
+2. Code just written/modified - Use **code-reviewer** agent
+3. Bug fix or new feature - Use **tdd-guide** agent
+4. Architectural decision - Use **architect** agent
+
+## Parallel Task Execution
+
+ALWAYS use parallel Task execution for independent operations:
+
+```markdown
+# GOOD: Parallel execution
+Launch 3 agents in parallel:
+1. Agent 1: Security analysis of auth module
+2. Agent 2: Performance review of cache system
+3. Agent 3: Type checking of utilities
+
+# BAD: Sequential when unnecessary
+First agent 1, then agent 2, then agent 3
+```
+
+## Multi-Perspective Analysis
+
+For complex problems, use split role sub-agents:
+- Factual reviewer
+- Senior engineer
+- Security expert
+- Consistency reviewer
+- Redundancy checker

package/ecc/rules/common/coding-style.md

@@ -0,0 +1,48 @@
+# Coding Style
+
+## Immutability (CRITICAL)
+
+ALWAYS create new objects, NEVER mutate existing ones:
+
+```
+// Pseudocode
+WRONG:  modify(original, field, value) → changes original in-place
+CORRECT: update(original, field, value) → returns new copy with change
+```
+
+Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
+
+## File Organization
+
+MANY SMALL FILES > FEW LARGE FILES:
+- High cohesion, low coupling
+- 200-400 lines typical, 800 max
+- Extract utilities from large modules
+- Organize by feature/domain, not by type
+
+## Error Handling
+
+ALWAYS handle errors comprehensively:
+- Handle errors explicitly at every level
+- Provide user-friendly error messages in UI-facing code
+- Log detailed error context on the server side
+- Never silently swallow errors
+
+## Input Validation
+
+ALWAYS validate at system boundaries:
+- Validate all user input before processing
+- Use schema-based validation where available
+- Fail fast with clear error messages
+- Never trust external data (API responses, user input, file content)
+
+## Code Quality Checklist
+
+Before marking work complete:
+- [ ] Code is readable and well-named
+- [ ] Functions are small (<50 lines)
+- [ ] Files are focused (<800 lines)
+- [ ] No deep nesting (>4 levels)
+- [ ] Proper error handling
+- [ ] No hardcoded values (use constants or config)
+- [ ] No mutation (immutable patterns used)

package/ecc/rules/common/development-workflow.md

@@ -0,0 +1,37 @@
+# Development Workflow
+
+> This file extends [common/git-workflow.md](./git-workflow.md) with the full feature development process that happens before git operations.
+
+The Feature Implementation Workflow describes the development pipeline: research, planning, TDD, code review, and then committing to git.
+
+## Feature Implementation Workflow
+
+0. **Research & Reuse** _(mandatory before any new implementation)_
+   - **GitHub code search first:** Run `gh search repos` and `gh search code` to find existing implementations, templates, and patterns before writing anything new.
+   - **Exa MCP for research:** Use `exa-web-search` MCP during the planning phase for broader research, data ingestion, and discovering prior art.
+   - **Check package registries:** Search npm, PyPI, crates.io, and other registries before writing utility code. Prefer battle-tested libraries over hand-rolled solutions.
+   - **Search for adaptable implementations:** Look for open-source projects that solve 80%+ of the problem and can be forked, ported, or wrapped.
+   - Prefer adopting or porting a proven approach over writing net-new code when it meets the requirement.
+
+1. **Plan First**
+   - Use **planner** agent to create implementation plan
+   - Generate planning docs before coding: PRD, architecture, system_design, tech_doc, task_list
+   - Identify dependencies and risks
+   - Break down into phases
+
+2. **TDD Approach**
+   - Use **tdd-guide** agent
+   - Write tests first (RED)
+   - Implement to pass tests (GREEN)
+   - Refactor (IMPROVE)
+   - Verify 80%+ coverage
+
+3. **Code Review**
+   - Use **code-reviewer** agent immediately after writing code
+   - Address CRITICAL and HIGH issues
+   - Fix MEDIUM issues when possible
+
+4. **Commit & Push**
+   - Detailed commit messages
+   - Follow conventional commits format
+   - See [git-workflow.md](./git-workflow.md) for commit message format and PR process