moicle 1.3.1 → 1.4.0

package/assets/skills/deep-debug/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: deep-debug
+description: Deep bug investigation workflow for hard-to-trace errors. Systematic root cause analysis — no guessing, no blind fixes. Use when user says "deep debug", "deep-debug", "trace bug", "find root cause", "hard bug", "investigate bug".
+---
+
+# Deep Bug Investigation Workflow
+
+Dành cho bug khó, fix nhiều lần không được. KHÔNG đoán mò — trace từng bước đến root cause.
+
+## Step 1: Thu thập evidence
+
+Ghi lại chính xác, KHÔNG diễn giải:
+
+- Error message nguyên văn
+- Stack trace: file, line number, call chain
+- Environment nào bị (production/staging/local)
+- Lỗi mọi lúc hay chỉ một số case
+
+## Step 2: Verify code đang chạy
+
+KHÔNG giả định code trên production = code trên local.
+
+- Xác định chính xác version/commit đang deploy
+- So sánh với code đang đọc trên local
+- Nếu KHÁC NHAU → đọc đúng version đang deploy trước khi phân tích tiếp
+
+## Step 3: Trace execution path
+
+Đây là bước quan trọng nhất. Đi từ entry point → đến dòng lỗi. Trace TỪNG bước, KHÔNG nhảy cóc.
+
+### 3a. Entry point → Error line
+
+- Request/event/job đi vào từ đâu?
+- Function nào gọi function nào? Theo đúng stack trace.
+- Data được truyền qua các layer thế nào?
+
+### 3b. Data ở dòng lỗi đến từ đâu?
+
+- Biến bị lỗi được tạo/load từ đâu?
+- Load trực tiếp từ source (DB, API) hay từ cache/session?
+- Có qua serialize → unserialize không?
+- Có qua transform/convert nào không?
+
+### 3c. Type & state tại thời điểm lỗi
+
+- Type thực tế của biến là gì? (string, object, null, enum...)
+- Code expect type gì?
+- Tại sao type thực tế khác type expected?
+
+### 3d. Framework internals (khi lỗi trong vendor/library)
+
+- Đọc source code tại ĐÚNG line number từ stack trace
+- Trace ngược: ai gọi method đó, với argument gì
+- Điều kiện nào khiến code đi vào branch gây lỗi
+
+## Step 4: Tìm root cause — Trả lời 3 câu
+
+1. **Tại sao lỗi?** — Nguyên nhân kỹ thuật cụ thể
+2. **Tại sao trước đây không lỗi?** — Cái gì thay đổi
+3. **Điều kiện reproduce?** — Khi nào lỗi, khi nào không
+
+Nếu chưa trả lời được cả 3 → quay lại Step 3, trace thêm.
+
+## Step 5: Check các nguồn state ẩn
+
+Bug "lúc được lúc không" thường do state ẩn. Check theo thứ tự:
+
+### Cache / Serialization
+
+- Object lấy từ cache có mất internal state không? (transient fields, lazy-loaded properties, runtime caches)
+- Cache cũ chứa data format cũ, code mới expect format mới?
+- Serialize/unserialize có thay đổi type không? (int↔float, null handling, enum↔string)
+
+### Database / Storage
+
+- Collation, encoding có ảnh hưởng comparison không?
+- Default value trong DB có match code expectation không?
+- Schema đã update trên production chưa?
+
+### Runtime cache / Compiled cache
+
+- Có compiled/cached config, routes, views chưa clear?
+- Bytecode cache (OPcache, compiled assets) có serve file cũ?
+- CDN/proxy cache serve asset cũ?
+
+### Environment
+
+- Env vars trên production có đúng/đủ không?
+- Version runtime (PHP, Node, Go, Python, etc.) có khác local không?
+- Dependency version có khác không?
+
+## Step 6: Fix
+
+Chỉ fix khi đã trả lời được 3 câu ở Step 4. Fix phải:
+
+- Xử lý đúng root cause, không phải symptom
+- Handle edge case đã phát hiện (cache stale, type mismatch)
+- Defensive ở data boundary (cache, DB, external API) — không ở internal logic
+- Không phá code path bình thường để fix edge case
+
+## Step 7: Verify
+
+- Reproduce điều kiện lỗi từ Step 4 → confirm đã fix
+- Test code path bình thường vẫn hoạt động
+- Nếu liên quan cache → test cả fresh load lẫn cached load
+- Verify đúng version đã deploy (lặp lại Step 2)
+
+## IMPORTANT
+
+- **KHÔNG ĐOÁN MÒ** — Trace evidence, không suy luận từ tên biến hay "có lẽ là..."
+- **KHÔNG FIX TRƯỚC KHI HIỂU** — Fix mà không hiểu root cause = tạo bug mới
+- **VERIFY DEPLOYED CODE** — Luôn check version đang chạy, không giả định production = local
+- **CHECK CACHE TRƯỚC** — Phần lớn bug "lúc được lúc không" là do stale cached state
+- **MỘT ROOT CAUSE** — Mỗi bug chỉ có 1 root cause. Nếu còn nhiều khả năng → trace thêm

