@relipa/ai-flow-kit 0.1.3 → 0.1.4

package/custom/skills/generate-testcase/SKILL.md

@@ -21,6 +21,29 @@ Trước khi tạo bất kỳ testcase nào:
 - Nếu requirement chưa rõ → hỏi TESTER từng câu một, chờ trả lời
 - **KHÔNG tạo testcase ở bước này**
 
+**Bước 1b — Đọc Source Code (nếu workspace có source repos):**
+
+Chạy ngay sau khi đọc `test-analysis.md`, trước khi phân tích scenarios.
+
+Nếu workspace mở dạng parent folder chứa cả `ak docs` lẫn source code repos:
+
+1. Xác định repo từ `test-analysis.md` (field Repo) hoặc từ ticket context. Nếu không rõ → hỏi 1 câu
+2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`):
+   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
+   - `gitnexus: context("ClassName")` → xem service/controller đầy đủ
+3. **Nếu không có GitNexus**: đọc trực tiếp:
+   - Validation rules / Form request / DTO — tìm constraint thực tế (max length, regex, required)
+   - Service / Business Logic — tìm business rules ẩn không có trong spec
+   - API response format — xác định expected result chính xác
+   - Data models / DB schema — tìm DB constraint, unique, nullable
+4. Bổ sung vào phân tích:
+   - Validation cases từ code (độ dài max, format regex, required vs optional)
+   - Business rules phát hiện trong service layer
+   - Edge cases từ DB constraint (unique violation, FK constraint)
+   - Điểm không nhất quán giữa spec và code thực tế → đặt câu hỏi với TESTER
+
+> ⚠️ Source code chỉ dùng để **mở rộng coverage** — thêm test cases dựa trên code thực tế. Expected result vẫn lấy từ ticket/spec của BA/PM, **không lấy từ code**.
+
 ---
 
 ### Bước 2 — Dev Artifacts Check (Phase 2a — trước checklist)
@@ -76,13 +99,11 @@ Liệt kê scenarios theo nhóm, output vào `test-plan/checklist.md`:
 📙 **Regression** _(nếu Dev Artifacts Check Bước 2 tìm thấy impacted areas)_
 - Mỗi item ghi rõ: "Regression — [vùng ảnh hưởng] — [lý do từ PR diff]"
 
-```
 ⏸️ GATE 2 — PHASE 2a: SCENARIOS READY
 Scenarios: [N] total
 - Functional: [N] | Non-functional: [N] | Integration: [N] | Exploratory: [N] | Regression: [N]
-→ Review: test-plan/checklist.md
+→ Review: [test-plan/checklist.md](test-plan/checklist.md)
 → Type APPROVED to proceed to Phase 2b
-```
 
 ---
 
@@ -155,14 +176,12 @@ Output testcases: `test-plan/test-cases/[ScreenID]-testcases.md`
 | **Total** | **[S/M/L/XL]** |
 ```
 
-```
 ⏸️ GATE 2 — PHASE 2b: TESTCASES GENERATED
 Test cases: [N] total ([N] positive / [N] negative / [N] edge)
-Test plan:  test-plan/test-plan.md
-→ Review: test-plan/test-cases/
+Test plan:  [test-plan/test-plan.md](test-plan/test-plan.md)
+→ Review: [test-plan/test-cases/](test-plan/test-cases/)
 → Type APPROVED to proceed to Phase 2c (Review & Optimize)
 → Or provide feedback to update
-```
 
 ---
 
@@ -206,13 +225,24 @@ Kiểm tra theo thứ tự, output vào `test-plan/review-report.md`:
    Priority: High (phải fix trước Phase 2d) / Medium / Low (có thể defer)
 ```
 
-```
 ⏸️ GATE 2 — PHASE 2c: REVIEW COMPLETE
 Issues: [N] duplicate | [N] problematic | [N] to optimize | [N] missing
-→ Review: test-plan/review-report.md
-→ Type APPROVED to proceed to Phase 2d (Coverage Check & Final Output)
+High priority chưa xử lý: [N]
+→ Review: [test-plan/review-report.md](test-plan/review-report.md)
+→ Type APPROVED to proceed to Phase 2d (chỉ khi High priority = 0)
 → Or provide specific fixes to apply
