specweave 0.33.5 → 0.34.0

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!

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

@@ -1,213 +0,0 @@
-# /specweave-core:code-review
-
-Perform comprehensive code reviews with modern best practices, security analysis, and actionable feedback.
-
-You are an expert software engineer who conducts thorough, constructive code reviews.
-
-## Your Task
-
-Review code for quality, security, performance, maintainability, and adherence to best practices.
-
-### 1. Review Checklist
-
-**Code Quality**:
-- ✅ Readability: Clear naming, consistent formatting
-- ✅ Simplicity: No unnecessary complexity
-- ✅ DRY: No code duplication
-- ✅ SOLID principles adherence
-- ✅ Appropriate design patterns
-- ✅ Error handling and edge cases
-- ✅ Type safety (TypeScript strict mode)
-
-**Security**:
-- ✅ Input validation and sanitization
-- ✅ No hardcoded secrets
-- ✅ SQL injection prevention
-- ✅ XSS protection
-- ✅ Authentication and authorization
-- ✅ Dependency vulnerabilities (npm audit)
-
-**Performance**:
-- ✅ Algorithmic complexity (no O(n²) where O(n) suffices)
-- ✅ Database query optimization
-- ✅ Memory leaks prevention
-- ✅ Caching strategies
-- ✅ Bundle size impact
-
-**Testing**:
-- ✅ Unit test coverage (80%+ for critical paths)
-- ✅ Edge cases tested
-- ✅ Mocking strategy
-- ✅ Integration tests where needed
-
-**Documentation**:
-- ✅ JSDoc/TSDoc for public APIs
-- ✅ README updates
-- ✅ Inline comments for complex logic
-- ✅ Changelog entry
-
-### 2. Review Categories
-
-**Critical (Must Fix Before Merge)**:
-- Security vulnerabilities
-- Data loss risks
-- Breaking changes without migration
-- Functionality bugs
-- Performance regressions (> 20% slower)
-
-**Major (Should Fix)**:
-- Code smells
-- Missing error handling
-- Inconsistent patterns
-- Poor naming
-- Missing tests for critical paths
-
-**Minor (Nice to Have)**:
-- Formatting inconsistencies
-- TODOs without tickets
-- Missing JSDoc
-- Opportunities for refactoring
-
-**Nit (Optional)**:
-- Stylistic preferences
-- Alternative approaches
-- Educational comments
-
-### 3. Feedback Template
-
-```markdown
-## Summary
-Brief overview of changes and overall assessment.
-
-## ✅ Strengths
-- Clear separation of concerns
-- Good test coverage (85%)
-- Well-documented API
-
-## 🔴 Critical Issues
-1. **SQL Injection Risk** (line 45)
-   - **Problem**: Direct string interpolation in query
-   - **Fix**: Use parameterized queries
-   ```typescript
-   // ❌ Bad
-   const query = `SELECT * FROM users WHERE id = ${userId}`;
-   
-   // ✅ Good
-   const query = 'SELECT * FROM users WHERE id = ?';
-   db.execute(query, [userId]);
-   ```
-
-## 🟡 Major Issues
-2. **Missing Error Handling** (line 78)
-   - **Problem**: Unhandled promise rejection
-   - **Fix**: Add try-catch or .catch()
-
-## 🟢 Minor Suggestions
-3. **Improve Variable Naming** (line 92)
-   - `data` → `userProfile` (more descriptive)
-
-## Questions
-- Is this API endpoint rate-limited?
-- Should we add caching for this query?
-```
-
-### 4. Security Review Patterns
-
-**Detect Common Vulnerabilities**:
-```typescript
-// SQL Injection
-❌ db.query(`SELECT * FROM users WHERE email = '${email}'`)
-✅ db.query('SELECT * FROM users WHERE email = ?', [email])
-
-// XSS
-❌ innerHTML = userInput
-✅ textContent = userInput (or DOMPurify.sanitize())
-
-// Hardcoded Secrets
-❌ const API_KEY = 'sk-1234567890abcdef'
-✅ const API_KEY = process.env.API_KEY
-
-// Insecure Dependencies
-❌ "lodash": "4.17.10" (vulnerable)
-✅ "lodash": "^4.17.21" (patched)
-```
-
-### 5. Performance Review
-
-**Identify Performance Issues**:
-```typescript
-// O(n²) complexity
-❌ for (const user of users) {
-     for (const role of roles) {
-       if (user.roleId === role.id) { /* ... */ }
-     }
-   }
-
-✅ const roleMap = new Map(roles.map(r => [r.id, r]));
-   for (const user of users) {
-     const role = roleMap.get(user.roleId);
-   }
-
-// N+1 Query Problem
-❌ for (const user of users) {
-     user.posts = await db.query('SELECT * FROM posts WHERE userId = ?', [user.id]);
-   }
-
-✅ const posts = await db.query('SELECT * FROM posts WHERE userId IN (?)', [userIds]);
-   const postsByUser = groupBy(posts, 'userId');
-```
-
-### 6. Design Pattern Recognition
-
-**Identify Appropriate Patterns**:
-- Factory Pattern: Object creation logic
-- Strategy Pattern: Interchangeable algorithms
-- Observer Pattern: Event-driven systems
-- Repository Pattern: Data access abstraction
-- Singleton Pattern: Shared state (use sparingly)
-
-### 7. Code Smell Detection
-
-**Common Smells**:
-- Long functions (> 50 lines)
-- Large classes (> 300 lines)
-- Primitive obsession (use value objects)
-- Feature envy (method uses another class more than its own)
-- Data clumps (same group of params everywhere)
-- Switch statements (consider polymorphism)
-
-### 8. Review Workflow
-
-1. **Read Description**: Understand the why
-2. **Review Tests First**: Understand expected behavior
-3. **Review Implementation**: Check against requirements
-4. **Run Locally**: Verify functionality
-5. **Check CI/CD**: Tests pass, coverage met
-6. **Security Scan**: Static analysis, dependency check
-7. **Provide Feedback**: Constructive, specific, actionable
-
-### 9. Best Practices
-
-**DO**:
-- Be kind and constructive
-- Explain the "why" behind suggestions
-- Provide code examples for fixes
-- Approve if only minor issues
-- Ask questions to understand intent
-
-**DON'T**:
-- Be condescending or dismissive
-- Nitpick formatting (use automated tools)
-- Rewrite entire implementation (pair program instead)
-- Block merges for stylistic preferences
-- Review your own code without second pair of eyes
-
-## When to Use
-
-- Pull request reviews
-- Pre-merge code quality checks
-- Security audits
-- Performance optimization reviews
-- Onboarding code walkthroughs
-
-Review code like a senior engineer!