package/assets/skills/new-feature/SKILL.md

@@ -1,317 +1,297 @@
 ---
 name: new-feature
-description: Complete feature development workflow from start to finish. Use when implementing new features, building functionality, or when user says "implement feature", "add feature", "build feature", "create feature", "new feature".
+description: DDD feature development workflow with phase-based checks and review loop. Use when implementing new features, building functionality, or when user says "implement feature", "add feature", "build feature", "create feature", "new feature".
+args: "[DOMAIN] [FEATURE]"
 ---
 
-# Feature Development Workflow
+# DDD Feature Development Workflow
 
-End-to-end workflow for developing features with feedback loops and quality gates.
+Build a new feature following DDD architecture, with automated checks after each phase and a review loop that keeps fixing until all checks pass.
 
-## IMPORTANT: Read Architecture First
+**ARGUMENTS:** `<domain> <feature>` — e.g., `wallet savings`, `notification broadcast`, `catalog products`
 
-**Before starting any phase, you MUST read the appropriate architecture reference:**
+## Read Architecture First
 
-### Global Architecture Files
-```
-~/.claude/architecture/
-├── clean-architecture.md    # Core principles for all projects
-├── flutter-mobile.md        # Flutter + Riverpod
-├── react-frontend.md        # React + Vite + TypeScript
-├── go-backend.md            # Go + Gin
-├── laravel-backend.md       # Laravel + PHP
-├── remix-fullstack.md       # Remix fullstack
-└── monorepo.md              # Monorepo structure
-```
-
-### Project-specific (if exists)
-```
-.claude/architecture/        # Project overrides
-```
-
-**Follow the structure and patterns defined in these files exactly.**
+**Before starting, MUST read TWO files:**
 
-## Recommended Agents
+1. **Core DDD spec**: `.claude/architecture/ddd-architecture.md`
+2. **Stack-specific doc**: detect stack → read the corresponding architecture doc
 
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| DESIGN | `@clean-architect` | Design based on architecture docs |
-| IMPLEMENT | `@react-frontend-dev`, `@go-backend-dev`, `@laravel-backend-dev`, `@flutter-mobile-dev`, `@remix-fullstack-dev` | Stack-specific implementation |
-| IMPLEMENT | `@db-designer` | Database schema design |
-| IMPLEMENT | `@api-designer` | API design (REST/GraphQL) |
-| REVIEW | `@code-reviewer` | Code quality review |
-| REVIEW | `@security-audit` | Security vulnerabilities check |
-| REVIEW | `@perf-optimizer` | Performance optimization |
-| TEST | `@test-writer` | Unit/integration/e2e tests |
-| COMPLETE | `@docs-writer` | Documentation (if needed) |
-
-## Workflow Overview
+### Stack Detection
+| File | Stack Doc |
+|------|-----------|
+| `go.mod` | `go-backend.md` |
+| `package.json` + `vite.config.*` | `react-frontend.md` |
+| `pubspec.yaml` | `flutter-mobile.md` |
+| `composer.json` | `laravel-backend.md` |
+| `remix.config.*` | `remix-fullstack.md` |
 
+### Architecture Files Location
 ```
-┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
-│ 1. PLAN  │──▶│ 2. DESIGN│──▶│3. IMPLEMENT──▶│ 4. REVIEW│──▶│ 5. TEST  │──▶│6. COMPLETE
-└──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘
-                                                   │              │
-                                                   └──────◀───────┘
-                                                    Feedback Loop
+.claude/architecture/{name}.md     # Project-specific (priority)
+~/.claude/architecture/{name}.md   # Global
 ```
 
 ---
 
