dw-kit 1.9.1 → 1.9.3

package/.dw/core/THINKING.md

@@ -1,126 +1,126 @@
-<!-- core-version: 1.0 -->
-
-# Tư Duy Phản Biện, Hệ Thống, Đa Góc Nhìn & First Principles
-
-Framework tư duy cho cả người và AI agent khi research, plan, và implement.
-
----
-
-## 1. First Principles Thinking
-
-**Mục đích**: Bỏ qua assumptions, trở về câu hỏi cơ bản nhất. Tránh "chúng tôi luôn làm vậy."
-
-### Quy Trình
-
-1. **Decompose**: Tách vấn đề thành các phần cơ bản nhất — không thể tách nhỏ hơn
-2. **Question assumptions**: Mỗi assumption: "Điều này có đúng không? Có thể kiểm chứng được không?"
-3. **Rebuild**: Từ những gì đã verify, build lại solution từ đầu
-4. **Compare**: Solution mới có ưu việt hơn solution cũ không? Tại sao?
-
-### Câu Hỏi First Principles
-
-- "Vấn đề thực sự cần giải quyết là gì?" (không phải symptom)
-- "Nếu không có bất kỳ constraint nào, solution tốt nhất là gì?"
-- "Constraint nào là thực sự hard, constraint nào là assumed?"
-- "Ai đang được served bởi solution này? Họ thực sự cần gì?"
-
----
-
-## 2. Tư Duy Phản Biện (Critical Thinking)
-
-**Mục đích**: Không chấp nhận giả định một chiều. Đặt câu hỏi, xem xét rủi ro, phương án thay thế.
-
-### Câu Hỏi Khi Research & Plan
-
-- **Giả định**: Những giả định nào đang coi là đúng? Nếu sai thì ảnh hưởng thế nào?
-- **Bằng chứng**: Kết luận dựa trên đâu (code, doc, đo lường)? Thiếu bằng chứng ở đâu?
-- **Edge cases**: Trường hợp biên nào có thể làm hỏng thiết kế? (null, empty, concurrent, rollback)
-- **Rủi ro**: Rủi ro kỹ thuật, vận hành, bảo mật? Xác suất và tác động?
-- **Phương án thay thế**: Còn cách nào khác? Trade-off so với approach hiện tại?
-- **Phản diện (Devil's advocate)**: Lý do mạnh nhất để KHÔNG làm theo approach đang chọn?
-- **Đơn giản hơn**: Có cách nào đơn giản hơn đạt cùng mục tiêu không?
-
-### Áp Dụng Trong Task
-
-- **Research**: Ghi rõ "Giả định", "Hạn chế đã biết", "Chưa rõ / cần kiểm chứng"
-- **Plan**: Có mục "Rủi ro & Giả định" và "Phương án đã xem xét"
-- **Execute**: Phát hiện giả định sai → DỪNG, ghi Changelog, cập nhật plan
-
----
-
-## 3. Tư Duy Hệ Thống (Systems Thinking)
-
-**Mục đích**: Xem task trong bối cảnh hệ thống lớn. Dependencies, tác động lan truyền, failure modes.
-
-### Các Khía Cạnh Cần Xem Xét
-
-- **Dependencies**: Task này phụ thuộc vào gì? Ai phụ thuộc vào kết quả của task này?
-- **Boundaries**: Ranh giới rõ ràng chưa? Interfaces ổn định chưa?
-- **Data flow**: Dữ liệu đi từ đâu đến đâu? Thêm DB/cache/queue? Consistency?
-- **Feedback loops**: Thay đổi có tạo vòng lặp không? Cần giới hạn hay debounce?
-- **Failure modes**: Một phần lỗi → hệ thống còn lại ứng xử thế nào? Graceful degradation?
-- **Scale**: Khi tải tăng, điểm nghẽn ở đâu? N+1 queries, missing indexes, locks?
-
-### Áp Dụng Trong Task
-
-- **Research**: Mô tả (hoặc diagram) luồng hiện tại và vị trí của task
-- **Plan**: Mục "Tác động hệ thống" — modules bị ảnh hưởng, API changes, migration
-- **Subtasks**: Tách rõ schema / service / route / frontend để review dependencies
-
----
-
-## 4. Đa Góc Nhìn (Multiple Perspectives)
-
-**Mục đích**: Tránh optimize cho một role. Cân bằng nhu cầu nhiều bên liên quan.
-
-### Bảng Góc Nhìn
-
-| Góc nhìn | Câu hỏi điển hình |
-|----------|-------------------|
-| **End user** | Dễ dùng không? Feature có match use case thực tế? |
-| **Developer** | Code dễ đọc, test được không? API nhất quán? |
-| **Security** | Ai được làm gì? Có lộ data không? Auth/authz đúng? Rate limit? |
-| **Ops/Vận hành** | Deploy thế nào? Migration cần gì? Metric/log/debug khi lỗi? |
-| **Business/Product** | Giải quyết đúng pain point chưa? Ship được từng phần? |
-| **Ngắn hạn vs dài hạn** | Ship nhanh vs kiến trúc bền vững. Tech debt chấp nhận được không? |
-
-### Áp Dụng Trong Task
-
-- **Plan**: Mục "Góc nhìn & Trade-offs" — mỗi quyết định lớn, ghi tác động per role
-- **Acceptance criteria**: Có thể tách "User: ...", "Dev: ...", "Security: ..."
-- **Review**: Nếu chỉ đúng về kỹ thuật nhưng bỏ qua security/ops → bổ sung
-
----
-
-## 5. Checklist Nhanh (Trước Khi Kết Thúc Mỗi Phase)
-
-### Research
-
-- [ ] Đã ghi giả định và có thể sai không?
-- [ ] Đã ghi những gì chưa rõ / cần kiểm chứng?
-- [ ] Đã identify failure modes của kiến trúc hiện tại?
-
-### Plan
-
-- [ ] Đã xem xét ≥2 approaches và so sánh trade-offs?
-- [ ] Có mục Rủi ro & Giả định?
-- [ ] Có mục Edge cases?
-- [ ] Có mục Tác động hệ thống?
-- [ ] Đã xem xét ≥2 góc nhìn (user, security, dev, ops)?
-- [ ] Devil's advocate: lý do mạnh nhất để không làm approach này?
-
-### Execute
-
-- [ ] Có assumption nào bị chứng minh sai? → Ghi Changelog, cập nhật plan
-- [ ] Có scope thay đổi? → Cập nhật plan, hỏi human
-
----
-
-## 6. Prompt Gợi Ý Cho Agent
-
-Khi giao task cho AI agent:
-
-> "Khi làm task này, áp dụng framework trong `core/THINKING.md`:
-> - Trước khi viết plan, liệt kê: (1) giả định đang dùng, (2) 2 rủi ro chính, (3) 1 phương án thay thế đã loại và lý do
-> - Xem xét tác động lên ít nhất 2 góc nhìn (vd: user + security)
-> - Nếu phát hiện giả định sai trong khi execute → dừng, ghi Changelog, hỏi"
+<!-- core-version: 1.0 -->
+
+# Tư Duy Phản Biện, Hệ Thống, Đa Góc Nhìn & First Principles
+
+Framework tư duy cho cả người và AI agent khi research, plan, và implement.
+
+---
+
+## 1. First Principles Thinking
+
+**Mục đích**: Bỏ qua assumptions, trở về câu hỏi cơ bản nhất. Tránh "chúng tôi luôn làm vậy."
+
+### Quy Trình
+
+1. **Decompose**: Tách vấn đề thành các phần cơ bản nhất — không thể tách nhỏ hơn
+2. **Question assumptions**: Mỗi assumption: "Điều này có đúng không? Có thể kiểm chứng được không?"
+3. **Rebuild**: Từ những gì đã verify, build lại solution từ đầu
+4. **Compare**: Solution mới có ưu việt hơn solution cũ không? Tại sao?
+
+### Câu Hỏi First Principles
+
+- "Vấn đề thực sự cần giải quyết là gì?" (không phải symptom)
+- "Nếu không có bất kỳ constraint nào, solution tốt nhất là gì?"
+- "Constraint nào là thực sự hard, constraint nào là assumed?"
+- "Ai đang được served bởi solution này? Họ thực sự cần gì?"
+
+---
+
+## 2. Tư Duy Phản Biện (Critical Thinking)
+
+**Mục đích**: Không chấp nhận giả định một chiều. Đặt câu hỏi, xem xét rủi ro, phương án thay thế.
+
+### Câu Hỏi Khi Research & Plan
+
+- **Giả định**: Những giả định nào đang coi là đúng? Nếu sai thì ảnh hưởng thế nào?
+- **Bằng chứng**: Kết luận dựa trên đâu (code, doc, đo lường)? Thiếu bằng chứng ở đâu?
+- **Edge cases**: Trường hợp biên nào có thể làm hỏng thiết kế? (null, empty, concurrent, rollback)
+- **Rủi ro**: Rủi ro kỹ thuật, vận hành, bảo mật? Xác suất và tác động?
+- **Phương án thay thế**: Còn cách nào khác? Trade-off so với approach hiện tại?
+- **Phản diện (Devil's advocate)**: Lý do mạnh nhất để KHÔNG làm theo approach đang chọn?
+- **Đơn giản hơn**: Có cách nào đơn giản hơn đạt cùng mục tiêu không?
+
+### Áp Dụng Trong Task
+
+- **Research**: Ghi rõ "Giả định", "Hạn chế đã biết", "Chưa rõ / cần kiểm chứng"
+- **Plan**: Có mục "Rủi ro & Giả định" và "Phương án đã xem xét"
+- **Execute**: Phát hiện giả định sai → DỪNG, ghi Changelog, cập nhật plan
+
+---
+
+## 3. Tư Duy Hệ Thống (Systems Thinking)
+
+**Mục đích**: Xem task trong bối cảnh hệ thống lớn. Dependencies, tác động lan truyền, failure modes.
+
+### Các Khía Cạnh Cần Xem Xét
+
+- **Dependencies**: Task này phụ thuộc vào gì? Ai phụ thuộc vào kết quả của task này?
+- **Boundaries**: Ranh giới rõ ràng chưa? Interfaces ổn định chưa?
+- **Data flow**: Dữ liệu đi từ đâu đến đâu? Thêm DB/cache/queue? Consistency?
+- **Feedback loops**: Thay đổi có tạo vòng lặp không? Cần giới hạn hay debounce?
+- **Failure modes**: Một phần lỗi → hệ thống còn lại ứng xử thế nào? Graceful degradation?
+- **Scale**: Khi tải tăng, điểm nghẽn ở đâu? N+1 queries, missing indexes, locks?
+
+### Áp Dụng Trong Task
+
+- **Research**: Mô tả (hoặc diagram) luồng hiện tại và vị trí của task
+- **Plan**: Mục "Tác động hệ thống" — modules bị ảnh hưởng, API changes, migration
+- **Subtasks**: Tách rõ schema / service / route / frontend để review dependencies
+
+---
+
+## 4. Đa Góc Nhìn (Multiple Perspectives)
+
+**Mục đích**: Tránh optimize cho một role. Cân bằng nhu cầu nhiều bên liên quan.
+
+### Bảng Góc Nhìn
+
+| Góc nhìn | Câu hỏi điển hình |
+|----------|-------------------|
+| **End user** | Dễ dùng không? Feature có match use case thực tế? |
+| **Developer** | Code dễ đọc, test được không? API nhất quán? |
+| **Security** | Ai được làm gì? Có lộ data không? Auth/authz đúng? Rate limit? |
+| **Ops/Vận hành** | Deploy thế nào? Migration cần gì? Metric/log/debug khi lỗi? |
+| **Business/Product** | Giải quyết đúng pain point chưa? Ship được từng phần? |
+| **Ngắn hạn vs dài hạn** | Ship nhanh vs kiến trúc bền vững. Tech debt chấp nhận được không? |
+
+### Áp Dụng Trong Task
+
+- **Plan**: Mục "Góc nhìn & Trade-offs" — mỗi quyết định lớn, ghi tác động per role
+- **Acceptance criteria**: Có thể tách "User: ...", "Dev: ...", "Security: ..."
+- **Review**: Nếu chỉ đúng về kỹ thuật nhưng bỏ qua security/ops → bổ sung
+
+---
+
+## 5. Checklist Nhanh (Trước Khi Kết Thúc Mỗi Phase)
+
+### Research
+
+- [ ] Đã ghi giả định và có thể sai không?
+- [ ] Đã ghi những gì chưa rõ / cần kiểm chứng?
+- [ ] Đã identify failure modes của kiến trúc hiện tại?
+
+### Plan
+
+- [ ] Đã xem xét ≥2 approaches và so sánh trade-offs?
+- [ ] Có mục Rủi ro & Giả định?
+- [ ] Có mục Edge cases?
+- [ ] Có mục Tác động hệ thống?
+- [ ] Đã xem xét ≥2 góc nhìn (user, security, dev, ops)?
+- [ ] Devil's advocate: lý do mạnh nhất để không làm approach này?
+
+### Execute
+
+- [ ] Có assumption nào bị chứng minh sai? → Ghi Changelog, cập nhật plan
+- [ ] Có scope thay đổi? → Cập nhật plan, hỏi human
+
+---
+
+## 6. Prompt Gợi Ý Cho Agent
+
+Khi giao task cho AI agent:
+
+> "Khi làm task này, áp dụng framework trong `core/THINKING.md`:
+> - Trước khi viết plan, liệt kê: (1) giả định đang dùng, (2) 2 rủi ro chính, (3) 1 phương án thay thế đã loại và lý do
+> - Xem xét tác động lên ít nhất 2 góc nhìn (vd: user + security)
+> - Nếu phát hiện giả định sai trong khi execute → dừng, ghi Changelog, hỏi"

package/.dw/core/WORKFLOW.md

@@ -1,10 +1,15 @@
-<!-- core-version: 1.0 -->
-<!-- last-updated: 2026-03-23 -->
+<!-- core-version: 1.1 -->
+<!-- last-updated: 2026-06-11 -->
 
 # dw-kit Workflow Methodology
 
 > **Platform-agnostic.** File này chứa methodology thuần — không có Claude syntax, không có tool names.
 > Platform-specific execution nằm trong `.dw/adapters/`.
+>
+> **Task doc lineage (canonical = v3, per ADR-0008 / ADR-0020):** mỗi task = **1 file `task.md`**
+> với Sections (1 Snapshot · 2 Intent & Scope · 3 Subtask Tracker · 4 Timeline · 5 Handoff). Bộ
+> 3-file đời cũ (`*-context/plan/progress.md`) và bộ 2-file v2 (`spec.md`+`tracking.md`) là **legacy** —
+> chỉ dùng `dw task migrate` cho task cũ. Ở dưới khi nói "task doc" nghĩa là `task.md` v3.
 
 ---
 
@@ -45,7 +50,7 @@
 Mỗi task nên có depth riêng, không khóa cứng theo project:
 
 - **Default**: dùng `workflow.default_depth` từ `.dw/config/dw.config.yml`
-- **Override**: ghi trực tiếp trong task docs (ví dụ `context.md`)
+- **Override**: ghi trực tiếp trong task doc (`task.md` frontmatter `depth:` hoặc Section 2 Intent)
 - **Rule**: task nào có API/DB/security scope thì có thể nâng lên `thorough` dù project đang `standard`
 
 Ưu tiên thực tế: `default_depth` giúp setup nhanh, còn execution quyết định theo rủi ro từng task.
@@ -70,9 +75,9 @@ Trả lời trước khi tiếp tục:
 
 ### Output Phase 1
 
-- [ ] Task docs tạo tại `{paths.tasks}/[task-name]/`
-- [ ] 3 files: `[name]-context.md`, `[name]-plan.md`, `[name]-progress.md`
-- [ ] Context file có: yêu cầu gốc + scope assessment + depth recommendation
+- [ ] Task doc tạo tại `{paths.tasks}/[task-name]/task.md` (v3, 1-file — qua `dw task new`)
+- [ ] Section 1 Snapshot + Section 2 Intent & Scope điền: yêu cầu gốc + scope assessment + depth recommendation
+- [ ] Section 3 Subtask Tracker khởi tạo (status sống DUY NHẤT ở đây — chống drift)
 
 ### Readiness Check
 
@@ -118,7 +123,7 @@ Khi context thiếu, AI không dừng và chờ. AI:
 
 ### Output Phase 2
 
-- [ ] `[name]-context.md` điền đầy đủ
+- [ ] `task.md` Section 2 (Intent & Scope) điền đầy đủ
 - [ ] Files liên quan: listed với vai trò rõ ràng
 - [ ] Kiến trúc hiện tại: documented (diagram nếu cần)
 - [ ] Gaps: identified, resolved hoặc flagged
@@ -181,7 +186,7 @@ Mỗi subtask phải:
 
 ### Output Phase 3
 
-- [ ] `[name]-plan.md` hoàn chỉnh
+- [ ] `task.md` Section 2/3 (plan + subtasks) hoàn chỉnh
 - [ ] ≥2 approaches so sánh
 - [ ] Subtasks với dependencies, criteria, estimate
 - [ ] Risk table với mitigation
@@ -219,12 +224,12 @@ Nếu task không có tests: viết tests sau implement, nhưng TRƯỚC khi mar
 2. **Chỉ làm đúng scope của subtask** — không "while I'm here" fixes
 3. **Gặp ambiguity → DỪNG và hỏi** — không tự suy diễn cho thay đổi lớn
 4. **Phát hiện scope thay đổi → cập nhật plan, hỏi human** trước khi tiếp tục
-5. **Mỗi subtask done = update progress file + commit**
+5. **Mỗi subtask done = update Section 3 Tracker + Section 4 Timeline + commit**
 
 ### Khi Gặp Blockers
 
 ```
-1. Ghi blocker vào progress file (mô tả, context)
+1. Ghi blocker vào `task.md` Section 5 Handoff & Friction (mô tả, context)
 2. Xác định: blocker có thể self-resolve không?
    - Có: document approach, proceed
    - Không: DỪNG, escalate, ghi next-steps rõ ràng
@@ -234,7 +239,7 @@ Nếu task không có tests: viết tests sau implement, nhưng TRƯỚC khi mar
 ### Output Phase 4
 
 - [ ] Mỗi subtask: code implemented + tests pass
-- [ ] Progress file cập nhật sau mỗi subtask
+- [ ] `task.md` Section 3 Tracker cập nhật sau mỗi subtask
 - [ ] Mỗi subtask: 1 commit (format chuẩn)
 - [ ] Không còn debug code (console.log, debugger)
 
@@ -333,7 +338,7 @@ Move task docs từ `{paths.tasks}/` → `{paths.tasks}/archive/` sau khi:
 ### Output Phase 6
 
 - [ ] Final commit(s) với message chuẩn
-- [ ] Progress file: trạng thái = Done, kết thúc date filled
+- [ ] `task.md` Section 3 Tracker: tất cả subtask = ✅ Done, Section 4 Timeline có entry close-out
 - [ ] Effort log updated (nếu enabled)
 - [ ] Handoff notes ghi (nếu bàn giao)
 - [ ] Task archived (sau merge)

package/.dw/core/templates/v2/spec.md

@@ -1,4 +1,6 @@
 ---
+# ⚠️ LEGACY TEMPLATE — v2 (spec+tracking). Canonical = v3 task.md (ADR-0008 / ADR-0020).
+# Kept only as reference for `dw task migrate`. Do not use for new tasks.
 task_id: {task-name}
 created: {YYYY-MM-DD}
 status: Draft | Approved | In Progress | Done

package/.dw/core/templates/v2/tracking.md

@@ -1,4 +1,6 @@
 ---
+# ⚠️ LEGACY TEMPLATE — v2 (spec+tracking). Canonical = v3 task.md (ADR-0008 / ADR-0020).
+# Kept only as reference for `dw task migrate`. Do not use for new tasks.
 task_id: {task-name}
 started: {YYYY-MM-DD}
 last_updated: {YYYY-MM-DD}

package/.dw/core/templates/vi/task-context.md

@@ -1,92 +1,96 @@
-# Context: [Task Name]
-
-## Ngày khảo sát: [date]
-## Depth: quick | standard | thorough
-## Depth Source: default (from config) | override (task-specific)
-## Override Reason (nếu có): [ví dụ: API contract change / DB migration / security-sensitive]
-
----
-
-## Yêu Cầu
-
-> [Mô tả yêu cầu gốc. Nếu có BA: link đến requirements doc]
-
-**Acceptance criteria cấp cao:**
-- Given [trạng thái ban đầu], When [action], Then [kết quả mong đợi]
-
----
-
-## Codebase Analysis
-
-### Scope Assessment
-
-AI đã phân tích codebase và tìm thấy:
-
-**Files liên quan:**
-| # | File | Vai trò | Thay đổi? | Confidence |
-|---|------|---------|-----------|-----------|
-| 1 | | | Có / Không / Chưa rõ | HIGH / MED / LOW |
-
-> Xác nhận hoặc sửa danh sách trên trước khi tiếp tục.
-
-### Kiến Trúc Hiện Tại
-
-```
-[Mô tả luồng — AI điền sau khi research]
-Input → [Module A] → [Module B] → Output
-```
-
-### Data Flow
-
-- **Input**: [từ đâu, format gì]
-- **Processing**: [logic chính]
-- **Output**: [đi đâu, format gì]
-
----
-
-## Dependencies
-
-**Upstream** (task này phụ thuộc vào):
-- [ ] [Module/API] — [vai trò]
-
-**Downstream** (bị ảnh hưởng bởi task):
-- [ ] [Module/API] — [ảnh hưởng thế nào]
-
----
-
-## Patterns Phát Hiện
-
-| Pattern | Mô tả | Ví dụ (file:line) | Follow? |
-|---------|--------|-------------------|---------|
-| | | | Có / Không |
-
----
-
-## Test Coverage
-
-- Tests hiện tại: [có/không, file nào]
-- Coverage: [% hoặc mô tả]
-- Gaps: [thiếu test ở đâu — cần bổ sung]
-
----
-
-## Giả Định
-
-> AI tự động điền dựa trên codebase analysis. Xác nhận hoặc sửa.
-
-| # | Giả định | Nguồn | Có thể sai không? |
-|---|----------|-------|-------------------|
-| 1 | | Code analysis | Thấp / Trung / Cao |
-
----
-
-## Chưa Rõ — Cần Làm Rõ Trước Khi Plan
-
-- [ ] [Câu hỏi 1] — ảnh hưởng đến approach nếu sai
-- [ ] [Câu hỏi 2]
-
----
-
-## Ghi Chú
-
-[Gotchas, tech debt liên quan, lịch sử thay đổi gần đây]
+<!-- ⚠️ LEGACY TEMPLATE — do not use for new tasks. -->
+<!-- Canonical task doc lineage = v3 (.dw/core/templates/v3/task.md), per ADR-0008 / ADR-0020. -->
+<!-- Kept only as reference for `dw task migrate` + reading legacy task docs. -->
+
+# Context: [Task Name]
+
+## Ngày khảo sát: [date]
+## Depth: quick | standard | thorough
+## Depth Source: default (from config) | override (task-specific)
+## Override Reason (nếu có): [ví dụ: API contract change / DB migration / security-sensitive]
+
+---
+
+## Yêu Cầu
+
+> [Mô tả yêu cầu gốc. Nếu có BA: link đến requirements doc]
+
+**Acceptance criteria cấp cao:**
+- Given [trạng thái ban đầu], When [action], Then [kết quả mong đợi]
+
+---
+
+## Codebase Analysis
+
+### Scope Assessment
+
+AI đã phân tích codebase và tìm thấy:
+
+**Files liên quan:**
+| # | File | Vai trò | Thay đổi? | Confidence |
+|---|------|---------|-----------|-----------|
+| 1 | | | Có / Không / Chưa rõ | HIGH / MED / LOW |
+
+> Xác nhận hoặc sửa danh sách trên trước khi tiếp tục.
+
+### Kiến Trúc Hiện Tại
+
+```
+[Mô tả luồng — AI điền sau khi research]
+Input → [Module A] → [Module B] → Output
+```
+
+### Data Flow
+
+- **Input**: [từ đâu, format gì]
+- **Processing**: [logic chính]
+- **Output**: [đi đâu, format gì]
+
+---
+
+## Dependencies
+
+**Upstream** (task này phụ thuộc vào):
+- [ ] [Module/API] — [vai trò]
+
+**Downstream** (bị ảnh hưởng bởi task):
+- [ ] [Module/API] — [ảnh hưởng thế nào]
+
+---
+
+## Patterns Phát Hiện
+
+| Pattern | Mô tả | Ví dụ (file:line) | Follow? |
+|---------|--------|-------------------|---------|
+| | | | Có / Không |
+
+---
+
+## Test Coverage
+
+- Tests hiện tại: [có/không, file nào]
+- Coverage: [% hoặc mô tả]
+- Gaps: [thiếu test ở đâu — cần bổ sung]
+
+---
+
+## Giả Định
+
+> AI tự động điền dựa trên codebase analysis. Xác nhận hoặc sửa.
+
+| # | Giả định | Nguồn | Có thể sai không? |
+|---|----------|-------|-------------------|
+| 1 | | Code analysis | Thấp / Trung / Cao |
+
+---
+
+## Chưa Rõ — Cần Làm Rõ Trước Khi Plan
+
+- [ ] [Câu hỏi 1] — ảnh hưởng đến approach nếu sai
+- [ ] [Câu hỏi 2]
+
+---
+
+## Ghi Chú
+
+[Gotchas, tech debt liên quan, lịch sử thay đổi gần đây]