@trungtamcongnghedigital/vsaf 1.0.0

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/05-dependent-filter/filter-rule-block-rule.md

@@ -0,0 +1,69 @@
+---
+cases_count: 15
+---
+# Filter Rule Block Rule
+
+## Mục đích
+
+Sinh testcase cho khối `Quy tắc Lọc giá trị (Filter Rules)` trong màn hình cấu hình phụ thuộc.
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi chức năng cho phép cấu hình quan hệ lọc giá trị theo thuộc tính cha/con.
+
+## Thành phần cần kiểm tra
+
+- Icon bộ lọc.
+- Nội dung empty state.
+- Button Thêm filter.
+- Cụm Thuộc tính cha.
+- Cụm Giá trị cha.
+- Cụm Giá trị con cho phép.
+- Icon `+` thêm cụm.
+- Icon `-` xóa cụm.
+- Button Lưu.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng. Không được gộp chung.
+
+### Empty state
+
+1. Khi chưa có filter nào.
+2. Hiển thị icon bộ lọc.
+3. Hiển thị content dòng 1: chưa có filter nào.
+4. Hiển thị content dòng 2: hướng dẫn bấm nút để thêm rule.
+5. Button Thêm filter enable.
+
+### Thêm filter
+
+1. Nhấn button Thêm filter.
+2. Hiển thị cụm Thuộc tính cha - Giá trị cha - Giá trị con cho phép.
+3. Kiểm tra từng combobox trong cụm.
+4. Kiểm tra icon `+`/`-` của cụm.
+
+### Xóa filter
+
+1. Xóa khi chỉ có 1 cụm chưa nhập dữ liệu.
+2. Xóa khi chỉ có 1 cụm đã nhập dữ liệu.
+3. Xóa cụm đầu/giữa/cuối khi có nhiều cụm.
+4. Sau khi xóa hết, quay về empty state.
+5. Xóa một thuộc tính đang làm cha của một thuộc tính phụ thuộc khác (Bắt lỗi cảnh báo không cho xóa).
+
+### Ràng buộc Cấu hình Nâng cao (Advanced Configuration Constraints)
+
+1. **Circular Dependency (Ràng buộc vòng)**: Báo lỗi khi người dùng cố tình cấu hình Cấp 1 phụ thuộc Cấp 2, và Cấp 2 lại được cấu hình phụ thuộc ngược lại Cấp 1 (VD: A -> B -> A). Cảnh báo rõ ràng để ngăn chặn vòng lặp vô tận.
+
+## Expected chuẩn
+
+Expected phải mô tả rõ trạng thái sau thao tác, ví dụ:
+
+```text
+Xóa cụm Thuộc tính cha - Giá trị cha - Giá trị con cho phép và hiển thị lại Khối Quy tắc Lọc giá trị (Filter Rules) gồm icon Bộ lọc, content Chưa có filter nào, content hướng dẫn và button Thêm filter enable.
+```
+
+## Điều kiện reject
+
+- Không được chỉ ghi `Xóa thành công`.
+- Không được bỏ qua empty state sau khi xóa cụm cuối.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/05-dependent-filter/filter-save-validation-rule.md

@@ -0,0 +1,49 @@
+---
+cases_count: 11
+---
+# Filter Save Validation Rule
+
+## Mục đích
+
+Sinh testcase validate khi lưu cấu hình filter rule.
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi khối filter có button Lưu và các field bắt buộc trong cụm filter.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng. Không được gộp chung.
+
+1. Lưu khi chưa chọn cả 3 trường: Thuộc tính cha, Giá trị cha, Giá trị con cho phép.
+2. Lưu khi chỉ chọn Thuộc tính cha.
+3. Lưu khi chỉ chọn Giá trị cha.
+4. Lưu khi chỉ chọn Giá trị con cho phép.
+5. Lưu khi chọn Thuộc tính cha + Giá trị cha nhưng chưa chọn Giá trị con cho phép.
+6. Lưu khi chọn Thuộc tính cha + Giá trị con cho phép nhưng chưa chọn Giá trị cha.
+7. Lưu khi chọn Giá trị cha + Giá trị con cho phép nhưng chưa chọn Thuộc tính cha.
+8. Lưu khi có nhiều cụm, trong đó một cụm thiếu dữ liệu.
+9. Lưu khi tất cả cụm hợp lệ.
+10. Lưu khi có quan hệ trùng lặp.
+11. Lưu khi child value trùng giữa nhiều rule nếu business không cho phép.
+
+## Expected chuẩn
+
+- Case thiếu dữ liệu phải hiển thị lỗi cụ thể tại field/cụm thiếu.
+- Case hợp lệ phải lưu thành công và hiển thị thông báo thành công.
+- Nếu message lỗi chưa có trong tài liệu thì không tự đoán, phải tạo Q&A.
+
+## Q&A bắt buộc nếu gặp `???`
+
+Nếu KBKT cũ hoặc tài liệu ghi `Báo lỗi: ???`, agent phải sinh Q&A thay vì tự điền message:
+
+```markdown
+| ID | Vùng thiếu thông tin | Câu hỏi cần làm rõ | Ảnh hưởng |
+| --- | --- | --- | --- |
+| QA-FILTER-001 | Filter Rules / Button Lưu | Khi nhấn Lưu mà chưa chọn Thuộc tính cha/Giá trị cha/Giá trị con cho phép thì message lỗi chính xác là gì? | Không thể viết expected result chính xác cho testcase validate |
+```
+
+## Điều kiện reject
+
+Reject testcase validate nếu expected vẫn còn `???`.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/06-validation/duplicate-data-rule.md

