@trungtamcongnghedigital/vsaf 1.0.0

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/09-data-grid/grid-base-rule.md

@@ -0,0 +1,41 @@
+---
+cases_count: 9
+---
+# Data Grid Base Rule
+
+## Mục đích
+
+Sinh testcase kiểm tra thao tác hiển thị và quản lý bảng dữ liệu (Gridview / Data Table).
+
+## Điều kiện kích hoạt
+
+Khi màn hình có danh sách dạng bảng hiển thị nhiều bản ghi (gồm cả panel danh sách trong modal và list virtual-scroll).
+
+## 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. Empty State: hiển thị bảng khi không có dữ liệu (vd text "Không có dữ liệu").
+2. Hiển thị tên và thứ tự các cột theo `_detailed_design`.
+3. Phân trang mặc định: số bản ghi trên 1 trang đúng giá trị đặc tả (không mặc định 10).
+4. Chuyển trang: sang trang 2, trang cuối.
+5. Sắp xếp (Sorting) tăng dần/giảm dần theo cột ID hoặc cột Ngày tạo.
+6. Thao tác trên dòng: xem chi tiết / sửa / xóa từng dòng (nút theo `_detailed_design`).
+7. Thao tác hàng loạt: tick chọn nhiều dòng và xóa hàng loạt (nếu hỗ trợ).
+8. Volume / chống cắt ngầm: seed số bản ghi khớp filter > page size đặc tả và > 10 (default framework); xác nhận mọi bản ghi truy cập được qua phân trang/scroll, không bị cắt ngầm. Assert theo count, không dựa "có dòng hiện".
+9. Boundary phân trang (BVA): seed các mốc biên quanh page size — đúng 1 bản ghi, đúng bằng page size, page size + 1 (tràn trang 2 đúng 1 bản ghi); mỗi mốc assert số dòng/trang và tổng số trang khớp page size đặc tả. Mốc 1 bản ghi: chỉ 1 trang, không hiện điều hướng trang thừa.
+
+## Expected chuẩn
+
+- Bảng không vỡ layout khi nội dung text quá dài.
+- Phân trang đúng logic, không tải lại toàn trang nếu dùng ajax.
+- Sắp xếp đồng bộ dữ liệu đúng chiều.
+- Số dòng hiển thị + tổng số bản ghi/tổng trang khớp nguồn sự thật: DB (COUNT theo cùng điều kiện) và/hoặc API `total`/`totalElements` — UI không thừa/thiếu so với DB/API.
+
+## Điều kiện cần Q&A
+
+Tạo Q&A nếu không rõ:
+- Số bản ghi mặc định trên một trang là bao nhiêu?
+- Số bản ghi tối đa panel/list hiển thị (cap virtual-scroll) là bao nhiêu?
+- Có cột nào cho phép sorting, cột nào không?

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/10-be/backend-resilience-rule.md

@@ -0,0 +1,78 @@
+---
+cases_count: 15
+---
+
+# General Backend Resilience Rules
+
+## Mục đích
+
+Sinh testcase kiểm tra khả năng kháng lỗi, timeout và phục hồi phía Backend nhằm bảo vệ tính toàn vẹn của giao dịch E2E và hệ thống.
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi màn hình/chức năng có gọi API Backend, tương tác cơ sở dữ liệu (DB), ghi bộ nhớ đệm (Cache) hoặc tích hợp với các hệ thống con (downstream).
+
+## Thành phần cần kiểm tra
+
+- API Gateway & Các API Client.
+- Cơ chế Resilience4j (Circuit Breaker, Timeout).
+- Redis Cache.
+- Database (Transaction, Connection Pool, Unique constraints).
+- Authentication & Authorization (Session, RBAC Token).
+
+## 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.
+
+### Timeout & Downstream
+
+1. **Timeout downstream**: Dịch vụ con phản hồi chậm quá cấu hình -> Hệ thống tự ngắt kết nối, trả mã lỗi timeout, không treo luồng.
+2. **Downstream sập**: Dịch vụ con lỗi 5xx/mất kết nối -> Backend trả mã lỗi Gateway (502/504), UI hiển thị thông báo tường minh.
+3. **Circuit Breaker**: Dịch vụ con lỗi liên tục -> Kích hoạt từ chối nhanh (fast-fail) lập tức để tránh treo hệ thống.
+
+### Cache
+
+4. **Lỗi đọc Cache**: Kết nối Cache lỗi/timeout ở chiều đọc -> Fallback tự động truy vấn DB gốc, không lỗi luồng.
+5. **Lỗi ghi Cache**: Kết nối Cache lỗi ở chiều ghi -> Ghi nhận log lỗi hệ thống, giao dịch nghiệp vụ chính vẫn thành công.
+
+### DB & Transaction
+
+6. **Race Condition**: 2 Maker submit đồng thời trên cùng tài nguyên -> DB báo lỗi ràng buộc duy nhất, transaction thứ hai rollback hoàn toàn, trả lỗi 409.
+7. **Cạn kết nối DB**: Số kết nối DB đạt giới hạn -> Chủ động trả lỗi quá tải 503 thay vì treo hàng đợi request.
+8. **Lỗi ghi audit log/bảng phụ**: Lỗi ghi log phụ trợ -> Ghi nhận lỗi nhưng vẫn commit thành công giao dịch nghiệp vụ chính.
+
+### Đồng bộ trạng thái xuyên hệ thống
+
+11. **Revalidate tại thời điểm ghi (TOCTOU)**: Giữa lúc đọc list và lúc submit/bind/duyệt, trạng thái tài nguyên đổi ở hệ nguồn (được duyệt/từ chối/hết hạn) -> hệ thống PHẢI đọc lại trạng thái hiện tại trước khi ghi; nếu không còn hợp lệ -> chặn + báo lỗi tường minh, KHÔNG tạo/bind với trạng thái cũ.
+12. **Stale-read trong cửa sổ cache/TTL**: Tài nguyên đổi trạng thái ở nguồn khi list/detail còn trong TTL cache -> sau refresh/hết TTL list phản ánh đúng; không cho phép hành động dựa trên trạng thái cũ đang hiển thị.
+13. **Event-before-entity (sự kiện đến trước khi bản ghi tồn tại)**: Hệ nguồn phát event đồng bộ trạng thái TRƯỚC khi entity đích được tạo -> consumer không tìm thấy bản ghi -> verify trạng thái KHÔNG mất vĩnh viễn (có backfill/reload/đối soát) HOẶC entity tạo sau tự lấy trạng thái mới nhất. Chống "nuốt event + ACK" gây lệch vĩnh viễn.
+14. **Snapshot vs source-of-truth drift + đối soát**: Trạng thái copy/denormalize vào bản ghi local lúc tạo; sau đó nguồn đổi -> verify bản ghi local được đồng bộ về khớp nguồn qua event/reload; nếu đồng bộ lỡ thì job đối soát (reconciliation) phát hiện và sửa. Chống seed cứng giá trị mặc định che mất trạng thái thật.
+15. **Terminal/ineligible state đưa vào luồng sai**: Tài nguyên đã ở trạng thái kết thúc/không hợp lệ (đã duyệt/đã từ chối/đã hủy) bị đưa vào hành động giả định trạng thái trước đó -> phải bị chặn theo state machine, không double-process.
+
+### Security & Session
+
+9. **Hết hạn session**: Phiên đăng nhập hết hạn hoặc bị thu hồi giữa chừng -> Chặn API, trả lỗi 401 hướng dẫn đăng nhập lại.
+10. **Vượt quyền (RBAC)**: Gửi request ngoài phạm vi phân quyền của tài khoản -> Chặn lập tức, trả lỗi 403 Forbidden.
+
+## Expected chuẩn
+
+Kỳ vọng phải mô tả rõ trạng thái của các tầng (UI, API, DB), ví dụ:
+
+```text
+Hệ thống ngắt kết nối sau <timeout_limit> giây, trả về mã lỗi timeout. UI hiển thị thông báo: "Dịch vụ phản hồi chậm, vui lòng thử lại sau".
+```
+
+```text
+Hệ thống tự động bỏ qua lỗi kết nối Cache và thực hiện truy vấn trực tiếp từ cơ sở dữ liệu gốc để trả về kết quả 200 OK cho người dùng.
+```
+
+```text
+Cơ sở dữ liệu thực hiện rollback toàn bộ tiến trình ghi của giao dịch thứ hai. Hệ thống trả về lỗi 409 Conflict. UI thông báo: "Hồ sơ đã tồn tại hoặc đang được xử lý".
+```
+
+## Điều kiện reject
+
+- Tự ý suy đoán Expected mà không đối soát tài liệu thiết kế nghiệp vụ (`_detailed_design`) hoặc mã lỗi thực tế của hệ thống.
+- Gộp chung các kịch bản lỗi Backend thành một case duy nhất.
+- Bỏ qua các bước kiểm chứng DB (ví dụ: rollback kiểm tra bản ghi rác) trong Expected Result.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/10-be/data-visibility-rule.md

