@leejungkiin/awkit 1.3.7 → 1.3.8

package/bin/awk.js

@@ -2201,12 +2201,12 @@ function cmdTrello(args) {
     const subCmd = args[0];
     const text = args.slice(1).join(' ');
 
-    if (!subCmd || subCmd === 'help') {
+    if (!subCmd || subCmd === 'help' || subCmd === '--help' || subCmd === '-h') {
         trelloHelp();
         return;
     }
 
-    if (!text && subCmd !== 'help') {
+    if (!text) {
         err(`Missing argument for 'trello ${subCmd}'. Usage: awkit trello ${subCmd} <text>`);
         return;
     }
@@ -2223,12 +2223,51 @@ function cmdTrello(args) {
             break;
 
         case 'item':
-            // trello-cli doesn't support adding checklist items natively.
-            // We fall back to marking an item incomplete (which implicitly creates it in some versions)
-            // or inform the user to use the REST API.
-            info(`Adding checklist item: ${text}`);
-            warn('Note: trello-cli may not support adding items. Use REST API if this fails.');
-            trelloExec(['card:check-item', '--item', text, '--state', 'incomplete']);
+            info(`Adding checklist item via REST API: ${text}`);
+            const credItem = trelloLoadCredentials();
+            const cfgItem = trelloLoadProjectConfig();
+            if (!credItem || !cfgItem) {
+                err("Credentials or config missing for REST API fallback.");
+                break;
+            }
+            
+            // 1. Get checklists
+            const clRes = spawnSync('npx', ['--yes', 'trello-cli', 'card:checklists', '--board', cfgItem.board, '--list', cfgItem.list, '--card', cfgItem.card, '--format', 'json'], { env: { ...process.env, TRELLO_KEY: credItem.api_key, TRELLO_TOKEN: credItem.api_token }, encoding: 'utf-8' });
+            
+            if (clRes.status !== 0) {
+                err(`Failed to get checklists: ${clRes.stderr || clRes.stdout}`);
+                break;
+            }
+            
+            try {
+                // Sometime trello-cli outputs to stdout along with some other logs.
+                // We extract the JSON array part.
+                const outText = clRes.stdout;
+                const jsonStr = outText.substring(outText.indexOf('['));
+                const checklists = JSON.parse(jsonStr);
+                
+                if (!checklists || checklists.length === 0) {
+                    err("No checklists found on card. Create one first using 'awkit trello checklist <name>'.");
+                    break;
+                }
+                
+                // Add to the LAST checklist (most recently appended usually)
+                const targetChecklist = checklists[checklists.length - 1];
+                const checklistId = targetChecklist.id;
+                
+                // 2. Add item via curl
+                const url = `https://api.trello.com/1/checklists/${checklistId}/checkItems?name=${encodeURIComponent(text)}&key=${credItem.api_key}&token=${credItem.api_token}`;
+                const addRes = spawnSync('curl', ['-s', '-X', 'POST', url], { encoding: 'utf-8' });
+                
+                const responseJson = JSON.parse(addRes.stdout);
+                if (responseJson.id) {
+                    ok(`Item added successfully to checklist "${targetChecklist.name}".`);
+                } else {
+                    err(`Failed to add item via REST API: ${addRes.stdout}`);
+                }
+            } catch (e) {
+                err(`Failed to parse checklists or execute curl: ${e.message}`);
+            }
             break;
 
         case 'complete':

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leejungkiin/awkit",
-  "version": "1.3.7",
+  "version": "1.3.8",
   "description": "Antigravity Workflow Kit. Unified AI agent orchestration system.",
   "main": "bin/awk.js",
   "bin": {

package/skill-packs/superpowers/skills/single-flow-task-execution/SKILL.md

@@ -110,6 +110,56 @@ digraph process {
 }
 ```
 
+## UI-First Task Ordering (Gate 4 Three-Phase — v12.3)
+
+When a task set includes UI components (COMPLEX or MODERATE), tasks MUST be ordered in three phases:
+
+### Phase A: Infrastructure Tasks
+```
+Priority: Execute FIRST
+Examples:
+  - Add dependencies (Gradle, SPM, CocoaPods)
+  - Create project structure (packages, modules, DI)
+  - Set up navigation skeleton (NavGraph, Router)
+  - Configure build variants, signing
+Gate: App MUST build successfully → proceed
+```
+
+### Phase B: UI Shell Tasks (Mock Data)
+```
+Priority: Execute SECOND, BEFORE any logic tasks
+Examples:
+  - Build all screen layouts with static/mock data
+  - Implement navigation between screens
+  - Add animations, transitions, loading/empty/error states
+  - Wire up UI components (no real API/DB calls)
+Gate: 🧪 USER TEST CHECKPOINT — user must test UI on device
+  → Present test guidance (see symphony-enforcer TP1.7)
+  → User confirms UI OK → proceed to Phase C
+  → User reports issue → fix → re-checkpoint
+```
+
+### Phase C: Logic Tasks (Per Feature)
+```
+Priority: Execute LAST, after UI is confirmed
+Examples:
+  - Replace mock data with real API/DB calls
+  - Implement business logic, validation
+  - Add error handling, retry, offline support
+  - Wire up hardware features (camera, GPS, sensors)
+Gate: 🧪 USER TEST CHECKPOINT per feature (batch small ones)
+  → Especially important for hardware-dependent features
+```
+
+### Task Sorting Rule
+```
+When creating task list from implementation plan:
+1. Tag each task: [INFRA] [UI] [LOGIC]  
+2. Sort: INFRA first → UI second → LOGIC last
+3. Within each phase: respect dependency ordering
+4. Between phases: MANDATORY checkpoint where indicated
+```
+
 ## Task Decomposition
 
 When facing multiple problems (e.g., 5 test failures across 3 files):

package/skills/admob-roas/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: admob-roas
+description: When the user wants to implement AdMob ROAS tracking, track ad impressions to Firebase, or optimize in-app ad revenue events in Native Android (Kotlin) or iOS (Swift). Also use when the user mentions "tROAS", "ad_impression", "OnPaidEventListener", "paidEventHandler", or "admob ROAS event".
+metadata:
+  version: 1.0.0
+---
+
+# ROAS Event Tracking cho AdMob (Native Android & iOS)
+
+You are an expert in mobile app analytics and AdMob monetization. Your goal is to help the user implement ROAS event tracking (`ad_impression`) for AdMob in Native Android (Kotlin) and iOS (Swift).
+
+> **🎯 Mục tiêu**: Đảm bảo Firebase Analytics nhận được sự kiện `ad_impression` kèm theo giá trị doanh thu (`value`, `currency`) mỗi khi quảng cáo hiển thị. Điều này **bắt buộc** để Google Ads / Facebook Ads có thể chạy tROAS (Target Return On Ad Spend) campaign.
+
+---
+
+## 1. Yêu Cầu Cốt Lõi (Requirements)
+
+Khi AI Agent được giao nhiệm vụ tích hợp quảng cáo (AdMob) vào dự án Native Android (Kotlin) hoặc iOS (Swift), **LUÔN** phải đảm bảo:
+- SDK `Firebase Analytics` đã được cài đặt và khởi tạo.
+- Bắt sự kiện **OnPaidEventListener** (Android) hoặc **paidEventHandler** (iOS) trên TẤT CẢ các loại quảng cáo: Banner, Interstitial, Rewarded, AppOpen, Native.
+- Convert chuẩn xác giá trị vi mô (`valueMicros` / `NSDecimalNumber`) ra giá trị thập phân thực.
+- Bắn event `ad_impression` về Firebase.
+
+---
+
+## 2. Standard Pattern: Android (Kotlin)
+
+### Bước 1: Tạo Helper/Tracker Class
+
+Tạo file `RoasTracker.kt` ở package data/analytics:
+
+```kotlin
+import android.os.Bundle
+import com.google.android.gms.ads.AdValue
+import com.google.android.gms.ads.AdapterResponseInfo
+import com.google.firebase.analytics.FirebaseAnalytics
+
+object RoasTracker {
+    fun trackAdMobImpression(
+        firebaseAnalytics: FirebaseAnalytics, 
+        adValue: AdValue, 
+        responseInfo: AdapterResponseInfo?, 
+        adFormat: String
+    ) {
+        val valueMicros = adValue.valueMicros
+        val currencyCode = adValue.currencyCode
+        val valueDouble = valueMicros / 1_000_000.0 // Convert sang dạng float/double
+        
+        val bundle = Bundle().apply {
+            putString(FirebaseAnalytics.Param.AD_PLATFORM, "admob")
+            putString(FirebaseAnalytics.Param.AD_SOURCE, responseInfo?.adSourceName ?: "AdMob")
+            putString(FirebaseAnalytics.Param.AD_FORMAT, adFormat)
+            putDouble(FirebaseAnalytics.Param.VALUE, valueDouble)
+            putString(FirebaseAnalytics.Param.CURRENCY, currencyCode)
+        }
+        
+        firebaseAnalytics.logEvent(FirebaseAnalytics.Event.AD_IMPRESSION, bundle)
+    }
+}
+```
+
+### Bước 2: Tích hợp vào Ad Lifecycle
+
+**Ví dụ với AppOpenAd / InterstitialAd:**
+```kotlin
+interstitialAd?.onPaidEventListener = OnPaidEventListener { adValue ->
+    RoasTracker.trackAdMobImpression(
+        firebaseAnalytics = FirebaseAnalytics.getInstance(context),
+        adValue = adValue,
+        responseInfo = interstitialAd?.responseInfo?.loadedAdapterResponseInfo,
+        adFormat = "interstitial"
+    )
+}
+```
+
+---
+
+## 3. Standard Pattern: iOS (Swift)
+
+### Bước 1: Tạo Helper/Tracker Struct
+
+Tạo file `RoasTracker.swift`:
+
+```swift
+import Foundation
+import FirebaseAnalytics
+import GoogleMobileAds
+
+struct RoasTracker {
+    static func trackAdMobImpression(
+        adValue: GADAdValue, 
+        responseInfo: GADAdNetworkResponseInfo?, 
+        adFormat: String
+    ) {
+        let value = adValue.value.doubleValue
+        let currency = adValue.currencyCode
+        
+        Analytics.logEvent(AnalyticsEventAdImpression, parameters: [
+            AnalyticsParameterAdPlatform: "admob",
+            AnalyticsParameterAdSource: responseInfo?.adNetworkClassName ?? "AdMob",
+            AnalyticsParameterAdFormat: adFormat,
+            AnalyticsParameterValue: value,
+            AnalyticsParameterCurrency: currency
+        ])
+    }
+}
+```
+
+### Bước 2: Tích hợp vào Ad Lifecycle
+
+**Ví dụ với GADRewardedAd:**
+```swift
+rewardedAd?.paidEventHandler = { [weak rewardedAd] adValue in
+    guard let ad = rewardedAd else { return }
+    RoasTracker.trackAdMobImpression(
+        adValue: adValue,
+        responseInfo: ad.responseInfo?.loadedAdNetworkResponseInfo,
+        adFormat: "rewarded"
+    )
+}
+```
+
+---
+
+## 4. Kiểm tra Validation
+
+Một luồng ROAS hợp lệ phải có đủ các yếu tố sau:
+1. Bạn phải đăng ký `OnPaidEventListener` NGAY SAU KHI Ad báo quá trình load thành công (trong `onAdLoaded`).
+2. Log output phải hiển thị event `ad_impression` trong Logcat (hoặc Xcode console) qua chế độ `-enable_core_ads` hoặc Firebase Verbose logging `adb shell setprop log.tag.FA VERBOSE`.
+3. Kiểm tra các event onboarding `tutorial_begin` và `tutorial_complete` để đảm bảo luồng cài đặt và sử dụng ứng dụng được tracking liên kết.

package/skills/orchestrator/SKILL.md

@@ -1,498 +1,96 @@
 ---
 name: orchestrator
-description: >-
-  Autonomous State Machine Gatekeeper — triages task complexity, enforces 7-Gate pipeline,
-  and auto-routes to the correct skill. AI tự kiểm tra trạng thái dự án và bắt buộc
-  user đi qua đúng Gate trước khi code. User KHÔNG CẦN gọi workflow bằng tay.
-  Hỗ trợ auto-detect .kiro/specs từ IDE Kiro để bypass/accelerate Gates.
-metadata:
-  stage: core
-  version: "2.3"
-  replaces: "2.2"
-  tags: [orchestrator, routing, gate, triage, state-machine, core, kiro]
-agent: Orchestrator
-trigger: always
-invocation-type: auto
-priority: 0
+description: Intelligent dispatcher — analyzes context and delegates to the right skill or workflow
 ---
 
-# Orchestrator v2.3 — Autonomous State Machine Gatekeeper
+# Orchestrator Skill
 
-> **Purpose:** Route mọi request qua hệ thống 7-Gate tự động.
-> AI tự nhận diện project state → tự quyết định gate nào cần chạy.
-> User chỉ cần nói ý tưởng, AI lo phần còn lại.
-> Hỗ trợ auto-detect `.kiro/specs` để accelerate/bypass Gates khi IDE đã tạo sẵn specs.
+## Purpose
+Route user requests to the correct workflow or skill based on context analysis.
 
----
-
-## ⚡ Core Principle
-
-```
-AI LÀ NGƯỜI GIÁM SÁT "CÁN CÂN" CỦA DỰ ÁN.
-- User không cần nhớ workflow nào để gọi
-- AI tự detect thiếu spec → tự hỏi
-- AI tự detect thiếu design → tự phác thảo
-- AI tự detect thiếu tickets → tự tạo
-- Chỉ cho phép code khi TẤT CẢ prerequisites thỏa mãn
-```
-
-### 6 Decision Principles (Auto-decide khi không cần hỏi user)
-
-```
-1. Complete > Shortcuts    — AI cost rẻ. Implement đủ, kể cả edge cases.
-2. Evidence > Assumptions  — Dựa trên data thực tế, không đoán.
-3. Standard > Custom       — Ưu tiên thư viện/pattern có sẵn.
-4. Explicit > Implicit     — Code rõ ràng, không clever tricks.
-5. Test > Trust            — Viết test, không "chắc chắn đúng".
-6. Small > Big             — Incremental changes, không big-bang.
-```
-
----
-
-## 🔍 Kiro Spec Detection (Auto-Accelerate Gates)
-
-> **Kiro** là IDE có khả năng sinh spec cấu trúc tại `.kiro/specs/`.
-> Khi phát hiện thư mục này, orchestrator tự động map nội dung vào Gate system,
-> giúp bypass/accelerate các Gates mà không cần AI tự sinh lại tài liệu.
-
-### Detection Logic (chạy ĐẦU TIÊN trước Gate check)
-
-```yaml
-kiro_detection:
-  trigger: Mỗi khi bắt đầu COMPLEX task
-  scan_path: ".kiro/specs/" (tương đối từ project root)
-
-  structure_expected:
-    .kiro/specs/
-    ├── <project-slug>/          # Top-level project spec
-    │   ├── requirements.md      # → Gate 1 (Spec)
-    │   ├── design.md            # → Gate 2 (Architecture)
-    │   └── tasks.md             # → Gate 3 (Symphony Tasks)
-    ├── <module-01>/             # Per-module specs
-    │   ├── requirements.md      # → Gate 1.5 (Module Spec)
-    │   ├── design.md            # → Gate 2 (per-module design)
-    │   └── tasks.md             # → Gate 3 (per-module tasks)
-    └── <module-02>/
-        └── ...
-
-  gate_mapping:
-    gate_1_spec:
-      pass_if: ANY requirements.md exists in .kiro/specs/
-      source: .kiro/specs/<project-slug>/requirements.md
-      action: Load as project BRIEF — bypass brainstorm-agent
-
-    gate_1_5_module_spec:
-      pass_if: ≥2 module folders (excluding project-slug) with requirements.md
-      source: .kiro/specs/<module>/requirements.md (each)
-      action: Load as module specs — bypass module-spec-writer
-
-    gate_2_architecture:
-      pass_if: ANY design.md exists in .kiro/specs/
-      source: .kiro/specs/<project-slug>/design.md + per-module design.md
-      action: Load as approved design — auto-approve (user already approved in Kiro)
-
-    gate_2_5_visual:
-      pass_if: NOT affected (Kiro doesn't produce visual designs)
-      action: Normal Gate 2.5 flow
-
-    gate_3_tasks:
-      pass_if: ANY tasks.md exists in .kiro/specs/
-      source: .kiro/specs/<module>/tasks.md (each)
-      action: Parse tasks → auto-create Symphony tickets
-
-  output_format:
-    "🔍 KIRO SPECS DETECTED at .kiro/specs/
-       📄 Requirements: {count} files (Gate 1 + 1.5 → AUTO-PASS)
-       📐 Design docs:  {count} files (Gate 2 → AUTO-PASS)
-       📋 Task lists:   {count} files (Gate 3 → AUTO-IMPORT)
-       Modules: {list module names}"
-```
-
-### Kiro Spec Priority Rules
-
-```
-1. .kiro/specs > docs/specs > docs/architecture > Brain/NeuralMemory
-   → Kiro specs LUÔN được ưu tiên khi tồn tại
-
-2. Nếu CẢ .kiro/specs VÀ docs/specs tồn tại:
-   → Dùng .kiro/specs làm source of truth
-   → Cảnh báo: "⚠️ Phát hiện cả .kiro/specs và docs/specs.
-     Sử dụng .kiro/specs làm source of truth. docs/specs có thể outdated."
-
-3. Kiro specs KHÔNG thay thế:
-   → Gate 2.5 (Visual Design) — Kiro không tạo design visuals
-   → Gate 5 (Verification) — luôn cần run tests/build
-   → NeuralMemory decisions — vẫn lưu context vào brain
-
-4. Khi code (Gate 4), AI PHẢI đối chiếu với:
-   → .kiro/specs/<module>/requirements.md (acceptance criteria)
-   → .kiro/specs/<module>/design.md (technical design)
-   → .kiro/specs/<module>/tasks.md (task checklist)
-```
-
----
-
-## 🎯 STEP 1: Complexity Triage (BẮT BUỘC)
-
-Mỗi khi nhận request từ user, orchestrator PHẢI phân loại complexity **TRƯỚC** mọi action khác.
-
-### Scoring Criteria
-
-```yaml
-factors:
-  persistence_change:  # Thay đổi Database/Storage/Model
-    score: +4
-    signals: ["database", "schema", "table", "collection", "model", "migration", "storage"]
-
-  new_feature:  # Feature hoàn toàn mới
-    score: +3
-    signals: ["tính năng mới", "new feature", "implement", "build", "tạo mới"]
-
-  multi_file:  # Ảnh hưởng nhiều file/module
-    score: +2
-    signals: [">3 files", "cross-module", "refactor lớn", "architecture"]
-
-  api_change:  # Thay đổi API contract
-    score: +2
-    signals: ["API", "endpoint", "request", "response", "contract"]
-
-  ui_only:  # Chỉ thay đổi UI/styling
-    score: +0
-    signals: ["đổi màu", "UI", "layout", "font", "padding", "margin"]
-
-  single_file_fix:  # Sửa 1 file, logic nhỏ
-    score: +0
-    signals: ["fix typo", "sửa lỗi nhỏ", "update text", "rename"]
-```
-
-### Classification
-
-```
-TRIVIAL  (score 0-2): Bypass ALL gates → Execute trực tiếp
-  Examples: đổi màu nút, sửa typo, thêm log, fix linter, update string
-
-MODERATE (score 3-5): Gate 3 + 4 + 5
-  Examples: thêm UI component, sửa logic business nhỏ, update 1-2 files
-
-COMPLEX  (score 6-10): ALL 7 Gates bắt buộc
-  Examples: thêm feature mới, thay đổi DB schema, thiết kế UI, refactor architecture, thêm API
-```
-
-### Output Format
-
-```
-🔍 TRIAGE: [TRIVIAL|MODERATE|COMPLEX] (score: N/10)
-   Factors: [list detected factors]
-   Gates required: [list gates]
-```
-
----
-
-## 🚦 STEP 2: Gate State Check (Cho COMPLEX tasks)
-
-Sau khi triage = COMPLEX, orchestrator kiểm tra **tuần tự** từng Gate.
-Dừng tại Gate ĐẦU TIÊN chưa thỏa mãn.
-
-### Gate 1: Spec Clarification 🔴
-
-```
-CHECK: Tồn tại file mô tả feature này?
-  → CHECK 1 (Kiro): .kiro/specs/<module>/requirements.md tồn tại?
-    → CÓ → AUTO-PASS Gate 1 (Kiro specs detected)
-  → CHECK 2: docs/specs/<feature>.md HOẶC docs/BRIEF.md có section liên quan
-  → CHECK 3: NeuralMemory có BRIEF/SPEC cho feature này
-
-PASS condition:
-  - .kiro/specs requirements.md tồn tại (highest priority), HOẶC
-  - docs/specs file tồn tại VÀ có nội dung rõ ràng, HOẶC
-  - NeuralMemory có BRIEF/SPEC
-
-FAIL action:
-  → Thông báo user: "Ý tưởng rất hay! Nhưng trước khi bắt tay vào code, 
-     để tôi hỏi vài câu để chốt rõ yêu cầu đã nhé."
-  → Kích hoạt: brainstorm-agent skill (Phase 2-6)
-  → Output: BRIEF.md hoặc docs/specs/<feature>.md
-  → Sau khi tạo xong → Re-check Gate 1 → Proceed Gate 1.5
-```
-
-### Gate 1.5: Module Specification 🟠
-
-```
-CHECK: Mỗi module có file spec chi tiết?
-  → CHECK 1 (Kiro): .kiro/specs/ chứa ≥2 module folders với requirements.md?
-    → CÓ → AUTO-PASS Gate 1.5 (Kiro module specs detected)
-    → Load từng .kiro/specs/<module>/requirements.md làm module spec
-  → CHECK 2: docs/specs/modules/<module>_spec.md tồn tại?
-  → CHECK 3: NeuralMemory có module specs cho project này
-
-PASS condition:
-  - .kiro/specs module folders tồn tại (highest priority), HOẶC
-  - Tất cả modules có spec file VÀ status "Approved"
-
-SKIP condition:
-  → TRIVIAL hoặc MODERATE tasks → SKIP
-  → Single-module projects (≤3 modules, không phải port) → SKIP
-  → User nói "skip spec" → SKIP
-
-MANDATORY condition:
-  → COMPLEX (score ≥6) VÀ >3 modules
-  → Port/migration projects (iOS→Android, Android→iOS)
-
-FAIL action:
-  → Thông báo user: "Trước khi thiết kế kỹ thuật, để em mô tả chi tiết
-     từng module — screens, flows, rules — để anh em hiểu rõ cùng nhau."
-  → Kích hoạt: module-spec-writer skill
-  → Output: docs/specs/modules/<module>_spec.md (per module)
-  → Sau khi tạo + approved → Re-check Gate 1.5 → Proceed Gate 2
-```
-
-### Gate 2: Architecture & Data Design 🟠
-
-```
-CHECK: Tồn tại bản thiết kế kỹ thuật đã được duyệt?
-  → CHECK 1 (Kiro): .kiro/specs/<module>/design.md tồn tại?
-    → CÓ → AUTO-PASS Gate 2 (Kiro design specs detected, pre-approved by IDE)
-    → Load design.md làm approved architecture document
-    → Lưu vào NeuralMemory: "Kiro design docs loaded for <modules>"
-  → CHECK 2: docs/architecture/<feature>_design.md tồn tại?
-  → CHECK 3: implementation_plan.md có section "Data Model" + marker "Approved"
-
-PASS condition:
-  - .kiro/specs design.md tồn tại (highest priority, auto-approved), HOẶC
-  - docs/architecture file tồn tại VÀ có marker "## Status: Approved"
-
-FAIL action:
-  → Thông báo user: "Đã có spec rồi. Giờ để tôi phác thảo thiết kế 
-     Database và API trước khi code, tránh phải sửa đi sửa lại sau nhé."
-  → Kích hoạt: spec-gate skill
-  → Output: docs/architecture/<feature>_design.md
-  → Yêu cầu user approve design
-  → Sau khi approved → Re-check Gate 2 → Proceed Gate 2.5
-```
-
-### Gate 2.5: Visual Design & UI Sync 🎨
-
-```
-CHECK: Đã có thiết kế UI/hiểu biết chung về UI chưa?
-  → Scan: docs/design/ hoặc docs/screenshot/ có ảnh/tài liệu UI
-  → HOẶC: file docs/design/<feature>.pen đã được duyệt
-
-PASS condition: Đã có ảnh UI tham chiếu HOẶC bản vẽ Pencil đính kèm.
-
-SKIP condition:
-  → Backend/Logic-only tasks (Cron, API pure, Refactor, DB Query...)
-  → User nói "skip design"
-
-FAIL action:
-  → Thông báo user: "Tính năng này có giao diện nên để đảm bảo đồng bộ, 
-     tôi sẽ phác thảo qua thiết kế bằng Pencil hoặc anh có thể gửi ảnh screenshot/vào docs/design/ trước nhé."
-  → Kích hoạt: visual-design-gate skill
-  → Output: UI layout thống nhất (ảnh / .pen file)
-  → Xác nhận approve visual preview
-  → Sau khi approved → Re-check Gate 2.5 → Proceed Gate 3
-```
-
-### Gate 3: Task Breakdown (Symphony) 🟡
-
-```
-CHECK: Có Symphony tasks liên kết feature này?
-  → CHECK 1 (Kiro): .kiro/specs/<module>/tasks.md tồn tại?
-    → CÓ → Parse tasks từ Kiro tasks.md
-    → Map task items → Symphony tickets (symphony_create_task)
-    → AUTO-IMPORT: Tạo Symphony tasks từ Kiro task list
-  → CHECK 2: symphony_available_tasks → filter by feature keyword/tag
-
-PASS condition: ≥1 task tồn tại cho feature này
-
-FAIL action:
-  → Đọc design doc từ Gate 2 (hoặc .kiro/specs design.md)
-  → Auto-generate 3-8 micro-tasks
-  → Tạo Symphony tasks (symphony_create_task cho mỗi task)
-  → Present danh sách cho user confirm
-  → Sau khi confirm → Proceed Gate 4
-```
-
-### Gate 4: Execution 🟢
-
-```
-CHECK: Có ticket đang In Progress?
-  → symphony_available_tasks(filter="in_progress")
-
-🔍 SEARCH BEFORE BUILDING (BẮT BUỘC trước khi viết code mới):
-  Layer 0 — Structural (GitNexus, CHỈ khi .gitnexus/ tồn tại):
-    → gitnexus_impact: Check blast radius của symbol cần sửa
-    → gitnexus_context: Xem 360° callers/callees trước khi code
-    → gitnexus_query: Tìm execution flows liên quan
-  Layer 1 — Tried-and-True:
-    → nmem_recall: Tìm similar problems đã giải quyết trong brain
-    → grep_search: Tìm existing utils/patterns trong codebase
-  Layer 2 — New-and-Popular:
-    → Tìm thư viện/SDK chuẩn ngành cho problem này
-    → Ưu tiên well-maintained, community-backed solutions
-  Layer 3 — First-Principles:
-    → CHỈ build from scratch khi Layer 1+2 không có solution phù hợp
-    → Ghi lý do tại sao existing solutions không đáp ứng
-
-  ⚠️ KHÔNG được skip layers! Log kết quả search vào progress report.
-
-ACTION:
-  → Nếu chưa có → Claim task tiếp theo: symphony_claim_task
-  → Code THEO TICKET, THEO DESIGN DOC, THEO search results
-  → Nếu phát hiện cần sửa schema khác design → ⛔ DỪNG:
-    "Schema change ngoài approved design detected. 
-     Quay lại Gate 2 để cập nhật design doc."
-  → Complete ticket → symphony_complete_task
-```
-
-### Gate 5: Verification 🔵
-
-```
-ACTION: Auto-trigger sau mỗi Gate 4 completion
-  → verification-gate skill (evidence before claims)
-  → Boil-the-Lake checklist (completeness check)
-  → code-review skill (nếu task phức tạp)
-  → Đối chiếu: code thực tế vs design doc
-  → OK → Task done → Auto-Next (TP4 in symphony-enforcer)
-```
-
----
-
-## 🔀 STEP 3: Slash Command Detection (Giữ lại)
-
-Nếu user dùng slash command rõ ràng → Load workflow file trực tiếp, SKIP triage.
+## Routing Logic
 
+### 1. Slash Command Detection
 ```
 User input starts with `/` → Load workflow file directly
   /plan     → workflows/lifecycle/plan.md
   /code     → workflows/lifecycle/code.md
   /debug    → workflows/lifecycle/debug.md
-  /brainstorm → brainstorm-agent skill
-  ...etc (see GEMINI.md)
+  ...etc (see GEMINI.md § 2)
 ```
 
-> **Note:** Slash commands bypass triage vì user ĐÃ BIẾT mình cần gì.
-
----
-
-## 🧠 STEP 4: Intent Detection (Fallback)
-
-Nếu KHÔNG phải slash command VÀ triage chưa rõ:
-
+### 2. Intent Detection (No slash command)
 ```yaml
 code_intent:
-  keywords: ["implement", "build", "create", "add", "code", "fix", "viết", "tạo", "làm"]
-  action: Run triage → route theo complexity
+  keywords: ["implement", "build", "create", "add", "code", "fix", "viết", "tạo"]
+  action: Suggest `/code` or `/codeExpert`
 
 debug_intent:
-  keywords: ["error", "bug", "crash", "fix", "lỗi", "sửa", "fail", "broken"]
-  action: systematic-debugging skill (bypass spec gates — debugging is reactive)
+  keywords: ["error", "bug", "crash", "fix", "lỗi", "sửa", "fail"]
+  action: Suggest `/debug` or `/debugExpert`
 
 plan_intent:
   keywords: ["plan", "design", "architect", "how to", "strategy", "thiết kế"]
-  action: Suggest Gate 1-2 flow
-
-brainstorm_intent:
-  keywords: ["brainstorm", "ý tưởng", "idea", "nên làm gì", "what should"]
-  action: brainstorm-agent skill
+  action: Suggest `/plan` or `/planExpert`
 
 context_intent:
   keywords: ["remember", "save", "continue", "where was I", "nhớ", "tiếp"]
-  action: Suggest /recap or /save-brain
+  action: Suggest `/recap` or `/save-brain`
 
-refactor_intent:
-  keywords: ["refactor", "rename", "extract", "split", "move", "restructure", "blast radius", "impact"]
-  action: gitnexus-intelligence skill (impact analysis + safe refactoring)
+ads_intent:
+  keywords: ["ads", "campaign", "CPI", "ROAS", "quảng cáo"]
+  action: Suggest `/ads-audit` or `/adsExpert`
 ```
 
----
-
-## 🗣️ Communication Style
-
-Orchestrator KHÔNG nói giọng máy móc. Dùng giọng đồng nghiệp senior:
-
+### 3. Skill Pack Check
 ```
-❌ "ERROR: Gate 1 not satisfied. Spec document missing."
-✅ "Ý tưởng rất hay! Kinh nghiệm cho thấy nếu không chốt yêu cầu trước, 
-    sau sửa cực lắm. Để tôi hỏi vài câu rồi mình chốt spec nhé?"
-
-❌ "Gate 2 failed. Architecture document required."  
-✅ "Đã hiểu yêu cầu rồi. Giờ để tôi phác thảo cấu trúc database 
-    cho anh xem trước — tránh kiểu vừa làm vừa đập đi xây lại."
-
-❌ "Execution blocked. No Symphony task found."
-✅ "Design ngon rồi! Giờ tôi bẻ ra thành 5 task nhỏ trên Symphony 
-    để track tiến độ nhé."
+If user request involves iOS-specific → Check if mobile-ios pack enabled
+If not enabled → Suggest: "awf enable-pack mobile-ios"
 ```
 
----
+### 3.5. Gate 4 Three-Phase Routing (v12.3 — AUTO-ENFORCE)
 
-## 🚫 Anti-Patterns
+> ⚠️ AI PHẢI CHỦ ĐỘNG kích hoạt — KHÔNG chờ user gọi.
+> Khi detect COMPLEX + UI → TỰ ĐỘNG announce Phase Announcement Block.
 
 ```yaml
-never_do:
-  - Cho phép code COMPLEX task mà chưa qua Gate 1-2
-  - Tự ý thêm cột DB ngoài approved design
-  - Hỏi "Bạn muốn chạy workflow nào?" — AI phải TỰ QUYẾT
-  - Tạo Symphony tickets trước khi có design doc (Gate 3 cần Gate 2)
-  - Force user qua 5 Gates cho trivial tasks
-  - Code mới mà chưa search existing solution (Search Before Building)
-  - Đồng ý approach có vấn đề mà không push back (Anti-sycophancy)
-  - Skip edge cases / error handling vì "trivial" (Boil the Lake)
-
-always_do:
-  - Hiển thị triage result trước mọi action
-  - Thông báo đang ở Gate nào khi chặn
-  - Giữ giọng thân thiện, giải thích LÝ DO chặn
-  - Cho phép user override gate: "skip gates" hoặc "bỏ qua"
-  - Re-check gates sau mỗi lần user provide input
-  - Search NeuralMemory + codebase TRƯỚC khi code mới
-  - Report DONE_WITH_CONCERNS nếu có caveats (Completion Status)
-  - Escalate sau 3 failed attempts (3-Strike Rule)
-```
-
----
-
-## 🔗 Skill Relationships
-
-```
-DELEGATES TO:
-  Gate 1 → brainstorm-agent (phỏng vấn → BRIEF.md)
-  Gate 1.5 → module-spec-writer (mô tả chi tiết per-module spec)
-  Gate 2 → spec-gate (thiết kế DB/API → design doc)
-  Gate 2.5 → visual-design-gate (thống nhất UI/UX bằng Pencil)
-  Gate 3 → symphony-enforcer (tạo + track tasks)
-  Gate 4 → relevant coding workflow (/code, /codeExpert)
-  Gate 5 → verification-gate + code-review
-
-WORKS WITH:
-  nm-memory-sync (đọc context từ NeuralMemory)
-  awf-session-restore (restore state)
-  symphony-orchestrator (đảm bảo Symphony server running)
-  gitnexus-intelligence (architectural awareness trước khi code)
-
-DOES NOT:
-  Execute code trực tiếp (delegates to workflows)
-  Modify files (chỉ route + enforce gates)
-```
-
----
-
-## 🧩 Edge Cases
-
-| Tình huống | Xử lý |
-|-----------|--------|
-| User nói "skip gates" / "bỏ qua" | Cho phép bypass, ghi cảnh báo |
-| Feature đã có partial spec | Gate 1 pass, check Gate 2 |
-| Debug request | Bypass spec gates — debugging is reactive |
-| User follow-up nhỏ sau feature done | Re-triage — thường TRIVIAL |
-| Multiple features cùng lúc | Triage TỪNG feature riêng |
-| Spec tồn tại nhưng outdated | Cảnh báo "Spec cũ, cần update?" |
-| Project chưa có docs/ folder | Tạo folder structure tự động |
-| `.kiro/specs/` tồn tại | AUTO-DETECT → accelerate Gates 1, 1.5, 2, 3 |
-| `.kiro/specs` + `docs/specs` cùng tồn tại | Ưu tiên `.kiro/specs`, cảnh báo potential conflict |
-| `.kiro/specs` chỉ có 1 module folder | Pass Gate 1, SKIP Gate 1.5 (single module) |
-| `.kiro/specs/<module>/tasks.md` format lạ | Parse best-effort, fallback tạo tasks thủ công |
-
----
-
-*orchestrator v2.3 — Autonomous State Machine Gatekeeper for AWKit (Kiro Spec Integration)*
+gate4_triage:
+  trigger: After Gate 3 (tasks created), before execution begins
+  auto_activate: true  # AI proactively triggers, no user command needed
+  
+  complex_with_ui:
+    condition: complexity == COMPLEX AND task has UI components
+    action: Enforce Three-Phase Execution
+    phases:
+      - Phase A: Infrastructure (dependencies, DI, navigation skeleton)
+        → Must build successfully before Phase B
+      - Phase B: UI Shell (all screens with mock data)
+        → TRIGGER TP1.7: User Test Checkpoint (MANDATORY)
+        → User must confirm UI OK before Phase C
+      - Phase C: Logic Integration (per feature)
+        → TRIGGER TP1.7: after each feature (batch small ones)
+    task_ordering: UI tasks MUST be grouped before logic tasks in Symphony
+  
+  moderate_with_ui:
+    condition: complexity == MODERATE AND task has UI components
+    action: Phase A+C merged, Phase B optional (recommend for hardware features)
+  
+  trivial_or_backend:
+    condition: complexity == TRIVIAL OR no UI components
+    action: Skip phases, code straight through (no checkpoints)
+  
+  detect_ui_components:
+    signals:
+      - Task mentions: screen, view, layout, UI, button, form, navigation
+      - Files include: *.xml (Android), *.swift (iOS views), *.compose, *.tsx
+      - Spec references: wireframe, mockup, design, screenshot
+```
+
+### 4. Fallback
+```
+No match → Ask clarifying question (max 2 times)
+Still unclear → Suggest `/help`
+```
+
+## Auto-Activation
+This skill is always active. It runs as the first layer before any other processing.

package/skills/symphony-enforcer/SKILL.md

@@ -4,13 +4,13 @@ description: |
   Mandatory Symphony checkpoint system. Ensures AI never forgets to create,
   update, or complete tasks in Symphony. Enforces progress reporting at every
   milestone and auto-detects task completion without waiting for user confirmation.
-  v3.4: Kiro Spec Integration, Completion Status Protocol, Search-Before-Building, Boil-the-Lake.
+  v3.5: UI-First Three-Phase Execution with User Test Checkpoints.
 metadata:
   stage: core
-  version: "3.4"
-  replaces: "v3.3"
+  version: "3.5"
+  replaces: "v3.4"
   requires: symphony-orchestrator
-  tags: [symphony, enforcement, checkpoint, task-lifecycle, core, spec-first, auto-next, kiro]
+  tags: [symphony, enforcement, checkpoint, task-lifecycle, core, spec-first, auto-next, kiro, ui-first, user-test]
 agent: Symphony Enforcer
 allowed-tools:
   - symphony_create_task
@@ -24,17 +24,14 @@ invocation-type: auto
 priority: 1
 ---
 
-# Symphony Enforcer v3.4 — Kiro Spec Integration + Completion Status Protocol
+# Symphony Enforcer v3.5 — UI-First Three-Phase Execution + User Test Checkpoints
 
 > **Purpose:** Đảm bảo AI KHÔNG BAO GIỜ quên cập nhật Symphony.
-> **Key Changes v3.4:**
-> - **Kiro Spec Integration**: Auto-detect `.kiro/specs/` → load specs + import tasks
-> - **Completion Status Protocol**: 4-status (DONE/DONE_WITH_CONCERNS/BLOCKED/NEEDS_CONTEXT)
-> - **Design Compliance (TP1.5)**: Đối chiếu schema changes vs approved design doc
-> - **Pre-Plan Gate**: Đọc spec trước khi plan, hỏi user về constraints
-> - **Auto-Lifecycle**: Liên kết task_boundary ↔ Symphony tự động
-> - **Auto-Next**: BẮT BUỘC gợi ý next steps sau mỗi task done
-> - **Atomic Git Commits**: Tự động commit sau mỗi task done
+> **Key Changes v3.5:**
+> - **Gate 4 Three-Phase Execution**: Phase A (Infra) → Phase B (UI Shell + User Test) → Phase C (Logic + User Test)
+> - **TP1.7: User Test Checkpoint**: Trigger dừng lại cho user test trên device thật
+> - **UI-First Task Ordering**: UI tasks PHẢI đi trước logic tasks trong Symphony
+> - Kế thừa tất cả features v3.4 (Kiro, Completion Status, Design Compliance).
 > **Principle:** AI tự detect completion — user KHÔNG CẦN nói "xong".
 
 ---
@@ -137,7 +134,7 @@ KHÔNG được bắt đầu work cho đến khi TẤT CẢ steps ✅.
 
 ---
 
-## Auto-Lifecycle: task_boundary ↔ Symphony (NEW v3.0)
+## Auto-Lifecycle: task_boundary ↔ Symphony (v3.5)
 
 ```
 LIÊN KẾT TỰ ĐỘNG:
@@ -145,6 +142,12 @@ LIÊN KẾT TỰ ĐỘNG:
 - task_boundary(EXECUTION) → symphony_report_progress(40%)
 - task_boundary(VERIFICATION) → symphony_report_progress(80%)
 - notify_user(BlockedOnUser=false) → TRIGGER TP2 (completion check)
+
+THREE-PHASE MAPPING (Gate 4 — COMPLEX tasks với UI):
+- Phase A done (build OK)     → report_progress(25%) + checkpoint build
+- Phase B done (UI mock)      → report_progress(45%) + TRIGGER TP1.7 (User Test)
+- Phase C per-feature done    → report_progress(50-85%) + TRIGGER TP1.7 (User Test)
+- Phase C all features done   → report_progress(90%) → Gate 5
 ```
 
 AI PHẢI giữ `current_task_id` xuyên suốt session.
@@ -152,6 +155,113 @@ Mỗi lần gọi `task_boundary` với mode mới → đồng thời report pro
 
 ---
 
+## 🚨 Three-Phase Auto-Enforcement Protocol (BẮT BUỘC — v3.5)
+
+> **Vấn đề:** AI không tự chủ động dùng Three-Phase nếu không bị ép.
+> **Giải pháp:** Auto-detect + auto-announce + auto-enforce.
+
+### Phase State Tracking
+
+AI PHẢI duy trì trạng thái phase hiện tại xuyên suốt Gate 4:
+
+```
+current_phase = "A" | "B" | "C" | "none"
+phase_b_confirmed = false | true
+checkpoint_count = 0
+```
+
+### Auto-Detection: Khi nào kích hoạt Three-Phase?
+
+Tại đầu Gate 4 (EXECUTION bắt đầu), AI PHẢI tự kiểm tra:
+
+```
+1. Task được triage là COMPLEX?
+2. Task có UI component? (detect qua):
+   → Symphony task title chứa: screen, view, UI, layout, dashboard, form
+   → Implementation plan mentions: Composable, Fragment, Activity, Screen, View
+   → Design doc tồn tại (docs/design/ hoặc docs/architecture/ có UI sections)
+   → Spec references: wireframe, mockup, screenshot
+   → Platform: Android/iOS/React Native/Flutter (hầu hết có UI)
+
+Nếu CẢ HAI điều kiện thỏa:
+   → BẮT BUỘC kích hoạt Three-Phase
+   → Hiển thị Phase Announcement Block
+```
+
+### Phase Announcement Block (BẮT BUỘC)
+
+Khi kích hoạt Three-Phase, AI PHẢI hiển thị:
+
+```
+🎯 THREE-PHASE EXECUTION ACTIVATED
+══════════════════════════════════════
+🏗️ Phase A: Infrastructure Setup
+   → {list tasks for Phase A}
+🎨 Phase B: UI Shell (Mock Data)
+   → {list tasks for Phase B}
+   → 🧪 USER TEST sau phase này
+⚡ Phase C: Logic Integration
+   → {list tasks for Phase C}
+   → 🧪 USER TEST mỗi feature
+══════════════════════════════════════
+Bắt đầu Phase A...
+```
+
+### Phase Transition Triggers (TỰ ĐỘNG)
+
+AI PHẢI tự động phát hiện khi chuyển phase:
+
+```yaml
+auto_triggers:
+  phase_a_to_b:
+    signal: Tất cả [INFRA] tasks đã done + build OK
+    action: |
+      - Announce: "🏗️ Phase A ✅ — Build thành công. Chuyển sang Phase B (UI Shell)."
+      - Set current_phase = "B"
+      - Bắt đầu code UI tasks
+
+  phase_b_to_checkpoint:
+    signal: Tất cả [UI] tasks đã done
+    action: |
+      - ⛔ DẪNG CODE NGAY LẬP TỨC
+      - TRIGGER TP1.7 (User Test Checkpoint)
+      - CHỊ user confirm "✅ OK" trước khi làm bất cứ gì khác
+      - KHÔNG được tự ý skip bước này
+
+  checkpoint_to_phase_c:
+    signal: User confirmed "✅" hoặc "OK"
+    action: |
+      - Set phase_b_confirmed = true
+      - Set current_phase = "C"
+      - Announce: "🎨 Phase B ✅ — UI đã được duyệt. Chuyển sang Phase C (Logic)."
+      - Bắt đầu code [LOGIC] tasks
+
+  phase_c_per_feature:
+    signal: 1 feature [LOGIC] đã done + có UI impact
+    action: |
+      - TRIGGER TP1.7 (mini checkpoint)
+      - Batch các features nhỏ lại nếu có thể
+```
+
+### Enforcement Rules
+
+```
+❌ VI PHạM NẶNG:
+  - Code logic (Phase C) khi phase_b_confirmed = false
+  - Skip Phase Announcement Block
+  - Code UI và Logic lẫn lộn trong cùng 1 lượt (phải tách rõ phase)
+  - Tự giả vờ user confirm để skip checkpoint
+  - Không hiển thị Phase Announcement khi Three-Phase activated
+
+✅ BẮT BUỘC:
+  - Luôn announce phase transition rõ ràng
+  - Luôn tạo hướng dẫn test CỤ THỂ (không chung chung)
+  - Luôn dùng notify_user(BlockedOnUser=true) cho checkpoints
+  - Ghi lại phase state vào NeuralMemory khi chuyển phase
+```
+
+---
+
 ## Trigger Points
 
 ### TP1: Progress Milestone
@@ -171,13 +281,16 @@ symphony_report_progress(
 )
 ```
 
-**Progress Guide:**
+**Progress Guide (Three-Phase Model):**
 ```
   10% — Task created, đang research/đọc code
-  25% — Implementation plan approved
-  40% — Bắt đầu code changes
-  60% — Code changes xong, đang test
-  80% — Tests pass, đang verification
+  20% — Implementation plan approved
+  25% — Phase A done (build OK, dependencies ready)
+  30% — Phase B bắt đầu (UI shell coding)
+  45% — Phase B done → USER TEST CHECKPOINT #1 (UI review)
+  50% — Phase C bắt đầu (logic integration)
+  50-85% — Phase C per-feature (each feature = +5-10%)
+  85% — Phase C done, đang final verification
   90% — Walkthrough/docs tạo xong
  100% — Hoàn thành (auto-trigger TP2)
 ```
@@ -229,6 +342,80 @@ File patterns:
 
 ---
 
+### TP1.7: User Test Checkpoint (NEW v3.5 — Gate 4 Three-Phase)
+
+**Khi nào:** Trigger ở 2 thời điểm chính trong Gate 4:
+
+1. **Phase B → C Transition (BẮT BUỘC cho COMPLEX):**
+   - ALL UI screens đã code xong với mock data
+   - Navigation hoạt động full flow
+   - App build và chạy OK trên emulator/device
+
+2. **Sau mỗi feature trong Phase C (COMPLEX tasks):**
+   - Feature X đã thay mock bằng real data
+   - Feature works end-to-end trên device
+
+**Điều kiện kích hoạt:**
+```
+COMPLEX + có UI component → BẮT BUỘC TP1.7
+MODERATE + có UI component → OPTIONAL (recommend cho hardware features: camera, GPS, sensors)
+TRIVIAL → SKIP
+Backend-only tasks → SKIP
+```
+
+**Action:**
+```
+1. Report progress trước: symphony_report_progress(current_task, progress)
+
+2. Present User Test Checkpoint:
+
+   🧪 USER TEST CHECKPOINT #{N}
+   ══════════════════════════════════════
+   📱 Phase: {B|C} — {phase_name}
+   📋 Đã code xong: {summary of completed work}
+   📁 Files changed: {N} files
+   
+   🔍 Hướng dẫn test:
+     1. {step 1 — cụ thể, actionable}
+     2. {step 2 — expected behavior}
+     3. {step 3 — edge case to check}
+   
+   ⏳ Anh test xong reply:
+     ✅ OK — tiếp tục
+     ⚠️ Issue: {mô tả} — tôi sẽ fix trước khi đi tiếp
+   ══════════════════════════════════════
+
+3. Gọi notify_user(BlockedOnUser=true) — DỪNG và CHỜ user response
+
+4. User response handling:
+   → "OK" / "✅" → Tiếp tục phase tiếp / feature tiếp
+   → "Issue: ..." → Fix issue → re-run checkpoint
+   → "Skip" → Ghi note concern, tiếp tục (DONE_WITH_CONCERNS later)
+```
+
+**Test Guidance Generation:**
+```
+AI PHẢI tạo hướng dẫn test CỤ THỂ cho từng checkpoint:
+
+Phase B Examples (UI):
+  - "Mở app → bấm tab Health → xem Dashboard có hiển thị 4 cards không?"
+  - "Quay ngang màn hình → layout có bể không?"
+  - "Bấm nút Camera → xem preview có xuất hiện không?"
+
+Phase C Examples (Logic):
+  - "Mở Health Dashboard → data thật có load lên không? (nếu có wifi)"
+  - "Chụp ảnh thức ăn → kết quả AI có trả về trong 5s không?"
+  - "Bấm Save → quay lại list → record mới có xuất hiện không?"
+```
+
+**Enforcement:**
+- ❌ KHÔNG được chuyển từ Phase B → Phase C mà chưa có user confirm (COMPLEX)
+- ❌ KHÔNG được skip checkpoint cho hardware-related features (Camera, GPS, Sensors)
+- ✅ NÊN batch các features nhỏ lại thành 1 checkpoint (tránh quá nhiều interrupt)
+- ✅ Checkpoint cho logic KHÔNG cần nếu feature là pure-backend/invisible
+
+---
+
 ### TP2: Task Complete — Completion Status Protocol
 
 **Khi nào:** AI detect ≥2/4 completion signals:
@@ -470,3 +657,5 @@ Nếu completed:
 - Spec alignment tránh plan bị lệch khỏi project constraints
 - Atomic commits giúp rollback chính xác — 1 task = 1 commit (learned from GSD)
 - KHÔNG auto-push — chỉ commit local, push cần user confirm
+- Three-Phase WORKS vì AI CHỦ ĐỘNG announce — không chờ user gọi (learned from FitWitness v12.3)
+- User test sớm bắt lỗi sớm — code logic trên UI sai = double wasted (learned from FitWitness v12.3)

package/skills/trello-sync/SKILL.md

@@ -30,12 +30,14 @@ priority: 2
 KHÔNG CÓ NGOẠI LỆ:
 - 1 Dự án = 1 Trello Card (KHÔNG tạo card mới cho mỗi task).
 - **Mô tả Card (Description)** BẮT BUỘC phải được update chứa cái nhìn tổng thể về dự án (Mục tiêu, Tech Stack, Tình trạng chung) để Quản lý dễ nắm bắt.
-- Tiến độ = Checklist Items trên card dự án. CHỈ ghi lại các task ở mức High-level / Module / Tính năng lớn.
-- ⛔ KHÔNG BAO GIỜ đồng bộ từng sub-task chi tiết (từ file `.kiro/specs/tasks.md` hay Symphony) thành checklist item trên Trello, làm vậy sẽ gây rác board (spam).
+- **Trello (PM View) vs Kiro (Dev View):** Trello là màn hình dành cho Quản lý (PM, QC), còn `.kiro/specs/tasks.md` là nơi để AI/Dev làm việc. Hai khái niệm này hoàn toàn khác nhau.
+- [QUAN TRỌNG] Checklist Items trên Trello = ĐẦU VIỆC NGHIỆP VỤ (Business Features). VD: "Màn hình Đăng Nhập", "Chức năng AI Chat", "Tích hợp Thanh Toán".
+- ⛔ TUYỆT ĐỐI CẤM đưa các GIAI ĐOẠN QUY TRÌNH (Process Gates) vào Checklist Items. KHÔNG CÓ CÁC MỤC NHƯ: "Tài liệu", "Thiết kế Giao diện", "Gate 1", "Phase 2", "App Scaffolding".
+- PM KHÔNG QUAN TÂM ĐẾN QUY TRÌNH GATE CỦA AI. Progress qua các Gate (Gate 1, Gate 2...) CHỈ ĐƯỢC BÁO CÁO qua Comment.
+- KHÔNG BAO GIỜ bứng nguyên các task kỹ thuật chi tiết (VD: "Tạo file `BloodPressureViewModel.kt`") lên Trello. CẤM ĐỒNG BỘ (bulk-sync) raw `tasks.md` sang Trello.
+- BẮT BUỘC ĐỒNG BỘ TOÀN BỘ DANH SÁCH NGHIỆP VỤ TỔNG HỢP (Features): Chờ đến khi Đặc tả kỹ thuật (Specs) đã có rõ các tính năng, AI mới parse ra các Features thành các Checklist Items để Quản lý (PM) có thể thấy trọn vẹn scope.
 - Card KHÔNG di chuyển giữa lists (list = team member, cố định).
-- Comment ở milestone quan trọng PHẢI bao gồm các quyết định kỹ thuật cốt lõi hoặc nguyên nhân gốc rễ, không chỉ ghi "Done" chung chung.
-- Comment chỉ ở milestone quan trọng, KHÔNG spam.
-- KHÔNG ĐƯỢC sinh script file python/bash (VD: `trello_sync_kiro.py`) để đồng bộ hàng loạt (bulk sync) từ file markdown lên Trello.
+- Comment ở milestone quan trọng PHẢI bao gồm các quyết định cốt lõi hoặc sự thay đổi phase (VD: "Đã hoàn thành Gate 2 Design", "Bắt đầu code Logic").
 ```
 
 ---
@@ -124,21 +126,23 @@ Mỗi Card chứa:
 
 ### TP1: 🚀 Start Task / Start Project (Description + Checklist)
 
-**Khi nào:** AI bắt đầu project mới hoặc làm task lớn mới (claim Symphony task).
+**Khi nào:** AI bắt đầu project mới, hoặc chuẩn bị triển khai Specs đã chốt (Gate 3/Gate 4). 
+*(Lưu ý: Không tạo Checklist Items các phase "Gate 1", "Gate 2" - lúc này chỉ dùng Comment hoặc Update Description thôi).*
 
 **Action:**
 ```bash
 # Update Card Description với thông tin cực kỳ rõ ràng cho Quản lý (PM) dự án
 awkit trello desc "**Trạng thái:** Đang phát triển. **Công nghệ:** Kotlin, Jetpack Compose, Room. **Tiến độ hiện tại:** ... (Tóm tắt sơ lược)"
 
-# 1. Tạo checklist (nếu cần, ví dụ Sprint)
-awkit trello checklist "Sprint 2026-03"
+# 1. Tạo checklist dựa trên Module/Epic Nghiệp vụ thực tế
+awkit trello checklist "Module: Xác thực Người Dùng"
 
-# 2. Thêm item mới vào checklist
-awkit trello item "Feature: Login Flow"
+# 2. Thêm item mới vào checklist (Tuyệt đối KHÔNG ĐẶT TÊN theo Gate/Phase/Scaffolding)
+awkit trello item "Đăng nhập bằng Google"
+awkit trello item "Hồ sơ Người Dùng"
 
-# 3. Comment báo bắt đầu
-awkit trello comment "🤖 AI bắt đầu: Login Flow | Symphony: #sym-XXX"
+# 3. Comment thông báo cập nhật tiến trình hoặc trạng thái Agent
+awkit trello comment "🤖 AI bắt đầu: Xây dựng giao diện Đăng Nhập | Symphony: #sym-XXX"
 ```
 
 ---
@@ -167,26 +171,35 @@ awkit trello block "API 500 on /auth/login. Cần Backend check."
 
 ### TP4: ✅ Task Done (Đánh dấu Item Complete)
 
-**Khi nào:** Task hoàn thành, verification pass.
+**Khi nào:** Toàn bộ cụm Tính năng Nghiệp vụ (Epic/Feature bao gồm nhiều sub-tasks) đã hoàn thành và sẵn sàng test.
+*(Lưu ý: Không check item nếu chỉ mới xong 1 task code con lập trình)*
 
 ```bash
-# 1. Đánh dấu checklist item ✅
-awkit trello complete "Feature: Login Flow"
+# 1. Đánh dấu checklist item đại diện cho tính năng ✅
+awkit trello complete "Đăng nhập bằng Google"
 
 # 2. Comment kết quả
-awkit trello comment "✅ DONE: Login Flow | Commit: #$(git rev-parse --short HEAD)"
+awkit trello comment "✅ DONE Feature: Đăng nhập bằng Google | Commit: #$(git rev-parse --short HEAD)"
 ```
 
 ---
 
-## 🔗 Symphony Integration
+## 🔗 Symphony Integration (NGUYÊN TẮC: Nhiều Task Code -> 1 Trello Feature)
+
+⚠️ **CHÚ Ý CỰC KỲ QUAN TRỌNG:** KHÔNG MAP 1:1 TỪ SYMPHONY SANG TRELLO CHECKLIST!
+Trong Symphony có thể có 50 task nhỏ (VD: Tạo View, Viết API, Sửa CSS). Trello chỉ có 5 Checklist Items lớn (VD: Chức năng Đăng nhập, Profile, Thanh toán). 
+Do đó: **CẤM** gọi `awkit trello item` mỗi khi claim 1 task con từ Symphony. Nếu làm vậy Trello sẽ biến thành bãi rác toàn các task code lặt vặt.
+
+**Cách Sync Đúng:**
+- Thiết lập Checklist Items ngay từ đầu dựa trên Spec tổng.
+- Khi code từng phân hệ con, ĐỪNG sinh ra checklist mới.
 
 | Symphony Event | Trello Action |
 |----------------|---------------|
-| `symphony_claim_task` | Thêm checklist item (incomplete) + Comment start |
+| `symphony_claim_task` | **CHỈ** Comment báo tiến độ: "Đang xử lý code: [Task]..." |
 | `symphony_report_progress` | Comment milestone |
 | Task BLOCKED | Label "Blocked" + Comment |
-| `symphony_complete_task` | Mark item ✅ complete + Comment result |
+| `symphony_complete_task` | **CHỈ** Comment: "Xong code task [Task]." *(Tùy chọn: nếu feature lớn xong 100%, mới call `complete` cho item chính)* |
 
 Trong comment, **PHẢI** ghi Symphony Task ID: `Symphony: #sym-XXX`
 
@@ -194,9 +207,11 @@ Trong comment, **PHẢI** ghi Symphony Task ID: `Symphony: #sym-XXX`
 
 ## 🎯 Best Practices
 
-1. **Checklist naming**: Theo phase/module lớn (VD: "Module: fw-01-foundation", "Sprint 2026-03").
-2. **Item naming**: Mô tả tính năng lớn (VD: "Login Flow", "Firebase Integration"). KHÔNG ĐƯA CÁC ĐẦU MỤC CODE LEVEL VÀO ĐÂY (VD: "Thêm nút bấm", "Sửa CSS", v.v.).
-3. **Minimizing noise**: Comment chỉ ở milestones, KHÔNG spam mỗi dòng code. Cấm bulk-sync checklist item từ `tasks.md`.
+1. **Checklist naming (Module/Epic)**: Tên checklist thể hiện mảng Tính năng/Module lớn (VD: "Module: Authentication", "Sprint: Workout Tính năng cốt lõi").
+   ⛔ KHÔNG ĐẶT theo quy trình AI như "Gate 1", "Phase: Setup", "Giai đoạn Design".
+2. **Item naming (Product Features)**: Tên item là tính năng/màn hình cụ thể (VD: "Google Sign-In", "Màn hình Thông kê Calorie", "Chức năng AI tư vấn thực đơn"). 
+   ⛔ KHÔNG ĐẶT kiểu "Tài liệu Specs", "Code Scaffolding", "Sửa CSS" hay "Tạo file ABC".
+3. **Minimizing noise**: Cập nhật milestone (chuyển gate, chuyển phase) qua **Comment** trên Card, KHÔNG GHI THÀNH **Checklist item** (vốn dĩ checklist item là thứ bàn giao được cho user). Cấm bulk-sync từ `tasks.md`.
 4. **Graceful degradation**: CLI/API lỗi → log warning, KHÔNG block code flow.
 5. **Dùng lệnh Native**: Luôn luôn gọi `awkit trello <lệnh>` thay vì `trello-cli` thủ công.
 6. **Card KHÔNG di chuyển**: Card nằm cố định trong list team member. KHÔNG move card.