@leejungkiin/awkit 1.0.6 → 1.0.8

package/workflows/mobile/reverse-ios-build.md

@@ -1,36 +1,37 @@
 ---
-description: 🔨 RE iOS Phase 2+3 — Per-feature Blueprint → Implementation → Parity Check
+description: 🔨 RE iOS Phase 2+3+4 — Blueprint + UI Shell → Logic Build → Final Parity (UI-First)
 parent: reverse-ios
 ---
 
-# /re-ios-build — Blueprint & Build (Per Feature)
+# /re-ios-build — Blueprint + UI + Build (Per Feature)
 
-> **Parent:** [`/reverse-ios`](reverse-ios.md) → Phase 2+3
+> **Parent:** [`/reverse-ios`](reverse-ios.md) → Phase 2+3+4
 > **Prerequisite:** Completed Architecture from [`/re-ios-design`](reverse-ios-design.md)
-> **Skill:** `smali-to-swift` → `phase-2-blueprint.md` + `phase-3-build.md`
+> **Skill:** `smali-to-swift` → `phase-2-blueprint-ui.md` + `phase-3-logic-build.md`
 
 ---
 
-## 🔄 Feature Loop
+## 🔄 Feature Loop (UI-First)
 
 ```
 For each feature (from Architecture Build Order):
-    Phase 2: Blueprint (Zoom 2 — signatures only)
-        ↓ [User approves]
-    Phase 3: Implementation (Zoom 3 — full code)
-        ↓ [Checkpoint]
+    Phase 2: Blueprint + UI (contracts + visual shell)
+        ↓ 🚦 GATE: User approves UI + contracts
+    Phase 3: Logic Build (domain → data → wire)
+        ↓ 📊 CHECKPOINT
     → Next feature
 ```
 
 ---
 
-## 📐 Phase 2: Feature Blueprint (Zoom 2)
+## 📐🎨 Phase 2: Blueprint + UI Design
 
-> **Output:** Contracts, protocols, state design. **Signatures only.**
+> **Output:** Approved contracts + Working SwiftUI shell with mock data.
 
-### 2.1: Deep Header Reading
+### Part A: Contracts (signatures only)
 
-Read class-dump headers + Hopper pseudo-code for chosen feature.
+#### 2.1: Deep Header Reading
+Read class-dump headers + Hopper pseudo-code. See `objc-reading-guide.md`.
 
 **ObjC → Swift Quick Ref:**
 ```
@@ -40,90 +41,200 @@ Read class-dump headers + Hopper pseudo-code for chosen feature.
 + (instancetype)sharedInstance      → static let shared
 ```
 
-### 2.2: Domain Contracts
-
+#### 2.2–2.5: Define Contracts
 ```swift
+// 2.2 Domain Model
 struct [Model]: Codable, Identifiable, Sendable {
-    let field1: Type
-    // CodingKeys if needed
+    let field: Type
 }
 
+// 2.3 Repository Protocol
 protocol [Feature]Repository: Sendable {
     func [method](...) async throws -> [Type]
 }
 
-struct [Action]UseCase: Sendable {
-    func execute(...) async throws -> [Type]
+// 2.4 API Endpoint
+enum [Feature]Endpoint {
+    case [action](param: Type)
+    var path: String { /* ... */ }
+}
+
+// 2.5 UseCase
+struct [Action]UseCase {
+    func execute(...) async throws -> [Type] // TODO
+}
+```
+
+#### 2.6: UI State Design
+```swift
+struct [Screen]ViewState {
+    var field: Type = default
+    var isLoading: Bool = false
+    var error: String? = nil
+}
+enum [Screen]Action { /* user interactions */ }
+enum [Screen]Event { /* navigation, alerts */ }
+
+extension [Screen]ViewState {
+    static let normal = [Screen]ViewState(/* sample */)
+    static let loading = [Screen]ViewState(isLoading: true)
+    static let error = [Screen]ViewState(error: "Error message")
+}
+```
+
+### Part B: UI Visual Shell
+
+#### 2.7: Resource Extraction ⭐ (BEFORE UI code!)
+
+Extract from IPA bundle / Assets.car:
+- Images → Assets.xcassets
+- Colors → Color extension or asset catalog
+- Strings → Localizable.xcstrings
+- Fonts → custom fonts
+
+Copy ONLY needed resources. Verify they build.
+
+#### 2.8: UI Implementation ⭐ (Visual shell with mock data)
+
+- Use ViewState from 2.6 with hardcoded defaults
+- Use REAL resources from 2.7
+- Create `[Screen]Content` view (stateless)
+- Match visual parity with original app
+- NO ViewModel connection, NO real API calls
+
+```swift
+struct [Screen]Content: View {
+    var state: [Screen]ViewState = .normal   // Mock
+    var onAction: ([Screen]Action) -> Void = { _ in }  // No-op
+
+    var body: some View {
+        // Full SwiftUI matching original app
+    }
 }
+
+#Preview("Normal") { [Screen]Content(state: .normal) }
+#Preview("Loading") { [Screen]Content(state: .loading) }
+#Preview("Error") { [Screen]Content(state: .error) }
 ```
 