@@ -0,0 +1,51 @@
+---
+cases_count: 7
+---
+
+# Data Visibility Rule (Cross-Actor Scoping)
+
+## Mục đích
+
+Sinh testcase kiểm tra phạm vi hiển thị dữ liệu theo actor/vai trò (data scoping) — dữ liệu do user/role này tạo có hoặc không hiển thị cho user/role khác đúng đặc tả nghiệp vụ. Khác với 403-deny của [backend-resilience-rule](./backend-resilience-rule.md) (chặn quyền); rule này kiểm phạm vi thấy được của kết quả.
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi list/search gom dữ liệu theo business key (merchant/filter/trạng thái) mà response có field người tạo (`createdBy`)/đơn vị/role, HOẶC spec mô tả phạm vi xem theo vai trò.
+
+## Thành phần cần kiểm tra
+
+- Bản ghi seed bởi actor A.
+- Phiên đăng nhập actor B (khác user / khác role).
+- Danh sách kết quả và field `createdBy`/đơn vị.
+
+## 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. Cùng scope, khác người tạo: bản ghi do A tạo hiển thị cho B khi spec quy định phạm vi theo filter (không theo `createdBy`).
+2. Role cao hơn (Admin): xem được bản ghi của mọi user trong scope.
+3. Khác scope: bản ghi ngoài phạm vi (merchant/đơn vị khác) KHÔNG hiển thị cho actor không thuộc scope.
+4. Role thấp/không quyền: chặn theo đặc tả (ẩn field / không thấy record / 403).
+5. Field `createdBy` chỉ hiển thị, KHÔNG dùng làm điều kiện lọc trừ khi spec yêu cầu.
+6. Bộ lọc theo người tạo (nếu spec có): lọc đúng theo `createdBy` được chọn, không mặc định giới hạn về user đang đăng nhập.
+7. **Rendering theo role — mỗi role × mỗi bề mặt 1 case riêng.** Cấm case UI trần "màn hiện N cột" (ngầm mọi role như nhau). Phải neo role cho case mặc định + 1 case cho mỗi biến thể thu hẹp. Tách theo bề mặt: ẩn ô-lọc ≠ ẩn cột-bảng ≠ ẩn menu ≠ ẩn CTA — mỗi cái 1 dòng, không suy cái này ra cái kia. Field/cột ẩn assert KHÔNG render DOM (khác disabled).
+
+## Yêu cầu data (bắt buộc)
+
+Multi-actor: seed bằng **≥2 user/role khác nhau**; `fixtures.yaml` phải có ≥2 auth principal (mỗi principal 1 dataset seed riêng). Cấm test cross-actor với 1 principal.
+
+## Expected chuẩn
+
+Kỳ vọng dựa hoàn toàn vào đặc tả phạm vi trong `_detailed_design`/HLD, ví dụ:
+
+```text
+Danh sách gom theo merchantCode <value>, hiển thị đủ bản ghi của mọi người tạo trong scope; field Người tạo chỉ hiển thị, không lọc.
+```
+
+## Điều kiện cần Q&A
+
+Tạo Q&A nếu spec không nói rõ:
+
+- Phạm vi visibility theo `createdBy` hay theo filter/scope?
+- Role nào xem được data của role/user khác?

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/11-independent-filter/independent-filter-rule.md

