sumulige-claude 1.5.1 → 1.5.2

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

@@ -1,230 +0,0 @@
-/**
- * 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

@@ -1,315 +0,0 @@
-# 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