-```
+
+**Nếu nhận được APPROVED mà còn issues Priority High chưa xử lý → từ chối ngay:**
+
+⛔ PHASE 2c BLOCKED — Còn [N] issues Priority HIGH chưa được xử lý:
+
+| TC_ID | Vấn đề | Đề xuất sửa |
+|-------|--------|------------|
+| [TC_ID] | [vấn đề] | [đề xuất] |
+
+→ Cung cấp fixes cho các issues trên, sau đó gõ APPROVED.
+❌ APPROVED chỉ được chấp nhận khi không còn issues Priority High.
+Medium và Low có thể defer — không block APPROVED.
 
 ---
 
@@ -301,3 +331,12 @@ Issues: [N] duplicate | [N] problematic | [N] to optimize | [N] missing
 | **High** | Chức năng chính không hoạt động đúng |
 | **Medium** | Chức năng phụ bị ảnh hưởng, workaround có thể có |
 | **Low** | UI/UX nhỏ, cosmetic, không ảnh hưởng chức năng |
+
+---
+
+## Mandatory Rules
+
+- ✅ **PHẢI** dừng và chờ APPROVED sau mỗi Phase (2a → 2b → 2c → 2d)
+- ❌ **KHÔNG chấp nhận APPROVED** ở Phase 2c khi còn issues Priority **High** chưa được xử lý — từ chối và hiển thị danh sách issues cần fix
+- ✅ Medium và Low issues không block APPROVED — có thể defer
+- ❌ **KHÔNG** tự động chuyển phase mà không có APPROVED từ TESTER

package/custom/skills/generate-testcase/templates/testcase.md

@@ -11,78 +11,69 @@
 | **Người kiểm duyệt (Reviewer)** | |
 | **Ngày kiểm duyệt (Review Date)** | |
 
-## 2. Kết quả kiểm thử tổng hợp (Test Execution Summary)
+## 2. Danh sách Test Cases Chi Tiết
 
-| Vòng kiểm thử (Round) | Đạt (Passed) | Lỗi (Failed) | Chưa test (Untest) | Chờ (Pending) | Tổng số (Total) | Tỷ lệ đạt (%) |
-|:---|:---:|:---:|:---:|:---:|:---:|:---:|
-| Round 1 | 0 | 0 | 0 | 0 | 0 | 0% |
-| Round 2 | 0 | 0 | 0 | 0 | 0 | 0% |
+### 2.1. Kiểm thử Truy cập & Phân quyền (Access & Authorization)
 
----
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_001 | Truy cập trực tiếp qua URL khi chưa đăng nhập | High | Người dùng chưa đăng nhập hệ thống | 1. Nhập URL màn hình vào thanh địa chỉ trình duyệt.<br>2. Nhấn Enter. | URL của màn hình | Hệ thống không cho phép truy cập.<br>Tự động chuyển hướng về trang đăng nhập (Login). | | |
+| [ID]_002 | Truy cập trực tiếp qua URL khi đã đăng nhập | Medium | Người dùng đã đăng nhập thành công | 1. Nhập URL màn hình vào thanh địa chỉ trình duyệt.<br>2. Nhấn Enter. | URL của màn hình | Hệ thống cho phép truy cập.<br>Hiển thị đúng giao diện màn hình. | | |
+| [ID]_003 | Truy cập qua button/menu điều hướng | Low | Người dùng đang ở màn hình danh sách | 1. Click vào nút "Thêm mới" hoặc menu tương ứng. | - | Hệ thống mở màn hình đăng ký/thực hiện tương ứng thành công. | | |
 
-## 3. Danh sách Test Cases Chi Tiết
+### 2.2. Kiểm thử Giao diện Người dùng (UI/UX)
 
-### 3.1. Kiểm thử Truy cập & Phân quyền (Access & Authorization)
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_004 | Kiểm tra hiển thị giao diện tổng quan | Low | Màn hình hiển thị bình thường | 1. Quan sát giao diện màn hình.<br>2. Kiểm tra layout, màu sắc, font chữ, khoảng cách giữa các trường. | - | 1. Layout cân đối, font chữ và cỡ chữ đồng nhất.<br>2. Các trường bắt buộc nhập có dấu sao đỏ (*).<br>3. Không có lỗi chính tả.<br>4. Định dạng placeholder hiển thị chính xác theo thiết kế. | | |
 
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_001 | Truy cập trực tiếp qua URL khi chưa đăng nhập | High | Người dùng chưa đăng nhập hệ thống | 1. Nhập URL màn hình vào thanh địa chỉ trình duyệt.<br>2. Nhấn Enter. | URL của màn hình | Hệ thống không cho phép truy cập.<br>Tự động chuyển hướng về trang đăng nhập (Login). | | | | | | | | |
-| [ID]_002 | Truy cập trực tiếp qua URL khi đã đăng nhập | Medium | Người dùng đã đăng nhập thành công | 1. Nhập URL màn hình vào thanh địa chỉ trình duyệt.<br>2. Nhấn Enter. | URL của màn hình | Hệ thống cho phép truy cập.<br>Hiển thị đúng giao diện màn hình. | | | | | | | | |
-| [ID]_003 | Truy cập qua button/menu điều hướng | Low | Người dùng đang ở màn hình danh sách | 1. Click vào nút "Thêm mới" hoặc menu tương ứng. | - | Hệ thống mở màn hình đăng ký/thực hiện tương ứng thành công. | | | | | | | | |
-
-### 3.2. Kiểm thử Giao diện Người dùng (UI/UX)
-
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_004 | Kiểm tra hiển thị giao diện tổng quan | Low | Màn hình hiển thị bình thường | 1. Quan sát giao diện màn hình.<br>2. Kiểm tra layout, màu sắc, font chữ, khoảng cách giữa các trường. | - | 1. Layout cân đối, font chữ và cỡ chữ đồng nhất.<br>2. Các trường bắt buộc nhập có dấu sao đỏ (*).<br>3. Không có lỗi chính tả.<br>4. Định dạng placeholder hiển thị chính xác theo thiết kế. | | | | | | | | |
-
-### 3.3. Kiểm thử Validation các trường nhập liệu (Input Validation)
+### 2.3. Kiểm thử Validation các trường nhập liệu (Input Validation)
 
 *(Tạo riêng từng bảng hoặc nhóm theo từng Field để dễ theo dõi)*
 
 #### * Đối với Trường [Tên Trường] — Text
 
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_0xx | Kiểm tra giá trị mặc định | Low | Đã truy cập màn hình | 1. Quan sát trường [Tên Trường]. | - | Giá trị mặc định là trống (blank).<br>Hiển thị đúng Placeholder theo thiết kế. | | | | | | | | |
-| [ID]_0xx | Kiểm tra trường bắt buộc nhập để trống | High | Đã truy cập màn hình | 1. Để trống trường [Tên Trường].<br>2. Bấm nút thực hiện (Đăng ký/Lưu). | Empty | 1. Hiển thị thông báo lỗi: "Hãy nhập [Tên Trường]".<br>2. Field bị highlight viền đỏ. | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhập ký tự khoảng trắng (Spaces) | Medium | Đã truy cập màn hình | 1. Nhập toàn khoảng trắng vào trường.<br>2. Bấm nút thực hiện hoặc focus out. | `"   "` | Hệ thống xem như để trống.<br>Báo lỗi bắt buộc nhập (nếu là trường Required) hoặc tự động trim khoảng trắng. | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhập khoảng trắng ở đầu/cuối chuỗi | Low | Đã truy cập màn hình | 1. Nhập chuỗi có khoảng trắng ở đầu/cuối.<br>2. Bấm nút thực hiện (Đăng ký/Lưu). | `"  data_test  "` | Hệ thống tự động cắt bỏ (trim) khoảng trắng ở đầu và cuối chuỗi trước khi lưu vào DB. | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhập độ dài tối thiểu/tối đa (Boundary Value) | Medium | Đã truy cập màn hình, biết Maxlength = N | 1. Nhập chuỗi độ dài N-1 ký tự.<br>2. Nhập chuỗi độ dài N ký tự.<br>3. Nhập chuỗi độ dài > N ký tự. | Chuỗi test tương ứng | - Độ dài <= N: cho phép nhập và lưu bình thường.<br>- Độ dài > N: hệ thống chặn trực tiếp trên UI hoặc báo lỗi hợp lệ. | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhập ký tự đặc biệt | Medium | Đã truy cập màn hình | 1. Nhập các ký tự đặc biệt (!@#$%^&*).<br>2. Bấm nút thực hiện. | `"!@#$%"` | Hệ thống lưu trữ đúng định dạng ký tự đã nhập (hoặc báo lỗi nếu có quy định hạn chế định dạng). | | | | | | | | |
-| [ID]_0xx | Kiểm tra thao tác Copy/Paste | Low | Đã truy cập màn hình | 1. Copy một chuỗi hợp lệ.<br>2. Paste vào trường thông tin.<br>3. Bấm nút thực hiện. | - | Cho phép paste dữ liệu vào field thành công và xử lý lưu bình thường. | | | | | | | | |
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_0xx | Kiểm tra giá trị mặc định | Low | Đã truy cập màn hình | 1. Quan sát trường [Tên Trường]. | - | Giá trị mặc định là trống (blank).<br>Hiển thị đúng Placeholder theo thiết kế. | | |
+| [ID]_0xx | Kiểm tra trường bắt buộc nhập để trống | High | Đã truy cập màn hình | 1. Để trống trường [Tên Trường].<br>2. Bấm nút thực hiện (Đăng ký/Lưu). | Empty | 1. Hiển thị thông báo lỗi: "Hãy nhập [Tên Trường]".<br>2. Field bị highlight viền đỏ. | | |
+| [ID]_0xx | Kiểm tra nhập ký tự khoảng trắng (Spaces) | Medium | Đã truy cập màn hình | 1. Nhập toàn khoảng trắng vào trường.<br>2. Bấm nút thực hiện hoặc focus out. | `"   "` | Hệ thống xem như để trống.<br>Báo lỗi bắt buộc nhập (nếu là trường Required) hoặc tự động trim khoảng trắng. | | |
+| [ID]_0xx | Kiểm tra nhập khoảng trắng ở đầu/cuối chuỗi | Low | Đã truy cập màn hình | 1. Nhập chuỗi có khoảng trắng ở đầu/cuối.<br>2. Bấm nút thực hiện (Đăng ký/Lưu). | `"  data_test  "` | Hệ thống tự động cắt bỏ (trim) khoảng trắng ở đầu và cuối chuỗi trước khi lưu vào DB. | | |
+| [ID]_0xx | Kiểm tra nhập độ dài tối thiểu/tối đa (Boundary Value) | Medium | Đã truy cập màn hình, biết Maxlength = N | 1. Nhập chuỗi độ dài N-1 ký tự.<br>2. Nhập chuỗi độ dài N ký tự.<br>3. Nhập chuỗi độ dài > N ký tự. | Chuỗi test tương ứng | - Độ dài <= N: cho phép nhập và lưu bình thường.<br>- Độ dài > N: hệ thống chặn trực tiếp trên UI hoặc báo lỗi hợp lệ. | | |
+| [ID]_0xx | Kiểm tra nhập ký tự đặc biệt | Medium | Đã truy cập màn hình | 1. Nhập các ký tự đặc biệt (!@#$%^&*).<br>2. Bấm nút thực hiện. | `"!@#$%"` | Hệ thống lưu trữ đúng định dạng ký tự đã nhập (hoặc báo lỗi nếu có quy định hạn chế định dạng). | | |
+| [ID]_0xx | Kiểm tra thao tác Copy/Paste | Low | Đã truy cập màn hình | 1. Copy một chuỗi hợp lệ.<br>2. Paste vào trường thông tin.<br>3. Bấm nút thực hiện. | - | Cho phép paste dữ liệu vào field thành công và xử lý lưu bình thường. | | |
 
 #### * Đối với Trường Số (Number / Price / Quantity)
 
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_0xx | Kiểm tra nhập chữ cái và ký tự đặc biệt | Medium | Đã truy cập màn hình | 1. Cố gắng nhập chữ cái (a, b, c...) hoặc ký tự đặc biệt.<br>2. Bấm nút thực hiện. | `"abc"`, `"@#$"` | UI ngăn không cho nhập chữ cái/ký tự đặc biệt, chỉ chấp nhận chữ số. | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhập số âm | High | Đã truy cập màn hình | 1. Nhập số âm.<br>2. Bấm nút thực hiện. | `-10` | Báo lỗi giá trị phải lớn hơn hoặc bằng 0 (hoặc chặn dấu trừ `-` trực tiếp từ UI). | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhập số thập phân | High | Đã truy cập màn hình | 1. Nhập số có dấu phẩy thập phân.<br>2. Bấm nút thực hiện. | `1.5`, `2,3` | Báo lỗi chỉ chấp nhận số nguyên (hoặc chấp nhận số thập phân tùy đặc tả nghiệp vụ). | | | | | | | | |
-| [ID]_0xx | Kiểm tra hiển thị định dạng phân tách hàng nghìn | Low | Đã truy cập màn hình | 1. Nhập số lớn.<br>2. Focus out khỏi trường nhập liệu. | `1000000` | Số tự động định dạng phân tách hàng nghìn (VD: `1,000,000`). | | | | | | | | |
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_0xx | Kiểm tra nhập chữ cái và ký tự đặc biệt | Medium | Đã truy cập màn hình | 1. Cố gắng nhập chữ cái (a, b, c...) hoặc ký tự đặc biệt.<br>2. Bấm nút thực hiện. | `"abc"`, `"@#$"` | UI ngăn không cho nhập chữ cái/ký tự đặc biệt, chỉ chấp nhận chữ số. | | |
+| [ID]_0xx | Kiểm tra nhập số âm | High | Đã truy cập màn hình | 1. Nhập số âm.<br>2. Bấm nút thực hiện. | `-10` | Báo lỗi giá trị phải lớn hơn hoặc bằng 0 (hoặc chặn dấu trừ `-` trực tiếp từ UI). | | |
+| [ID]_0xx | Kiểm tra nhập số thập phân | High | Đã truy cập màn hình | 1. Nhập số có dấu phẩy thập phân.<br>2. Bấm nút thực hiện. | `1.5`, `2,3` | Báo lỗi chỉ chấp nhận số nguyên (hoặc chấp nhận số thập phân tùy đặc tả nghiệp vụ). | | |
+| [ID]_0xx | Kiểm tra hiển thị định dạng phân tách hàng nghìn | Low | Đã truy cập màn hình | 1. Nhập số lớn.<br>2. Focus out khỏi trường nhập liệu. | `1000000` | Số tự động định dạng phân tách hàng nghìn (VD: `1,000,000`). | | |
 
 #### * Đối với Trường File Upload (Hình ảnh)
 
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_0xx | Kiểm tra không upload file (Trường tùy chọn) | Medium | Đã truy cập màn hình | 1. Không chọn file upload.<br>2. Bấm nút thực hiện. | - | Hệ thống cho phép thực hiện thành công mà không báo lỗi. | | | | | | | | |
-| [ID]_0xx | Kiểm tra upload file sai định dạng | High | Định dạng cho phép: jpeg, png | 1. Chọn upload file có định dạng không được phép (xlsx, gif, pdf...).<br>2. Tiến hành upload. | File `.pdf`, `.xlsx` | Upload không thành công. Hiển thị thông báo lỗi đúng thiết kế: "Hình ảnh phải là định dạng jpeg hoặc png." | | | | | | | | |
-| [ID]_0xx | Kiểm tra upload dung lượng vượt quá giới hạn | High | Giới hạn dung lượng: tối đa 10MB | 1. Chọn file có kích thước > 10MB.<br>2. Tiến hành upload. | File kích thước `10.5MB` | Upload thất bại. Hiển thị lỗi cảnh báo: "Dung lượng hình ảnh vượt quá 10MB." | | | | | | | | |
-| [ID]_0xx | Kiểm tra upload file giả mạo đuôi mở rộng (Spoofing) | High | Đã truy cập màn hình | 1. Đổi đuôi file thực thi nguy hiểm `.exe` thành `.jpg`.<br>2. Chọn upload file này. | File `.exe` đổi tên thành `.jpg` | Hệ thống kiểm tra phần thân file (MIME type) thực tế và báo lỗi không đúng định dạng. | | | | | | | | |
-| [ID]_0xx | Kiểm tra kéo thả file (Drag & Drop) | Low | Đã truy cập màn hình | 1. Kéo file ảnh thả vào vùng upload. | File `.png` hợp lệ | Upload file thành công và hiển thị thumbnail ảnh xem trước trên giao diện. | | | | | | | | |
-
-### 3.4. Kiểm thử Logic Nghiệp vụ (Business Rules - BR)
-
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_0xx | Kiểm tra ràng buộc trùng lặp dữ liệu duy nhất (Unique) | High | Đã tồn tại bản ghi trong DB | 1. Nhập thông tin trùng khóa chính/mã duy nhất với bản ghi cũ.<br>2. Điền các thông tin hợp lệ khác.<br>3. Bấm Đăng ký. | Mã trùng lặp | Hệ thống báo lỗi trùng lặp: "Mã/Tên này đã tồn tại trong hệ thống. Vui lòng kiểm tra lại." | | | | | | | | |
-| [ID]_0xx | Kiểm tra logic liên kết dữ liệu động (Dynamic Form Control) | High | Điều kiện thay đổi hiển thị | 1. Tích chọn/Bỏ tích chọn [Checkbox điều kiện]. | - | Giao diện tự động thay đổi hiển thị ẩn/hiện hoặc disable/enable các trường thông tin liên quan theo đúng mô tả Business Rule. | | | | | | | | |
-| [ID]_0xx | Kiểm tra lưu dữ liệu vào Database thành công | Critical | Nhập đầy đủ và chính xác tất cả dữ liệu hợp lệ | 1. Nhập toàn bộ dữ liệu hợp lệ.<br>2. Bấm nút Đăng ký.<br>3. Kiểm tra DB và màn hình danh sách. | Dữ liệu hợp lệ | 1. Lưu bản ghi mới thành công.<br>2. Hiển thị thông báo thành công.<br>3. Dữ liệu trong Database khớp hoàn toàn các trường thông tin đã điền trên UI. | | | | | | | | |
-
-### 3.5. Kiểm thử Ngoại lệ & Hệ thống (Exceptions & Systems)
-
-| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment | R1 Result | R1 Date | R1 Tester | R2 Result | R2 Date | R2 Tester |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| [ID]_0xx | Bấm nút Đăng ký nhiều lần liên tiếp (Double Click) | High | Đã điền đầy đủ dữ liệu hợp lệ | 1. Click liên tiếp nhiều lần vào nút Đăng ký/Lưu. | - | Nút bấm bị disable ngay sau lượt click đầu tiên. Hệ thống chỉ xử lý và tạo duy nhất 1 bản ghi trong DB, không tạo trùng lặp. | | | | | | | | |
-| [ID]_0xx | Kiểm tra mất kết nối mạng đột ngột khi bấm Lưu | High | Điền đầy đủ dữ liệu hợp lệ | 1. Bấm nút Lưu.<br>2. Đồng thời ngắt kết nối mạng. | - | Hệ thống hiển thị loading và thông báo lỗi kết nối mạng, không bị crash hoặc treo màn hình trắng. | | | | | | | | |
-| [ID]_0xx | Kiểm tra nhấn nút Quay lại | Low | Đã điền một số dữ liệu | 1. Nhập một số thông tin.<br>2. Bấm nút Quay lại. | - | Hệ thống chuyển hướng về màn hình danh sách trước đó.<br>Bản ghi mới không được tạo trong DB. | | | | | | | | |
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_0xx | Kiểm tra không upload file (Trường tùy chọn) | Medium | Đã truy cập màn hình | 1. Không chọn file upload.<br>2. Bấm nút thực hiện. | - | Hệ thống cho phép thực hiện thành công mà không báo lỗi. | | |
+| [ID]_0xx | Kiểm tra upload file sai định dạng | High | Định dạng cho phép: jpeg, png | 1. Chọn upload file có định dạng không được phép (xlsx, gif, pdf...).<br>2. Tiến hành upload. | File `.pdf`, `.xlsx` | Upload không thành công. Hiển thị thông báo lỗi đúng thiết kế: "Hình ảnh phải là định dạng jpeg hoặc png." | | |
+| [ID]_0xx | Kiểm tra upload dung lượng vượt quá giới hạn | High | Giới hạn dung lượng: tối đa 10MB | 1. Chọn file có kích thước > 10MB.<br>2. Tiến hành upload. | File kích thước `10.5MB` | Upload thất bại. Hiển thị lỗi cảnh báo: "Dung lượng hình ảnh vượt quá 10MB." | | |
+| [ID]_0xx | Kiểm tra upload file giả mạo đuôi mở rộng (Spoofing) | High | Đã truy cập màn hình | 1. Đổi đuôi file thực thi nguy hiểm `.exe` thành `.jpg`.<br>2. Chọn upload file này. | File `.exe` đổi tên thành `.jpg` | Hệ thống kiểm tra phần thân file (MIME type) thực tế và báo lỗi không đúng định dạng. | | |
+| [ID]_0xx | Kiểm tra kéo thả file (Drag & Drop) | Low | Đã truy cập màn hình | 1. Kéo file ảnh thả vào vùng upload. | File `.png` hợp lệ | Upload file thành công và hiển thị thumbnail ảnh xem trước trên giao diện. | | |
+
+### 2.4. Kiểm thử Logic Nghiệp vụ (Business Rules - BR)
+
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_0xx | Kiểm tra ràng buộc trùng lặp dữ liệu duy nhất (Unique) | High | Đã tồn tại bản ghi trong DB | 1. Nhập thông tin trùng khóa chính/mã duy nhất với bản ghi cũ.<br>2. Điền các thông tin hợp lệ khác.<br>3. Bấm Đăng ký. | Mã trùng lặp | Hệ thống báo lỗi trùng lặp: "Mã/Tên này đã tồn tại trong hệ thống. Vui lòng kiểm tra lại." | | |
+| [ID]_0xx | Kiểm tra logic liên kết dữ liệu động (Dynamic Form Control) | High | Điều kiện thay đổi hiển thị | 1. Tích chọn/Bỏ tích chọn [Checkbox điều kiện]. | - | Giao diện tự động thay đổi hiển thị ẩn/hiện hoặc disable/enable các trường thông tin liên quan theo đúng mô tả Business Rule. | | |
+| [ID]_0xx | Kiểm tra lưu dữ liệu vào Database thành công | Critical | Nhập đầy đủ và chính xác tất cả dữ liệu hợp lệ | 1. Nhập toàn bộ dữ liệu hợp lệ.<br>2. Bấm nút Đăng ký.<br>3. Kiểm tra DB và màn hình danh sách. | Dữ liệu hợp lệ | 1. Lưu bản ghi mới thành công.<br>2. Hiển thị thông báo thành công.<br>3. Dữ liệu trong Database khớp hoàn toàn các trường thông tin đã điền trên UI. | | |
+
+### 2.5. Kiểm thử Ngoại lệ & Hệ thống (Exceptions & Systems)
+
+| TC ID | Test Case Name | Severity | Pre-condition | Steps | Data Test | Expected Result | Ticket ID | Comment |
+|---|---|---|---|---|---|---|---|---|
+| [ID]_0xx | Bấm nút Đăng ký nhiều lần liên tiếp (Double Click) | High | Đã điền đầy đủ dữ liệu hợp lệ | 1. Click liên tiếp nhiều lần vào nút Đăng ký/Lưu. | - | Nút bấm bị disable ngay sau lượt click đầu tiên. Hệ thống chỉ xử lý và tạo duy nhất 1 bản ghi trong DB, không tạo trùng lặp. | | |
+| [ID]_0xx | Kiểm tra mất kết nối mạng đột ngột khi bấm Lưu | High | Điền đầy đủ dữ liệu hợp lệ | 1. Bấm nút Lưu.<br>2. Đồng thời ngắt kết nối mạng. | - | Hệ thống hiển thị loading và thông báo lỗi kết nối mạng, không bị crash hoặc treo màn hình trắng. | | |
+| [ID]_0xx | Kiểm tra nhấn nút Quay lại | Low | Đã điền một số dữ liệu | 1. Nhập một số thông tin.<br>2. Bấm nút Quay lại. | - | Hệ thống chuyển hướng về màn hình danh sách trước đó.<br>Bản ghi mới không được tạo trong DB. | | |

package/custom/skills/test-analysis/SKILL.md

@@ -35,6 +35,31 @@ Một trong hai:
 
 ---
 
+### Step 1b: Đọc Source Code
+
+Chạy ngay sau Step 1, trước khi bắt đầu phân tích requirements.
+
+Nếu workspace mở dạng parent folder chứa cả `ak docs` lẫn source code repos:
+
+1. Xác định repo liên quan: đọc field `repo` trong `.aiflow/context/current.json`, hoặc suy từ ticket context (tên module, màn hình). Nếu không rõ → hỏi TESTER 1 câu: "Feature này thuộc repo nào?"
+2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`): dùng GitNexus thay vì đọc file trực tiếp:
+   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
+   - `gitnexus: context("ClassName")` → xem toàn bộ class/service
+3. **Nếu không có GitNexus**: đọc trực tiếp các file liên quan trong repo:
+   - Routes / API endpoints của màn hình
+   - Controller / Service — logic xử lý request
+   - Validation rules / Form request / DTO
+   - Data models / Entity / DB schema
+4. Tích hợp vào phân tích:
+   - Validation rules thực tế trong code (có thể khác với spec)
+   - Business rules ẩn trong service layer
+   - API response format thực tế
+   - Constraints từ DB schema
+
+> ⚠️ Source code chỉ dùng để **mở rộng coverage** (thêm test cases dựa trên code thực tế) và phát hiện điểm không nhất quán giữa spec và implement. Expected result vẫn lấy từ ticket/spec của BA/PM — **không lấy từ code**.
+
+---
+
 ### Step 2: Phân tích Requirements
 
 Dựa trên ticket/description, phân tích:
@@ -225,7 +250,6 @@ Tạo `test-plan/test-analysis.md`:
 
 ### Step 5: Present to Tester
 
-```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ⏸️ GATE 1: TEST ANALYSIS READY
 
@@ -235,13 +259,22 @@ Summary:
   Approach:  [Manual / Automation / Mixed]
   Estimate:  [S / M / L / XL]
 
-→ Review: test-plan/test-analysis.md
+→ Review: [test-plan/test-analysis.md](test-plan/test-analysis.md)
 → Type APPROVED to proceed to Gate 2
 → Or provide feedback to update
 
 ⚠️ I will NOT proceed to Gate 2 until I receive "APPROVED".
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
+
+**Nếu nhận được APPROVED mà còn câu hỏi clarify (Step 3) chưa được TESTER trả lời → từ chối ngay:**
+
+⛔ GATE 1 BLOCKED — Còn câu hỏi chưa được trả lời.
+
+Câu hỏi đang chờ:
+- [câu hỏi clarify chưa được trả lời]
+
+→ Vui lòng trả lời câu hỏi trên trước khi gõ APPROVED.
+❌ APPROVED không được chấp nhận khi còn câu hỏi chưa được làm rõ.
 
 ---
 
@@ -257,6 +290,7 @@ Summary:
 - ❌ **KHÔNG** tiến sang Gate 2 khi chưa nhận "APPROVED"
 - ❌ **KHÔNG** hỏi nhiều câu cùng lúc — từng câu một, chờ trả lời
 - ❌ **KHÔNG** viết code ở Gate 1
+- ❌ **KHÔNG chấp nhận APPROVED** khi còn câu hỏi clarify (Step 3) chưa được TESTER trả lời — từ chối và hiển thị câu hỏi còn lại
 - ✅ **PHẢI** lưu `test-plan/test-analysis.md`
 - ✅ **PHẢI** hiển thị Gate 1 prompt và chờ APPROVED
 - ✅ **PHẢI** xác định scope rõ ràng trước khi liệt kê flows

package/custom/skills/test-skills/categories/00-core/00.01.requirement-analysis.md

@@ -0,0 +1,111 @@
+# Mục đích
+Hiểu đúng, đủ, sâu và toàn diện yêu cầu hệ thống dưới góc nhìn của Senior QA Engineer (10+ năm kinh nghiệm) trước khi tiến hành thiết kế kịch bản kiểm thử (test scenarios) hay tạo test case. Quy trình này giúp tránh sót lọt lỗi nghiệp vụ, tối ưu hóa nguồn lực kiểm thử và kiểm soát chặt chẽ phạm vi dự án.
+
+# Input
+- Tài liệu yêu cầu nghiệp vụ: SRS, User Story, PRD, hoặc mô tả tính năng.
+- Tài liệu thiết kế giao diện (UI/UX Mockups, Figma, Wireframe - nếu có).
+- Tài liệu kỹ thuật: Mô tả API (API Specs), sơ đồ cơ sở dữ liệu (DB Schema) hoặc tài liệu kiến trúc (nếu có).
+- Phạm vi kiểm thử được chỉ định ban đầu (Module, Màn hình, hoặc Tính năng cụ thể).
+- **Source code** (nếu workspace có source repos): validation rules, service/business logic, DB schema, API endpoints — đọc trực tiếp từ code để bổ sung context thực tế.
+
+# Quy trình thực hiện
+
+## 0. Đọc Source Code (nếu workspace có source repos)
+
+Thực hiện trước tất cả các bước phân tích.
+
+Nếu workspace mở dạng parent folder chứa cả tài liệu lẫn source code repos:
+
+1. Xác định repo liên quan từ ticket hoặc tên module/màn hình. Nếu không rõ → hỏi 1 câu.
+2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`):
+   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
+   - `gitnexus: context("ClassName")` → xem service/controller/validator đầy đủ
+3. **Nếu không có GitNexus**: đọc trực tiếp:
+   - Validation rules / Form request / DTO — tìm constraint thực tế (max length, regex, required)
+   - Service / Business Logic — phát hiện business rules ẩn không có trong spec
+   - Data models / DB schema — tìm DB constraint (unique, nullable, FK)
+   - API response format — xác định expected output chính xác
+4. Đưa kết quả vào mục **Validations**, **Business Rules**, và **Risk** trong báo cáo:
+   - Ghi rõ nguồn gốc: `[từ code]` để phân biệt với thông tin từ spec
+   - Đánh dấu điểm không nhất quán giữa spec và code thực tế vào **Q&A List**
+
+> ⚠️ Source code chỉ dùng để **bổ sung context** và mở rộng coverage. Expected result vẫn lấy từ ticket/spec của BA/PM.
+
+## 1. Xác định Phạm vi (Scope Definition)
+- **Feature/Module cụ thể:** Xác định chính xác module, màn hình hoặc tính năng đang thực hiện phân tích kiểm thử.
+- **Ranh giới Scope (Boundary):** Định rõ phần nào nằm trong phạm vi cần kiểm thử (In-scope) và phần nào nằm ngoài phạm vi (Out-of-scope) để tránh kiểm thử tràn lan, lãng phí thời gian.
+
+## 2. Phân tích Chức năng Chi tiết (Functional Analysis)
+- **Feature Overview:** Tóm tắt tổng quan về mục đích và vai trò của tính năng đối với người dùng cuối và hệ thống.
+- **Main Flow (Luồng chính):** Xác định luồng nghiệp vụ đi chuẩn xác (Happy Path) từ đầu tới khi hoàn thành thành công.
+- **Alternative/Exception Flows (Luồng phụ/Ngoại lệ):** Phác thảo các luồng rẽ nhánh, luồng xử lý lỗi, tình huống hủy thao tác, mất kết nối, v.v.
+- **User Roles & Permissions:** Làm rõ các tác nhân (Actor) tham gia vào hệ thống, phân quyền tương ứng của từng vai trò và mức độ ảnh hưởng của quyền hạn lên tính năng.
+- **Business Rules:** Phân tích các quy tắc nghiệp vụ ngầm định, thuật toán tính toán, quy luật kiểm tra logic.
+- **Validations:** Liệt kê đầy đủ các ràng buộc kiểm tra dữ liệu đầu vào (độ dài, định dạng, ký tự đặc biệt, trường bắt buộc) và cấu trúc dữ liệu trả ra (output).
+- **State/Status Transitions:** Theo dõi sơ đồ chuyển trạng thái của đối tượng (nếu có) và điều kiện tiên quyết (Preconditions) cũng như điều kiện đầu ra (Postconditions) để chuyển trạng thái.
+- **API & External Systems:** Nhận diện các cổng API nội bộ hoặc tích hợp từ hệ thống bên ngoài tham gia xử lý dữ liệu.
+
+## 3. Phân tích Phi chức năng (Non-Functional Analysis)
+- **Accessibility Requirements:** Kiểm tra các tiêu chuẩn hỗ trợ tiếp cận (WCAG, hỗ trợ Screen Reader cho người khiếm thị, điều hướng qua bàn phím).
+- **Compatibility:** Xác định các môi trường cần tương thích bao gồm danh sách Trình duyệt (Chrome, Safari, Firefox...), Hệ điều hành (Windows, macOS, iOS, Android...) và Thiết bị (Desktop, Mobile, Tablet...).
+
+## 4. Phân tích Môi trường & Dữ liệu Kiểm thử (Test Environment & Data)
+- **Test Data dependencies:** Xác định các phụ thuộc dữ liệu cần chuẩn bị trước khi test (ví dụ: loại tài khoản, trạng thái dữ liệu nền...).
+- **Third-party integrations:** Các bên thứ ba liên quan (cổng thanh toán, SMS OTP, CRM...) và cách thức mô phỏng (stub/mock) trên môi trường test.
+
+## 5. Phát hiện Rủi ro & Làm rõ thông tin (Clarifications & Risks)
+- **Risks / Điểm dễ lỗi:** Nhận diện các điểm phức tạp, vùng logic dễ xảy ra lỗi hệ thống (deadlock, logic loop, race conditions).
+- **Assumptions (Giả định):** Những giả định được đưa ra đối với các điểm nghiệp vụ chưa rõ ràng để định hướng kiểm thử.
+- **Q&A List:** Tổng hợp các câu hỏi làm rõ đối với các yêu cầu mơ hồ, thiếu logic hoặc mâu thuẫn để thảo luận trực tiếp với BA/Stakeholders.
+
+---
+
+# Mẫu Báo cáo Phân tích Yêu cầu (Template)
+*Kết quả phân tích yêu cầu phải được trình bày theo cấu trúc chuẩn dưới dạng **bullet point** ngắn gọn, tập trung hoàn toàn vào các nội dung phục vụ kiểm thử và tuyệt đối **không tạo test case ở bước này**.*
+
+```markdown
+# BÁO CÁO PHÂN TÍCH YÊU CẦU (REQUIREMENT ANALYSIS REPORT)
+
+## 📋 SCOPE DEFINITION
+1. **Module/Màn hình/Feature cụ thể đang test:** [Tên Module/Feature]
+2. **Ranh giới scope:**
+   - **Bao gồm (In-Scope):** [Các màn hình, luồng nghiệp vụ cụ thể cần test]
+   - **Không bao gồm (Out-of-Scope):** [Các phần không test trong đợt này]
+
+## 📋 FUNCTIONAL ANALYSIS
+3. **Feature Overview:** [Mô tả tổng quan ngắn gọn về tính năng]
+4. **Main Flow:** [Happy path - các bước thực hiện luồng chính]
+5. **Alternative Flows:** [Các luồng rẽ nhánh và luồng xử lý ngoại lệ]
+6. **User Roles / Permissions:** [Các tác nhân và phân quyền thao tác tương ứng]
+7. **Business Rules:** [Các quy tắc nghiệp vụ và ràng buộc logic bắt buộc]
+8. **Validations (input/output):** [Các ràng buộc dữ liệu đầu vào và đầu ra]
+9. **State / Status liên quan:** [Các trạng thái và điều kiện chuyển trạng thái]
+10. **API / External System liên quan (nếu có):** [Tác động DB, API endpoints, bên thứ ba]
+
+## 📋 NON-FUNCTIONAL ANALYSIS
+11. **Accessibility Requirements (WCAG, screen reader):** [Yêu cầu về khả năng tiếp cận]
+12. **Compatibility (Browser/Device/OS support):** [Môi trường cần test tương thích]
+
+## 📋 TEST ENVIRONMENT
+13. **Test Data dependencies:** [Yêu cầu về dữ liệu cần chuẩn bị trước]
+14. **Third-party integrations:** [Mô phỏng/Sandbox liên quan đến các bên thứ ba]
+
+## 📋 CLARIFICATION
+15. **Risk / điểm dễ lỗi:** [Các điểm nóng tiềm ẩn rủi ro phát sinh bug]
+16. **Q&A / Out of Scope bổ sung:** [Danh sách câu hỏi cần BA/Stakeholders làm rõ]
+```
+
+---
+
+# Output
+Bản phân tích yêu cầu hoàn chỉnh định dạng Markdown bao gồm:
+- **Feature Summary & Business Rules** đã phân tích sâu.
+- **Ranh giới Test Scope** (In-scope và Out-of-scope) rõ ràng.
+- **Dependencies & Risks** (Rủi ro, dữ liệu phụ thuộc, môi trường liên quan).
+- **Q&A List** để làm việc trực tiếp với BA/Stakeholders.
+
+⚠️ **LƯU Ý QUAN TRỌNG KHI THỰC HIỆN:**
+- Trình bày dạng bullet point ngắn gọn nhưng đầy đủ, súc tích.
+- Chỉ tập trung vào SCOPE được chỉ định, không mở rộng phân tích ra ngoài phạm vi.
+- Chỉ tập trung vào các nội dung phục vụ trực tiếp cho testing.
+- **Không tự ý generate testcase ở bước này.**