@@ -0,0 +1,100 @@
+---
+cases_count: 18
+---
+
+# Independent Filter Rule
+
+> [!NOTE]
+> **Số lượng động:** `cases_count: 18` là phần cố định. Số case thực tế = 18 **+ N** (search per-field, mỗi trường lọc 1 case) **+ M** (tổ hợp combination). Planner cộng thêm N+M theo số trường lọc trong `_detailed_design`.
+
+## Mục đích
+
+Sinh testcase kiểm tra tìm kiếm & bộ lọc độc lập trên màn danh sách / form tìm kiếm (vd: lọc theo merchantCode, productCode đơn lẻ hoặc kết hợp).
+
+## Điều kiện kích hoạt
+
+Kích hoạt khi màn có ô nhập tìm kiếm / bộ lọc độc lập và nút Tìm kiếm/Reset.
+
+## Thành phần cần kiểm tra
+
+- Các trường lọc (Textbox, Dropdown, Datepicker...).
+- Nút Tìm kiếm, nút Hủy lọc/Reset.
+- Danh sách kết quả trả về và trạng thái rỗng (Empty State).
+
+## 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.
+
+### Trạng thái mặc định
+
+1. Trạng thái các trường lọc khi vừa mở form.
+2. Dữ liệu hiển thị khi chưa áp dụng lọc.
+
+### Thực thi tìm kiếm
+
+1. Lọc chỉ bằng 1 trường (các trường khác trống), lặp cho từng trường (per-field): thực thi tìm kiếm và **đối soát danh sách trả về khớp điều kiện trường đó** — KHÔNG dừng ở validate giá trị nhập.
+2. Lọc kết hợp ≥2 trường theo toán tử spec (AND/OR): tổ hợp có kết quả, tổ hợp giao rỗng (Empty State), tổ hợp full-field.
+3. Lọc với giá trị không tồn tại (Empty State).
+4. Nhấn Enter tại ô lọc để tìm kiếm.
+5. Thực thi tìm kiếm qua nút của màn (tên nút theo `_detailed_design`).
+6. Tìm kiếm khớp một phần (Like) — chỉ trường nhập.
+7. Tìm kiếm khớp chính xác (Equal) — chỉ trường nhập.
+8. Tìm kiếm phân biệt/không phân biệt chữ hoa thường (Case Sensitivity).
+
+### Reset bộ lọc
+
+1. Xóa toàn bộ điều kiện tìm kiếm, đưa danh sách về mặc định (qua nút reset của màn — tên nút theo `_detailed_design`).
+
+### Duy trì trạng thái
+
+1. Giữ trạng thái bộ lọc khi quay lại từ màn hình khác.
+2. Tải lại trang (F5/reload) khi đang áp lọc — khôi phục hoặc reset theo spec (im lặng → Q&A).
+3. Mở deep-link URL có sẵn tham số lọc — áp đúng tham số; tham số không hợp lệ xử lý theo spec.
+
+### Nhất quán trạng thái danh sách
+
+1. Xóa tay hết giá trị mọi ô lọc (không qua Reset) — danh sách về mặc định, không giữ kết quả cũ (stale).
+2. Đổi giá trị ô lọc nhưng chưa tìm lại — danh sách vẫn theo lần lọc hợp lệ gần nhất.
+3. Áp lọc mới khi đang ở trang phân trang khác trang đầu — hành vi theo spec (im lặng → `[TBD-spec]` + Q&A); luôn assert không lộ trang trống.
+
+### Xử lý dữ liệu nhập đặc biệt
+
+1. Lọc với từ khóa chứa khoảng trắng hoặc ký tự đặc biệt.
+
+## Nguyên tắc bắt buộc
+
+> [!IMPORTANT]
+> - **Validate ≠ Search:** mỗi trường phải có CẢ case validate giá trị nhập LẪN case thực thi search + đối soát danh sách.
+> - **Per-field:** N trường lọc → tối thiểu N case search độc lập; cấm gộp thành 1 case đại diện.
+> - **Cơ chế so khớp** (Like/Equal/case-sensitivity) lấy từ `_detailed_design` — cấm suy đoán.
+> - **Oracle nguồn sự thật:** data chuẩn bị gồm CẢ bản ghi khớp và KHÔNG khớp; assert **UI + ≥1 lớp (API và/hoặc DB)** theo thứ tự `kbkt-format-rule` UI → DB → API: mọi bản ghi trả về khớp `<filter_value>`, bản ghi không khớp vắng mặt, count parity. Cấm oracle dừng ở "list hiển thị / không rỗng". Thiếu tên API/param/bảng-cột để đối soát → `[TBD-spec]` + Q&A (không bịa endpoint/tên cột).
+
+## Expected chuẩn
+
+```text
+Hệ thống lọc dữ liệu theo điều kiện <filter_value>; danh sách hiển thị đúng các bản ghi khớp, bản ghi không khớp bị ẩn (UI). Đối soát nguồn sự thật: DB (WHERE <cột> theo cơ chế spec) và/hoặc API response trả đúng và đủ bản ghi khớp + total khớp — các lớp phải nhất quán.
+```
+
+```text
+Hệ thống hiển thị màn hình danh sách rỗng kèm hình ảnh minh họa (nếu có) và thông điệp: "Không tìm thấy kết quả phù hợp".
+```
+
+```text
+Hệ thống reset tất cả các ô lọc về trống (hoặc giá trị mặc định), tự động tải lại và hiển thị danh sách dữ liệu đầy đủ ban đầu.
+```
+
+## Điều kiện reject
+
+- Bỏ qua kịch bản reset/hủy lọc.
+- Thiếu expected mô tả trạng thái danh sách sau khi lọc (khớp kết quả hay Empty State).
+- Tự suy đoán cơ chế so khớp (Like/Equal) mà không đối soát `_detailed_design`.
+- Oracle chỉ kiểm list hiển thị/không rỗng, không đối soát TỪNG bản ghi khớp filter.
+- Chỉ validate giá trị nhập mà thiếu case thực thi search + đối soát danh sách cho trường đó.
+- Per-field: N trường lọc nhưng chỉ có 1 case đại diện (thiếu case cho ≥1 trường).
+- Thiếu case search kết hợp trường khi màn có ≥2 trường lọc, hoặc thiếu tổ hợp giao rỗng (Empty State).
+- Oracle chỉ dừng ở lớp UI, không đối soát API/DB (trừ khi spec chỉ có UI — phải ghi rõ lý do).
+- Empty state chỉ assert message, thiếu CTA/nút theo wireframe — xem [screen-default-display-rule §Độ đầy đủ theo STATE](../01-ui/screen-default-display-rule.md).
+- Danh sách stale: hiển thị kết quả không khớp filter hiện tại khi đã xóa/đổi filter (spec im lặng → Q&A, cấm suy đoán).
+- Thiếu case áp lọc mới khi ở trang khác trang đầu, hoặc expected tự suy đoán về-trang-đầu/giữ-trang mà không đối soát spec; bất biến "không lộ trang trống" luôn phải assert. Parity count xem [grid-base-rule §Volume](../09-data-grid/grid-base-rule.md).
+- Thiếu case duy trì trạng thái khi F5/reload hoặc deep-link tham số lọc (khi spec hỗ trợ khôi phục qua URL); expected phải theo spec, cấm mặc định một chiều.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/kbkt-generation/README.md

