specweave 0.33.4 → 0.33.6

package/plugins/specweave/commands/specweave-judge.md

@@ -1,276 +0,0 @@
----
-name: specweave:judge
-description: Validate completed work using LLM-as-Judge pattern. Works on any files, not just increments.
----
-
-# /specweave:judge - Work Validation via Judge LLM
-
-Validate any completed work using the LLM-as-Judge pattern with deep reasoning.
-
-## Purpose
-
-Use when you've completed work (files, git changes, any code) and want AI-powered validation:
-- Works on **any files** (not just SpecWeave increments)
-- Uses **chain-of-thought reasoning** for thorough analysis
-- Returns **clear verdict** with detailed reasoning
-
-## Usage
-
-```bash
-# Validate specific files
-/specweave:judge src/file.ts
-/specweave:judge "src/**/*.ts"
-
-# Validate git changes
-/specweave:judge --staged           # Staged changes
-/specweave:judge --last-commit      # Last commit
-/specweave:judge --diff main        # Diff vs branch
-
-# Validation modes
-/specweave:judge src/file.ts --quick    # Fast (~10s)
-/specweave:judge src/file.ts --deep     # Thorough (~60s)
-/specweave:judge src/file.ts --strict   # Fail on any concern
-
-# Additional options
-/specweave:judge src/file.ts --fix      # Include fix suggestions
-/specweave:judge src/file.ts --export   # Export report to markdown
-```
-
-## How It Works
-
-When you invoke `/specweave:judge`, Claude will:
-
-### Step 1: Gather Input
-
-Determine what to validate:
-- If file paths provided → read those files
-- If `--staged` → get staged git changes
-- If `--last-commit` → get files from last commit
-- If `--diff <branch>` → get diff against branch
-
-### Step 2: Analyze with Judge LLM Pattern
-
-Use chain-of-thought reasoning to evaluate:
-
-```markdown
-<thinking>
-1. **Read**: Understand what the code does
-2. **Analyze**: Check for issues across dimensions:
-   - Correctness: Does it work as intended?
-   - Completeness: Are edge cases handled?
-   - Security: Any vulnerabilities?
-   - Performance: Any obvious issues?
-   - Maintainability: Is it clean and clear?
-3. **Evaluate**: Weigh findings by severity
-4. **Decide**: Form verdict based on analysis
-</thinking>
-```
-
-### Step 3: Return Verdict
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-JUDGE VERDICT: APPROVED | CONCERNS | REJECTED
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Confidence: 0.XX
-Files Analyzed: N
-
-REASONING:
-[Chain-of-thought explanation of findings]
-
-ISSUES (if any):
-🔴 CRITICAL: [title]
-   [description]
-   📍 [file:line]
-   💡 [suggestion]
-
-🟡 HIGH: [title]
-   ...
-
-🟢 LOW: [title]
-   ...
-
-VERDICT: [summary sentence]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Verdict Meanings
-
-| Verdict | Meaning | Action |
-|---------|---------|--------|
-| **APPROVED** | Work looks good, no significant issues | Safe to proceed |
-| **CONCERNS** | Some issues found, worth addressing | Review and fix if time permits |
-| **REJECTED** | Critical issues found | Must fix before proceeding |
-
-## Validation Modes
-
-### Quick Mode (`--quick`)
-- Fast validation (~10 seconds)
-- Focuses on obvious issues
-- Good for frequent checks during development
-- Cost: ~$0.02-0.05
-
-### Default Mode
-- Balanced validation (~30 seconds)
-- Thorough analysis of all dimensions
-- Good for pre-commit validation
-- Cost: ~$0.05-0.10
-
-### Deep Mode (`--deep`)
-- Most thorough validation (~60 seconds)
-- Extended thinking for complex reasoning
-- Good for critical code or security review
-- Cost: ~$0.10-0.20
-
-### Strict Mode (`--strict`)
-- Any concern results in REJECTED
-- Use for critical paths, security code, or CI gates
-
-## Examples
-
-### Example 1: Validate a new feature
-
-```
-User: /specweave:judge src/core/auth/login.ts
-
-Claude:
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-JUDGE VERDICT: APPROVED
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Confidence: 0.85
-Files Analyzed: 1
-
-REASONING:
-The login implementation follows security best practices:
-- Password hashing uses bcrypt with appropriate cost factor
-- Rate limiting is implemented (5 attempts, 15 min lockout)
-- Input validation prevents injection attacks
-- Error messages don't leak user existence
-
-No critical or high-severity issues found.
-
-VERDICT: Implementation is solid and ready for use.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-### Example 2: Validate staged changes
-
-```
-User: /specweave:judge --staged
-
-Claude:
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-JUDGE VERDICT: CONCERNS
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Confidence: 0.78
-Files Analyzed: 3
-
-REASONING:
-Changes add new API endpoint but have some issues:
-- Missing input validation on user-provided data
-- Error messages could leak internal paths
-- No rate limiting on new endpoint
-
-🟡 HIGH: Missing Input Validation
-   User input passed directly to database query
-   📍 src/api/users.ts:45
-   💡 Add Zod schema validation before processing
-
-🟡 HIGH: Information Disclosure
-   Stack traces exposed in error responses
-   📍 src/api/users.ts:62
-   💡 Use production error handler that sanitizes output
-
-VERDICT: Address the input validation before merging.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-### Example 3: Deep validation with fixes
-
-```
-User: /specweave:judge src/payments/checkout.ts --deep --fix
-
-Claude:
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-JUDGE VERDICT: REJECTED
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Confidence: 0.92
-Files Analyzed: 1
-
-REASONING:
-Critical security issue found in payment processing:
-- API key hardcoded in source file
-- No HTTPS enforcement for payment requests
-- Missing idempotency key handling
-
-🔴 CRITICAL: Hardcoded API Key
-   Stripe API key exposed in source code
-   📍 src/payments/checkout.ts:12
-   💡 Move to environment variable:
-   ```typescript
-   // Before (INSECURE)
-   const stripe = new Stripe('sk_live_xxx...');
-
-   // After (SECURE)
-   const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
-   ```
-
-🔴 CRITICAL: No HTTPS Enforcement
-   Payment requests may go over HTTP
-   📍 src/payments/checkout.ts:34
-   💡 Add protocol check:
-   ```typescript
-   if (process.env.NODE_ENV === 'production' && !req.secure) {
-     return res.status(403).json({ error: 'HTTPS required' });
-   }
-   ```
-
-VERDICT: MUST FIX before deployment - security critical.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Difference from /specweave:qa
-
-| Aspect | `/specweave:qa` | `/specweave:judge` |
-|--------|-----------------|-------------------|
-| **Scope** | Increments only | Any files |
-| **Input** | Increment ID | Files, git diff |
-| **Pattern** | 7-dimension scoring | Judge LLM reasoning |
-| **Focus** | Spec quality, risks | Code correctness |
-| **When** | Before increment close | After any work |
-
-## Best Practices
-
-1. **Use frequently**: Run during development, not just at the end
-2. **Use `--staged`**: Validate before committing
-3. **Use `--strict` for critical code**: Payment, auth, security
-4. **Fix CRITICAL issues immediately**: Never ignore these
-5. **Address CONCERNS before release**: They matter
-6. **Use after bug fixes**: Especially effective when work has definitive expected behavior
-
-**Simplest workflow** - just mention "llm judge" in your prompt:
-```
-"llm judge my fix"
-"use llm judge on this"
-```
-
-Claude will automatically gather context and apply the pattern - no need to specify files.
-
-This follows the [LLM-as-Judge pattern](https://www.anthropic.com/engineering/multi-agent-research-system) - single LLM call with structured evaluation proves more consistent than multiple validation passes.
-
-## Limitations
-
-- ❌ Doesn't execute tests (use test runners)
-- ❌ Doesn't auto-apply fixes (only suggests)
-- ❌ May miss domain-specific issues
-- ❌ Not a replacement for human review
-
-## Related
-
-- `/specweave:qa` - Increment-bound quality assessment
-- `/specweave-core:code-review` - Prompt-based code review
-- `ado-sync-judge` agent - Uses judge pattern for sync validation

package/plugins/specweave-core/.claude-plugin/plugin.json

@@ -1,21 +0,0 @@
-{
-  "name": "specweave-core",
-  "description": "Core software engineering practices including code review, refactoring, architecture design, design patterns, SOLID principles, clean code, technical debt management, and software craftsmanship.",
-  "version": "0.24.0",
-  "author": {
-    "name": "Anton Abyzov",
-    "email": "anton.abyzov@gmail.com"
-  },
-  "homepage": "https://spec-weave.com",
-  "repository": "https://github.com/anton-abyzov/specweave",
-  "license": "MIT",
-  "keywords": [
-    "code-review",
-    "refactoring",
-    "architecture",
-    "design-patterns",
-    "clean-code",
-    "solid",
-    "specweave"
-  ]
-}

package/plugins/specweave-core/commands/architecture-review.md

@@ -1,288 +0,0 @@
-# /specweave-core:architecture-review
-
-Review software architecture for scalability, maintainability, security, and alignment with best practices.
-
-You are an expert software architect who evaluates system design and architecture decisions.
-
-## Your Task
-
-Perform comprehensive architecture reviews covering design patterns, scalability, security, and technical debt.
-
-### 1. Architecture Review Framework
-
-**Evaluation Dimensions**:
-- ✅ Scalability: Can it handle 10x growth?
-- ✅ Maintainability: Can new developers understand it?
-- ✅ Security: Defense in depth, least privilege
-- ✅ Performance: Meets latency/throughput requirements
-- ✅ Reliability: Fault tolerance, disaster recovery
-- ✅ Cost: Infrastructure and operational costs
-- ✅ Observability: Logging, monitoring, tracing
-
-### 2. Architecture Patterns Assessment
-
-**Microservices vs Monolith**:
-```yaml
-Monolith (Start Here):
-  Pros:
-    - Simple deployment
-    - Easy local development
-    - No distributed system complexity
-    - Lower operational overhead
-  Cons:
-    - Scaling entire app (not individual services)
-    - Slower build times as codebase grows
-    - Technology lock-in
-  
-  Best for:
-    - Startups, MVPs
-    - Small teams (< 10 engineers)
-    - Well-defined domain
-
-Microservices (Migrate When Needed):
-  Pros:
-    - Independent scaling
-    - Technology diversity
-    - Team autonomy
-    - Fault isolation
-  Cons:
-    - Distributed system complexity
-    - Higher operational overhead
-    - Network latency
-    - Data consistency challenges
-  
-  Best for:
-    - Large teams (> 20 engineers)
-    - Clear service boundaries
-    - Different scaling needs per service
-```
-
-**Event-Driven Architecture**:
-```typescript
-// Use when:
-// - Decoupling producers/consumers
-// - Async processing
-// - Event sourcing
-// - CQRS pattern
-
-interface EventBus {
-  publish(event: DomainEvent): Promise<void>;
-  subscribe<T>(eventType: string, handler: (event: T) => Promise<void>): void;
-}
-
-// Example: Order processing
-await eventBus.publish({
-  type: 'OrderPlaced',
-  orderId: '123',
-  userId: 'user-456',
-  total: 99.99,
-});
-
-// Multiple subscribers (inventory, email, analytics)
-eventBus.subscribe('OrderPlaced', inventoryService.reserve);
-eventBus.subscribe('OrderPlaced', emailService.sendConfirmation);
-eventBus.subscribe('OrderPlaced', analyticsService.track);
-```
-
-**CQRS (Command Query Responsibility Segregation)**:
-```typescript
-// Separate read and write models
-
-// Command (Write)
-class CreateUserCommand {
-  execute(data: UserData) {
-    // Validate
-    // Save to write database (normalized)
-    // Publish UserCreatedEvent
-  }
-}
-
-// Query (Read)
-class GetUserProfile {
-  execute(userId: string) {
-    // Read from read database (denormalized, optimized for reads)
-    // May use cache, different DB tech (e.g., Elasticsearch)
-  }
-}
-```
-
-### 3. Scalability Review
-
-**Horizontal vs Vertical Scaling**:
-```yaml
-Horizontal Scaling (Add More Machines):
-  Requires:
-    - Stateless application servers
-    - Shared session store (Redis, database)
-    - Load balancer
-    - Database replication/sharding
-  
-  Benefits:
-    - No single point of failure
-    - Cost-effective with cloud auto-scaling
-    - Unlimited scaling potential
-
-Vertical Scaling (Bigger Machine):
-  Requires:
-    - Downtime for upgrades
-    - Eventually hits hardware limits
-  
-  Benefits:
-    - Simpler (no distributed system)
-    - No code changes needed
-```
-
-**Database Scaling Strategies**:
-```yaml
-Read Replicas:
-  - Offload read traffic (analytics, reports)
-  - Eventual consistency acceptable
-  - 80% reads, 20% writes
-
-Sharding:
-  - Partition data across multiple databases
-  - Shard key: user_id, tenant_id, region
-  - Complexity: cross-shard queries, rebalancing
-
-Caching:
-  - Redis for hot data (user sessions, product catalog)
-  - CDN for static assets
-  - Application-level caching
-```
-
-### 4. Security Architecture Review
-
-**Defense in Depth**:
-```yaml
-Network Layer:
-  - VPC with private subnets
-  - Security groups (whitelist)
-  - WAF for DDoS protection
-
-Application Layer:
-  - Input validation and sanitization
-  - Output encoding (XSS prevention)
-  - Parameterized queries (SQL injection)
-  - CSRF tokens
-  - Rate limiting
-
-Data Layer:
-  - Encryption at rest (database, S3)
-  - Encryption in transit (TLS)
-  - Secrets management (AWS Secrets Manager, Vault)
-  - Database access control (least privilege)
-
-Authentication/Authorization:
-  - Multi-factor authentication
-  - OAuth 2.0 / OpenID Connect
-  - JWT with short expiration
-  - Role-based access control (RBAC)
-```
-
-**Threat Modeling**:
-```markdown
-## STRIDE Analysis
-
-**Spoofing**: Can attacker impersonate user?
-- Mitigation: MFA, session management
-
-**Tampering**: Can attacker modify data?
-- Mitigation: Data integrity checks, audit logs
-
-**Repudiation**: Can user deny actions?
-- Mitigation: Comprehensive audit trail
-
-**Information Disclosure**: Can attacker access sensitive data?
-- Mitigation: Encryption, access control
-
-**Denial of Service**: Can attacker make system unavailable?
-- Mitigation: Rate limiting, auto-scaling, WAF
-
-**Elevation of Privilege**: Can attacker gain admin access?
-- Mitigation: Least privilege, input validation
-```
-
-### 5. Observability Review
-
-**Three Pillars**:
-```yaml
-Logging:
-  - Structured logging (JSON)
-  - Centralized (ELK, CloudWatch Logs)
-  - Request IDs for tracing
-  - Log levels: ERROR, WARN, INFO, DEBUG
-
-Metrics:
-  - RED: Rate, Errors, Duration
-  - USE: Utilization, Saturation, Errors
-  - Business metrics (orders/min, revenue)
-  - Infrastructure metrics (CPU, memory, disk)
-
-Tracing:
-  - Distributed tracing (OpenTelemetry, Jaeger)
-  - End-to-end request flow
-  - Performance bottleneck identification
-```
-
-### 6. Architecture Decision Records (ADRs)
-
-```markdown
-# ADR-001: Use PostgreSQL for Primary Database
-
-## Status
-Accepted
-
-## Context
-Need persistent storage for user data, transactions, and analytics.
-
-## Decision
-Use PostgreSQL as primary database.
-
-## Consequences
-
-**Pros**:
-- ACID compliance (strong consistency)
-- Rich query capabilities (joins, aggregations)
-- Mature ecosystem, wide adoption
-- JSON support for semi-structured data
-
-**Cons**:
-- Vertical scaling limits (mitigated with read replicas)
-- Complex sharding if needed
-- Higher cost than NoSQL for massive scale
-
-**Alternatives Considered**:
-- MongoDB: Less mature for transactions, eventual consistency
-- DynamoDB: Lock-in to AWS, limited query flexibility
-```
-
-### 7. Technical Debt Assessment
-
-**Debt Quadrant** (Martin Fowler):
-```yaml
-Reckless + Deliberate:
-  "We don't have time for design"
-  Priority: HIGH - Fix immediately
-
-Prudent + Deliberate:
-  "We must ship now, will refactor later"
-  Priority: MEDIUM - Plan refactoring sprint
-
-Reckless + Inadvertent:
-  "What's layering?"
-  Priority: HIGH - Training + mentorship
-
-Prudent + Inadvertent:
-  "Now we know how we should have done it"
-  Priority: LOW - Document for next time
-```
-
-## When to Use
-
-- Pre-launch architecture review
-- Quarterly architecture health checks
-- Scaling preparation (before 10x growth)
-- Post-incident architecture analysis
-- Acquisition due diligence
-
-Evaluate architecture like a principal engineer!