-## Phase 1: PLAN
-
-**Goal**: Understand requirements and break down into tasks
-
-### Actions
-1. Clarify requirements with user
-2. **Identify project stack** (Flutter, React, Go, Laravel, Remix, etc.)
-3. **Read the appropriate architecture doc** for this stack
-4. Identify affected files/modules based on architecture
-5. List acceptance criteria
-6. Create task breakdown using TodoWrite
-
-### Output
-```markdown
-## Feature: [Name]
-
-### Stack & Architecture
-- Stack: [Flutter/React/Go/Laravel/Remix]
-- Architecture Doc: [path to architecture file]
-
-### Requirements
-- [ ] Requirement 1
-- [ ] Requirement 2
+## Workflow
 
-### Affected Areas (based on architecture)
-- [Layer/Module 1]
-- [Layer/Module 2]
-
-### Tasks
-1. Task 1
-2. Task 2
 ```
-
-### Gate
-- [ ] Requirements clear
-- [ ] Architecture doc read
-- [ ] Scope defined based on architecture
-- [ ] Tasks broken down
+PHASE 1: Analyze & Plan
+  → PHASE 2: Build Domain Layer
+  → PHASE 3: Build Infrastructure Layer
+  → PHASE 4: Build Application Layer
+  → PHASE 5: Registration & Wiring
+  → PHASE 6: Domain Tests
+  → REVIEW LOOP (run /architect-review, fix issues, repeat until clean)
+```
 
 ---
 
-## Phase 2: DESIGN
+## PHASE 1: Analyze & Plan
+
+### 1.1 Read Architecture Docs
+1. Read `ddd-architecture.md` (core DDD rules)
+2. Read stack-specific architecture doc
+3. Extract: DDD directory structure, layer rules, hard rules, forbidden imports, check scripts
+
+### 1.2 Read Reference Module
+Pick a SMALL existing module in the project as reference. Read ALL its files to understand exact patterns:
+- Entities, value objects, events, ports, usecases
+- Service, handler, DTOs, listeners
+- Infrastructure store/API implementations
+- Registration in router/provider/registry
+
+### 1.3 Plan Feature
+Present to user:
+- All entities and their fields
+- All endpoints/screens/UI (depending on stack)
+- All domain events
+- All value objects
+- Business rules summary
+- Files to create/modify
+
+### Rule Check Phase 1
+- [ ] Architecture docs read and understood
+- [ ] Reference module read
+- [ ] Plan presented and **user CONFIRMED** before continuing
 
-**Goal**: Design feature following the project's architecture
-
-### Actions
-1. **Re-read architecture doc** for the specific stack
-2. Apply architecture principles from the doc:
-   - Identify which layers are affected
-   - Define components for each layer
-   - Follow naming conventions from doc
+---
 
-3. Design data flow based on architecture patterns
+## PHASE 2: Build Domain Layer
+
+Create in order: value objects → entities → events → ports → usecases
+
+### 2.1 Value Objects (`valueobjects/`)
+- Typed values with behavior methods
+- Status with `IsTerminal()`, `CanTransitionTo()`
+- **Only stdlib imports** — read Forbidden Imports from architecture doc
+
+### 2.2 Entities (`entities/`)
+- Constructor function/method
+- Behavior methods that raise events (state transitions, calculations)
+- Guard methods (isActive, canXxx)
+- Business error types
+- Only imports: stdlib + valueobjects + domain/shared
+
+### 2.3 Events (`events/`)
+- One file per event
+- Extend/embed base event type
+- Carry data needed by listeners (userID, amounts, names)
+
+### 2.4 Ports (`ports/`)
+- One file per interface
+- Store interfaces use domain entity types and value objects
+- DTOs for complex query results live here
+- No infrastructure imports
+
+### 2.5 UseCases (`usecases/`)
+- Constructor with port dependencies + event dispatcher
+- Split by concern: one file per action group
+- Business logic lives HERE
+- Dispatch entity events after successful save
+- **No infrastructure imports** — read Forbidden Imports from architecture doc
+
+### Rule Check Phase 2
+Run the **Domain Purity** check scripts from the stack architecture doc:
+```bash
+# Example (Go):
+go build ./internal/domain/$DOMAIN/... && echo "PASS" || echo "FAIL"
+go vet ./internal/domain/$DOMAIN/... && echo "PASS" || echo "FAIL"
+grep -rn {forbidden_imports} internal/domain/$DOMAIN/ && echo "FAIL" || echo "PASS"
+
+# Example (React):
+npx tsc --noEmit && echo "PASS" || echo "FAIL"
+grep -rn "from 'react'" src/domain/$DOMAIN/ && echo "FAIL" || echo "PASS"
+
+# Example (Flutter):
+dart analyze lib/domain/$DOMAIN/ && echo "PASS" || echo "FAIL"
+grep -rn "package:flutter" lib/domain/$DOMAIN/ && echo "FAIL" || echo "PASS"
+```
 
-### Design Template
-```markdown
-## Architecture Design
+---
 