@@ -0,0 +1,44 @@
+---
+cases_count: 6
+---
+# Duplicate Data Rule
+
+## Mục đích
+
+Sinh testcase kiểm tra dữ liệu trùng lặp.
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi field có vai trò định danh hoặc mã duy nhất, ví dụ:
+
+- Mã nhóm thuộc tính.
+- Mã template.
+- Tên template nếu business yêu cầu unique.
+- Cặp quan hệ cha-con nếu không cho trùng.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng. Không được gộp chung.
+
+1. Nhập giá trị chưa tồn tại.
+2. Nhập giá trị đã tồn tại trong cùng màn hình.
+3. Nhập giá trị đã tồn tại trong DB/hệ thống.
+4. Nhập trùng khác hoa/thường nếu business không phân biệt case.
+5. Nhập trùng sau trim space.
+6. Nhập trùng trong nhiều dòng/cụm động.
+
+## Expected chuẩn
+
+- Với dữ liệu không trùng: cho phép lưu.
+- Với dữ liệu trùng: hiển thị lỗi rõ vị trí và message.
+- Không được lưu bản ghi trùng.
+
+## Điều kiện cần Q&A
+
+Tạo Q&A nếu chưa rõ:
+
+- Có bắt unique không.
+- Unique theo field đơn hay tổ hợp field.
+- Có phân biệt hoa/thường không.
+- Có trim trước khi check duplicate không.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/06-validation/error-response-behavior-rule.md

@@ -0,0 +1,42 @@
+---
+cases_count: dynamic
+---
+# Error Response Behavior Rule
+
+## Mục đích
+
+Sinh testcase cho danh mục mã lỗi (error-code catalog) mà spec đặc tả hành vi hệ thống per-code, phủ ĐỦ và ĐÚNG mọi phản hồi + side-effect — không rút gọn về "hiện lỗi".
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi tài liệu (`_detailed_design`/API spec — phần Logic/Dữ liệu) có bảng/danh mục mã lỗi kèm hành vi phản hồi per-code (message, side-effect UI, HTTP status). Bao trùm mọi tầng: validation nghiệp vụ, conflict, phân quyền, tích hợp downstream.
+
+> **Ranh giới (MECE):** provoke lỗi hạ tầng (timeout/circuit-breaker/cache/session) thuộc [backend-resilience-rule](../10-be/backend-resilience-rule.md); cơ chế lỗi inline theo field thuộc [inline-error-rule](./inline-error-rule.md). Rule này chỉ sở hữu việc phủ ĐỦ hành vi phản hồi per-code (đặc biệt side-effect UI).
+
+## Nguyên tắc phủ (mỗi mã lỗi `<code>` trong catalog)
+
+1. Tái lập đúng điều kiện kích hoạt `<code>` theo spec.
+2. Assert HTTP status / `error_code` trả về (nếu spec nêu).
+3. Assert nội dung message verbatim (cấm paraphrase).
+4. Assert TỪNG side-effect đặc tả là 1 dòng độc lập: đổi trạng thái control (uncheck/disable/lock), badge/marker, focus, điều hướng, KHÔNG-tự-retry, giữ/dọn input…
+5. Assert exclusivity: chỉ phản hồi của `<code>` xuất hiện (xem [kbkt-format-rule §Chất lượng Expected](../00-core/kbkt-format-rule.md)).
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** mỗi cặp (mã lỗi × side-effect) là 1 testcase độc lập. Cấm gộp nhiều side-effect vào 1 Expected "hiện lỗi phù hợp".
+
+## Expected chuẩn
+
+Phân tầng UI → DB → API → Log; liệt kê từng side-effect rời:
+
+```text
+**UI:** hiển thị đúng 1 <thông báo verbatim>; <control liên quan> chuyển <trạng thái đặc tả>; không xuất hiện thông báo khác.
+**API:** HTTP <status> (`<error_code>`).
+**DB:** <trạng thái dữ liệu — không tạo bản ghi rác / rollback>.
+```
+
+## Điều kiện reject
+
+- Gộp nhiều mã lỗi hoặc nhiều side-effect vào 1 case.
+- Bỏ side-effect đặc tả (badge, uncheck, no-retry, focus, navigation).
+- Expected chung chung "báo lỗi phù hợp" / thiếu exclusivity.
+- Tự suy hành vi per-code không có trong catalog → Q&A.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/06-validation/field-level-validation-rule.md