-### 2.3: UI State Design
+#### 2.9: Visual Parity Check ⭐
 
-- @Observable ViewModel properties
-- User actions
-- Navigation events
-- Wireframe
+Compare with original app:
+- [ ] Layout structure matches
+- [ ] Colors, typography, spacing correct
+- [ ] Icons/images positioned correctly
+- [ ] All states: normal, loading, error, empty
 
-### ✅ Blueprint Gate
+### 🚦 UI + Contracts Gate (MANDATORY)
 
 ```
-"📐 Blueprint cho [Feature] xong. OK? → Code."
+"📐🎨 Blueprint + UI cho [Feature] xong:
+📝 Contracts: [N] models, [N] protocols, [N] use cases, [N] endpoints
+🎨 UI: [Screen] with [N] state previews
+📸 Visual Parity: [OK / needs adjustment]
+
+→ ✅ Approve → Phase 3 (Logic Build)
+→ 🎨 Adjust UI → fix then re-check
+→ 📝 Adjust contracts → revise"
 ```
 
+> ⚠️ **DO NOT proceed to Phase 3 without user approval.**
+
 ---
 
-## 🔨 Phase 3: Implementation (Zoom 3)
+## 🔨 Phase 3: Logic Build
 
-> **Full Swift code for THIS feature only.**
+> **Output:** Full Swift code. Wire logic to EXISTING UI.
 
-### 3.1: Domain → Data → DI → ViewModel → Screen
+### 3.1: Domain Layer
+Models + Repository protocols + UseCases (implement with repo calls)
 
-Standard implementation order:
-1. Codable structs
-2. Repository protocol + implementation
-3. APIClient endpoints
-4. SwiftData models (if applicable)
-5. DI container entries
-6. @Observable ViewModel
-7. SwiftUI Screen
-8. Resource extraction (on-demand only)
+### 3.2: Data Layer
+DTOs + APIClient endpoints + SwiftData (if applicable) + Repository implementation
 
-### 🔒 Crypto (Special)
+### 3.3: DI Container
+AppContainer with lazy properties for repos, use cases, view models
+
+### 3.4: ViewModel
+@Observable with state property + handle(_ action:) + event handler
+
+### 3.5: Wire UI ↔ Logic ⭐ (NOT "code new UI")
+
+The UI already exists from Phase 2.8. Only CONNECT it:
 
+```swift
+// Keep stateless Content view from Phase 2 (for Preview):
+// [Screen]Content(state:, onAction:) — DO NOT MODIFY
+
+// ADD wrapper that wires ViewModel:
+struct [Screen]: View {
+    @State private var viewModel: [Screen]ViewModel
+
+    init(container: AppContainer) {
+        _viewModel = State(initialValue: container.make[Screen]ViewModel())
+    }
+
+    var body: some View {
+        [Screen]Content(
+            state: viewModel.state,
+            onAction: viewModel.handle
+        )
+    }
+}
+```
+
+### 3.6: Integration Test ⭐
+- [ ] API calls succeed, data displays
+- [ ] Loading/error states work
+- [ ] Navigation correct
+- [ ] Crypto output matches (if applicable)
+
+### 🔒 Crypto (Special)
 ```swift
 import CryptoKit
 import CommonCrypto
 // XCTest mandatory for crypto utils
 ```
