@haposoft/cafekit 0.3.11 → 0.4.0

package/src/common/skills/impact-analysis/references/dependency-scouting.md

@@ -1,12 +1,12 @@
-# Dependency Scouting - Tìm Files Bị Ảnh Hưởng
+# Dependency Scouting - Finding Affected Files
 
-Phương pháp tìm kiếm và phân tích dependencies để xác định phạm vi tác động.
+Methods for finding and analyzing dependencies to determine impact scope.
 
 ## Scouting Strategies
 
 ### 1. Import Analysis (Direct Dependencies)
 
-Tìm files import code đã sửa:
+Find files that import the modified code:
 
 ```bash
 # JavaScript/TypeScript
@@ -35,7 +35,7 @@ grep -r "from.*utils/auth" src/
 
 ### 2. Function/Class Usage (Reverse Dependencies)
 
-Tìm nơi sử dụng functions/classes:
+Find where functions/classes are used:
 
 ```bash
 # Function calls
@@ -60,7 +60,7 @@ grep -r "validateEmail(" src/
 
 ### 3. API Endpoint Consumers
 
-Nếu sửa backend API, tìm frontend calls:
+If backend API is modified, find frontend calls:
 
 ```bash
 # Fetch/Axios calls
@@ -84,7 +84,7 @@ grep -r "api/users" src/
 
 ### 4. Database Dependencies
 
-Nếu sửa database schema:
+If database schema is modified:
 
 ```bash
 # Table usage
@@ -109,7 +109,7 @@ grep -r "prisma.user.findMany" src/
 
 ### 5. Type/Interface Dependencies
 
-Tìm nơi sử dụng types:
+Find where types are used:
 
 ```bash
 # TypeScript interfaces
@@ -134,7 +134,7 @@ grep -r "as User" src/
 
 ## Using /ck:scout for Parallel Scouting
 
-Khi có nhiều files thay đổi, sử dụng `/ck:scout` để parallel search:
+When multiple files change, use `/ck:scout` for parallel search:
 
 ```
 /ck:scout Scout dependencies for changes.

package/src/common/skills/impact-analysis/references/edge-case-identification.md

@@ -1,6 +1,6 @@
-# Edge Case Identification - Xác Định Edge Cases
+# Edge Case Identification - Identifying Edge Cases
 
-Phương pháp phát hiện và phân tích edge cases để tránh bugs tiềm ẩn.
+Methods for detecting and analyzing edge cases to avoid potential bugs.
 
 ## Edge Case Categories
 