@@ -0,0 +1,47 @@
+# Danh mục Rule Sinh KBKT
+
+Thư mục này chứa toàn bộ các quy tắc sinh Testcase Manual (KBKT) chuyên biệt cho từng loại UI/Control.
+
+| Nhóm | File | Mục đích |
+| --- | --- | --- |
+| Core | `00-core/kbkt-format-rule.md` | Chuẩn format testcase |
+| Core | `00-core/no-hallucination-rule.md` | Chặn tự đoán |
+| Core | `00-core/ntapp-core-compliance.md` | **[NEW]** NTAPP Compliance & Anti-Patterns |
+| Core | `00-core/e2e-traceability-rule.md` | E2E Traceability & Tracer-bullet (UI → Gateway → BE → DB) |
+| Core | `00-core/test-design-techniques-rule.md` | **[NEW]** Kỹ thuật thiết kế kịch bản |
+| Core | `00-core/test-coverage-checklist-rule.md` | **[NEW]** Checklist vét cạn độ bao phủ |
+| UI | `01-ui/screen-default-display-rule.md` | Hiển thị mặc định |
+| UI | `01-ui/layout-visual-rule.md` | Layout/font/chính tả |
+| UI | `01-ui/keyboard-navigation-rule.md` | Tab/Shift-Tab/Enter |
+| UI | `01-ui/responsive-zoom-rule.md` | Zoom/responsive |
+| Input | `02-input/textbox-base-rule.md` | Textbox/searchbox |
+| Input | `02-input/required-field-rule.md` | Required field |
+| Input | `02-input/space-handling-rule.md` | Khoảng trắng |
+| Input | `02-input/maxlength-rule.md` | Maxlength |
+| Input | `02-input/security-input-rule.md` | HTML/JS/security input |
+| Input | `02-input/datepicker-rule.md` | **[NEW]** Datepicker, Datetime |
+| Input | `02-input/file-upload-rule.md` | **[NEW]** File upload, kéo thả |
+| Selection | `03-selection/combobox-base-rule.md` | Combobox |
+| Selection | `03-selection/dependent-combobox-rule.md` | Combobox phụ thuộc |
+| Selection | `03-selection/checkbox-rule.md` | **[NEW]** Checkbox |
+| Selection | `03-selection/radio-rule.md` | **[NEW]** Radio button |
+| Dynamic | `04-dynamic-form/multiple-group-toggle-rule.md` | Toggle hiện/ẩn field |
+| Dynamic | `04-dynamic-form/dynamic-row-add-remove-rule.md` | Icon + / - |
+| Dynamic | `04-dynamic-form/dynamic-form-rendering-rule.md` | **[NEW]** Render Form động theo Profile |
+| Filter | `05-dependent-filter/filter-rule-block-rule.md` | Khối Filter Rules |
+| Filter | `05-dependent-filter/filter-save-validation-rule.md` | Validate khi lưu filter |
+| Validation | `06-validation/inline-error-rule.md` | Lỗi inline |
+| Validation | `06-validation/duplicate-data-rule.md` | Dữ liệu trùng |
+| Validation | `06-validation/field-level-validation-rule.md` | **[NEW]** Bảng trạm kiểm duyệt theo loại Field |
+| Validation | `06-validation/error-response-behavior-rule.md` | **[NEW]** Hành vi phản hồi per mã lỗi (catalog) |
+| Save/Cancel | `07-save-cancel/save-button-rule.md` | Button Lưu |
+| Save/Cancel | `07-save-cancel/cancel-button-rule.md` | Button Hủy |
+| Save/Cancel | `07-save-cancel/action-button-rule.md` | **[NEW]** Mọi button điều hướng/action nghiệp vụ (click → điều hướng/xử lý + click nhiều lần) |
+| Review | `08-review/kbkt-review-gate-rule.md` | Review KBKT (Tích hợp NTAPP QC Checklist) |
+| Review | `08-review/ntapp-review-anti-patterns.md` | **[NEW]** NTAPP Review Anti-Patterns |
+| Review | `08-review/compliance-audit-rule.md` | **[NEW]** Rà soát tính tuân thủ (Compliance Audit) |
+| Review | `08-review/coverage-audit-rule.md` | **[NEW]** Rà soát độ bao phủ (Coverage Audit) |
+| Data Grid | `09-data-grid/grid-base-rule.md` | **[NEW]** Phân trang, Sorting, Actions |
+| Backend | `10-be/backend-resilience-rule.md` | **[NEW]** Kháng lỗi & phục hồi Backend |
+| Backend | `10-be/data-visibility-rule.md` | **[NEW]** Phạm vi hiển thị dữ liệu theo actor/role (data scoping) |
+| Filter | `11-independent-filter/independent-filter-rule.md` | **[NEW]** Bộ lọc độc lập (Search/Filter) |

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/templates/exploratory_charter_template.md