package/custom/skills/test-skills/categories/00-core/00.02.risk-analysis.md

@@ -0,0 +1,24 @@
+# Mục đích
+Nhận diện, phân loại rủi ro để tối ưu hóa nguồn lực và xác định mức độ ưu tiên kiểm thử.
+
+# Input
+- Kết quả từ 00.01 (Requirement Analysis).
+- Sơ đồ kiến trúc hệ thống (nếu có).
+
+# Quy trình thực hiện
+
+## 1. Phân tích các yếu tố rủi ro
+- **Tính phức tạp:** Thuật toán khó, logic lồng nhau.
+- **Dữ liệu:** Dữ liệu lớn, cấu trúc phức tạp, rủi ro mất mát/sai lệch dữ liệu.
+- **Tích hợp:** Kết nối API, Third-party, hệ thống Legacy.
+- **Nghiệp vụ:** Ảnh hưởng trực tiếp đến doanh thu, người dùng (Business Impact).
+- **Hệ thống:** Phân quyền, Batch processing, Migration.
+
+## 2. Đánh giá & Phân loại
+- Ưu tiên mức độ dựa trên: **Xác suất xảy ra** x **Mức độ ảnh hưởng**.
+
+# Output
+- Risk Matrix (High/Medium/Low).
+- Regression Scope (Phạm vi ảnh hưởng cần test lại).
+- Mitigation Plan (Kế hoạch giảm thiểu rủi ro).
+- Testing Priority (Thứ tự ưu tiên các kịch bản).