-
 > ⚠️ Crypto MUST match original output.
 
 ### ✅ Feature Checkpoint
 
 ```markdown
 ## ✅ Feature Complete: [Name]
-### Files created: [list]
-### Tests: [crypto verified?]
-⏭️ Next: Phase 2 for [next feature]
+Files: [list] | Resources: [count] | Tests: [status]
+⏭️ Next Feature: [Name] → Return to Phase 2
 ```
 
 ---
 
-## ✅ Final Parity Check
+## ✅ Phase 4: Final Parity Check (After ALL features)
 
-- [ ] API Parity
-- [ ] Data/Crypto Parity
-- [ ] UI Parity
+### Checklist
+- [ ] API Parity — all endpoints match
+- [ ] Data/Crypto Parity — output identical
+- [ ] UI Parity — screen-by-screen comparison
+- [ ] Edge Cases — empty, error, offline, lifecycle
 - [ ] Build: `xcodebuild build && xcodebuild test`
 
+### 🎉 Final Summary
+
+```markdown
+## ✅ Reverse Engineering Complete!
+- Screens: [N] | Features: [N]
+- Frameworks reused: [N] | Replaced: [N]
+- Tests: [pass/fail]
+
+⏭️ Next: /test → /deploy → /code-janitor
+```
+
 ---
 
 ## 🔗 Related
 
 - **Parent:** [`/reverse-ios`](reverse-ios.md)
-- **Previous:** [`/re-ios-design`](reverse-ios-design.md)
-- **Skill:** `smali-to-swift` → `phase-2-blueprint.md` + `phase-3-build.md`
+- **Previous:** [`/re-ios-design`](reverse-ios-design.md) (Phase 1)
+- **Skill:** `smali-to-swift` → `phase-2-blueprint-ui.md` + `phase-3-logic-build.md`
 
 ---
 
-*re-ios-build v3.0.0 — Phase 2+3: Blueprint & Build*
+*re-ios-build v4.0.0 — UI-First Blueprint + Build*

package/workflows/mobile/reverse-ios-design.md

@@ -65,10 +65,19 @@ App/
 └── Resources/
 ```
 
-### Step 6: Build Order
+### Step 6: Build Order (UI-First) ⭐
 
 | # | Phase | Scope | Complexity |
 |---|-------|-------|-----------|
+| 1 | 🟢 Foundation | Xcode project + DI skeleton + Theme | Low |
+| 2 | 🟢 Navigation | NavigationStack, TabView, routes | Low |
+| 3 | 🔵 Per Feature | Blueprint (contracts) + UI Shell (visual) | Medium |
+| 4 | 🚦 UI Gate | User approves UI before logic | — |
+| 5 | 🟡 Per Feature | Logic Build (Domain → Data → VM → Wire UI) | High |
+| 6 | 📦 SDKs | Third-party SDK + Native libs integration | Medium |
+| N | 🔴 Final | Full Parity Check | High |
+
+> **UI-First:** Design and approve UI before coding logic for each feature.
 
 ### Step 7: Tech Decisions
 

package/workflows/mobile/reverse-ios.md

@@ -1,13 +1,13 @@
 ---
-description: 🍎 Dịch ngược IPA iOS (class-dump, Hopper output) → App Swift hiện đại với SwiftUI, Clean Architecture. Progressive Disclosure: Map → Blueprint → Build.
+description: 🍎 Dịch ngược IPA iOS (class-dump, Hopper output) → App Swift hiện đại với SwiftUI, Clean Architecture, và UI-First methodology.
 skill: smali-to-swift
 ---
 
 # /reverse-ios — iOS IPA Reverse Engineering Workflow
 
 > **Skill:** `smali-to-swift` v2.0 | **Tech:** Swift + SwiftUI + async/await + URLSession + SwiftData
-> **Philosophy:** "Treat decompiled code as a MAP, not a TODO list"
-> **Approach:** Map → Blueprint → Build (progressive disclosure)
+> **Philosophy:** "Map → Blueprint → UI First → Logic Behind"
+> **Key:** UI is designed and approved BEFORE coding any business logic.
 > **Sibling:** `/reverse-android`
 
 ---
@@ -15,7 +15,7 @@ skill: smali-to-swift
 ## ⚡ QUICK START
 
 User cung cấp: Decrypted `.app` bundle, class-dump headers, Hopper pseudo-code, hoặc nói "reverse engineer IPA này".
-Workflow dẫn dắt qua **4 phases** — mỗi phase có zoom level riêng, **không bao giờ nhảy cóc**.
+Workflow dẫn dắt qua **5 phases** — UI-First approach, **không bao giờ nhảy cóc**.
 
 ---
 
@@ -29,10 +29,11 @@ reverse_ios_session:
   app_bundle_dir: "[path]"
   headers_dir: "[class-dump output]"
   current_phase: 0
-  current_zoom: 0
   current_feature: null
-  app_map_done: false
-  architecture_done: false
+  phase_2_status:
+    contracts: pending
+    ui_shell: pending
+    resources: pending
   completed_features: []
   pending_features: []
   decisions: []
@@ -41,7 +42,7 @@ reverse_ios_session:
 ### Bước 0.2: Xác nhận input
 
 ```