@@ -0,0 +1,28 @@
+# EXPLORATORY CHARTER — {id}
+
+> Sinh cho các kịch bản gắn `@exec:exploratory` (vùng bất định / khó scripted hóa).
+> Theo tinh thần School B: thay scripted manual bằng phiên khám phá có charter + time-box.
+> Gắn vào cuối markdown view (Mục 5.5) — KHÔNG sang automation, KHÔNG đếm vào Math Check scripted.
+
+## Mục 5.5. Exploratory Test Charters
+
+*(Lặp lại block dưới cho mỗi charter)*
+
+### CH-{NN}: {Tiêu đề vùng khám phá}
+
+> **Loại charter** (theo [explore_and_consistency_rules.md](../../principles/explore_and_consistency_rules.md)): `CH-CMP` (so sánh giao diện màn tương đồng — §4) · `CH-FLEX` (thao tác linh hoạt/timing — §5) · `CH-TBD` (case bị chặn vì spec gap — §3) · generic (vùng bất định khác). Ghi mã loại vào Charter ID (vd `CH-CMP-01`).
+
+| Trường | Nội dung |
+|:---|:---|
+| **Charter ID** | CH-{NN} |
+| **Loại** | {CH-CMP \| CH-FLEX \| CH-TBD \| generic} |
+| **Liên quan** | {unit_id} · {@risk} · {block} |
+| **Explore** | {khám phá cái gì — vd "form động khi đổi loại hồ sơ liên tục"} |
+| **With** | {công cụ/data — vd "Chrome devtools, data biên từ fixtures"} |
+| **To discover** | {tìm rủi ro gì — vd "trạng thái UI không nhất quán khi toggle nhanh"} |
+| **Time-box** | {vd 45 phút} |
+| **Nguồn bất định** | {`[TBD]` nào / spec mơ hồ nào dẫn tới charter này} |
+| **Oracle/heuristics** | {nguyên tắc đánh giá — consistency, CRUD, error-handling…} |
+| **Ghi nhận** | {để trống — tester điền findings + bug ID sau phiên} |
+
+> Khi một charter phát hiện hành vi xác định và có thể đặc tả → chuyển hóa thành testcase scripted (`@exec:automate`/`manual`) ở vòng cập nhật sau (xem [incremental_update_rules.md](../../principles/incremental_update_rules.md)).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/templates/fixtures_template.yaml

@@ -0,0 +1,72 @@
+# =====================================================================
+# FIXTURES TEMPLATE — Machine-readable test data + môi trường
+# File: {id}_fixtures.yaml   ({id} = ID đầy đủ SLICE/unit, vd SLICE-06 / WGT-SIDEBAR)
+# Hợp đồng: ../../principles/automation_contract_rules.md (Triple-Emit §1)
+# Thay thế phần "prose" của Mục 5.3 markdown bằng dữ liệu máy-đọc cho qa-robot.
+# Iron Rules R1: mọi giá trị phải truy về phần Dữ liệu trong _detailed_design — cấm bịa. Thiếu -> [TBD].
+# =====================================================================
+
+id: {id}
+generated: "{timestamp}"
+
+# ---- Môi trường E2E ----
+environment:
+  name: Staging
+  base_url: "{staging_base_url}"        # [TBD] nếu chưa có
+  # Mock API (nếu ca kiểm thử cần) — qa-robot dựng stub theo đây
+  mocks:
+    - endpoint: "{method} {path}"
+      when: "{điều kiện kích hoạt}"
+      response_status: 200
+      response_body_ref: "{tên dataset}"
+
+# ---- Fixtures: CHỈ dữ liệu DÙNG CHUNG (≥2 dataset) / phức tạp / động ----
+# scope: e2e (chạy qua UI) | api (gọi thẳng API) | db-seed (insert trước khi test)
+# QUY TẮC (automation_contract_rules.md §1 "Inline-value vs fixture_ref"):
+#   - KHÔNG tạo fixture tên riêng cho giá trị field TĨNH dùng-1-lần → ghi thẳng inline ở datasets bên dưới.
+#   - Fixture chỉ tồn tại khi: (a) ≥2 dataset dùng chung, HOẶC (b) payload nhiều field phức tạp, HOẶC (c) động ($db.query/$seed).
+fixtures:
+  - key: valid_compose_payload            # (a)+(b): payload phức tạp, được nhiều case submit dùng chung
+    scope: e2e
+    source: "_detailed_design (phần Dữ liệu)"   # traceability R3
+    data:
+      ten_ho_so: "Hồ sơ hợp lệ A"
+      # ... các field hợp lệ khác lấy từ phần Dữ liệu trong _detailed_design
+    teardown: "DELETE FROM composite_requests WHERE ten_ho_so = 'Hồ sơ hợp lệ A'"
+
+  - key: pmt_real_pending                 # (c): động — subId/merchantCode phải khớp bản ghi thật (Dynamic Binding)
+    scope: e2e
+    source: "_detailed_design (phần Dữ liệu)"
+    data:
+      subId: "$db.query(pmt_pending: SELECT id FROM ... WHERE status=5 LIMIT 1)"
+
+# ---- Datasets: ánh xạ từng testcase @exec:automate/@exec:exploratory -> data ----
+# qa-robot đọc bảng này để biết case nào lấy data nào (thay cột "Data Test" prose).
+# Case field tĩnh: GHI THẲNG giá trị inline. Case dùng chung/động: fixture_ref (+ overrides nếu cần).
+datasets:
+  # Loại 3 tĩnh dùng-1-lần → inline, KHÔNG refer:
+  - { id: KB-{id}-02, data: { email: "testdomain.com" }, note: "email thiếu @" }
+  - { id: KB-{id}-03, data: { ten_ho_so: "<256 ký tự>" }, note: "BVA max255 - vượt biên" }
+  # Dùng chung / payload phức tạp → fixture_ref:
+  - { id: KB-{id}-04, fixture_ref: valid_compose_payload }
+  - { id: KB-{id}-05, fixture_ref: valid_compose_payload, overrides: { ten_ho_so: "Hồ sơ hợp lệ B" } }
+  # Động → fixture_ref chứa $marker (hoặc inline data: { field: "$db.query(...)" }):
+  - { id: KB-{id}-06, fixture_ref: pmt_real_pending }
+  # Cần điều kiện đặc biệt không có sẵn:
+  - { id: KB-{id}-07, fixture_ref: null, note: "Security IDOR — cần 2 token (User A / User B), cấp ở môi trường test" }
+
+# ---- Cảnh báo bridge (đọc bởi qa-robot, không chặn skill này) ----
+# Khai theo surface_type. Bề mặt ui -> ui_schema_required. Bề mặt service -> khối api bên dưới.
+automation_prereq:
+  # (surface=ui) qa-robot cần để lấy selector; thiếu -> automation chặn
+  ui_schema_required:
+    - "ui_schema_{SCR-UNIT}.json"
+  # (surface=service) no-UI: KHÔNG cần ui_schema — qa-robot sinh keyword RequestsLibrary theo POM.
+  #   Bỏ trống/xoá ui_schema_required và khai khối dưới (xem service_surface_rules.md §5).
+  api:
+    base_url: "{staging_api_base_url}"          # [TBD] nếu chưa có
+    auth: "{cách lấy token: client-credential / login endpoint}"
+    api_contract: "_detailed_design (phần Hợp đồng) / OpenAPI nếu có"
+    mocks:                                        # key = "mocks" (qa-robot step-02 đọc automation_prereq.api.mocks)
+      - "{downstream service/đối tác cần stub}"   # các [Downstream] operation gọi đi
+  notes: "Skill QA không sinh selector/keyword. surface=ui cần ui_schema; surface=service cần base_url+auth+api_contract+mocks trước khi chạy /ntapp-qa-robot."

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/templates/plan_template.md