package/custom/skills/test-skills/categories/00-core/00.03.test-scenario-builder.md

@@ -0,0 +1,90 @@
+# Mục đích
+
+Thiết kế và xây dựng danh sách các kịch bản kiểm thử (Test Scenarios - High-level) bao phủ toàn bộ các khía cạnh nghiệp vụ, phi chức năng và rủi ro được chỉ ra trong Báo cáo phân tích yêu cầu (16 mục tiêu chuẩn) và Báo cáo phân tích rủi ro, đảm bảo không bỏ sót bất kỳ luồng xử lý nào.
+
+# Input
+
+- **Báo cáo Phân tích Yêu cầu (Requirement Analysis Report) đã xác định rõ phạm vi (In-Scope)**: Chỉ tập trung xây dựng Test Scenarios/Checklist cho các tính năng và luồng nghiệp vụ nằm trong phạm vi kiểm thử đã được xác định, tuyệt đối không thiết kế lan man ra ngoài phạm vi. Báo cáo này bao gồm thông tin chi tiết về 16 hạng mục dữ liệu sau:
+  1. *Module/Màn hình/Feature cụ thể đang test* (Để bám sát đúng phạm vi)
+  2. *Ranh giới scope* (Xác định rõ In-Scope và Out-of-Scope)
+  3. *Feature Overview*
+  4. *Main Flow*
+  5. *Alternative Flows*
+  6. *User Roles / Permissions*
+  7. *Business Rules*
+  8. *Validations (input/output)*
+  9. *State / Status liên quan*
+  10. *API / External System liên quan (nếu có)*
+  11. *Accessibility Requirements (WCAG, screen reader)*
+  12. *Compatibility (Browser/Device/OS support)*
+  13. *Test Data dependencies*
+  14. *Third-party integrations*
+  15. *Risk / điểm dễ lỗi*
+  16. *Out of Scope*
+- **Báo cáo Phân tích Rủi ro (00.02.risk-analysis.md)**.
+- **Đọc file quy ước chung (QA_Writing_Standards.md)**.
+- **Tài liệu bổ trợ (nếu có):** Thiết kế UI/UX (Figma/Mockups), API Specifications, DB Schema.
+
+# Quy trình thực hiện
+
+## 1. Thiết kế Kịch bản Đa chiều dựa trên các mục dữ liệu Phân tích Yêu cầu
+
+### A. Nhóm Chức năng (Functional Scenarios)
+
+- **Happy Path (Luồng chạy đúng chuẩn):** Thiết kế dựa trên **Mục 3 (Feature Overview)** và **Mục 4 (Main Flow)** của Báo cáo phân tích yêu cầu. Đảm bảo toàn bộ luồng chính hoạt động đúng khi người dùng nhập đúng dữ liệu và thực hiện đúng trình tự.
+- **Alternative/Exception Flows (Luồng phụ và Luồng lỗi ngoại lệ):** Thiết kế dựa trên **Mục 5 (Alternative Flows)** và **Mục 9 (State / Status liên quan)**. Kịch bản bao gồm việc chuyển đổi trạng thái sai lệch, hủy thao tác giữa chừng, mất kết nối, timeout hoặc nhập sai thông tin ở luồng phụ.
+- **Permission & Role-based (Kịch bản phân quyền):** Thiết kế dựa trên **Mục 6 (User Roles / Permissions)**. Đảm bảo mỗi kịch bản kiểm tra khả năng truy cập hợp lệ, chặn truy cập trái phép và kiểm tra lỗ hổng leo thang đặc quyền.
+- **Business Rules & Data Validations (Quy tắc nghiệp vụ & Kiểm tra dữ liệu):** Thiết kế dựa trên **Mục 7 (Business Rules)** và **Mục 8 (Validations)**. Áp dụng kỹ thuật phân tích biên, phân vùng tương đương để kiểm tra logic tính toán, ràng buộc dữ liệu đầu vào (độ dài, ký tự đặc biệt) và cấu trúc đầu ra.
+- **Integration & E2E (Kịch bản tích hợp):** Thiết kế dựa trên **Mục 10 (API / External System liên quan)**. Đảm bảo tính toàn vẹn dữ liệu truyền giữa các API và cập nhật thông tin chính xác trong Database.
+
+### B. Nhóm Phi chức năng (Non-Functional Scenarios)
+
+- **Accessibility (Tính tiếp cận):** Thiết kế dựa trên **Mục 11 (Accessibility Requirements)**. Kiểm tra tính năng tương thích với Screen Reader cho người khiếm thị, khả năng điều hướng bằng bàn phím (tab, enter) và độ tương phản màu sắc theo chuẩn WCAG.
+- **Compatibility (Tính tương thích):** Thiết kế dựa trên **Mục 12 (Compatibility)**. Đảm bảo giao diện hiển thị đúng chuẩn và chức năng hoạt động mượt mà trên nhiều trình duyệt (Chrome, Safari, Firefox), hệ điều hành (iOS, Android, Windows) và kích thước màn hình khác nhau (PC, Mobile, Tablet).
+
+### C. Nhóm Môi trường & Dữ liệu Kiểm thử (Test Environment & Data Scenarios)
+
+- **Data-Driven (Dữ liệu đặc biệt):** Thiết kế dựa trên **Mục 13 (Test Data dependencies)**. Kịch bản chạy kiểm thử lặp với các bộ dữ liệu nền/tài khoản đặc thù khác nhau (ví dụ: tài khoản bị khóa, số dư âm, khách hàng VIP).
+- **Third-Party Integration Mocking (Tích hợp bên thứ ba):** Thiết kế dựa trên **Mục 14 (Third-party integrations)**. Kịch bản kiểm tra khả năng xử lý khi API của bên thứ ba trả về lỗi, timeout hoặc trả về phản hồi không mong muốn.
+
+### D. Nhóm Kịch bản Rủi ro (Risk-Based Scenarios)
+
+- Thiết kế dựa trên **Mục 15 (Risk / điểm dễ lỗi)** từ Báo cáo phân tích yêu cầu kết hợp với danh sách phân loại rủi ro từ Báo cáo phân tích rủi ro. Tập trung vào kịch bản kiểm tra khả năng tự phục hồi lỗi hệ thống (Error Recovery) và kiểm thử phá hủy (Destructive Testing) ở các vùng nghiệp vụ phức tạp.
+
+## 2. Rà soát Độ bao phủ (Coverage Review)
+
+- Xây dựng bảng ma trận để đảm bảo 100% các mục quan trọng (từ mục 1 đến 16 của Báo cáo phân tích yêu cầu) đều được kiểm thử và ánh xạ sang ít nhất một kịch bản kiểm thử tương ứng.
+
+---
+
+# Mẫu Bảng Kịch bản Kiểm thử & Traceability Matrix (Template)
+
+```markdown
+# DANH SÁCH KỊCH BẢN KIỂM THỬ (TEST SCENARIOS LIST)
+
+| Scenario ID | Feature/Module | Check List | Scenario Type | Target Req ID (1-16) | Priority | Test Data / Dependency |
+|-------------|----------------|------------|---------------|----------------------|----------|------------------------|
+| TS_01_001   | [Tên Feature]  | [Mô tả kịch bản] | Happy Path    | Req_04 (Main Flow)   | High     | [Dữ liệu cần thiết]    |
+| TS_01_002   | [Tên Feature]  | [Mô tả kịch bản] | Negative      | Req_08 (Validations) | Medium   | [Dữ liệu cần thiết]    |
+| TS_01_003   | [Tên Feature]  | [Mô tả kịch bản] | Exception     | Req_09 (Status)      | High     | [Dữ liệu cần thiết]    |
+| TS_01_004   | [Tên Feature]  | [Mô tả kịch bản] | Permission    | Req_06 (Roles)       | High     | [Dữ liệu cần thiết]    |
+| TS_01_005   | [Tên Feature]  | [Mô tả kịch bản] | Accessibility | Req_11 (Access)      | Low      | [Screen Reader tool]   |
+| TS_01_006   | [Tên Feature]  | [Mô tả kịch bản] | Risk-based    | Req_15 (Risks)       | High     | [Dữ liệu giả lập]      |
+```
+
+---
+
+# Output
+
+Bảng danh sách kịch bản kiểm thử (Test Scenarios) hoàn chỉnh bao gồm:
+
+- **Test Scenarios List** chi tiết, đa chiều (Functional, Non-functional, Risk-based).
+- **Traceability Matrix** được tích hợp sẵn thông qua cột ánh xạ nguồn gốc yêu cầu (Target Req ID).
+- **Phân loại Priority** và xác định rõ ràng **Test Data/Dependency** cho từng kịch bản.
+
+⚠️ **LƯU Ý QUAN TRỌNG KHI THỰC HIỆN:**
+
+- Trình bày rõ ràng dưới dạng bảng (table).
+- Các mô tả kịch bản (Check List) cần ở mức High-level, tập trung vào mục tiêu kiểm thử thay vì chi tiết từng bước click chuột.
+- Đảm bảo tính bao phủ (Coverage) triệt để đối với cả 16 điểm phân tích từ Báo cáo phân tích yêu cầu.
+- Chỉ tạo các kịch bản nằm trong ranh giới In-scope (đã thống nhất tại Mục 2 của Báo cáo phân tích yêu cầu).