-🍎 iOS Reverse Engineering v2.0 — Map → Blueprint → Build
+🍎 iOS Reverse Engineering v2.0 — UI-First Pipeline
 
 Em cần biết:
 1. Decrypted .app bundle ở đâu?
@@ -55,14 +56,15 @@ Chưa chuẩn bị?
 
 ---
 
-## 📋 Pipeline Overview (4 Phases)
+## 📋 Pipeline Overview (5 Phases — UI-First)
 
-| Phase | Name | Sub-workflow | Zoom | Code? | Gate |
-|-------|------|-------------|------|-------|------|
-| 0 | 🗺️ Discovery | [`/re-ios-discover`](reverse-ios-discover.md) | Satellite | ❌ | User approves Map |
-| 1 | 🏗️ Architecture | [`/re-ios-design`](reverse-ios-design.md) | District | ❌ | User approves Architecture |
-| 2 | 📐 Blueprint | [`/re-ios-build`](reverse-ios-build.md) | Block | Signatures | Per-feature approval |
-| 3 | 🔨 Implementation | [`/re-ios-build`](reverse-ios-build.md) | Ground | Full | Per-feature checkpoint |
+| Phase | Name | Sub-workflow | Code? | Gate |
+|-------|------|-------------|-------|------|
+| 0 | 🗺️ Discovery | [`/re-ios-discover`](reverse-ios-discover.md) | ❌ | User approves Map |
+| 1 | 🏗️ Architecture | [`/re-ios-design`](reverse-ios-design.md) | ❌ | User approves Architecture |
+| 2 | 📐🎨 Blueprint + UI | [`/re-ios-build`](reverse-ios-build.md) | UI code | User approves UI + Contracts |
+| 3 | 🔨 Logic Build | [`/re-ios-build`](reverse-ios-build.md) | Full logic | Feature checkpoint |
+| 4 | ✅ Final Parity | [`/re-ios-build`](reverse-ios-build.md) | — | Final check |
 
 ### Execution Flow
 
@@ -73,11 +75,14 @@ Phase 0: Discovery (/re-ios-discover) → App Map
     ↓ [User approves]
 Phase 1: Architecture (/re-ios-design) → Architecture Blueprint
     ↓ [User approves + picks feature]
-Phase 2+3 Loop (/re-ios-build):
-    → Blueprint Feature X → Build Feature X → Checkpoint
-    → Blueprint Feature Y → Build Feature Y → Checkpoint
+Feature Loop (/re-ios-build):
+    Phase 2: Blueprint + UI (contracts + visual shell + resources)
+        ↓ 🚦 GATE: User approves UI + contracts
+    Phase 3: Logic Build (domain → data → DI → VM → wire UI)
+        ↓ 📊 CHECKPOINT: Feature done
+    → Repeat for next feature
     ↓
-Final: Parity Check & Quality Gate
+Phase 4: Final Parity Check & Quality Gate
 ```
 
 ---
@@ -86,15 +91,18 @@ Final: Parity Check & Quality Gate
 
 ```yaml
 pre_output_check:
-  - "Đang ở zoom level nào?"
-  - "Output có đúng zoom level không?"
-  - "Có function body trong Phase 0/1 không? → REMOVE"
-
-zoom_rules:
-  zoom_0: "NO CODE. Only diagrams, tables, maps."
-  zoom_1: "NO CODE BODIES. Only architecture, file lists."
-  zoom_2: "SIGNATURES ONLY. Protocols, structs, enums."
-  zoom_3: "FULL CODE. Implementation for ONE feature."
+  - "Đang ở phase nào?"
+  - "Output có đúng phase rule không?"
+  - "Phase 0/1: NO CODE BODIES"
+  - "Phase 2: UI code + signatures (no logic bodies)"
+  - "Phase 3: Full implementation code"
+
+phase_rules:
+  phase_0: "NO CODE. Only diagrams, tables, maps."
+  phase_1: "NO CODE BODIES. Only architecture, file lists."
+  phase_2_contracts: "SIGNATURES ONLY. Protocols, structs, enums."
+  phase_2_ui: "FULL UI CODE. SwiftUI with hardcoded mock data + #Preview."
+  phase_3: "FULL LOGIC CODE. Domain → Data → DI → VM → Wire UI."
 ```
 
 ---
@@ -104,23 +112,27 @@ zoom_rules:
 ```yaml
 never_skip:
   - Phase 0 (Discovery) — always first
-  - Phase 1 (Architecture) — design before code
-  - Per-feature Blueprint before Implementation
+  - Phase 1 (Architecture) — design before coding
+  - Phase 2 UI Gate — user MUST approve UI before Phase 3
+  - Per-feature Blueprint before Logic Build
 
 never_do:
-  - Write code in Phase 0 or Phase 1
-  - Mass-copy assets from IPA
+  - Write logic code before UI is approved
+  - Mass-copy assets from IPA (on-demand only)
   - Use UIKit when SwiftUI equivalent exists
   - Use GCD for new async code (use async/await)
   - Use ObjC in new code (Swift only)