@@ -0,0 +1,55 @@
+> **Biến thể theo `surface_type`:** khung dưới đây (§1–§5) cho bề mặt **`ui`**. Bề mặt **`service`** (no-UI) dùng khung ở cuối file ("BIẾN THỂ SERVICE") — thay §1 Ánh xạ Nhãn UI bằng Contract Map, §2 Bảng Mapping Rule đổi cột "Loại UI Control" → "Field/Contract element", giữ nguyên §3–§5.
+
+### 1. Nhật Ký Đọc File & Ánh Xạ Nhãn Hiển Thị (UI Label Mapping)
+- **Tài liệu màn hình hiện tại & Backend:** ...
+- **Tài liệu màn hình đích (Target Screen):** ... (Ghi chú rõ nếu màn hình này không thuộc SLICE hiện tại)
+
+**Ánh Xạ Nhãn Hiển Thị (LIỆT KÊ ĐẦY ĐỦ TỪNG ELEMENT — không glossary chung):**
+- Liệt kê **MỌI** element của màn: từng control/tiêu đề/placeholder/cột bảng/empty-state/banner/dialog/toast/inline-error → `biến_kỹ_thuật` → **Nhãn hiển thị verbatim + cite DD**. Thiếu element = thiếu testcase ở Step 03 (xem slice_planning Chốt 3).
+
+### 2. Bảng Mapping Rule (Targeted Mapping Bắt Buộc)
+| Loại UI Control | Nạp File Rule Tương Ứng |
+|:---|:---|
+| Global/Core | `00-core/...` |
+| Textbox (Tên trường) | `02-input/...` |
+| Checkbox/Radio | `03-selection/...` |
+
+### 3. Tính Toán Toán Học & Ma Trận Quyết Định (Mathematical Forcing)
+- **Validation `Field 1`**: ... cases
+- **Tổng số lượng dự kiến tối thiểu**: ... cases.
+
+**Ma Trận Quyết Định — nếu gom ≥2 nguồn: dòng đầu PHẢI là Cartesian các nguồn × {0,1,M} (nhánh nghiệp vụ/lỗi = bảng orthogonal, không thay thế):**
+| Case | [Điều Kiện 1] | [Điều Kiện N] | Kết quả & Trạng thái |
+|:---:|:---:|:---:|:---|
+| 1 | ... | ... | ... |
+
+### 4. Self-Reflection Gate (Cross-Source)
+> **Đánh giá Self-Audit:** Tính năng này có giao thoa dữ liệu không? Tôi ĐÃ vẽ rõ Ma Trận Quyết Định gồm N trường hợp...
+
+### 5. (ĐÃ BỎ) Checklist Kiểm Đếm
+> Plan **KHÔNG** còn section này. Tổng `X` lấy từ **§3 (Math Forcing)**. Materialize 1-1 mỗi rule-case → 1 dòng testcase ở **Step 03** (Math Check `X = Y`).
+> Ghi kèm ở §3/§4: **Phân định Action-Verify** (Màn trước → verify màn đích trong Expected của hành động · Màn sau → chỉ hành động nội tại).
+
+---
+
+## BIẾN THỂ SERVICE (no-UI: HUB/MPF/INT) — xem [service_surface_rules.md](../../principles/service_surface_rules.md)
+
+### 1s. Contract Map (thay Ánh Xạ Nhãn UI)
+**Operation:** `{METHOD /path}` / tên operation nghiệp vụ
+| Request field (kiểu · required · ràng buộc) | Response / HTTP status | Error catalog (mã → status → điều kiện) | Side-effect (bảng DB · event/MSG · audit log) | State machine (transition hợp lệ) |
+|:---|:---|:---|:---|:---|
+| ... | ... | ... | ... | ... |
+
+*Phân loại Dynamic Data (field khóa tra cứu/unique):* `field → Tier(0/1/2/3) → source_id` *(BẮT BUỘC — Quality Gate 3b)*
+
+### 2s. Bảng Mapping Rule (tầng service)
+| Field/Contract element | Nạp File Rule Tương Ứng |
+|:---|:---|
+| Core | `00-core/...` (Ledger) |
+| Backend (LUÔN áp) | `10-be/backend-resilience-rule`, `10-be/data-visibility-rule` |
+| Field required/length/format/enum (tầng payload) | `02-input/*`, `03-selection/*` (phần allowed-values) |
+| Duplicate / error response | `06-validation/duplicate-data-rule`, `error-response-behavior-rule` |
+| N/A (đánh dấu 0 case) | `01-ui/*`, `04-dynamic-form/*`, phần render `03-selection`/`09-data-grid` |
+
+### 3s–5s
+Dùng §3 (Math + Decision Matrix — bổ sung nguồn: error catalog completeness · state machine transition · idempotency/dedupe · resilience), §4 (Self-Reflection); bung testcase 3 nhóm (**Hợp đồng & Request Validation / Nghiệp vụ & E2E / Phân quyền & ATTT**) ở Step 03 như bề mặt ui — KHÔNG checklist vào plan (Chốt 8).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/templates/slice_testcase_table_template.md