-### Reference
-- Architecture Doc: [path]
-- Pattern: [pattern from doc]
+## PHASE 3: Build Infrastructure Layer
 
-### Layers Affected (from architecture doc)
-- Layer 1: [components]
-- Layer 2: [components]
-- Layer 3: [components]
+### 3.1 Persistence Models (if applicable)
+- ORM models, Prisma schema, Freezed classes
+- Table/collection configuration
+- Helper functions for atomic updates
 
-### Data Flow (from architecture doc)
-[Follow the data flow pattern defined in doc]
+### 3.2 Store/API Implementation
+- Implements port interfaces from domain
+- Compile-time interface check (where language supports it)
+- Mapper functions: domain entity ↔ persistence model
+- NO business logic — pure persistence/communication
+- Use context consistently
 
-### Dependencies
-[List dependencies following DI pattern from doc]
+### Rule Check Phase 3
+```bash
+# Build infrastructure layer
+{stack_build_command_for_infra}
 ```
 
-### Gate
-- [ ] Design follows architecture doc
-- [ ] Layers properly defined
-- [ ] Dependencies follow doc patterns
-
 ---
 
-## Phase 3: IMPLEMENT
+## PHASE 4: Build Application Layer
 
-**Goal**: Code the feature following the architecture doc
+### 4.1 Service
+- Thin wrapper delegating to usecases
+- Can orchestrate cross-domain calls if needed
 
-### Actions
-1. **Read implementation order from architecture doc**
-2. Follow the directory structure from doc
-3. Follow naming conventions from doc
-4. Use patterns defined in doc (DI, state management, etc.)
+### 4.2 Transport/Handler/Controller/Screen
+- Registration/wiring function: create store → usecase → service → handler → routes
+- Thin handlers: parse input → call service → return output
+- DTOs in separate file
 
-### Implementation Checklist
-```markdown
-## Implementation (following [stack] architecture)
-
-Reference: [architecture doc path]
-
-### Directory Structure (from doc)
-[Follow exact structure from architecture doc]
+### 4.3 Listeners (if domain has events)
+- One file per event
+- Side-effects only (notifications, SSE, analytics, async jobs)
+- Use background context for async work
+- Register in event bus/registry
 
-### Implementation Order (from doc)
-[Follow order defined in architecture doc]
-
-### Code Conventions (from doc)
-[Follow conventions defined in architecture doc]
+### Rule Check Phase 4
+```bash
+# Build application layer
+{stack_build_command_for_application}
 ```
 
-### Gate
-- [ ] Structure matches architecture doc
-- [ ] All layers implemented per doc
-- [ ] Code compiles without errors
-- [ ] Basic functionality works
-
 ---
 
-## Phase 4: REVIEW
-
-**Goal**: Review code quality against architecture doc
+## PHASE 5: Registration & Wiring
 
-### Actions
-1. **Compare implementation with architecture doc**
-2. Check architecture rules are followed:
-   - [ ] Layer boundaries respected
-   - [ ] Dependencies flow correctly
-   - [ ] Patterns used correctly
+### 5.1 Router/Provider Registration
+- Add routes/screens/providers for the new module
+- Wire service dependencies between modules if needed
 
-3. Security check:
-   - [ ] Input validation
-   - [ ] No sensitive data exposure
-   - [ ] Proper authentication/authorization
+### 5.2 Persistence Setup
+- Add model migrations/schemas
+- Run migrations if needed
 
-4. Performance check:
-   - [ ] Efficient queries
-   - [ ] Proper caching (if in doc)
-   - [ ] No obvious bottlenecks
+### 5.3 Event Registry
+- Register all new event listeners
+- Verify event name strings match between events and registry
 
-### Review Output
-```markdown
-## Code Review Summary
-
-### Architecture Compliance: [Pass/Fail]
-- Reference: [architecture doc]
-- Issues: [list]
-
-### Quality: [Good/Needs Work]
-- Issues: [list]
-
-### Security: [Pass/Fail]
-- Issues: [list]
-
-### Performance: [Pass/Fail]
-- Issues: [list]
+### Rule Check Phase 5
+```bash
+# Full build
+{stack_full_build_command}
 ```
 
-### Gate
-- [ ] Architecture doc followed
-- [ ] No critical issues
-- [ ] Security issues resolved
+---
 