@@ -0,0 +1,26 @@
+# Field-Level Validation Rule
+
+## Mục đích
+Đảm bảo sinh các ca kiểm thử validation (kiểm duyệt dữ liệu) chi tiết, đầy đủ và chuyên biệt cho TỪNG loại trường dữ liệu (Field Type) trên UI. Tuyệt đối không dùng chung một kịch bản validation cho tất cả các trường.
+
+## Bảng tra cứu các trạm kiểm duyệt bắt buộc (Validation Checkpoints)
+
+Dựa vào danh sách input fields từ UI Spec (phần Giao diện trong `_detailed_design`), Agent phải áp dụng các trạm kiểm tra tương ứng sau đây:
+
+| Loại Field (Field Type) | 🔍 Các Trạm Kiểm Duyệt Cần Test (Validation Checkpoints) |
+| :--- | :--- |
+| **Text** <br> *(Name, Address...)* | Required/Optional · Min/Max length · Chỉ khoảng trắng (whitespace-only) · Ký tự đặc biệt (`<>&"'`) · XSS injection (`<script>alert(1)</script>`) · SQL injection (`' OR 1=1--`) · Unicode/Emoji · Khoảng trắng đầu, cuối (trimspace) · Chữ hoa · Chữ thường · Số. |
+| **Email** | Format hợp lệ (`user@domain.com`) · Thiếu `@` · Thiếu domain · Domain không hợp lệ · Nhiều `@` · Ký tự đặc biệt trước `@` · Max length · Case sensitivity · Email đã tồn tại (nếu unique) · Khoảng trắng đầu, cuối (trimspace) · Chữ hoa · Chữ thường · Số. |
+| **Phone** | Chỉ chấp nhận số · Prefix hợp lệ (ví dụ: `+84`, `0`) · Min/Max length · Chữ cái xen lẫn · Dấu `-`, `.`, khoảng trắng · Mã vùng không hợp lệ. |
+| **Date / DateTime** | Format đúng (`dd/MM/yyyy`, ISO...) · Ngày không tồn tại (`31/02`, `30/02`) · Năm nhuận (`29/02/2024`) · Ngày quá khứ / tương lai (tùy business rule) · Giá trị min/max date · Timezone · Kiểm tra mặc định (nếu có). |
+| **Number / Currency** | Min/Max value · Số âm · Số 0 · Số thập phân · Ký tự không phải số · Overflow (số cực lớn) · Leading zeros · Định dạng currency (dấu phẩy, dấu chấm). |
+| **Dropdown / Select** | Giá trị mặc định · Tất cả options hợp lệ · Option bị disabled · Thay đổi selection · Required validation (chưa chọn). |
+| **Checkbox / Radio** | Trạng thái mặc định · Check/Uncheck · Required validation · Nhóm radio (chỉ chọn 1). |
+| **File Upload** | File type hợp lệ/không hợp lệ · Max size · File rỗng (`0 KB`) · Tên file có ký tự đặc biệt · Multiple files · Kéo thả vs nút chọn. |
+| **Password** | Min/Max length · Yêu cầu ký tự đặc biệt · Yêu cầu chữ hoa/thường · Yêu cầu số · Copy-paste bị chặn? · Hiện/ẩn password · Confirm password khớp/không khớp. |
+| **Textarea** | Max length · Line breaks (xuống dòng) · HTML tags · Resize (nếu UI cho phép) · Character counter (nếu có). |
+
+## Yêu cầu khi sinh testcase
+- Mỗi trường dữ liệu phải có nhóm testcase validation riêng rẽ.
+- Tên testcase phải thể hiện rõ trường nào đang được test và điều kiện kiểm tra là gì (Ví dụ: `Validate trường Số điện thoại khi nhập chữ cái`).
+- Dữ liệu test (`Data Test`) phải phản ánh chính xác điều kiện (Ví dụ nhập `abc` cho số điện thoại).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/06-validation/inline-error-rule.md

