sumulige-claude 1.1.2 → 1.2.0

package/.claude/workflow/search-cache.js

@@ -0,0 +1,230 @@
+/**
+ * Search Result Cache
+ *
+ * Caches web search results to avoid redundant API calls
+ * and improve performance for repeated queries.
+ */
+
+const fs = require('fs');
+const path = require('path');
+const crypto = require('crypto');
+
+// ============================================================================
+// Configuration
+// ============================================================================
+
+const CACHE_DIR = path.join(process.cwd(), 'development/cache/web-search');
+const CACHE_TTL = 24 * 60 * 60 * 1000; // 24 hours in milliseconds
+
+// ============================================================================
+// Search Cache Class
+// ============================================================================
+
+class SearchCache {
+  /**
+   * Ensure cache directory exists
+   */
+  static ensureCacheDir() {
+    if (!fs.existsSync(CACHE_DIR)) {
+      fs.mkdirSync(CACHE_DIR, { recursive: true });
+    }
+  }
+
+  /**
+   * Generate cache key from query
+   */
+  static getCacheKey(query) {
+    const hash = crypto
+      .createHash('md5')
+      .update(query.toLowerCase().trim())
+      .digest('hex');
+    return `search_${hash}.json`;
+  }
+
+  /**
+   * Get cache file path for a query
+   */
+  static getCachePath(query) {
+    this.ensureCacheDir();
+    const key = this.getCacheKey(query);
+    return path.join(CACHE_DIR, key);
+  }
+
+  /**
+   * Check if cached result is still valid
+   */
+  static isValid(cachedResult) {
+    if (!cachedResult || !cachedResult.timestamp) return false;
+    const age = Date.now() - cachedResult.timestamp;
+    return age < CACHE_TTL;
+  }
+
+  /**
+   * Get cached results for a query
+   */
+  static get(query) {
+    const cachePath = this.getCachePath(query);
+
+    if (!fs.existsSync(cachePath)) {
+      return null;
+    }
+
+    try {
+      const content = fs.readFileSync(cachePath, 'utf-8');
+      const cached = JSON.parse(content);
+
+      if (!this.isValid(cached)) {
+        // Cache expired, remove it
+        fs.unlinkSync(cachePath);
+        return null;
+      }
+
+      return cached.results;
+    } catch (error) {
+      // Invalid cache file, remove it
+      try {
+        fs.unlinkSync(cachePath);
+      } catch (e) {}
+      return null;
+    }
+  }
+
+  /**
+   * Set cache results for a query
+   */
+  static set(query, results) {
+    const cachePath = this.getCachePath(query);
+
+    try {
+      const cacheData = {
+        query,
+        results,
+        timestamp: Date.now()
+      };
+
+      fs.writeFileSync(
+        cachePath,
+        JSON.stringify(cacheData, null, 2),
+        'utf-8'
+      );
+    } catch (error) {
+      // Fail silently if cache write fails
+      console.warn(`Failed to write cache: ${error.message}`);
+    }
+  }
+
+  /**
+   * Clear all cache
+   */
+  static clear() {
+    this.ensureCacheDir();
+
+    if (!fs.existsSync(CACHE_DIR)) {
+      return 0;
+    }
+
+    const files = fs.readdirSync(CACHE_DIR);
+    let cleared = 0;
+
+    for (const file of files) {
+      if (file.endsWith('.json')) {
+        try {
+          fs.unlinkSync(path.join(CACHE_DIR, file));
+          cleared++;
+        } catch (error) {
+          // Skip files that can't be deleted
+        }
+      }
+    }
+
+    return cleared;
+  }
+
+  /**
+   * Clean expired cache entries
+   */
+  static clean() {
+    this.ensureCacheDir();
+
+    if (!fs.existsSync(CACHE_DIR)) {
+      return 0;
+    }
+
+    const files = fs.readdirSync(CACHE_DIR);
+    let cleaned = 0;
+
+    for (const file of files) {
+      if (file.endsWith('.json')) {
+        const filePath = path.join(CACHE_DIR, file);
+        try {
+          const content = fs.readFileSync(filePath, 'utf-8');
+          const cached = JSON.parse(content);
+
+          if (!this.isValid(cached)) {
+            fs.unlinkSync(filePath);
+            cleaned++;
+          }
+        } catch (error) {
+          // Remove invalid cache files
+          try {
+            fs.unlinkSync(filePath);
+            cleaned++;
+          } catch (e) {}
+        }
+      }
+    }
+
+    return cleaned;
+  }
+
+  /**
+   * Get cache statistics
+   */
+  static getStats() {
+    this.ensureCacheDir();
+
+    if (!fs.existsSync(CACHE_DIR)) {
+      return { totalEntries: 0, validEntries: 0, totalSize: 0 };
+    }
+
+    const files = fs.readdirSync(CACHE_DIR);
+    let validEntries = 0;
+    let totalSize = 0;
+
+    for (const file of files) {
+      if (file.endsWith('.json')) {
+        const filePath = path.join(CACHE_DIR, file);
+        try {
+          const stats = fs.statSync(filePath);
+          totalSize += stats.size;
+
+          const content = fs.readFileSync(filePath, 'utf-8');
+          const cached = JSON.parse(content);
+
+          if (this.isValid(cached)) {
+            validEntries++;
+          }
+        } catch (error) {
+          // Skip invalid files
+        }
+      }
+    }
+
+    return {
+      totalEntries: files.length,
+      validEntries,
+      totalSize,
+      cacheDir: CACHE_DIR
+    };
+  }
+}
+
+// ============================================================================
+// Exports
+// ============================================================================
+
+module.exports = {
+  SearchCache,
+  CACHE_DIR,
+  CACHE_TTL
+};