-### Feedback Loop
-If issues found → Return to IMPLEMENT phase → Fix → Re-review
+## PHASE 6: Domain Tests
+
+### 6.1 Value Object Tests
+- All status transitions
+- Terminal states
+- Behavior methods
+- Edge cases
+
+### 6.2 Entity Tests
+- Constructor
+- State transitions
+- Event collection after state change
+- Guard methods
+- Edge cases (boundary values)
+
+### 6.3 UseCase Tests
+- Mock port interfaces
+- Happy path for each method
+- Validation errors
+- Business rules
+- Event dispatching
+
+### Rule Check Phase 6
+```bash
+# Run domain tests
+{stack_test_command_for_domain}
+```
 
 ---
 
-## Phase 5: TEST
+## REVIEW LOOP
 
-**Goal**: Ensure feature works with tests
+After all phases complete, run the architecture review. **Keep looping until ALL checks pass.**
 
-### Actions
-1. **Read testing patterns from architecture doc**
-2. Write tests following doc conventions:
-   - Test locations from doc
-   - Mocking patterns from doc
-   - Coverage expectations from doc
+```
+LOOP:
+  1. Run /architect-review {stack} {domain}
+  2. Collect violations
+  3. IF violations with severity >= MEDIUM:
+     a. Fix all violations
+     b. Run build to verify
+     c. Run tests to verify
+     d. GOTO 1
+  4. IF score >= B:
+     BREAK → Final Report
+```
 
-3. Run tests:
-   ```bash
-   # Use test command from architecture doc
-   flutter test           # Flutter
-   go test ./...          # Go
-   bun test               # React/Remix
-   php artisan test       # Laravel
-   ```
+---
 
-### Gate
-- [ ] Tests follow architecture doc patterns
-- [ ] All tests pass
-- [ ] Coverage acceptable
+## Final Report
 
-### Feedback Loop
-If tests fail → Return to IMPLEMENT → Fix → Re-test
+When review loop passes:
 
----
+```markdown
+## Feature Complete: {domain}/{feature}
 
-## Phase 6: COMPLETE
+### Files Created
+- List all new files
 
-**Goal**: Finalize and deliver the feature
+### Files Modified
+- List all modified files
 
-### Actions
-1. Final checks:
-   - [ ] All gates passed
-   - [ ] Code formatted (use formatter from doc)
-   - [ ] No TODO comments left
+### Endpoints/Screens (depending on stack)
+| Method/Route | Description |
+|-------------|-------------|
 
-2. Git operations:
-   ```bash
-   git add .
-   git commit -m "feat: [feature description]"
-   ```
+### Domain Events
+| Event | Listeners |
+|-------|-----------|
 
-3. Create PR (if applicable):
-   ```bash
-   gh pr create --title "feat: [feature]" --body "[description]"
-   ```
+### Test Coverage
+- X test files, Y test functions
+- Areas covered: value objects, entities, usecases
 
-### Completion Checklist
-- [ ] Feature follows architecture doc
-- [ ] Tests passing
-- [ ] Code reviewed
-- [ ] Committed/PR created
+### Review Status: ALL CHECKS PASS
+- Build: PASS
+- Lint: PASS
+- Domain purity: PASS
+- Tests: PASS (X/X)
+- Architecture score: {A/B}
+```
 
 ---
 
-## Quick Reference
-
-### Architecture Docs
-| Stack | Doc |
-|-------|-----|
-| All | `clean-architecture.md` |
-| Flutter | `flutter-mobile.md` |
-| React | `react-frontend.md` |
-| Go | `go-backend.md` |
-| Laravel | `laravel-backend.md` |
-| Remix | `remix-fullstack.md` |
-| Monorepo | `monorepo.md` |
-
-### Phase Summary
-| Phase | Key Actions |
-|-------|-------------|
-| PLAN | Read arch doc, clarify, breakdown |
-| DESIGN | Design per arch doc |
-| IMPLEMENT | Code per arch doc |
-| REVIEW | Check arch compliance |
-| TEST | Test per arch doc patterns |
-| COMPLETE | Commit, PR |
-
-### When to Loop Back
-- **REVIEW fails** → Return to IMPLEMENT
-- **TEST fails** → Return to IMPLEMENT
-- **Requirements change** → Return to PLAN
-
-### Success Criteria
-Feature is complete when:
-1. Follows architecture doc
-2. All acceptance criteria met
-3. All tests passing
-4. Code review passed
-5. Committed/PR created
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| PLAN | `@clean-architect` | Architecture design |
+| IMPLEMENT | Stack-specific dev agent | Code per architecture |
+| IMPLEMENT | `@db-designer` | Database schema |
+| IMPLEMENT | `@api-designer` | API design |
+| REVIEW | `@code-reviewer` | Code quality |
+| REVIEW | `@security-audit` | Security check |
+| TEST | `@test-writer` | Write tests |