@@ -23,10 +23,10 @@ function getUser(id: string) {
 ```
 
 **Check:**
-- [ ] Có check null/undefined trước khi access?
-- [ ] Optional chaining (`?.`) được sử dụng?
-- [ ] Nullish coalescing (`??`) cho default values?
-- [ ] Type guards cho union types?
+- [ ] Check null/undefined before access?
+- [ ] Optional chaining (`?.`) used?
+- [ ] Nullish coalescing (`??`) for default values?
+- [ ] Type guards for union types?
 
 #### Empty Collections
 
@@ -39,9 +39,9 @@ const firstUser = users.length > 0 ? users[0].name : null;
 ```
 
 **Check:**
-- [ ] Array.length check trước khi access index?
-- [ ] Empty array handling trong map/filter/reduce?
-- [ ] Object.keys() check trước khi iterate?
+- [ ] Array.length check before accessing index?
+- [ ] Empty array handling in map/filter/reduce?
+- [ ] Object.keys() check before iterating?
 
 #### Type Coercion
 
@@ -54,8 +54,8 @@ if (value !== null && value !== undefined) { }
 ```
 
 **Check:**
-- [ ] Strict equality (`===`) thay vì loose (`==`)?
-- [ ] Explicit type checks cho boolean logic?
+- [ ] Strict equality (`===`) instead of loose (`==`)?
+- [ ] Explicit type checks for boolean logic?
 - [ ] Number validation (isNaN, isFinite)?
 
 ### 2. Boundary Conditions

package/src/common/skills/impact-analysis/references/industry-techniques.md

@@ -1,10 +1,10 @@
 # Industry Techniques - Code Change Impact Analysis
 
-Tổng hợp các kỹ thuật và công cụ phân tích tác động code changes từ industry và research.
+Compilation of techniques and tools for analyzing code change impacts from industry and research.
 
-## 📚 Nguồn Tham Khảo
+## 📚 References
 
-Dựa trên research và industry best practices từ:
+Based on research and industry best practices from:
 - Academic papers (ACM, ResearchGate, arXiv)
 - Static analysis tools (NDepend, CppDepend, SonarQube)
 - Software engineering practices
@@ -12,22 +12,22 @@ Dựa trên research và industry best practices từ:
 
 ---
 
-## 🎯 Các Phương Pháp Chính
+## 🎯 Main Methods
 
 ### 1. Traceability-Based Impact Analysis
 
-**Khái niệm:**
-Sử dụng links giữa requirements, specifications, design elements, và tests để xác định phạm vi thay đổi.
+**Concept:**
+Use links between requirements, specifications, design elements, and tests to determine scope of changes.
 
-**Cách hoạt động:**
+**How it works:**
 ```
 Requirement → Design → Code → Tests
      ↓           ↓        ↓       ↓
   Change    → Impact → Affected → Test Cases
 ```
 
-**Ứng dụng trong Impact Analysis:**
-- Map code changes về requirements
+**Application in Impact Analysis:**
+- Map code changes to requirements
 - Identify affected user stories
 - Generate test scenarios từ requirements
 
@@ -53,10 +53,10 @@ Requirement → Design → Code → Tests
 
 ### 2. Dependency-Based Impact Analysis
 
-**Khái niệm:**
-Phân tích dependencies (imports, function calls, class usage) để tìm affected files.
+**Concept:**
+Analyze dependencies (imports, function calls, class usage) to find affected files.
 
-**Cách hoạt động:**
+**How it works:**
 
 #### A. Call Graph Analysis
 ```
@@ -92,7 +92,7 @@ Module B imports Module C
 - **Madge** (JavaScript): Circular dependency detection
 - **jdeps** (Java): Package dependencies
 
-**Ứng dụng:**
+**Application:**
 ```bash
 # Find all files importing authService
 grep -r "from.*authService" src/
@@ -108,10 +108,10 @@ madge --image graph.png src/
 
 ### 3. AST-Based Impact Analysis
 
-**Khái niệm:**
-Sử dụng Abstract Syntax Tree để phân tích code structure và detect changes ở semantic level.
+**Concept:**
+Use Abstract Syntax Tree to analyze code structure and detect changes at semantic level.
 
-**Cách hoạt động:**
+**How it works:**
 ```
 Source Code → Parser → AST → Analysis → Impact Report
 ```
@@ -147,9 +147,9 @@ function login(email, password, rememberMe) {
 - **Python ast module**: Python AST analysis
 - **Roslyn** (.NET): C# AST analysis
 
-**Ứng dụng:**
+**Application:**
 ```javascript
-// Detect function signature changes
+# Detect function signature changes
 const ast = parse(sourceCode);
 ast.body.forEach(node => {
   if (node.type === 'FunctionDeclaration') {
@@ -163,8 +163,8 @@ ast.body.forEach(node => {
 
 ### 4. Static Analysis-Based Impact
 
-**Khái niệm:**
-Analyze code without executing để detect issues, dependencies, và potential impacts.
+**Concept:**
+Analyze code without executing to detect issues, dependencies, and potential impacts.
 
 **Techniques:**
 
@@ -244,10 +244,10 @@ interface User {
 
 ### 5. Model-Based Impact Analysis
 
-**Khái niệm:**
-Sử dụng models (UML, architecture diagrams) để predict impact trước khi code.
+**Concept:**
+Use models (UML, architecture diagrams) to predict impact before coding.
 
-**Cách hoạt động:**
+**How it works:**
 ```
 Architecture Model → Component Dependencies → Impact Prediction
 ```
@@ -272,10 +272,10 @@ Architecture Model → Component Dependencies → Impact Prediction
 
 ### 6. Test-Based Impact Analysis
 
-**Khái niệm:**
-Sử dụng test coverage để identify affected tests và features.
+**Concept:**
+Use test coverage to identify affected tests and features.
 
-**Cách hoạt động:**
+**How it works:**
 ```
 Code Change → Test Coverage Map → Affected Tests → Affected Features
 ```
@@ -299,7 +299,7 @@ Code Change → Test Coverage Map → Affected Tests → Affected Features
 - **JaCoCo**: Java code coverage
 - **Istanbul**: JavaScript coverage
 
-**Ứng dụng:**
+**Application:**
 ```bash
 # Run tests with coverage
 npm test -- --coverage
@@ -315,10 +315,10 @@ jest --coverage --coverageReporters=html
 
 ### 7. Behavior-Driven Impact Analysis
 
-**Khái niệm:**
-Map code changes về user behaviors và scenarios (BDD approach).
+**Concept:**
+Map code changes to user behaviors and scenarios (BDD approach).
 
-**Cách hoạt động:**
+**How it works:**
 ```
 Code Change → Feature Mapping → User Scenarios → Test Scenarios
 ```
@@ -367,8 +367,8 @@ describe('Biometric Login', () => {
 
 ### 8. Feature Mapping Techniques
 
-**Khái niệm:**
-Map code files về features và user actions.
+**Concept:**
+Map code files to features and user actions.
 
 **Techniques:**
 
@@ -423,10 +423,10 @@ export function login(email: string, password: string) {
 
 ### 9. Machine Learning-Based Impact Analysis
 
-**Khái niệm:**
-Sử dụng ML models để predict impact dựa trên historical data.
+**Concept:**
+Use ML models to predict impact based on historical data.
 
-**Cách hoạt động:**
+**How it works:**
 ```
 Historical Changes + Outcomes → ML Model → Predict Impact
 ```
@@ -547,7 +547,7 @@ Code Change → Feature Impact → User Action Impact → Test Scenarios
 
 ### 4. Prioritize by Risk
 
-Sử dụng risk scoring:
+Use risk scoring:
 
 ```javascript
 const riskScore = 

package/src/common/skills/impact-analysis/references/practical-techniques-guide.md

@@ -14,8 +14,8 @@ Document này cung cấp:
 
 ## 🎯 Technique #1: Dependency Analysis (MUST HAVE)
 
-### Mục Đích
-Tìm tất cả files bị ảnh hưởng bởi code changes.
+### Purpose
+Find all files affected by code changes.
 
 ### Tools & Commands
 
@@ -23,7 +23,7 @@ Tìm tất cả files bị ảnh hưởng bởi code changes.
 
 **1. Find Direct Imports**
 ```bash
-# Tìm files import module đã sửa
+# Find files importing modified module
 grep -r "from.*authService" src/ --include="*.ts" --include="*.tsx"
 grep -r "import.*authService" src/ --include="*.ts" --include="*.tsx"
 
@@ -33,7 +33,7 @@ rg "from.*authService" src/ -t ts -t tsx
 
 **2. Find Function Calls**
 ```bash
-# Tìm files gọi function đã sửa
+# Find files calling modified function
 grep -r "login\(" src/ --include="*.ts" --include="*.tsx"
 
 # Exclude test files
@@ -57,7 +57,7 @@ madge src/services/authService.ts
 
 **4. Find API Consumers**
 ```bash
-# Tìm frontend components gọi API
+# Find frontend components calling API
 grep -r "fetch.*\/api\/auth" src/
 grep -r "axios.*\/api\/auth" src/
 grep -r "\/api\/auth" src/ --include="*.ts" --include="*.tsx"
@@ -67,7 +67,7 @@ grep -r "\/api\/auth" src/ --include="*.ts" --include="*.tsx"
 
 **Find Component Usage**
 ```bash
-# Tìm components sử dụng component đã sửa
+# Find components using modified component
 grep -r "<LoginButton" src/ --include="*.tsx"
 grep -r "LoginButton" src/ --include="*.tsx" | grep "import"
 ```
@@ -111,8 +111,8 @@ grep -r "login(" . --include="*.py"
 
 ## 🎯 Technique #2: AST-Based Analysis (NICE TO HAVE)
 
-### Mục Đích
-Phát hiện semantic changes (function signature, type changes, breaking changes).
+### Purpose
+Detect semantic changes (function signature, type changes, breaking changes).
 
 ### Tools & Setup
 
@@ -222,8 +222,8 @@ diff /tmp/before.json /tmp/after.json
 
 ## 🎯 Technique #3: Static Analysis (NICE TO HAVE)
 
-### Mục Đích
-Phát hiện code quality issues, security issues, và potential bugs.
+### Purpose
+Detect code quality issues, security issues, and potential bugs.
 
 ### Tools
 
@@ -284,8 +284,8 @@ sonar-scanner \
 
 ## 🎯 Technique #4: Test Coverage Analysis (SHOULD HAVE)
 
-### Mục Đích
-Tìm tests bị ảnh hưởng và identify untested code.
+### Purpose
+Find affected tests and identify untested code.
 
 ### Tools & Commands
 
@@ -370,8 +370,8 @@ pytest --collect-only | grep auth_service
 
 ## 🎯 Technique #5: Feature Mapping (MUST HAVE)
 
-### Mục Đích
-Map code changes về features và user actions.
+### Purpose
+Map code changes to features and user actions.
 
 ### Implementation
 
@@ -478,8 +478,8 @@ function mapFeatures(changedFiles) {
 
 ## 🎯 Technique #6: Risk Scoring (SHOULD HAVE)
 
-### Mục Đích
-Đánh giá mức độ risk của changes.
+### Purpose
+Assess risk level of changes.
 
 ### Algorithm
 

package/src/common/skills/impact-analysis/references/project-detection.md

@@ -1,6 +1,6 @@
 # Project Detection - Auto-Adapt Impact Analysis
 
-Hệ thống tự động detect và adapt Impact Analysis cho nhiều loại projects.
+System to automatically detect and adapt Impact Analysis for different project types.
 
 ## Project Type Detection
 

package/src/common/skills/impact-analysis/references/report-template.md

@@ -1,6 +1,6 @@
-# Report Template - Mẫu Báo Cáo Impact Analysis
+# Report Template - Impact Analysis Report Template
 
-Template chuẩn cho báo cáo phân tích tác động và hướng dẫn test.
+Standard template for impact analysis reports and test guidance.
 
 ## Full Report Template
 

package/src/common/skills/impact-analysis/scripts/README.md

@@ -1,15 +1,15 @@
 # Impact Analysis Scripts
 
-Helper scripts để thực hiện advanced impact analysis techniques.
+Helper scripts for performing advanced impact analysis techniques.
 
 ## 📋 Overview
 
-Các scripts này implement industry techniques từ `references/industry-techniques.md`:
+These scripts implement industry techniques from `references/industry-techniques.md`:
 
 1. **ast-analyze.js** - AST-based analysis (Technique #3)
 2. **find-dependencies.sh** - Dependency analysis (Technique #2)
 3. **calculate-risk.js** - Risk scoring (Technique #6)
-4. **run-analysis.sh** - Master script chạy tất cả
+4. **run-analysis.sh** - Master script that runs all
 
 ## 🚀 Quick Start
 

package/src/common/skills/review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: hapo:review
+description: Review recent changes for correctness, security, regressions, and maintainability after hapo:code.
+version: 1.0.0
+argument-hint: [scope]
+---
+
+# Hapo Review
+
+Review recent code changes with the spec context in mind.
+
+## Usage
+
+```bash
+/hapo:review
+/hapo:review <scope>
+```
+
+## Load First
+
+- `references/review-focus.md`
+- recent diff or changed files
+- relevant spec context when the changes came from `.specs/`
+
+## Execute
+
+1. Review recent changes or the requested scope.
+2. Prioritize:
+   - correctness
+   - security
+   - regressions
+   - maintainability
+3. Use the spec context when changes were produced from a spec workflow.
+4. Output findings by severity with concrete fixes.
+5. If there are no findings, say so clearly.
+
+## Rules
+
+- Prefer concrete, actionable findings over vague style notes.
+- Focus on code that changed.
+- Call out missing tests when the change risk is non-trivial.
+
+## Related
+
+- Command: `/review`
+- Previous skills: `/hapo:code`, `/hapo:test`

package/src/common/skills/review/references/review-focus.md

@@ -0,0 +1,28 @@
+# Review Focus
+
+## Review order
+
+1. correctness
+2. security
+3. regressions
+4. maintainability
+
+## Focus areas
+
+- Does the change satisfy the approved spec task?
+- Did the change introduce behavior outside the approved scope?
+- Are edge cases or failure paths obviously missing?
+- Are tests missing for non-trivial risk?
+
+## Good findings
+
+- concrete
+- reproducible
+- tied to changed code
+- includes a fix direction
+
+## Avoid
+
+- vague style-only comments
+- speculative refactors outside scope
+- comments on unchanged code unless it creates risk

package/src/common/skills/spec-design/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: hapo:spec-design
+description: Create technical design from approved requirements. Use after hapo:spec-requirements in Claude Code.
+version: 1.0.0
+argument-hint: <feature-name> [-y]
+---
+
+# Hapo Spec Design
+
+Translate approved requirements into architecture, interfaces, research notes, and design decisions.
+
+## Usage
+
+```bash
+/hapo:spec-design <feature-name>
+```
+
+## Load First
+
+- `references/design-discovery.md`
+- `.claude/skills/specs/templates/design.md`
+- `.claude/skills/specs/templates/research.md`
+- `.claude/skills/specs/rules/design-principles.md`
+
+## Execute
+
+1. Read `.specs/$ARGUMENTS/spec.json` first.
+2. Stop if requirements are missing or not ready.
+3. Read:
+   - `.specs/$ARGUMENTS/spec.json`
+   - `.specs/$ARGUMENTS/requirements.md`
+   - `.specs/$ARGUMENTS/design.md` when it already exists
+   - `.specs/$ARGUMENTS/research.md` when it exists
+   - `.specs/steering/` and `docs/` context when present
+4. Respect `scope_lock`. Design only for in-scope requirement IDs.
+5. Choose a discovery mode:
+   - minimal for small CRUD or UI-only changes
+   - light for extensions of existing systems
+   - full only for explicit integration, security, schema, or performance reasons
+6. Persist findings to `.specs/$ARGUMENTS/research.md` before finalizing the design.
+7. Generate `.specs/$ARGUMENTS/design.md` using the shared template.
+8. Add diagrams only when the design is genuinely multi-step or cross-boundary.
+9. Update `spec.json` with phase, timestamps, discovery mode, and validation recommendation.
+
+## Output
+
+Return:
+- design status and file path
+- chosen discovery mode and reason
+- 2-3 key findings that shaped the design
+- any deferred or out-of-scope items
+- next step: run `/spec-validate $ARGUMENTS` when validation is recommended, otherwise continue with `/hapo:spec-tasks $ARGUMENTS`
+
+## Rules
+
+- Keep design focused on architecture and interfaces, not implementation code.
+- Prefer light discovery unless a concrete trigger requires full discovery.
+- Stop if requirements use invalid numeric IDs.
+- If templates are missing, report the exact missing file.
+
+## Related
+
+- Command: `/spec-design`
+- Previous skill: `/hapo:spec-requirements`
+- Validation bridge: `/spec-validate $ARGUMENTS`
+- Next skill: `/hapo:spec-tasks $ARGUMENTS`

package/src/common/skills/spec-design/references/design-discovery.md

@@ -0,0 +1,46 @@
+# Design Discovery
+
+## Goal
+
+Pick the lightest discovery mode that still supports a solid design.
+
+## Modes
+
+### Minimal
+Use for:
+- small UI changes
+- basic CRUD
+- at most 2 clear integration points
+
+### Light
+Use for:
+- extensions to existing features
+- moderate integration work
+- pattern matching against current codebase
+
+### Full
+Use only when there is a concrete trigger:
+- external service integration
+- auth or security boundaries
+- schema or storage boundaries
+- explicit performance constraints
+- explicit user request for deep research
+
+## Default
+
+If uncertain, choose **light**.
+
+## Discovery outputs
+
+Capture only what affects the design:
+- existing patterns to follow
+- constraints from steering or docs
+- interfaces and boundaries
+- integration risks
+- deferred out-of-scope findings
+
+## Guardrails
+
+- Design only for in-scope requirement IDs.
+- Do not open new domains without approval.
+- Keep `research.md` short and decision-focused.

package/src/common/skills/spec-init/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: hapo:spec-init
+description: Initialize a new specification from a feature description. Use in Claude Code when starting spec-driven work.
+version: 1.0.0
+argument-hint: <feature-description>
+---
+
+# Hapo Spec Init
+
+Create the initial `.specs/<feature>/` structure from a concrete feature description.
+
+## Usage
+
+```bash
+/hapo:spec-init <feature-description>
+```
+
+## When to Use
+
+Use this when starting a new feature that should go through requirements, design, tasks, code, test, and review.
+
+Do not use this for tiny fixes, vague requests, or work that already has a spec folder.
+
+## Execute
+
+1. Treat `$ARGUMENTS` as the feature description only.
+2. If the description is vague, too short, or missing concrete nouns, stop and ask the user 1-2 focused clarification questions.
+3. Check `.specs/` for slug conflicts with `Glob`.
+4. Read these installed templates first:
+   - `.claude/skills/specs/templates/init.json`
+   - `.claude/skills/specs/templates/requirements-init.md`
+5. Generate a kebab-case feature name from the description.
+6. If the slug already exists, append a numeric suffix.
+7. Create `.specs/<feature-name>/spec.json` and `.specs/<feature-name>/requirements.md`.
+8. Initialize `scope_lock` in `spec.json` with:
+   - `source`
+   - `in_scope`
+   - `out_of_scope`
+   - `expansion_policy: requires-user-approval`
+9. Do not generate requirements, design, or tasks in this step.
+
+## Output
+
+Return:
+- generated feature name
+- short project summary
+- created file paths
+- next command: `/hapo:spec-requirements <feature-name>`
+
+## Rules
+
+- Keep phase separation strict.
+- Only initialize files in this step.
+- Prefer the shared `specs` templates over ad-hoc structure.
+- If templates are missing, stop and report the exact missing path.
+
+## Related
+
+- Command: `/spec-init`
+- Next skill: `/hapo:spec-requirements <feature-name>`
+- Shared resources: `.claude/skills/specs/templates/`