+  - Modify UI significantly in Phase 3 (only wire, don't redesign)
   - Implement multiple features simultaneously
 
 always_do:
-  - Start with App Map
-  - Create Blueprint before each feature
+  - Extract resources BEFORE coding UI (Phase 2.7 → 2.8)
+  - Create #Preview for ALL states
+  - Keep stateless View (LoginScreenContent) after wiring
   - XCTest all crypto/hash functions
   - Use @Observable for ViewModels
   - Use NavigationStack, SPM
+  - Checkpoint after each feature
 ```
 
 ---
@@ -130,11 +142,11 @@ always_do:
 - **Sub-workflows:**
   - [`/re-ios-discover`](reverse-ios-discover.md) — Phase 0: Discovery
   - [`/re-ios-design`](reverse-ios-design.md) — Phase 1: Architecture
-  - [`/re-ios-build`](reverse-ios-build.md) — Phase 2+3: Blueprint + Build
-- **Skill:** `smali-to-swift` v2.0
+  - [`/re-ios-build`](reverse-ios-build.md) — Phase 2+3+4: Blueprint + UI + Build
+- **Skill:** `smali-to-swift` v2.0 (UI-First pipeline)
 - **Sibling:** `/reverse-android`
 - **After RE done:** `/test`, `/deploy`, `/code-janitor`
 
 ---
 
-*reverse-ios workflow v3.0.0 — Progressive Disclosure RE Pipeline*
+*reverse-ios workflow v4.0.0 — UI-First RE Pipeline*

package/skills/adaptive-language/SKILL.md

@@ -1,189 +0,0 @@
----
-name: awf-adaptive-language
-description: >-
-  Adjust terminology based on user technical level. Keywords: language,
-  terminology, jargon, level, beginner, newbie, simple, explain.
-  Reads technical_level from preferences.json and sets communication context.
-version: 1.0.0
----
-
-# AWF Adaptive Language
-
-Tự động điều chỉnh ngôn ngữ kỹ thuật theo trình độ user.
-
-## Trigger Conditions
-
-**Pre-hook for ALL workflows** - Activates at session start.
-
-**Check preferences:**
-```
-if exists(".brain/preferences.json"):
-    → Read technical_level
-else if exists("~/.antigravity/preferences.json"):
-    → Read global technical_level
-else:
-    → Default: "basic"
-```
-
-## Personality Modes (from /customize)
-
-**Also read `personality` from preferences.json:**
-
-### Mentor Mode (`mentor`)
-```
-Khi làm bất kỳ task nào:
-1. Giải thích TẠI SAO làm vậy
-2. Giải thích thuật ngữ mới gặp
-3. Đôi khi hỏi ngược: "Anh nghĩ tại sao phải làm vậy?"
-4. Sau khi xong: "Anh học được gì từ bước này?"
-```
-
-### Strict Coach Mode (`strict_coach`)
-```
-Khi làm bất kỳ task nào:
-1. Đòi hỏi cao về chất lượng
-2. Chỉ ra cách làm tốt hơn
-3. Giải thích best practices
-4. Không chấp nhận code xấu: "Cách này không tối ưu vì..."
-```
-
-### Default (không có personality setting)
-→ Dùng style "Trợ lý thông minh" - hữu ích, đưa lựa chọn
-
----
-
-## Technical Levels
-
-### Level: `newbie`
-**Target:** Không biết code, chỉ có ý tưởng
-
-| Term | Translation |
-|------|-------------|
-| database | kho lưu trữ thông tin |
-| API | cổng giao tiếp giữa các phần mềm |
-| deploy | đưa lên mạng cho người khác dùng |
-| commit | lưu lại thay đổi |
-| branch | bản nháp của dự án |
-| error | lỗi cần sửa |
-| debug | tìm và sửa lỗi |
-| test | kiểm tra xem có chạy đúng không |
-| server | máy tính chạy ứng dụng |
-| frontend | giao diện người dùng thấy |
-| backend | phần xử lý ẩn phía sau |
-
-**Communication style:**
-- Giải thích MỌI khái niệm kỹ thuật
-- Dùng ví dụ đời thường
-- Tránh từ viết tắt
-- Bước nhỏ, từng bước một
-
-### Level: `basic`
-**Target:** Biết dùng máy tính, đọc được code cơ bản
-
-| Term | Usage |
-|------|-------|
-| database | database (cơ sở dữ liệu) |
-| API | API (giao diện lập trình) |
-| deploy | deploy (triển khai) |
-| commit | commit (lưu thay đổi vào git) |
-
-**Communication style:**
-- Giải thích từ kỹ thuật lần đầu
-- Sau đó dùng bình thường
-- Gợi ý tra cứu thêm nếu cần
-- Nhóm nhiều bước nhỏ lại
-
-### Level: `technical`
-**Target:** Developers, có kinh nghiệm code
-
-**Communication style:**
-- Dùng thuật ngữ chuẩn
-- Không cần giải thích
-- Tập trung vào implementation
-- Có thể dùng viết tắt (PR, CI/CD, etc.)
-
-## Execution Logic
-
-### Step 1: Load Preferences
-
-```
-preferences = null
-
-# Try local first
-if exists(".brain/preferences.json"):
-    preferences = parse(".brain/preferences.json")
-
-# Fallback to global
-if !preferences && exists("~/.antigravity/preferences.json"):
-    preferences = parse("~/.antigravity/preferences.json")
-
-# Extract level
-level = preferences?.technical?.technical_level || "basic"
-```
-
-### Step 2: Set Context
-
-```
-Set internal context for session:
-- terminology_level = level
-- Apply translation rules based on level
-```
-
-### Step 3: Silent Operation
-
-This skill operates SILENTLY:
-- KHÔNG show indicator
-- KHÔNG notify user
-- Just sets context for subsequent responses
-
-## Integration with Workflows
-
-All AWF workflows should respect the set terminology level:
-
-```
-When outputting technical terms:
-if level == "newbie":
-    → Use translated terms from table
-    → Add explanations
-elif level == "basic":
-    → Use term (explanation) format first time
-    → Plain term after that
-else:
-    → Use standard technical terms
-```
-
-## Performance
-
-- Load time: < 100ms
-- Single file read
-- Cached for session duration
-
-## Error Handling
-
-```
-If preferences.json corrupted:
-→ Use default level: "basic"
-→ NO error message to user
-
-If technical_level invalid:
-→ Map to closest: "newbie"/"basic"/"technical"
-→ Log warning internally
-```
-
-## Example Behavior
-
-**User level: newbie**
-```
-User: /deploy
-
-Output: "Sẵn sàng đưa ứng dụng lên mạng (deploy) cho người khác dùng.
-Em sẽ kiểm tra xem mọi thứ đã sẵn sàng chưa..."
-```
-
-**User level: technical**
-```
-User: /deploy
-
-Output: "Initiating deployment pipeline.
-Running pre-deploy checks..."
-```