@@ -0,0 +1,62 @@
+---
+cases_count: 8
+---
+# Inline Error Rule
+
+## Mục đích
+
+Chuẩn hóa cách sinh testcase validate lỗi inline.
+
+## Điều kiện kích hoạt
+
+Khi field có validate: required, format, maxlength, business rule, duplicate, invalid relation.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng. Không được gộp chung.
+
+1. Trigger lỗi bằng focus out (click vào field → click ra ngoài) nếu spec yêu cầu.
+2. Trigger lỗi bằng nhấn Lưu/Áp dụng **chỉ khi nút submit vẫn click được lúc form invalid** (xem "Chọn cách trigger đúng").
+3. Kiểm tra vị trí (neo đúng field) + loại message lỗi (inline validation, không phải toast/lỗi hệ thống generic).
+4. Kiểm tra nội dung message lỗi.
+5. Kiểm tra màu sắc/icon lỗi nếu UI design có quy định.
+6. Kiểm tra lỗi biến mất khi nhập lại dữ liệu hợp lệ.
+7. Kiểm tra button Lưu có enable/disable theo trạng thái lỗi.
+8. Nếu nút submit disabled khi form invalid: trigger lỗi bằng focus-in → blur-out, KHÔNG dùng bước "bấm Lưu/Submit" (nút disabled không click được).
+
+## Chọn cách trigger đúng (BẮT BUỘC — tránh mâu thuẫn với case #7)
+
+Bước trigger PHẢI khớp cơ chế lỗi thật nổi lên:
+
+- **Lỗi required/empty** (field bỏ trống): chỉ nổi khi field ở trạng thái `touched` → trigger = **click vào field → click ra ngoài (blur)**.
+- **Nút submit disabled khi invalid** (case #7 khẳng định): nút disabled → KHÔNG click được → KHÔNG được viết bước "Bấm <Submit> để hiện lỗi". Dùng focus-in → blur-out.
+- **Nút submit vẫn enabled khi invalid**: mới được dùng "nhấn Lưu/Áp dụng" làm trigger.
+
+> [!CAUTION]
+> **Cấm mâu thuẫn:** với CÙNG một field, KHÔNG sinh đồng thời case "bấm Submit → hiện lỗi" (#2) và case "Submit disabled khi field lỗi" (#7). Nếu #7 đúng thì #2 phải chuyển sang focus-in/blur-out (#8). Không rõ trạng thái nút → tạo Q&A.
+
+## Expected chuẩn
+
+```text
+Hiển thị báo lỗi inline ngay dưới trường dữ liệu với nội dung: <message>.
+```
+
+```text
+Khi nhập lại dữ liệu hợp lệ, message lỗi không còn hiển thị và field trở về trạng thái bình thường.
+```
+
+## Exclusivity + message-correctness áp cho MỌI trigger (không chỉ 1)
+
+> [!CAUTION]
+> Điểm mù kinh điển: agent chỉ gắn check "đúng 1 lỗi / đúng field / đúng loại" vào **một** trigger đại diện (thường là regex-fail, vd `"đx"`) rồi coi như xong. Nhưng đa lỗi/sai field/sai loại thường **chỉ nổ trên trigger khác** (đặc biệt **over-length lọt tới BE** khi `N_attr > N_be` — xem [maxlength-rule](../02-input/maxlength-rule.md)).
+>
+> BẮT BUỘC: liệt kê **tất cả đường sinh lỗi** của field (required/empty · sai format-regex · **over-length tới server** · min/max nghiệp vụ · duplicate · invalid relation) và áp check #3 (đúng loại + neo đúng field) + reject "sai field / sai loại / >1 lỗi" cho **TỪNG đường**, không dùng lại 1 trigger cho tất cả. Trigger nào chưa rõ hành vi → Q&A, không bỏ qua.
+
+## Điều kiện reject
+
+- Không được để message là `???`.
+- Không được viết `Báo lỗi phù hợp`.
+- Không được thiếu vị trí hiển thị lỗi.
+- Lỗi validation hiển thị dưới dạng lỗi hệ thống/generic (sai loại) hoặc gắn sai field.
+- Xuất hiện >1 thông báo lỗi khi spec chỉ định 1 (toast generic thừa) — xem [kbkt-format-rule §Chất lượng Expected](../00-core/kbkt-format-rule.md).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/07-save-cancel/action-button-rule.md

@@ -0,0 +1,67 @@
+---
+cases_count: 9
+---
+
+# Action / Navigation Button Rule
+
+## Mục đích
+
+Sinh testcase cho **MỌI button/nút bấm hiển thị trong chức năng** kích hoạt điều hướng hoặc một hành vi nghiệp vụ — mà **không** thuộc nhóm Lưu/Submit (dùng `save-button-rule.md`) hay Hủy/Đóng/Back (dùng `cancel-button-rule.md`).
+
+Ví dụ: "Xem chi tiết", "Tiếp tục", "Bước tiếp theo", "Duyệt", "Từ chối", "Xuất file/Tải xuống", "Thêm mới" (mở màn/dialog), CTA điều hướng, nút chuyển tab, nút áp dụng bộ lọc, icon-action trên hàng lưới (kết hợp `09-data-grid/grid-base-rule.md`).
+
+## Điều kiện kích hoạt
+
+Áp dụng **cho từng button riêng lẻ** xuất hiện trong màn hình/dialog/khu vực đang test mà ở trạng thái **enable** có thể click được. Không có ngoại lệ: mỗi button enable = một cụm testcase độc lập theo danh sách dưới đây.
+
+> [!IMPORTANT]
+> **Quy tắc vét cạn button:** Trong Step 02, sau khi ánh xạ nhãn giao diện, phải **liệt kê đầy đủ mọi button** của bề mặt đang test và gắn mỗi button với rule tương ứng (Lưu → `save-button-rule`; Hủy → `cancel-button-rule`; còn lại → rule này). Cấm bỏ sót bất kỳ button enable nào.
+>
+> **Bao gồm button trong STATE điều kiện (BẮT BUỘC):** button chỉ hiện trong state lỗi/degraded/timeout/empty/loading/dialog — điển hình **[Thử lại]/Retry**, CTA empty-state (**[Tạo mới]**, **[Tinh chỉnh bộ lọc]**), nút trong confirm-dialog — thường **không có trong bảng UI-Controls** (DD mô tả chúng như hành vi của banner/state cha). Vẫn phải enroll vào danh sách button và chạy đủ cụm dưới đây. KHÔNG được coi là "hiển thị của state" rồi chỉ assert render qua `screen-default-display-rule`.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng, và **lặp cho TỪNG button** enable. Không được gộp chung nhiều button vào một dòng, không viết "tương tự".
+
+1. Kiểm tra hiển thị button (nhãn/icon/vị trí đúng thiết kế).
+2. Kiểm tra điều kiện enable/disable theo nghiệp vụ (khi nào enable, khi nào disable, mặc định là gì).
+3. **Click khi button ENABLE → điều hướng/xử lý đúng nghiệp vụ:** xác minh đích đến (màn hình/dialog mở đúng, API đúng được gọi, trạng thái/dữ liệu thay đổi đúng) theo spec.
+4. Click khi ở trạng thái DISABLE (nếu button vẫn hiển thị dạng mờ) → không phát sinh hành động nào.
+5. **Click nhiều lần liên tiếp (double-click / spam click):** chỉ xử lý MỘT lần — không tạo request trùng, không mở chồng dialog, không điều hướng lặp/nhân bản bản ghi (idempotency + chống double-submit).
+6. Click khi thiếu điều kiện tiên quyết nghiệp vụ (nếu có) → chặn và thông báo phù hợp, không điều hướng.
+7. Kiểm tra trạng thái loading/disable trong lúc xử lý bất đồng bộ (nếu button gọi hành động async).
+8. Kiểm tra hành vi khi hành động/API lỗi (nếu button gọi Backend) → hiển thị thông báo lỗi, giữ nguyên màn/trạng thái, không điều hướng nhầm.
+9. Kiểm tra dữ liệu E2E / trạng thái sau khi hành động thành công (nếu button tạo tác động nghiệp vụ — tuân thủ `e2e-traceability-rule.md`).
+
+## Cụm bổ sung cho nút Retry ("Thử lại") — BẮT BUỘC khi có
+
+Nút retry trên banner lỗi/degraded/timeout hoặc toast phải có tối thiểu 3 dòng độc lập (ngoài các mục 1-9 ở trên):
+
+10. **Click retry → hành động lặp lại THÀNH CÔNG:** banner/thông báo lỗi biến mất, dữ liệu/panel render đúng; đối soát API được gọi lại.
+11. **Click retry mà VẪN lỗi lần nữa:** banner/thông báo lỗi **giữ nguyên** (không biến mất), trạng thái an toàn được duy trì (panel giữ trạng thái lỗi/rỗng, control chính vẫn dùng được), nút retry vẫn bấm được lần tiếp theo.
+12. **Giới hạn số lần retry (nếu spec nêu):** vd "retry thủ công tối đa N lần" → sau N lần lỗi liên tiếp, lần thứ N+1 bị chặn không cho retry; đối soát đúng N request phát sinh, không có request thứ N+1. Nếu spec KHÔNG nêu giới hạn → Q&A, không tự đoán.
+
+## Expected chuẩn
+
+- Button hiển thị và enable/disable đúng điều kiện nghiệp vụ trong spec.
+- Khi click enable: điều hướng đến đúng đích hoặc thực thi đúng hành vi nghiệp vụ mô tả trong spec (đích đến phải ghi cụ thể, cấm ghi "điều hướng đúng"/"theo thiết kế").
+- Click nhiều lần: hệ thống chỉ xử lý một lần, không nhân bản request/bản ghi, không mở chồng nhiều màn/dialog.
+- Khi lỗi: giữ nguyên trạng thái an toàn và thông báo rõ ràng.
+
+## Điều kiện cần Q&A
+
+Tạo Q&A (không tự đoán) nếu spec không nói rõ:
+
+- Đích điều hướng cụ thể sau khi click là màn/dialog nào?
+- Hành vi nghiệp vụ khi click là gì (gọi API nào, đổi trạng thái ra sao)?
+- Hành vi khi click nhiều lần liên tiếp (có khóa nút/idempotency không)?
+- Điều kiện enable/disable của button.
+
+## Điều kiện reject
+
+- Thiếu testcase click → điều hướng/xử lý cho **bất kỳ button enable nào** hiển thị trong chức năng (kể cả button lồng trong state lỗi/degraded/empty/dialog).
+- Bỏ sót button chỉ xuất hiện trong state điều kiện (retry, CTA empty-state, nút trong dialog) khỏi danh sách vét cạn.
+- Có nút retry nhưng thiếu dòng "retry vẫn lỗi lần nữa" (mục 11) hoặc thiếu dòng giới hạn retry khi spec có nêu (mục 12).
+- Thiếu testcase click nhiều lần liên tiếp cho button gây tác động nghiệp vụ.
+- Cột Kết quả mong muốn ghi mơ hồ ("điều hướng đúng", "xử lý theo thiết kế") thay vì đích đến/hành vi cụ thể.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/07-save-cancel/cancel-button-rule.md

@@ -0,0 +1,42 @@
+---
+cases_count: 9
+---
+
+# Cancel Button Rule
+
+## Mục đích
+
+Sinh testcase cho button Hủy/Đóng/Back.
+
+## Điều kiện kích hoạt
+
+Khi màn hình/form có button Hủy, Đóng, Back, icon X hoặc Cancel.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng. Không được gộp chung.
+
+1. Kiểm tra hiển thị button.
+2. Kiểm tra trạng thái enable/disable.
+3. Click khi form chưa thay đổi dữ liệu.
+4. Click khi form đã thay đổi dữ liệu.
+5. Click khi đang có lỗi validate.
+6. Click khi đang loading submit.
+7. Kiểm tra điều hướng sau khi hủy.
+8. Kiểm tra dữ liệu chưa lưu không bị ghi nhận.
+9. Kiểm tra popup confirm nếu spec có.
+
+## Expected chuẩn
+
+- Nếu chưa sửa dữ liệu: đóng form/quay về màn trước theo spec.
+- Nếu đã sửa dữ liệu: hiển thị confirm hoặc hủy không lưu theo spec.
+- Dữ liệu đang chỉnh sửa không được lưu nếu user chọn hủy.
+
+## Điều kiện cần Q&A
+
+Tạo Q&A nếu không rõ khi hủy form đã sửa dữ liệu:
+
+- Có confirm không?
+- Confirm message là gì?
+- Điều hướng về đâu?

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/07-save-cancel/save-button-rule.md

@@ -0,0 +1,48 @@
+---
+cases_count: 14
+---
+
+# Save Button Rule
+
+## Mục đích
+
+Sinh testcase cho button Lưu của form.
+
+## Điều kiện kích hoạt
+
+Khi màn hình/form có button Lưu, Tạo mới, Cập nhật, Hoàn tất hoặc Submit.
+
+## Danh sách Testcase Bắt Buộc (Mỗi mục là 1 hàng riêng biệt trong bảng)
+
+> [!CAUTION]
+> **KHÔNG ĐƯỢC GỘP:** Mỗi số thứ tự dưới đây **BẮT BUỘC PHẢI LÀ 1 DÒNG (1 TESTCASE) ĐỘC LẬP** trong bảng testcase cuối cùng. Không được gộp chung.
+
+1. Kiểm tra hiển thị button.
+2. Kiểm tra trạng thái mặc định.
+3. Khi form chưa thay đổi dữ liệu.
+4. Khi form thiếu dữ liệu bắt buộc.
+5. Khi form có dữ liệu không hợp lệ.
+6. Khi form có dữ liệu hợp lệ tối thiểu.
+7. Khi form có dữ liệu hợp lệ đầy đủ.
+8. Click liên tục nhiều lần.
+9. Kiểm tra loading/disable trong lúc submit nếu có.
+10. Kiểm tra thông báo thành công.
+11. Kiểm tra thông báo thất bại từ API.
+12. **Retry thủ công sau lỗi (khi spec cho phép re-submit):** submit lỗi 5xx → thông báo lỗi + form giữ nguyên → bấm lại submit lần nữa thành công (đối soát chỉ tạo 1 bản ghi ở lần thành công). Nếu spec nêu **giới hạn số lần retry** (vd "retry thủ công tối đa N lần") → thêm 1 dòng: sau N lần lỗi liên tiếp, lần N+1 bị chặn, đối soát đúng N request phát sinh. Spec không nêu → Q&A, không tự đoán.
+13. Kiểm tra dữ liệu E2E sau khi lưu (BẮT BUỘC tuân thủ `e2e-traceability-rule.md`).
+14. **Kiểm lưu đủ trường trong DB sau khi tạo mới:** từng trường của bản ghi vừa tạo đều có dữ liệu (khác NULL/rỗng), gồm cả bảng phụ thuộc. Trường mã hóa/hash chỉ kiểm có giá trị, không so nguyên văn (`e2e-traceability-rule.md` §1.1).
+
+## Expected chuẩn
+
+- Button hiển thị đúng thiết kế.
+- Button enable/disable đúng trạng thái form.
+- Khi thiếu dữ liệu: không lưu và hiển thị lỗi validate.
+- Khi hợp lệ: lưu thành công và hiển thị message thành công.
+- Sau khi tạo mới: mọi trường của bản ghi trong DB đều đã được lưu, không trường nào rỗng ngoài đặc tả.
+- Không tạo duplicate request khi click nhiều lần.
+
+## Điều kiện reject
+
+- Không được chỉ có testcase click Lưu thành công.
+- Phải có testcase lỗi validate trước testcase thành công.
+- Phải kiểm tra trạng thái button mặc định.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/08-review/compliance-audit-rule.md

@@ -0,0 +1,30 @@
+# Compliance Audit Rule (Rà Soát Tính Tuân Thủ)
+
+## Mục đích
+Quy định chi tiết các tiêu chí kiểm tra tính tuân thủ cấu trúc và nội dung kỹ thuật cơ bản của file kịch bản kiểm thử.
+
+## 3 Tiêu Chí Rà Soát Tính Tuân Thủ
+
+### ⚙️ Tiêu chí 1: Tuân thủ cấu trúc kịch bản chức năng người dùng cuối (End-User Scenarios)
+- **Đối tượng:** Các kịch bản kiểm thử thao tác trực tiếp trên giao diện người dùng (ví dụ: login form, input data form, search list screen...).
+- **Yêu cầu:** Kịch bản phải được tổ chức và bao phủ đầy đủ cả 3 nội dung sau:
+  - 🖥️ **Giao diện (UI):** Kiểm tra hiển thị, bố cục, font chữ, trạng thái default của các control (checkbox, input, select box...), tính responsive và căn chỉnh.
+  - 💼 **Chức năng (Functional):** Kiểm tra logic nghiệp vụ khi click nút, chuyển trang, submit dữ liệu, các luồng happy/negative.
+  - 🔒 **An toàn thông tin (Security - nếu có):** Kiểm thử phân quyền truy cập (Authorization), mã hóa dữ liệu nhập (ví dụ: password hiển thị dạng `*`), tự động timeout session.
+- **Lỗi cần bắt:** Kịch bản người dùng cuối bị thiếu một trong ba nội dung trên (ví dụ: chỉ test chức năng mà bỏ qua kiểm tra hiển thị giao diện hoặc bỏ qua các case an toàn thông tin cơ bản).
+
+### 🌐 Tiêu chí 2: Tuân thủ cấu trúc kịch bản tiến trình/API (Backend / API Scenarios)
+- **Đối tượng:** Các kịch bản kiểm thử gọi API trực tiếp, chạy các tiến trình ngầm, hoặc các service kết nối downstream.
+- **Yêu cầu:** Kịch bản phải bao phủ đầy đủ cả 2 nội dung sau:
+  - ⚙️ **Chức năng (Functional):** Kiểm tra định dạng API Payload, các mã code trả về (`200 OK`, `400 Bad Request`, `500 Internal Error`), kiểm tra lưu trữ DB tương ứng, logic xử lý lỗi nghiệp vụ và lỗi downstream.
+  - 🔒 **An toàn thông tin (Security - nếu có):** Kiểm tra JWT token validation (expired token, invalid token, missing Bearer header), kiểm tra SQL Injection, Manipulation URL, CSRF hoặc dữ liệu nhạy cảm bị rò rỉ trong API payload/response.
+- **Lỗi cần bắt:** Kịch bản API thiếu kiểm thử an toàn thông tin (chỉ test happy path của API mà không thử bypass token hoặc inject payload độc hại).
+
+### 📝 Tiêu chí 3: Sự hiện diện của 5 thông tin bắt buộc trong từng Testcase
+- **Yêu cầu:** Bất kể định dạng kịch bản như thế nào, từng dòng testcase trong bảng bắt buộc phải điền đầy đủ và rõ ràng 5 thông tin cốt lõi sau:
+  1. **Mục đích kiểm thử:** Mô tả ngắn gọn kiểm thử cái gì (ví dụ: `Kiểm tra hiển thị form đăng ký merchant`).
+  2. **Trường hợp kiểm thử (Test Case Title):** Mô tả bối cảnh và điều kiện test (ví dụ: `Đăng ký merchant mới với đầy đủ thông tin hợp lệ`).
+  3. **Data test (Dữ liệu kiểm thử):** Ghi rõ dữ liệu nhập cụ thể (ví dụ: `merchant_name: Cửa hàng Hoa Sen`, `phone: 0987654321`). Tuyệt đối không để trống hoặc dùng placeholder chung chung.
+  4. **Các bước thực hiện (Test Steps):** Mô tả từng bước thao tác vật lý, đánh số thứ tự rõ ràng (Step 1, Step 2...).
+  5. **Kết quả mong muốn (Expected Result):** Mô tả chi tiết kết quả kỳ vọng ở các tầng UI, DB, Log và ghi nợ/có ví/ngân hàng nếu có.
+- **Lỗi cần bắt:** Bất kỳ testcase nào bị để trống hoặc ghi chung chung một trong năm thông tin bắt buộc trên.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/08-review/coverage-audit-rule.md

@@ -0,0 +1,48 @@
+# Coverage Audit Rule (Rà Soát Độ Bao Phủ)
+
+## Mục đích
+Thực hiện đối chiếu chéo (Cross-check) chi tiết kịch bản kiểm thử với các tài liệu Specs nguồn nhằm đảm bảo tính đầy đủ, độ bao phủ nghiệp vụ, hiệu năng và bảo mật.
+
+## Các Tiêu Chí Rà Soát Độ Bao Phủ
+
+### 📊 Tiêu chí 1: Kiểm tra tính Đầy đủ (Completeness Audit)
+Bạn phải xác minh tính đầy đủ trên 5 khía cạnh nghiệp vụ và kỹ thuật:
+
+1. **Common Testcase Giao diện:**
+   - **Yêu cầu:** Kịch bản kiểm tra giao diện phải bao phủ đầy đủ các trường hợp kiểm tra quy định trong *common testcase* (kiểm tra font, màu sắc, bố cục, căn chỉnh, validate biên ký tự, regex format, leading/trailing space, whitespace-only, và xử lý ký tự đặc biệt `<>&"'`).
+   - **Lỗi cần bắt:** Bỏ sót kịch bản validation hoặc kiểm tra hiển thị cơ bản của bất kỳ UI control nào.
+
+2. **Bao phủ Yêu cầu Nghiệp vụ (Specs Coverage):**
+   - **Yêu cầu:** Kịch bản kiểm tra chức năng phải bao phủ 100% yêu cầu nghiệp vụ được mô tả trong Specs hoặc phiếu yêu cầu nghiệp vụ (Business Requirements).
+   - **Lỗi cần bắt:** Thiếu kịch bản cho bất kỳ luồng nghiệp vụ rẽ nhánh, luồng ngoại lệ hoặc logic nghiệp vụ nào được mô tả trong phần Logic (`_detailed_design`).
+
+2b. **Bao phủ Button / Action (Button Coverage):**
+   - **Yêu cầu:** MỌI button enable hiển thị trong chức năng phải có testcase click → điều hướng/xử lý đúng nghiệp vụ (đích đến cụ thể), và testcase click nhiều lần liên tiếp (chống double-submit/tạo request trùng/mở chồng dialog).
+   - **Lỗi cần bắt:** Bỏ sót button enable không có case click; case click ghi đích đến mơ hồ ("điều hướng đúng"); thiếu case click nhiều lần cho button gây tác động nghiệp vụ.
+
+3. **Môi trường triển khai cụ thể:**
+   - **Yêu cầu:** Kịch bản kiểm thử bắt buộc phải ghi rõ nội dung môi trường triển khai chi tiết ở cột Môi trường/Công cụ test, bao gồm: **loại trình duyệt** (ví dụ: Google Chrome, Microsoft Edge, Firefox, Safari) và **version tương ứng** (hoặc ghi rõ *Latest version*).
+   - **Lỗi cần bắt:** Chỉ ghi chung chung `Môi trường Staging` hoặc `Môi trường Web` không có thông tin chi tiết trình duyệt/version.
+
+4. **Kịch bản kiểm thử hồi quy (Regression Testing):**
+   - **Yêu cầu:** Với các nghiệp vụ thuộc luồng **nâng cấp, sửa đổi hệ thống**, bắt buộc phải có các testcase kiểm thử hồi quy (Regression) cho các chức năng, phân hệ hoặc luồng dữ liệu bị ảnh hưởng gián tiếp bởi lần nâng cấp này (dựa trên bảng Impact Analysis).
+   - **Lỗi cần bắt:** Thiếu các ca test hồi quy cho các chức năng xung quanh phân hệ được nâng cấp sửa đổi.
+
+5. **Mô tả tác động Tài khoản Ngân hàng / Tài khoản Ví kênh:**
+   - **Yêu cầu:** Với các nghiệp vụ có tác động tới tài khoản ngân hàng hoặc tài khoản ví kênh (ví dụ: rút tiền, nạp tiền, thanh toán, đối soát), cột **Kết quả mong muốn** bắt buộc phải mô tả chi tiết:
+     - **Tài khoản nào bị GHI NỢ (Debit):** Số tiền ghi nợ cụ thể, số dư sau khi ghi nợ.
+     - **Tài khoản nào được GHI CÓ (Credit):** Số tiền ghi có cụ thể, số dư sau khi ghi có.
+     - Trạng thái hạch toán kế toán tương ứng.
+   - **Lỗi cần bắt (Nghiêm trọng):** Thiếu mô tả ghi nợ/ghi có tài khoản đối với từng tình huống kiểm thử liên quan đến tài chính.
+
+### ⚡ Tiêu chí 2: Kiểm tra tính Hiệu năng (Performance Audit)
+- **Yêu cầu:** Đối với các nghiệp vụ có yêu cầu phi chức năng về hiệu năng (ví dụ: xử lý đồng thời, thời gian phản hồi API phải dưới 500ms, khả năng chịu tải của hệ thống), kịch bản kiểm thử bắt buộc phải có các testcase kiểm tra hiệu năng cụ thể (nêu rõ công cụ kiểm thử như JMeter/k6, số lượng concurrent users, và tiêu chí đánh giá).
+- **Lỗi cần bắt:** Bỏ sót kịch bản hiệu năng đối với các nghiệp vụ có yêu cầu hiệu năng cao.
+
+### 🔒 Tiêu chí 3: Kiểm tra tính Bảo mật (Security Audit)
+- **Yêu cầu:** Kịch bản kiểm thử bắt buộc phải bao phủ các ca kiểm tra lỗi bảo mật cơ bản cho toàn bộ các trường nhập liệu tự do, thanh tìm kiếm, URL và API endpoint:
+  1. **SQL Injection:** Inject payload độc hại (`' OR 1=1--`, v.v.) vào input fields và API endpoint.
+  2. **Cross-Site Scripting (XSS):** Nhập các thẻ script (`<script>alert(1)</script>`, v.v.) để kiểm tra escape HTML.
+  3. **Manipulation URL:** Thay đổi tham số ID trên thanh địa chỉ trình duyệt (ví dụ: đổi `?id=100` thành `?id=101`) để kiểm tra lỗi phân quyền ngang (IDOR - Insecure Direct Object Reference) và kiểm tra lỗi rò rỉ dữ liệu.
+  4. **Cross-Site Request Forgery (CSRF):** Kiểm tra tính hợp lệ của Anti-CSRF Token hoặc kiểm tra SameSite cookie attribute trên các request nhạy cảm (POST/PUT/DELETE).
+- **Lỗi cần bắt:** Thiếu bất kỳ ca kiểm tra lỗi bảo mật cơ bản nào (SQLi, XSS, Manipulation URL, CSRF) trong bộ kịch bản kiểm thử.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/08-review/kbkt-review-gate-rule.md

@@ -0,0 +1,42 @@
+# KBKT Review Gate Rule (NTAPP & Core)
+
+## Mục đích
+
+Đánh giá chất lượng KBKT sau khi sinh testcase.
+
+## Điều kiện kích hoạt
+
+Bắt buộc chạy sau bước generate KBKT và trước khi chuyển sang tạo data test hoặc automation.
+
+## Tiêu chuẩn Đánh giá (QC Checklist Thang 100 Điểm)
+
+Review KBKT phải chấm theo các tiêu chí và tổng điểm tối đa là 100.
+**Đạt khi tổng điểm >= 85.**
+
+| Tiêu chí | Mô tả chi tiết (Tương đương thang điểm 10 cũ) | Điểm tối đa |
+|---|---|---:|
+| **Đúng nghiệp vụ** | - Đầy đủ nội dung Giao diện - Chức năng - ATTT đối với user cuối.<br>- Đầy đủ Chức năng - ATTT đối với kịch bản tiến trình/API.<br>- Đầy đủ thông tin môi trường triển khai (trình duyệt, version). | 25 |
+| **Coverage đủ Slice** | - Bao phủ 100% yêu cầu nghiệp vụ trong specs (`_detailed_design`) và common testcase giao diện.<br>- Có kịch bản hồi quy (Regression) cho chức năng ảnh hưởng.<br>- Có đầy đủ kịch bản Hiệu năng (nếu có yêu cầu).<br>- Có đầy đủ kịch bản Bảo mật (SQLi, XSS, URL Manipulation, CSRF). | 25 |
+| **Traceability rõ** | - Nguồn gốc từ đâu (`_detailed_design`, PRD).<br>- Mỗi kịch bản có đủ 5 thông tin: Mục đích, TH test, Data, Bước thực hiện, KQ mong muốn. | 15 |
+| **Expected result chính xác** | - Mô tả rõ ràng luồng ghi nợ/ghi có tài khoản ví/ngân hàng.<br>- Phải rõ UI hiển thị gì, Database thay đổi bảng nào, Log ghi gì. | 10 |
+| **Format đúng chuẩn** | - Bám sát định dạng 11 cột, rõ ràng, dễ đọc. | 10 |
+| **Không hallucination** | - Dữ liệu thực tế, không dùng placeholder (`abc`, `{username}`). | 5 |
+| **Automation readiness** | - Testcase có thể tự động hóa không?<br>- Expected có locator/điểm kiểm chứng rõ không?<br>- Data test có thể setup/teardown không? | 10 |
+
+## Ngưỡng pass và Luật Vòng Lặp (Loop Rules)
+
+- **>= 85**: đạt.
+- **70-84**: cần chỉnh sửa nhỏ.
+- **< 70**: phải update KBKT và review lại.
+
+Nếu tổng điểm **Score < 85**:
+- KBKT bị từ chối, bắt buộc quay lại bước **Update KBKT** (Auto-Remediation).
+- Tự động khắc phục lỗi, tách validation, thay placeholder bằng data thật.
+- Sau khi update bắt buộc phải review và tính điểm lại cho đến khi >= 85.
+
+## Điều kiện reject ngay
+
+- Có expected `???`.
+- Có field/control không tồn tại.
+- Có testcase thiếu steps hoặc expected.
+- Có testcase tự bịa message lỗi.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/08-review/ntapp-review-anti-patterns.md

@@ -0,0 +1,16 @@
+# NTAPP Review Anti-Patterns
+
+## Mục đích
+Tài liệu này liệt kê các hành vi "chống mẫu" (cấm kỵ) khi thực hiện Review kịch bản kiểm thử (KBKT).
+
+---
+
+## Quy Tắc Chống Mẫu Khi Review (Anti-Patterns)
+
+Nghiêm cấm các hành vi sau khi Review kịch bản:
+
+- ❌ **Đánh giá hời hợt, chỉ kiểm tra Happy Path:** Phải rà soát cực kỳ kỹ lưỡng các kịch bản Negative, Boundary, Regression, Performance và Security.
+- ❌ **Chấp nhận dữ liệu placeholder:** Bất kỳ dữ liệu nào dạng `{username}`, `abc`, `...` đều phải bị đánh lỗi chất lượng và trừ điểm, yêu cầu làm rõ thành dữ liệu thực tế.
+- ❌ **Chấp nhận expected result chung chung:** Không chấp nhận kiểu ghi `Hệ thống xử lý thành công`. Phải ghi rõ UI hiển thị gì, Database thay đổi bảng nào, Log ghi nhận mã gì, và chi tiết ghi nợ/ghi có đối với tài khoản ví/ngân hàng.
+- ❌ **Bỏ qua lỗi gộp Validation:** Nếu thấy testcase gộp validation nhiều trường, bắt buộc phải đánh lỗi và yêu cầu tách ra.
+- ❌ **Thiếu kịch bản bảo mật cơ bản:** Bỏ qua kiểm tra XSS, SQLi, CSRF và Manipulation URL trên các trường nhập liệu tự do và API endpoints.