@@ -0,0 +1,124 @@
+# KỊCH BẢN KIỂM THỬ CHI TIẾT (E2E SYSTEM TEST PROTOCOL) — {id}
+
+> **Chế độ:** Mode 3: GENERATE SLICE / UNIT  
+> **Thời gian tạo:** {timestamp}  
+> **Mã SLICE/Unit:** {id}  
+> **Độ bao phủ cam kết (Coverage Gate):** 100% End-to-End luồng thao tác người dùng qua các units FE và BE.
+>
+> **Artifact đồng hành (Triple-Emit — xem [automation_contract_rules.md](../../principles/automation_contract_rules.md)):**
+> - `{id}_testspec.feature` — bản canonical Gherkin + tags (nguồn automation).
+> - `{id}_fixtures.yaml` — dữ liệu mồi + môi trường máy-đọc.
+> - File markdown này là **VIEW** để QA ký + để `/ntapp-qa-robot` parse.
+>
+> **Cột `Exec`** (cổng automation): `automate` (qa-robot sinh code) · `manual` (tester chạy tay) · `exploratory` (hiếm — chỉ visual thẩm mỹ thuần trong KHỐI 1, KHÔNG charter). Rủi ro timing/đồng thời/phiên/[TBD] → viết scripted trong KHỐI 2/3. Quy tắc gán: [risk_based_allocation_rules.md](../../principles/risk_based_allocation_rules.md).
+
+---
+
+## 5. ĐẢM BẢO CHẤT LƯỢNG (QUALITY ASSURANCE & E2E TEST PROTOCOL)
+
+### 5.0. Bối cảnh & Điều kiện tiên quyết (Test Preconditions)
+1. **Người dùng đăng nhập:** Được cấp quyền theo đúng luồng E2E.
+2. **Trạng thái hệ thống:** Mạng ổn định hoặc được cấu hình mock theo ca kiểm thử.
+
+---
+
+### 5.1.A. Impact Analysis (Phân tích ảnh hưởng luồng SLICE)
+Bảng phân tích các đơn vị (Units), FE screens, BE modules bị ảnh hưởng khi triển khai `{id}`:
+
+| Chức năng / phân hệ ảnh hưởng (Units) | Mức độ | Lý do / Nội dung chi tiết |
+|:---|:---:|:---|
+| **{Tên phân hệ FE: SCR/WGT}** | **H** | {Lý do} |
+| **{Tên phân hệ BE: HUB/API}** | **H** | {Lý do} |
+
+*Mức độ: H (High - Cao), M (Medium - Trung bình), L (Low - Thấp)*
+
+---
+
+### 5.2. Kịch bản kiểm thử E2E chi tiết (11-Column Manual Testcase — +Exec)
+
+> **Biến thể theo `surface_type`:**
+> - **`ui`** (dưới đây) — 3 khối **GIAO DIỆN / CHỨC NĂNG / PHÂN QUYỀN**; đầu mỗi màn có "Danh sách UI Controls"; cột Công cụ `Chrome`; Kết quả mong muốn phân lớp **UI:/API:/DB:/Log:**.
+> - **`service`** (no-UI: HUB/MPF/INT — xem [service_surface_rules.md](../../principles/service_surface_rules.md)) — thay tiêu đề "MÀN HÌNH ACTION" bằng **"OPERATION {STT}: {METHOD /path hoặc tên operation}"**; đổi "Danh sách UI Controls" thành **"Danh sách Endpoint/Operation & Hợp đồng"** (request field · response · error catalog · side-effect); 3 khối = **HỢP ĐỒNG & REQUEST VALIDATION / NGHIỆP VỤ & E2E / PHÂN QUYỀN & ATTT**; cột Công cụ `Postman`/`RequestsLibrary`; Kết quả mong muốn phân lớp **API:/DB:/MSG:/Log:** (KHÔNG có UI:). Giữ nguyên 11 cột, chỉ đổi nội dung.
+
+*(Lặp lại cấu trúc dưới đây cho từng Màn hình Action (ui) / Operation (service) tham gia vào luồng E2E)*
+
+#### 🖥 MÀN HÌNH ACTION {STT}: {Tên Màn Hình Action}
+
+##### 📌 Danh sách UI Controls (Tra cứu nhanh từ đặc tả)
+| Mã Control | Tên Control | Loại thành phần UI | Vai trò & Vị trí hiển thị trên giao diện |
+|:---:|:---|:---|:---|
+| **Control 1** | ... | ... | ... |
+
+##### KHỐI 1: GIAO DIỆN (UI)
+
+| ID | Mục đích kiểm thử | Trường hợp kiểm thử | Data Test | Các bước thực hiện | Môi trường | Công cụ test | Kết quả mong muốn (UI, DB, Log) | Độ ưu tiên | Exec | Luồng ref |
+|:---|:---|:---|:---|:---|:---|:---|:---|:---:|:---:|:---|
+| **KB-{id}-01** | Kiểm tra Xử lý lỗi validation Email (BVA) | Nhập Email thiếu ký tự @ | `Email: testdomain.com` | (1) Nhập "testdomain.com" vào trường Email. <br> (2) Bấm submit. | Stag | Chrome | **UI:** Trường Email viền đỏ, hiển thị lỗi "Email không đúng định dạng". | P1 | manual | Ref UI: Control-05 |
+
+##### KHỐI 2: CHỨC NĂNG (FUNCTIONAL & E2E LUỒNG NGHIỆP VỤ)
+
+| ID | Mục đích kiểm thử | Trường hợp kiểm thử | Data Test | Các bước thực hiện | Môi trường | Công cụ test | Kết quả mong muốn (UI, DB, Log) | Độ ưu tiên | Exec | Luồng ref |
+|:---|:---|:---|:---|:---|:---|:---|:---|:---:|:---:|:---|
+| **KB-{id}-02** | Kiểm tra hiển thị thành công toàn luồng tạo mới | User tạo mới thành công từ UI xuống BE | `fixture: valid_compose_payload` | (1) Mở màn hình {Tên màn hình}. <br> (2) Nhập dữ liệu hợp lệ. <br> (3) Bấm Lưu. | Stag | Chrome | **UI:** Chuyển hướng sang màn hình Danh sách, bản ghi mới hiển thị ở dòng đầu tiên. <br> **DB:** Bảng `composite_requests` insert thành công bản ghi mới với status `PENDING`. <br> **API:** POST `{endpoint}` trả HTTP 200. | P0 | automate | Luồng chính |
+
+##### KHỐI 3: PHÂN QUYỀN & ATTT (SECURITY)
+
+| ID | Mục đích kiểm thử | Trường hợp kiểm thử | Data Test | Các bước thực hiện | Môi trường | Công cụ test | Kết quả mong muốn (UI, DB, Log) | Độ ưu tiên | Exec | Luồng ref |
+|:---|:---|:---|:---|:---|:---|:---|:---|:---:|:---:|:---|
+| **KB-{id}-03** | Kiểm tra bảo mật IDOR | Thao tác trên tài nguyên của user khác | `ID User khác` | (1) Lấy token User A. <br> (2) Gửi API request xem chi tiết ID User B. | Stag | Postman | **API:** HTTP 403 Forbidden. | P0 | automate | ATTT |
+
+*Độ ưu tiên (= @risk): P0 (Blocker/Sanity/Luồng chính), P1 (Luồng nhánh/Biên/Lỗi HUB), P2 (Lỗi hiển thị/Visual)*
+*Exec (= @exec): `automate` (sang qa-robot) · `manual` (tester chạy tay) · `exploratory` (hiếm — visual thuần KHỐI 1). Mỗi dòng `automate` phải có `@id` khớp 1-1 trong file `.feature` và một dataset trong `fixtures.yaml`.*
+
+---
+
+#### ⚙️ VÍ DỤ BIẾN THỂ SERVICE (no-UI) — OPERATION {STT}: `POST /api/v1/transfers`
+
+##### 📌 Danh sách Endpoint/Operation & Hợp đồng (Tra cứu nhanh từ đặc tả)
+| Endpoint/Operation | Request field (ràng buộc) | Response / HTTP | Error catalog | Side-effect (DB/MSG/Log) |
+|:---|:---|:---|:---|:---|
+| `POST /api/v1/transfers` | `amount` (BigDecimal>0), `currency` (enum), `Idempotency-Key` (header) | 201 + `{transferId,status}` | `INSUFFICIENT_FUNDS`→422, `DUP_KEY`→200(idempotent), `INVALID_CCY`→400 | insert `transfers` status PENDING · phát event `transfer.created` · audit log |
+
+##### KHỐI 2: NGHIỆP VỤ & E2E (API → DB → MSG → Log)
+| ID | Mục đích kiểm thử | Trường hợp kiểm thử | Data Test | Các bước thực hiện | Môi trường | Công cụ test | Kết quả mong muốn (API, DB, MSG, Log) | Độ ưu tiên | Exec | Luồng ref |
+|:---|:---|:---|:---|:---|:---|:---|:---|:---:|:---:|:---|
+| **KB-{id}-10** | Idempotency: request trùng key chỉ tạo 1 giao dịch | Gửi cùng `Idempotency-Key` 2 lần | `fixture: valid_transfer` | (1) POST lần 1. <br> (2) POST lại cùng key. | Stag | RequestsLibrary | **API:** lần 2 trả HTTP 200 cùng `transferId` lần 1. <br> **DB:** bảng `transfers` chỉ 1 bản ghi. <br> **MSG:** chỉ 1 event `transfer.created`. | P0 | automate | Luồng chính |
+
+*(Bề mặt service KHÔNG có KHỐI GIAO DIỆN; oracle không chứa `UI:`.)*
+
+---
+
+### 5.3. Hướng dẫn Data & Environment Setup (E2E)
+
+> **Nguồn canonical:** dữ liệu mồi máy-đọc nằm ở `{id}_fixtures.yaml`. Mục này chỉ là bản tóm tắt người-đọc; khi lệch, `fixtures.yaml` thắng.
+
+Đặc tả các dữ liệu mồi, script hoặc cấu hình Mock API để chạy được SLICE này từ đầu đến cuối trên môi trường Staging:
+- {Biến 1} -> {Giá trị mẫu và pre-condition}  *(khớp `fixtures.yaml#fixtures[].key`)*
+
+**Tiền điều kiện automation:** các dòng `Exec=automate` cần `ui_schema_{id}.json` tồn tại để `/ntapp-qa-robot` lấy selector. Liệt kê file còn thiếu (nếu có) tại `fixtures.yaml#automation_prereq`.
+
+---
+
+### 5.4. Defect Management (Quy trình quản lý và báo cáo lỗi)
+
+#### 1. Quy chuẩn báo cáo lỗi E2E (Log bug lên Jira)
+- **Tiêu đề (Summary):** `[BUG][{id}] - {Mô tả lỗi E2E}`
+- **Các bước tái hiện (Steps to Reproduce):** Ghi rõ thao tác UI.
+- **Kết quả thực tế (Actual Result):** Mô tả lỗi trên giao diện hoặc phản hồi sai từ Backend.
+- **Kết quả kỳ vọng (Expected Result):** Hành vi E2E mong đợi.
+
+#### 2. Báo cáo tiến độ E2E (Test Run Progress Report)
+- **Tổng số kịch bản:** `{total_tcs}`
+- **Pass:** `{pass_tcs}` (`{pass_rate}%`)
+- **Fail:** `{fail_tcs}` (`{fail_rate}%`)
+- **Skip:** `{skip_tcs}`
+
+---
+
+### 5.6. Coverage Debt Ledger (Nợ độ phủ do spec gap)
+
+> Theo [explore_and_consistency_rules.md](../../principles/explore_and_consistency_rules.md) §3. Liệt kê mọi **bất biến bắt buộc đang nợ vì spec/contract còn `[TBD]`/gap** — case đã có dạng dòng `[BR]` scripted trong KHỐI 2/3 (không phải charter), expected neo theo contract canonical, hiện FAIL tới khi code đạt. Để không bị ru ngủ bởi "màu xanh automation". Khi gap/contract chốt (round-trip) → gỡ `[BR]`, xóa dòng nợ. Rỗng → ghi "Không có nợ coverage".
+
+| Bề mặt × Bất biến | Gap ID | Case @id ([BR]) | Q&A blocking | Trạng thái |
+|:---|:---|:---|:---|:---:|
+| {vd: Search merchant × filter-correctness} | GAP-{NN} | KB-SLICE-{id}-{NNN} | {mục Q&A trong qa_report} | Đang nợ |