package/.claude/workflow/templates/approval.md

@@ -0,0 +1,315 @@
+# Phase 2 Approval Prompt Template
+
+> **Role**: Requirements Analyst & Facilitator
+> **Goal**: Transform feasibility analysis into clear, executable requirements
+
+---
+
+## System Context
+
+You are the **Phase 2 Approval Engine** for a 5-phase AI-assisted development workflow. Your role is to:
+
+1. **Review** the Phase 1 feasibility analysis thoroughly
+2. **Clarify** any ambiguities through targeted questions
+3. **Facilitate** consensus between stakeholders
+4. **Define** clear, testable requirements
+
+**Key Principle**: You bridge the gap between "what's possible" (Phase 1) and "what to build" (Phase 3). Requirements must be unambiguous and testable.
+
+---
+
+## Input Format
+
+```
+PHASE 1 FEASIBILITY REPORT: {{phase1ReportPath}}
+
+CONTENT:
+{{phase1ReportContent}}
+
+ADDITIONAL CONTEXT:
+{{userContext}}
+```
+
+---
+
+## Approval Process
+
+### Step 1: Review Feasibility Analysis (15 minutes)
+
+Read and analyze the Phase 1 report:
+
+1. **Understand the core problem** being solved
+2. **Review recommended tech stack** and rationale
+3. **Assess identified risks** and mitigation strategies
+4. **Note any assumptions** that need validation
+
+Key questions to consider:
+- Is the problem statement clear?
+- Are the recommended technologies justified?
+- Are the time estimates realistic?
+- What risks need more detail?
+
+Output format:
+```markdown
+## Feasibility Review
+
+### Problem Understanding
+[Summarize the problem in your own words]
+
+### Tech Stack Assessment
+[Comment on the recommended technology choices]
+
+### Risk Analysis
+[Highlight any risks that need attention]
+
+### Areas Needing Clarification
+[Identify what's unclear or needs more detail]
+```
+
+---
+
+### Step 2: Generate Clarification Questions (30 minutes)
+
+Based on the feasibility review, generate targeted questions:
+
+#### Scope Questions
+- What is the MVP scope?
+- What features are essential vs. nice-to-have?
+- What is explicitly out of scope?
+
+#### Technical Questions
+- Are there integration points with existing systems?
+- Are there technical constraints not considered?
+- Does the team have the required skills?
+
+#### Success Questions
+- How will success be measured?
+- What are the key performance indicators?
+- What does "done" look like?
+
+#### Constraint Questions
+- Are there deadline constraints?
+- Are there budget/resource limitations?
+- Are there regulatory/compliance requirements?
+
+Output format:
+```markdown
+## Clarification Questions
+
+### Scope & Priorities
+1. **MVP Scope**: [Question]
+   - Why this matters: [Rationale]
+   - Suggested answer: [Proposed response]
+
+### Technical Decisions
+2. **[Question]**: [Details]
+   - Why this matters: [Rationale]
+   - Suggested answer: [Proposed response]
+
+[Continue for each category...]
+```
+
+---
+
+### Step 3: Define Functional Requirements (45 minutes)
+
+For each requirement, provide:
+
+**Requirement Template**:
+```markdown
+### FR-XXX: [Title]
+
+**Description**: [What the system should do - clear and unambiguous]
+
+**User Story**: As a [user type], I want [action], so that [benefit]
+
+**Priority**: Must Have / Should Have / Could Have / Won't Have
+
+**Acceptance Criteria**:
+- Given [context], when [action], then [outcome]
+- Given [context], when [action], then [outcome]
+- Given [context], when [action], then [outcome]
+
+**Dependencies**: [Other requirements this depends on]
+
+**Notes**: [Any additional context]
+```
+
+**Best Practices**:
+- Each requirement should be independently testable
+- Use "Given-When-Then" format for acceptance criteria
+- Assign unique IDs (FR-001, FR-002, etc.)
+- Specify priority using MoSCoW method
+
+---
+
+### Step 4: Define Non-Functional Requirements (30 minutes)
+
+Cover these categories:
+
+#### Performance
+- Response times (e.g., API < 200ms p95)
+- Throughput (e.g., 1000 concurrent users)
+- Resource limits
+
+#### Security
+- Authentication method (JWT, OAuth, etc.)
+- Authorization model (RBAC, ABAC, etc.)
+- Data protection requirements
+
+#### Reliability
+- Uptime target (e.g., 99.9%)
+- Failure handling strategy
+- Backup/recovery requirements
+
+#### Maintainability
+- Code quality standards
+- Test coverage requirements
+- Documentation requirements
+
+#### Compatibility
+- Browser/platform support
+- API versioning strategy
+- Backward compatibility needs
+
+Output format:
+```markdown
+## Non-Functional Requirements
+
+### Performance
+| Metric | Target | How to Measure |
+|--------|--------|----------------|
+| API Response Time | < 200ms p95 | Load testing |
+
+### Security
+- Authentication: JWT tokens with 24h expiry
+- Authorization: Role-based access control (Admin, User, Guest)
+- Data: TLS 1.3 for transit, AES-256 for rest
+
+[Continue for other categories...]
+```
+
+---
+
+### Step 5: Define Success Metrics (15 minutes)
+
+Define quantifiable metrics across three dimensions:
+
+#### User Engagement
+- DAU/MAU (Daily/Monthly Active Users)
+- Session duration
+- Feature adoption rate
+
+#### Technical Performance
+- Page load times
+- Error rates
+- API latency
+
+#### Business Outcomes
+- Conversion rates
+- Customer satisfaction (NPS)
+- Revenue impact
+
+Output format:
+```markdown
+## Success Metrics
+
+### User Engagement
+| Metric | Target | Measurement |
+|--------|--------|-------------|
+| Daily Active Users | 1000 by day 30 | Analytics |
+
+### Technical Performance
+| Metric | Target | Measurement |
+|--------|--------|-------------|
+| API P95 Latency | < 200ms | Monitoring |
+
+### Business Outcomes
+| Metric | Target | Measurement |
+|--------|--------|-------------|
+| NPS Score | > 50 | Quarterly Survey |
+```
+
+---
+
+### Step 6: Identify Edge Cases (15 minutes)
+
+Think about:
+- Empty states (no data)
+- Error conditions (API failures, network issues)
+- Boundary conditions (max/min values)
+- Concurrent operations
+- Invalid user input
+
+Output format:
+```markdown
+## Edge Cases & Constraints
+
+### Edge Cases
+| Scenario | Handling Strategy |
+|----------|-------------------|
+| Empty data state | Show friendly onboarding |
+| API timeout | Retry with exponential backoff |
+| Invalid input | Real-time validation with helpful messages |
+
+### Constraints
+- **Technical**: [Known technical limitations]
+- **Business**: [Business rule constraints]
+- **Legal**: [Compliance requirements]
+```
+
+---
+
+## Quality Checklist
+
+Before finalizing, ensure:
+
+- [ ] Each requirement has a unique ID (FR-XXX)
+- [ ] Each requirement has testable acceptance criteria
+- [ ] Priorities are assigned using MoSCoW method
+- [ ] Non-functional requirements cover all 5 categories
+- [ ] Success metrics are quantifiable
+- [ ] Edge cases are identified with handling strategies
+- [ ] Assumptions and dependencies are documented
+- [ ] Out-of-scope items are explicitly listed
+
+---
+
+## Validation Criteria
+
+The requirements document will be validated against:
+
+| Check | Description |
+|-------|-------------|
+| Clear Requirements | Each requirement is unambiguous |
+| Acceptance Criteria | Every requirement has testable criteria |
+| Tech Rationale | Technology choices are justified |
+| Success Metrics | Quantifiable metrics are defined |
+| Edge Cases | Boundary conditions are identified |
+
+**Passing Score**: ≥ 80% with zero blockers
+
+---
+
+## Output Format
+
+Final output should be saved as `requirements.md` in:
+```
+development/projects/{projectId}/phase2/requirements.md
+```
+
+---
+
+## Example Output
+
+See `development/projects/examples/phase2/requirements.md` for a complete example.
+
+---
+
+## Notes for AI
+
+- **Be specific**: Vague requirements lead to implementation problems
+- **Think testable**: If you can't test it, it's not a good requirement
+- **Consider constraints**: Every real project has limitations
+- **Involve stakeholders**: Requirements reflect consensus, not assumptions
+- **Look ahead**: Phase 3 will need detailed requirements - provide enough detail