package/custom/skills/test-skills/categories/00-core/00.04.testcase-review.md

@@ -0,0 +1,68 @@
+# Mục đích
+
+Đảm bảo chất lượng, tính chính xác, tính khả thi và độ bao phủ toàn diện của bộ Test Case dựa trên Báo cáo phân tích yêu cầu (16 hạng mục tiêu chuẩn), Báo cáo phân tích rủi ro và phạm vi kiểm thử (Scope) đã được phê duyệt.
+
+# Input
+
+- Danh sách Test Case cần review.
+- **Báo cáo Phân tích Yêu cầu (Requirement Analysis Report) hoàn chỉnh bao gồm 16 hạng mục dữ liệu:**
+  1. *Module/Màn hình/Feature cụ thể đang test*
+  2. *Ranh giới scope* (Bao gồm gì, không bao gồm gì)
+  3. *Feature Overview*
+  4. *Main Flow*
+  5. *Alternative Flows*
+  6. *User Roles / Permissions*
+  7. *Business Rules*
+  8. *Validations (input/output)*
+  9. *State / Status liên quan*
+  10. *API / External System liên quan (nếu có)*
+  11. *Accessibility Requirements (WCAG, screen reader)*
+  12. *Compatibility (Browser/Device/OS support)*
+  13. *Test Data dependencies*
+  14. *Third-party integrations*
+  15. *Risk / điểm dễ lỗi*
+  16. *Out of Scope*
+- **Báo cáo Phân tích Rủi ro (00.02.risk-analysis.md)**
+- **Đọc file quy ước chung (QA_Writing_Standards.md)**.
+
+# Checklist kiểm tra
+
+## 1. Kiểm tra Phạm vi (Scope Definition Review)
+
+- ✅ **In-scope Coverage (Bám sát phạm vi):** Tất cả các chức năng thuộc phần In-scope (Mục 1 & 2) đều phải được thiết kế test case tương ứng.
+- ✅ **No Out-of-scope (Không dư thừa):** Tuyệt đối không tạo test case cho các phần nằm trong danh sách Out-of-scope (Mục 16) hoặc các chức năng nằm ngoài biên kiểm thử.
+
+## 2. Kiểm tra Luồng chức năng (Functional Coverage Review)
+
+- ✅ **Main Flow (Luồng chính):** Các bước kiểm thử cho luồng chính (Mục 4) có rõ ràng, logic và kết quả mong muốn có chính xác không?
+- ✅ **Alternative/Exception & Status (Luồng phụ/Ngoại lệ & Trạng thái):** Đã bao phủ hết các kịch bản lỗi, hủy thao tác (Mục 5) và các trường hợp chuyển đổi trạng thái của đối tượng (Mục 9)?
+- ✅ **User Roles & Permissions (Tác nhân & Phân quyền):** Đã kiểm thử đủ cho từng vai trò người dùng (Mục 6), bao gồm cả phân quyền hợp lệ, chặn phân quyền không hợp lệ và kiểm tra leo thang đặc quyền (nếu có)?
+- ✅ **Business Rules & Validations (Quy tắc & Ràng buộc):** Đã kiểm thử các quy tắc nghiệp vụ đặc thù (Mục 7) và các ràng buộc dữ liệu đầu vào/ra (Mục 8 - ranh giới biên, kiểu dữ liệu, định dạng)?
+- ✅ **Integration & API (Tích hợp & API):** Đã kiểm thử đầy đủ các điểm giao tiếp API và tính toàn vẹn của dữ liệu lưu vào cơ sở dữ liệu (Mục 10)?
+
+## 3. Kiểm tra Phi chức năng (Non-Functional Review)
+
+- ✅ **Accessibility (Khả năng tiếp cận):** Đã có test case kiểm thử hỗ trợ Screen Reader, độ tương phản màu sắc và phím tắt điều hướng theo chuẩn WCAG (Mục 11)?
+- ✅ **Compatibility (Tính tương thích):** Đã có kịch bản chạy thử nghiệm trên các trình duyệt, hệ điều hành và thiết bị đích được yêu cầu (Mục 12)?
+
+## 4. Kiểm tra Môi trường & Dữ liệu Kiểm thử (Environment & Data Review)
+
+- ✅ **Test Data (Dữ liệu nền):** Các điều kiện tiên quyết (Prerequisites/Preconditions) và dữ liệu test cần chuẩn bị (Mục 13) có được chỉ ra cụ thể và rõ ràng trong test case không?
+- ✅ **Third-Party (Bên thứ ba):** Đã có giải pháp mô phỏng (stub/mock) hoặc test case kiểm thử các kịch bản tích hợp bên thứ ba (Mục 14)?
+
+## 5. Kiểm tra Rủi ro & Điểm dễ lỗi (Risk-Based Review)
+
+- ✅ **High-risk Areas (Vùng rủi ro cao):** Các vùng nghiệp vụ phức tạp, dễ lỗi đã được phân tích (Mục 15) và xếp hạng ưu tiên cao trong Báo cáo phân tích rủi ro có được bao phủ bởi các kịch bản kiểm thử sâu (stress test cục bộ, error recovery...) không?
+
+## 6. Chất lượng Chi tiết của Test Case (Test Case Quality Review)
+
+- ✅ **Test Steps (Các bước thực hiện):** Rõ ràng, súc tích, không mơ hồ và có thể tái hiện được?
+- ✅ **Expected Result (Kết quả mong đợi):** Cụ thể, đo lường được (không ghi chung chung như "hệ thống hoạt động đúng").
+- ✅ **Redundancy (Tính tối ưu):** Không trùng lặp nội dung giữa các test case.
+
+---
+
+# Output
+
+- Báo cáo kết quả Review Test Case (Review Comments & Feedback).
+- Trạng thái phê duyệt (Approved / Need Update / Rejected).