@trungtamcongnghedigital/vsaf 1.0.0

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/principles/risk_based_allocation_rules.md

@@ -0,0 +1,118 @@
+# RISK-BASED ALLOCATION RULES — Phân bổ test theo rủi ro (School B, chế độ Hybrid)
+
+> **Mục đích:** Gán cho mỗi kịch bản 2 thuộc tính: **`@risk`** (P0/P1/P2) và **`@exec`** (automate/manual/exploratory),
+> để (a) tối ưu effort theo rủi ro thay vì phủ phẳng, (b) định tuyến sang automation.
+> Dùng ở [step-02b-risk-allocation.md](../steps/step-02b-risk-allocation.md), sau Step 02 (plan), trước Step 03 (write).
+>
+> **Triết lý Hybrid:** KHÔNG vứt bỏ phủ exhaustive. Có **2 mode**, chọn qua config `risk_mode` (Layer 3 `.bmm-config.yaml`,
+> mặc định `exhaustive`). `risk_mode` chỉ ảnh hưởng **độ bung số case**; việc gán `@exec` áp dụng cho **cả hai mode**.
+
+---
+
+## 1. Hai mode (Hybrid)
+
+| Mode | `risk_mode` | Hành vi bung case | Khi dùng |
+|---|---|---|---|
+| **Exhaustive** *(default)* | `exhaustive` | Giữ nguyên `cases_count` của mọi rule file (hành vi gốc skill). Không cắt case. | Regulated/audit, slice rủi ro cao, nghiệm thu cứng |
+| **Risk-gated** *(opt-in)* | `risk-gated` | Bung đủ cho P0/P1; với **P2 visual/display** chỉ giữ **smoke subset** (phần cắt = **drop hẳn**, KHÔNG đẩy charter) | Slice rủi ro thấp, cần nhanh, tinh thần modern QA |
+
+> Mode chỉ đổi **số lượng**; **không** đổi cấu trúc 3 khối, không đổi Iron Rules. Math Check Gate (R2) vẫn chạy:
+> ở `risk-gated`, số case kỳ vọng = `cases_count` đã trừ phần P2 bị cắt — phải **ghi rõ công thức trừ** ra chat (vd `46 − 9 (P2 zoom/responsive drop) = 37`).
+
+---
+
+## 2. Chấm `@risk` (Risk tier = cột "Độ ưu tiên")
+
+Risk = **Likelihood × Impact**, ánh xạ về 3 tier (giữ tương thích thang P0/P1/P2 sẵn có):
+
+| Tier | Định nghĩa | Ví dụ điển hình |
+|---|---|---|
+| **P0** | Luồng chính / Blocker / Sanity / mất tiền / phân quyền-ATTT | Tạo-lưu thành công E2E; IDOR; SQLi; luồng thanh toán |
+| **P1** | Luồng nhánh / biên / validation / lỗi do Backend spec | BVA maxlength; required-field; error path API |
+| **P2** | Hiển thị / visual / layout / điều hướng phụ | Zoom/responsive; focus order; tab navigation; tooltip |
+
+Nguồn để chấm: phần Tổng quan (nghiệp vụ), phần Logic (nhánh), khối testcase (UI/Functional/Security → security luôn ≥P1, thường P0).
+
+---
+
+## 3. Gán `@exec` (cổng automation) — áp dụng CẢ HAI mode
+
+Quyết định theo **khả năng assert tự động của oracle** + **bản chất khối**:
+
+| Điều kiện | `@exec` | `@target` | Lý do |
+|---|---|---|---|
+| Khối Functional/E2E có oracle `api`/`db`/`ui-deterministic` | `automate` | `robot` *(default)* | qa-robot assert được qua keyword + DB + request |
+| Khối Security tái lập bằng API (IDOR, tampering, authz, SQLi qua payload) | `automate` | `robot` | Postman→Robot requests |
+| Khối UI visual: zoom, responsive, focus order, màu/spacing, animation | `manual` | — | Automation giòn / cần mắt người |
+| Rủi ro timing/đồng thời/phiên/ngắt-giữa-chừng (double-submit, đa tab, session timeout, back-forward, mạng chập chờn, TOCTOU) | `automate`/`manual` **scripted trong KHỐI 2/3** | `robot` | **CẤM đẩy charter** — phân tích ra oracle xác định (đúng 1 bản ghi, 401/409, degraded=true...) rồi viết case scripted. Đa số là deterministic |
+| Vùng bất định cao (spec còn `[TBD]`, UX mới) | `automate`/`manual` **scripted trong KHỐI 2/3** | `robot`/— | KHÔNG hạ exploratory: viết case scripted với **expected = contract canonical** (dòng `[BR]`) hoặc `[TBD]` + Q&A; ghi Coverage Debt (§3 explore) — case KHÔNG bốc hơi khỏi coverage |
+| Oracle chính phải người phán đoán (nội dung, thẩm mỹ, trải nghiệm) | `manual` + `@manual-verify` | — | Cấm automation giả vờ phủ |
+
+**Quy tắc cứng:**
+- **`@exec` quyết định theo ASSERT-ABILITY (§3), KHÔNG theo tier/Khối:** case hiển thị có oracle **tất định** — placeholder, nhãn/label, default value, enable/disable state, control tồn tại, count "(N kết quả)", **message lỗi text** — là `automate` (`@oracle:ui`, qa-robot assert text/attribute/state). **CHỈ** visual thẩm mỹ (zoom, responsive, font/màu/spacing, focus order, animation) mới `manual`. ⚠️ CẤM xếp placeholder/label/default/message vào `manual` chỉ vì nó "thuộc Khối 1 UI".
+- Mỗi `@exec:automate` PHẢI có ≥1 `@oracle` trong {ui, api, db, msg} và một `@target`.
+- Tầng oracle KHÔNG tự động được (vd `Log:` cần soi tay) → vẫn ghi ở Then nhưng gắn `@manual-verify`; case vẫn có thể `automate` nếu còn oracle khác tự động.
+- **Mặc định KHÔNG dùng `@exec:exploratory`** và **KHÔNG tạo khối/charter exploratory riêng**. Mọi rủi ro — kể cả timing/đồng thời/phiên/UX mới/spec `[TBD]` — phải phân tích ra oracle rồi ghi thành **case scripted (`automate` hoặc `manual`) trong KHỐI 2 (Functional/E2E) hoặc KHỐI 3 (Security)**. `exploratory` chỉ được giữ cho **quan sát thẩm mỹ thuần không thể assert** (so màu/spacing/thiện cảm) và **nằm trong KHỐI 1 UI**, không sinh section riêng.
+- **P0 không bao giờ là `exploratory`** — luồng chính/ATTT phải có testcase tường minh (automate hoặc manual scripted).
+- **Oracle-first theo `surface_type`:**
+  - *(bề mặt `ui`)* **UI-first (CỨNG):** test được trên UI thì BẮT BUỘC drive qua UI (`@scr` + `@oracle:ui` + dòng `Then UI:`, cột Công cụ `Chrome`/`Chrome+Postman`). API-only (`Postman`, bỏ `@scr`) CHỈ khi hành vi không thể thao tác/quan sát qua UI (backend thuần: audit log, fan-out nội bộ, bypass FE). CẤM drive UI nhưng oracle backend-only.
+  - *(bề mặt `service` — no-UI)* **API-first (CỨNG):** dùng `@svc` + `@oracle:api` (hoặc `@oracle:db`/`@oracle:msg` khi job/consumer không trả HTTP), cột Công cụ `Postman`/`RequestsLibrary`. **CẤM `@oracle:ui`** và CẤM tag `@scr` (không có màn). Oracle nông "trả 200 là pass" bị cấm — phải assert body/schema + side-effect (xem [service_surface_rules.md §3](./service_surface_rules.md)).
+
+---
+
+## 4. Bảng chính sách tổng hợp (cheat-sheet)
+
+**Bề mặt `ui`:**
+
+| Khối \ Tier | P0 | P1 | P2 |
+|---|---|---|---|
+| **Functional/E2E** | automate (full) | automate (full) | exhaustive: automate(smoke) · risk-gated: smoke hoặc drop |
+| **Security/ATTT** | automate (full) | automate/manual (full) | hiếm |
+| **UI/Visual** | manual (sanity) | manual | exhaustive: manual(full) · risk-gated: manual(smoke) hoặc drop |
+
+**Bề mặt `service` (no-UI)** — không có khối UI/Visual; oracle `api/db/msg/log`:
+
+| Khối \ Tier | P0 | P1 | P2 |
+|---|---|---|---|
+| **Nghiệp vụ & E2E** (decision table, state machine, idempotency, side-effect API→DB→MSG) | automate (full) | automate (full) | exhaustive: automate(smoke) · risk-gated: smoke |
+| **Hợp đồng & Request Validation** (required/length/format/enum tầng payload) | automate | automate (full) | exhaustive: automate · risk-gated: cắt bớt SỐ case (per-case, data ở fixtures — KHÔNG gom Outline) |
+| **Phân quyền & ATTT** (IDOR, role/scope, injection, rò rỉ dữ liệu nhạy cảm) | automate (full) | automate/manual | hiếm |
+
+---
+
+## 5. Output của bước allocation
+
+Step 02b gán **policy per rule-group** (từ Math Forcing Step 02) — mỗi (control × rule) 1 dòng policy trong plan; Step 03 áp policy này xuống TỪNG dòng testcase khi bung (điền cột Độ ưu tiên + Exec). Định dạng policy per rule-group (default + ngoại lệ sub-split):
+```
+Tên hồ sơ × textbox-base   → P1 · automate · @oracle:ui  (trừ case hiển thị thuần placeholder/label/default = P2 · automate; KHÔNG manual)
+UI toàn màn × layout-visual → P2 · manual · @oracle:ui   (chỉ zoom/font/spacing/focus-order)
+Tạo hồ sơ × save-button    → P0 · automate · @oracle:ui,api,db (happy 201); nhánh lỗi = P1 · automate
+double-submit / session / degraded (KHỐI 2 · [BR]) → P0/P1 · automate · @oracle:db/api  (spec [TBD] → expected=canonical + Q&A + Coverage Debt)
+IDOR/SQLi/tampering (KHỐI 3) → P0 · automate · @oracle:api
+```
+> Không còn dòng `exploratory · charter:CH-xx`: rủi ro timing/đồng thời/phiên/[TBD] được viết thẳng thành dòng scripted KHỐI 2/3 với oracle xác định (chú thích `[BR]` nếu expected neo theo contract canonical mà code chưa đạt).
+Các annotation này là **đầu vào trực tiếp** để Step 03 sinh tag `@risk/@exec/@target/@oracle` trong `.feature` và cột `Exec` trong markdown — đảm bảo Sync Invariant (automation_contract_rules §1).
+
+---
+
+## 6. Rebalance ngân sách case (chống over-invest single-field / under-invest integration)
+
+Áp CẢ HAI mode. Không để validation single-field lặp nuốt hết ngân sách trong khi chiều tích hợp/behavior — nơi bug thật hay lọt — chỉ có 1 case nông.
+
+### 6.1 Validation lặp single-field — per-case, data ở fixtures (CẤM gom)
+Một trường có ≥2 case cùng-một-logic chỉ khác giá trị input (EP/EG/BVA/space/security) → viết **N `Scenario` riêng** trong `.feature`, mỗi case 1 `@id` (giữ R2 — [automation_contract_rules §1](./automation_contract_rules.md)). **CẤM `Scenario Outline`/`Examples`.** Chống trùng-lặp bằng cách để giá trị input ở `fixtures.yaml` (mỗi case 1 dataset), KHÔNG bằng cách gom scenario. Markdown liệt kê đủ mỗi case thành 1 dòng; count KHÔNG đổi.
+
+> **⚠️ Rebalance = quản ngân sách số case (`cases_count`), KHÔNG phải gom block.** N case cùng-logic → **N `@id` = N `Scenario`** (mỗi cái = 1 dòng `.md` `Exec=automate`), KHÔNG giữ 1 @id "đại diện" rồi bỏ phần còn lại. Rebalance chỉ điều tiết SỐ case giữa single-field vs integration, KHÔNG giảm @id, KHÔNG đổi cấu trúc thành Outline — kiểm bằng HARD CHECK cross-artifact [automation_contract_rules §1](./automation_contract_rules.md). Drop @id = vi phạm R2.
+
+### 6.2 Sàn chiều sâu integration (bắt buộc)
+Mọi chiều tích hợp/behavior có mặt trong slice là **P0/P1** (không P2, không bị risk-gated cắt); số case + độ sâu oracle theo ĐÚNG `cases_count` của rule nguồn, KHÔNG rút về 1 scenario nông:
+
+| Chiều | Rule nguồn | Oracle tối thiểu |
+|---|---|---|
+| Filter-correctness | [11-independent-filter](../references/kbkt-generation/11-independent-filter/independent-filter-rule.md) | khớp TỪNG bản ghi (Like/Equal), bản ghi không khớp vắng mặt |
+| Cross-actor visibility | [10-be/data-visibility](../references/kbkt-generation/10-be/data-visibility-rule.md) | ≥2 principal, phạm vi thấy theo scope/role |
+| Volume-boundary | [09-data-grid](../references/kbkt-generation/09-data-grid/grid-base-rule.md) | count > page size + > default framework |
+| Error-code → UI side-effect | [06-validation/error-response-behavior](../references/kbkt-generation/06-validation/error-response-behavior-rule.md) | hành vi UI đúng per mã lỗi |
+| Stale-state | [11-independent-filter](../references/kbkt-generation/11-independent-filter/independent-filter-rule.md) | danh sách khớp filter hiện tại sau xóa/đổi |
+
+CẤM chiều integration chỉ 1 case oracle "list hiển thị" / "không rỗng".

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/principles/run_mode_rules.md

@@ -0,0 +1,84 @@
+# RUN MODE RULES — 3 lane chạy + Context Ledger + batch-gate
+
+> **Mục đích:** Giảm ceremony, mở incremental, chống context-drift trên SLICE lớn — **mà không nới Iron Rules**.
+> Cùng một skill, 3 lane khác nhau ở *tần suất dừng người* (HITL) + *phạm vi reload tài liệu* + *điểm vào (entry)*.
+> Chất lượng (R1 zero-fabrication, R2 Math Check, R6 canonical-only, R8 ID liên tục, Sync Invariant 3 chiều) **enforce ở MỌI lane**.
+
+---
+
+## 1. Resolve `run_mode`
+
+Thứ tự ưu tiên (cao → thấp):
+1. **Ý định người dùng trong câu lệnh:** "chế độ nhanh / batch" → `batch`; "cập nhật / sửa label / chạy lại delta" → `delta`; "đầy đủ / governance / audit" → `full`.
+2. **Layer 3 `.bmm-config.yaml`** mục `ntapp-qa-generate-testcase:` key `run_mode`.
+3. **Auto-detect (chỉ gợi ý, không tự ép):** ở [Step 00](../steps/step-00-shiftleft-gate.md), nếu **đã tồn tại đủ 3 artifact** của `{id}` (`{id}_testspec.feature` + `{id}_detailed_test_manual_testcase.md` + `{id}_fixtures.yaml`) tại `{qa_artifacts}/{id}/` → **đề xuất** `delta` và hỏi 1 lần; người đồng ý mới vào delta.
+4. **Default = `full`** (backward-compat tuyệt đối: project cũ không khai `run_mode` → hành vi y như trước).
+
+---
+
+## 2. Ma trận 3 lane
+
+| Đặc tính | `full` *(default)* | `batch` | `delta` |
+|---|---|---|---|
+| **Khi dùng** | Slice mới quan trọng, cần governance/audit | Lặp nhanh, slice mới nhưng tin tay nghề, muốn ít gián đoạn | Re-run trên slice **đã có** 3 artifact (đổi unit / label / logic) |
+| **Entry point** | Step 00 → 01 → … | Step 00 → 01 → … | **Bỏ qua** 00/01/02 → vào thẳng [Step 05 Nhánh A](../steps/step-05-roundtrip.md) |
+| **HITL gate** | 4 (E2E flow + Plan + per-screen + finalize) | **2**: ① E2E flow (Step 01) ② Batch review *toàn bộ* testcase cuối (Step 04) | **0–1**: in delta-map chờ 1 OK rồi patch |
+| **Giữa các màn** | Dừng từng màn | **Auto-proceed** (không dừng) | n/a (chỉ chạm màn delta) |
+| **9 checkpoint (Step 02)** | Chạy + narrate đầy đủ | Chạy **im lặng**, chỉ in `X = Y` tổng hợp | Chỉ chạy trên màn bị ảnh hưởng |
+| **Reload tài liệu** | Per-screen reload đầy đủ | **Scoped reload** (Context Ledger + phần Giao diện màn hiện tại) | Chỉ tài liệu của delta |
+| **Số lần dừng (slice 20 màn)** | ~41 | ~2 | ~1 |
+
+> **Lưu ý ceremony:** `batch`/`delta` chỉ gộp/bỏ **HITL của người**, KHÔNG bỏ **internal checkpoint**. 9 chốt chặn [slice_planning_rules.md](./slice_planning_rules.md) vẫn chạy để giữ độ phủ; chỉ thôi narrate từng dòng.
+
+---
+
+## 3. Batch-gate (lane `batch`)
+
+- Phân biệt rõ 2 loại cổng:
+  - **HITL gate** = cần *người ký* (`RequestFeedback: true`, DỪNG).
+  - **Internal checkpoint** = self-audit của AI (Math Check, Sync Invariant, mapping rule) — *không* dừng người.
+- Ở `batch`: các HITL gate per-screen của [Step 03](../steps/step-03-write-testcase.md) **chuyển thành "defer"** — không dừng, ghi artifact rồi tự sang màn kế. Tích lũy đến hết màn cuối → **một** batch review ở [Step 04](../steps/step-04-finalize-testcase.md): in **bảng tổng hợp đầy đủ** (mọi màn, mọi `@id`, thống kê automate/manual/exploratory) + kết quả Sync Invariant, rồi mới `RequestFeedback: true` 1 lần.
+- **Guard bắt buộc:** trước khi mở batch review, **Math Check Gate (R2)** và **Sync Invariant 3 chiều** phải PASS toàn slice. Nếu lệch ở bất kỳ màn nào → **rớt về dừng-tại-màn-đó** (không cho silent-pass lỗi), báo màn lỗi ra chat.
+
+---
+
+## 4. Context Ledger (load-once — chống drift, giải reload dư)
+
+**Vấn đề:** Step 02/03 hiện ép "tải lại trọn bộ `_detailed_design`" *mỗi màn* → với 20+ màn, phần dùng chung bị đọc lại hàng chục lần. *(Lưu ý: thiết kế đã gộp về 1 file `_detailed_design.md` — "scoped reload" nghĩa là đọc theo **section/heading** cần trong file đó, KHÔNG mở lại toàn file mỗi màn.)* Cùng vấn đề xảy ra với **rule-library tĩnh** (`00-core/*` bắt buộc mọi màn + `01-ui/*` bắt buộc mọi màn FE theo [slice_planning_rules.md §4](./slice_planning_rules.md)) — nội dung các file này **không đổi theo màn**, nhưng nếu không cache thì bị `view_file` lại nguyên vẹn ở mỗi màn.
+
+**Cơ chế:** Tại [Step 01](../steps/step-01-init-slice.md), dựng **một** mục `## Context Ledger` trong `implementation_plan.md`, gom **fact + rule dùng chung toàn slice** (đọc 1 lần):
+- **Slice overview**: mục tiêu, danh sách unit + vai trò (Action/Verify/Nav).
+- **BE contract map**: endpoint / story-code / bảng DB mà nhiều màn cùng tham chiếu.
+- **(KHÔNG dùng Glossary nhãn dùng chung)** — nhãn cụ thể KHÔNG gom về Ledger; **mỗi màn tự liệt kê ĐẦY ĐỦ từng element ở Step 02 (Chốt 3)**. Ledger chỉ giữ luật **UI Text Source Map** (dưới đây) + Bảng Override cho nhãn phải-giống-cross-screen.
+- **UI Text Source Map** *(chống bịa text):* mọi chuỗi hiển thị (placeholder/label/option/message/tiêu đề) lấy **verbatim từ DD** (bảng control F-0x / wireframe / text DD trích) + cite `DD §/F-0x`. Generate **chỉ đọc DD + qa_report** (KHÔNG ui_schema/i18n/ux) → DD im lặng hoặc chỉ có i18n-key không kèm text → **`[TBD]`+Q&A**. Cấm cả **bịa** (text không có trong DD) lẫn **over-`[TBD]`** (hạ giá trị đang có trong DD, vd `"Tất cả"` ở F-01). **Label-vs-code drift** (DD stale, vd DD "Áp dụng"/"Cập nhật" nhưng code "Tìm kiếm"/"Thời gian tạo") design-time KHÔNG bắt được → thuộc **runtime**: qa-robot assert text render == expected.
+- **Core rules đã nạp**: `view_file` toàn bộ `00-core/*` (+ toàn bộ `01-ui/*` nếu slice có ≥1 FE unit) **một lần duy nhất**, ghi danh sách tên file đã nạp vào Ledger. Đây là rule-library cố định của cả slice, không phải fact riêng màn.
+
+**Per-screen (Step 02/03) — scoped reload:**
+- Reload **chỉ**: phần Giao diện của *riêng* màn hiện tại (nhãn + control cụ thể) + phần Logic/Dữ liệu của BE *trực tiếp* map màn đó + các file rule **đặc thù theo control của màn đó** (`02-input/*`, `03-selection/*`, `04-dynamic-form/*`, ... — tùy Bảng Mapping của màn).
+- Fact dùng chung → lấy từ **Context Ledger**, KHÔNG đọc lại `_detailed_design` của *mọi* BE.
+- **Rule dùng chung** (`00-core/*`, `01-ui/*`) → lấy từ mục "Core rules đã nạp" trong Ledger, KHÔNG `view_file` lại — chỉ cite tên file khi áp dụng. Chỉ `view_file` lại 1 file cụ thể nếu nội dung Ledger cho file đó bị nghi ngờ sai/thiếu.
+- **Anti-drift vẫn giữ:** Ledger là nguồn ổn định thay cho "đọc lại tất cả"; nếu màn hiện tại phát hiện mâu thuẫn với Ledger (fact hoặc rule) → cập nhật Ledger (1 dòng) và ghi chú, không reload toàn bộ.
+
+**Ngưỡng slice lớn:** nếu slice > 12 màn Action → Ledger ghi cảnh báo, khuyến nghị chunk sub-batch (xử lý 6–8 màn/đợt) hoặc tách slice. Không tự động tách.
+
+> Context Ledger áp dụng cho **mọi lane** (kể cả `full`) — nó chỉ thay "reload tất cả" bằng "reload có phạm vi", không bỏ bất kỳ tài liệu nào của *màn đang xử lý*.
+
+---
+
+## 5. Delta entry-mode (lane `delta`)
+
+- Điều kiện: 3 artifact của `{id}` đã tồn tại + input (SLICE / `_detailed_design`) đã đổi.
+- **Bỏ qua** Step 00/01/02/02b/03 ceremony; vào thẳng [Step 05 Nhánh A](../steps/step-05-roundtrip.md), theo [incremental_update_rules.md](./incremental_update_rules.md) §1:
+  1. So khớp theo `@id` + `@rule` + `@scr` → in **delta-map** (mục bị ảnh hưởng) ra chat.
+  2. Người xác nhận (1 OK) → patch đúng phần delta trên **cả 3 artifact**.
+  3. Chạy lại **Math Check (R2)** + **Sync Invariant 3 chiều** *toàn file*; ID không nhảy cóc (R8).
+  4. Đánh dấu `@regression` các case logic đổi → xuất tập regression chọn lọc.
+- **Fallback an toàn:** nếu delta phủ rộng (đổi >40% màn, hoặc đổi cấu trúc luồng E2E) → KHÔNG dùng delta; báo và chuyển về `full`/`batch` chạy lại có kiểm soát.
+
+---
+
+## 6. Bất biến chung (mọi lane)
+
+- Iron Rules R1/R2/R3/R6/R8 + Sync Invariant 3 chiều **không đổi** theo lane.
+- Triple-emit ([automation_contract_rules.md](./automation_contract_rules.md)) áp dụng như nhau; `emit_automation:false` (legacy) độc lập với `run_mode`.
+- Lane chỉ điều chỉnh **khi nào dừng người** và **đọc lại bao nhiêu**, KHÔNG điều chỉnh **độ phủ** hay **độ chính xác**.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/principles/service_surface_rules.md

@@ -0,0 +1,136 @@
+# SERVICE SURFACE RULES — Lập kế hoạch kiểm thử cho bề mặt KHÔNG-GIAO-DIỆN (API / service / job / consumer)
+
+> **Mục đích:** File này là **biến thể tầng-service** của [slice_planning_rules.md](./slice_planning_rules.md) (vốn dành cho bề mặt UI). Dùng khi một unit/bề mặt test **không có giao diện** — nghiệp vụ chỉ phơi ra qua API/hợp đồng, không qua màn hình. Áp cho `surface_type=service` (detect ở [step-00](../steps/step-00-shiftleft-gate.md) / [step-01](../steps/step-01-init-slice.md)).
+>
+> **Không thay Iron Rules.** R1 (zero-fabrication), R2 (zero-summarization), R3 (traceability), Math Check, Sync Invariant vẫn nguyên. File này chỉ đổi **đối tượng test** (endpoint/operation thay cho màn hình) và **tầng oracle** (api/db/log/msg thay cho ui).
+
+---
+
+## 0. Khi nào dùng file này (`surface_type=service`)
+
+> **⚠️ GATE QUAN TRỌNG — quyết định ở CẤP TEST-TARGET, không per-unit:** File này CHỈ áp khi **TOÀN BỘ test-target KHÔNG có màn hình nào** (`input_type=unit` trên 1 unit BE, hoặc slice thuần BE không chứa `SCR-*`/`WGT-*`).
+>
+> **Nếu target có ≥1 màn (slice UI): TUYỆT ĐỐI KHÔNG dùng file này cho các unit BE.** Trong slice UI, HUB/MPF/INT/PMT-EXT… là **backend của màn** — test E2E **tích hợp đi qua màn** (theo [slice_planning_rules.md](./slice_planning_rules.md)), BE được verify bằng **oracle API/DB nhúng trong testcase của màn** ([unit_classification_rules.md §3](./unit_classification_rules.md): BE map theo story-code; BE không map → Background). BE **KHÔNG** phải "service surface" độc lập, **KHÔNG** đứng riêng trong thứ tự E2E. Đây là luật "có UI thì tích hợp như cũ; không UI mới test API riêng".
+
+Đọc `_detailed_design` của unit. Xác định `surface_type=service` khi **KHÔNG có phần Giao diện** mô tả màn hình/control render được, và unit phơi nghiệp vụ qua một trong các dạng:
+
+| Dạng bề mặt service | Nhận diện trong DD | Ví dụ prefix WBS |
+|---|---|---|
+| **REST/HTTP endpoint** | mô tả method + path + request/response schema | HUB-*, MPF-*, INT-* |
+| **gRPC / SOAP operation** | operation + message contract | INT-* |
+| **Message consumer** | tiêu thụ topic/queue, xử lý event | HUB-*, INT-* |
+| **Message producer / outbox** | phát event/message ra hệ thống khác | HUB-*, INT-* |
+| **Batch / scheduled job** | chạy theo lịch/trigger, xử lý theo lô | MPF-*, HUB-* |
+| **Internal service method có hợp đồng** | method phơi qua contract nội bộ (không UI) | HUB-* |
+
+> Prefix WBS chỉ là **tín hiệu phụ**. Quyết định cuối dựa trên: DD có phần Giao diện render được không. `SCR-*`/`WGT-*` gần như luôn là `ui`; `HUB-*`/`MPF-*`/`INT-*` gần như luôn là `service` — nhưng nếu một `HUB-*` lại mô tả màn hình admin thì vẫn là `ui`, và ngược lại. **Đọc DD, không suy từ prefix.**
+
+Một bề mặt hỗn hợp (unit vừa có màn admin vừa phơi API độc lập) → tách 2 bề mặt: chạy nhánh `ui` cho phần màn, nhánh `service` cho phần API. KHÔNG gộp.
+
+---
+
+## 1. Phân loại vai trò unit (service) — analog Action/Verify/Nav
+
+Thay bộ nhãn UI (`[Action]`/`[Verify]`/`[Nav]`) bằng bộ nhãn service:
+
+- **`[Operation]`** (operation/endpoint chính đang test): chạy đầy đủ vòng lặp Step 02 → Step 03. Là đối tượng test chính.
+- **`[Effect]`** (đích side-effect để xác minh): bảng DB, bút toán ledger, outbox/event phát ra, audit log, trạng thái được chuyển. **KHÔNG chạy Step 02-03 riêng**; nhúng thành **oracle** (`@oracle:db`/`@oracle:log`/`@oracle:msg`) trong testcase của `[Operation]` gây ra nó.
+- **`[Downstream]`** (đối tác/service khác mà operation này GỌI đi): core-banking, payment gateway, service nội bộ khác. **KHÔNG chạy Step 02-03 riêng**; đưa vào Precondition + khai báo **mock/stub** trong `fixtures.yaml#environment.mocks`. Vẫn phải `list_dir` liệt kê tài liệu (`_detailed_design`/integration spec) của nó; thiếu → thông báo rõ.
+
+> Với `input_type=unit` no-UI: unit `{id}` mặc định `[Operation]`. Các bảng/event/log nó tác động là `[Effect]`; các service nó gọi là `[Downstream]`.
+
+---
+
+## 2. Quy trình lập plan service (9 Chốt chặn — analog slice_planning §1)
+
+Giữ nguyên đánh số 9 chốt để đồng bộ với [step-02](../steps/step-02-plan-screen.md); chỉ đổi nội dung theo tầng service.
+
+1. **Nạp trí nhớ E2E:** Xác định operation/endpoint hiện tại từ `implementation_plan.md` + **Context Ledger**. (Với unit đơn: chính `{id}`.)
+
+2. **Nạp tài liệu thiết kế (SCOPED RELOAD):** `view_file` phần **Logic + Dữ liệu + Hợp đồng API** của `_detailed_design` operation hiện tại và các `[Downstream]` trực tiếp. **KHÔNG có phần Giao diện để đọc.** Fact dùng chung lấy từ Context Ledger.
+
+3. **Lập Bảng Hợp đồng (Contract Map) — thay "Ánh xạ Nhãn UI":** Trích từ DD, không bịa (R1). Với mỗi operation:
+   - **Request contract:** danh sách field (tên, kiểu, `required?`, ràng buộc: range/length/format/enum), header bắt buộc (auth, `Idempotency-Key`…), path/query param.
+   - **Response contract:** schema thành công + mã HTTP; schema lỗi.
+   - **Error catalog:** liệt kê **mọi mã lỗi nghiệp vụ** DD khai (mã lỗi + HTTP status + điều kiện kích hoạt). Thiếu định nghĩa → `[TBD]` + Q&A.
+   - **Side-effects (`[Effect]`):** bảng/cột DB ghi, trạng thái chuyển, event/message phát, audit log ghi.
+   - **State machine (nếu có):** tập trạng thái + transition hợp lệ (vd `INIT → PENDING → SUCCESS/FAILED → REVERSED`).
+   - Ghi Contract Map vào `implementation_plan.md` (thay cho "Nhật Ký Đọc File" + ánh xạ nhãn).
+
+4. **Lập Bảng Mapping Rule (tầng service):**
+   - **Core (luôn có):** `00-core/*` — đánh dấu "đã nạp qua Context Ledger".
+   - **Backend (luôn có với service):** `10-be/backend-resilience-rule.md` + `10-be/data-visibility-rule.md` — service surface **luôn** áp (không như UI chỉ áp khi có gọi API).
+   - **Request-field validation (tái dùng rule input ở TẦNG REQUEST-BODY, KHÔNG phải control UI):** với mỗi field request có ràng buộc, map sang rule tương ứng nhưng diễn giải ở tầng payload:
+     - bắt buộc → `02-input/required-field-rule.md` (thiếu field → 400/422, KHÔNG phải "viền đỏ").
+     - độ dài → `02-input/maxlength-rule.md` (BVA N-1/N/N+1 trên giá trị gửi lên; bỏ phần "đọc attr DOM maxlength" — không có DOM).
+     - format/regex/kiểu → `02-input/textbox-base-rule.md` phần định dạng (bỏ phần thao tác gõ/space UI thuần; giữ trim/space-handling nếu server chuẩn hóa).
+     - injection/payload độc → `02-input/security-input-rule.md` ở tầng API (SQLi/oversized body/type-confusion).
+     - enum/giá trị-cho-phép → `03-selection/*` phần **allowed-values** (giá trị ngoài whitelist → lỗi), BỎ hành vi combobox/render UI.
+   - **Validation nghiệp vụ:** `06-validation/duplicate-data-rule.md`, `06-validation/error-response-behavior-rule.md` ở tầng API (mã lỗi + status + side-effect DB, thay "toast").
+   - **KHÔNG áp (đánh dấu N/A, 0 case):** `01-ui/*`, `02-input` phần thao tác bàn phím/space thuần-UI, `03-selection` phần render dropdown, `04-dynamic-form/*`, `datepicker`/`file-upload` phần widget UI, `09-data-grid` phần hiển thị bảng — **trừ khi** operation là query/list endpoint (khi đó lấy phần *logic phân trang/filter* của `09`/`11` ở tầng response, bỏ phần render).
+   - **[!CAUTION] Dynamic Data Gate — vẫn BẮT BUỘC (workflow Quality Gate 3b):** quét field request là khóa tra cứu (FK/lookup do hệ thống khác cấp) hoặc `UNIQUE`/`PK` → `view_file` [dynamic_data_rules.md](./dynamic_data_rules.md), phân Tier, ghi `source_id`. Service surface **dễ dính** vì payload hay chứa mã do backend cấp (subId, merchantCode, transactionRef). CẤM hardcode.
+
+5. **Đọc Rule kiểm thử (PRE-FLIGHT GATE):** `view_file` từng rule per-operation chưa có trong Ledger (10-be/*, 06-validation/*, và các input-rule được map ở tầng request).
+
+6. **Tính số lượng case (Deterministic):** tổng case = cộng các nguồn dưới (đọc `cases_count` header rule, không đếm tay):
+   - **Request validation:** mỗi field × các rule áp cho field đó (ở tầng request-body).
+   - **Business logic / Decision Table:** vẽ bảng quyết định cho logic rẽ nhánh; mỗi dòng = 1 case (tổ hợp > 30 dòng → script `allpairspy`, như UI).
+   - **State machine:** mỗi transition **hợp lệ** = 1 case; mỗi transition **KHÔNG hợp lệ phải bị chặn** = 1 case (rule tài chính: cấm set status tự do).
+   - **Error catalog completeness:** mỗi mã lỗi trong catalog (chốt chặn 3) = ≥1 case kích hoạt → assert đúng HTTP status + error body + **side-effect đúng** (0 row / bút toán đảo khi lỗi).
+   - **Idempotency / dedupe** (BẮT BUỘC nếu operation ghi giao dịch tiền hoặc là consumer): gửi trùng `Idempotency-Key`/message id → assert **đúng 1** side-effect, lần 2 trả kết quả lần đầu, KHÔNG xử lý lại.
+   - **Resilience (10-be):** timeout downstream, circuit breaker, retry-safety, partial failure → theo `cases_count` của `backend-resilience-rule`.
+   - **Data-visibility / scope:** phạm vi dữ liệu theo owner/role → theo `data-visibility-rule`.
+   - **AuthZ/IDOR:** ownership check + role check (xem §4 dưới).
+
+7. **Tự đối soát (Self-Reflection):** bao phủ tổ hợp đa điều kiện + **đối chiếu error catalog** (mọi mã lỗi có case? mọi transition invalid bị chặn?).
+
+8. **Bung testcase 3 nhóm (reframe cho service — KHÔNG checklist vào plan; theo slice_planning Chốt 8):**
+   - **Nhóm 1 — Hợp đồng & Request Validation:** mọi field request × rule validation của nó (required/length/format/enum/injection) → mỗi case = 1 dòng testcase (bung ở Step 03). Bao gồm conformance schema/HTTP status của happy-path.
+   - **Nhóm 2 — Nghiệp vụ & E2E (API → DB → downstream/event/audit):** mọi dòng Decision Table, mọi transition state machine, mọi mã error catalog + side-effect, idempotency/dedupe, resilience. **Mỗi dòng Decision Table/transition/error-code ánh xạ 1-1 thành 1 dòng testcase, cấm gộp.**
+   - **Nhóm 3 — Phân quyền & ATTT:** IDOR/ownership, role/scope, injection, **rò rỉ dữ liệu nhạy cảm trong response/log** (PAN/OTP/token/mật khẩu — theo rule tài chính, cấm log thô).
+   - Quy tắc Zero-Summarization + công thức phân rã toán học + không lộ mã hệ thống trong nội dung (dùng tên nghiệp vụ, ID chỉ ở phần `rule:`/`Ref:`) — **giữ nguyên như [slice_planning_rules.md §1.8](./slice_planning_rules.md)**.
+
+9. **Ghi & Duyệt Plan (HITL GATE):** append vào `implementation_plan.md` theo [plan_template.md](../references/templates/plan_template.md) (dùng phần Contract Map thay Bảng UI Controls). Dừng/defer theo `run_mode` — [run_mode_rules.md §3](./run_mode_rules.md).
+
+---
+
+## 3. Oracle service (API-first) — thay quy tắc UI-first
+
+Bề mặt `service` KHÔNG có `@oracle:ui`. Thứ tự ưu tiên oracle và prefix Expected result:
+
+```
+API: <HTTP status + response body/schema>   →  @oracle:api
+DB:  <trạng thái/row/bút toán sau xử lý>     →  @oracle:db
+MSG: <event/message phát ra outbox/topic>    →  @oracle:msg
+Log: <audit trail append-only>               →  @oracle:log
+```
+
+- Mỗi mục test được ở tầng service **BẮT BUỘC có `@oracle:api`** (hoặc `@oracle:db`/`@oracle:msg` khi là job/consumer không trả HTTP). CẤM oracle nông kiểu "gọi API trả 200 là pass" — phải assert **body/schema + side-effect** (§1 explore: oracle phủ định bất biến).
+- `Công cụ test` (cột markdown) = `Postman` / `RequestsLibrary` (API), KHÔNG `Chrome`.
+- Tag surface: dùng **`@svc:<unit_id>`** thay cho `@scr:<unit_id>` (xem [automation_contract_rules.md §2](./automation_contract_rules.md)).
+
+---
+
+## 4. Surface Inventory (service) — reframe explore §2 cho tầng API
+
+Áp ở [step-02b](../steps/step-02b-risk-allocation.md). Thay bảng bề mặt UI bằng bảng bề mặt service:
+
+| Loại bề mặt service | Nhận diện | Bất biến BẮT BUỘC | Data đối nghịch phải seed |
+|---|---|---|---|
+| **Write op (create/update)** | endpoint ghi | **error-side-effect:** mỗi mã lỗi → HTTP status đúng + error body đúng + **DB 0 row / bút toán đảo** khi lỗi | tái lập từng nhánh lỗi: duplicate/conflict (409), validation (400/422), business-rule (422) |
+| **Money op** | ghi giao dịch tiền / số dư | **rounding+scale đúng, currency khớp, không âm quỹ, không double-spend** khi 2 request song song | biên: 0, âm, max, scale lẻ, currency không thập phân; 2 request đồng thời |
+| **Idempotent write / consumer** | có `Idempotency-Key` / tiêu thụ message | **dedupe:** request/message trùng → đúng 1 side-effect, lần 2 trả kết quả cũ | gửi trùng key/message id ≥2 lần |
+| **Query / list endpoint** | trả danh sách | **filter-correctness** (mọi record khớp điều kiện, record không khớp vắng mặt, `count==kỳ vọng`) + **volume/pagination** (> page size không im lặng cắt) | ≥1 khớp + ≥2 không khớp; seed > page size |
+| **Có phân quyền/scope** | dữ liệu theo owner/role | **cross-actor:** principal A không truy được resource của B (IDOR → 403/404 theo spec) | seed data ≥2 owner; gọi bằng token khác chủ |
+| **State-changing** | chuyển trạng thái bản ghi | **state-machine:** transition hợp lệ đúng; transition KHÔNG hợp lệ bị chặn (không set status tự do) | đưa bản ghi về từng trạng thái rồi thử transition sai |
+| **Gọi downstream** | call đối tác/core-banking | **resilience:** timeout → PENDING/UNKNOWN (không tự đoán success), circuit breaker mở, retry chỉ khi idempotent | mock downstream: timeout / 5xx / trả sai schema |
+
+Đối soát gate (explore §2.2): in bảng `<bề mặt service> × <bất biến> → <@id | THIẾU>`. Còn `THIẾU` → bổ sung case (hoặc TBD-escape §3) trước khi sang Step 03.
+
+---
+
+## 5. Bridge sang qa-robot (API — vẫn theo POM)
+
+- Với dòng `@exec:automate` bề mặt `service`, `/ntapp-qa-robot` sinh keyword bằng **RequestsLibrary** (hoặc client tương đương) — **vẫn tổ chức theo POM**: mỗi endpoint/operation là một "service object" (resource file đóng vai page-object), keyword = thao tác gọi + assert contract, tách khỏi test case như POM tách locator.
+- Service surface **KHÔNG cần `ui_schema_{id}.json`** (không có selector). Thay vào đó `fixtures.yaml#automation_prereq` khai: `base_url`, `auth` (cách lấy token), `api_contract` (tham chiếu phần Hợp đồng trong DD/OpenAPI nếu có), `mocks` (các `[Downstream]` cần stub).
+- Do đó Rule 6 pre-commit (thiếu `ui_schema` chặn) **không áp** cho code test service — nêu rõ ở Mục 5.3.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/principles/slice_planning_rules.md

@@ -0,0 +1,54 @@
+# SLICE PLANNING RULES — Quy tắc lập Kế hoạch Kiểm thử Màn hình
+
+> **Mục đích:** Quy định chi tiết các bước lập kế hoạch test plan cho màn hình hiện tại (Step 02).
+>
+> **Phạm vi bề mặt:** File này là biến thể **`ui`** (9 chốt chặn cho bề mặt có màn hình). Bề mặt **`service`** (không giao diện) dùng 9 chốt chặn tương ứng tại [service_surface_rules.md §2](./service_surface_rules.md) — Contract Map thay Ánh xạ Nhãn UI, rule 10-be + request-validation tầng payload thay rule control UI.
+>
+> **Áp dụng cả 2 lane:** File này là quy trình **per-screen** — chạy đầy đủ 9 chốt chặn cho TỪNG màn, cả lane `slice` (nhiều unit → nhiều màn) lẫn lane `unit` (các màn của chính `{id}`). KHÔNG skip. Chốt 2 (exit points → màn đích) và phân định Action-Verify ở lane `unit` thu về phạm vi nội bộ của `{id}` (màn ngoài `{id}` là "Out of scope", chỉ verify chuyển hướng — theo [unit_classification_rules.md §4](./unit_classification_rules.md)).
+
+---
+
+## 1. Quy trình Thực hiện (9 Chốt chặn)
+
+1. **Nạp trí nhớ E2E:** 
+   - Đọc `implementation_plan.md` để xác định màn hình/widget hiện tại và các BE unit liên quan.
+2. **Nạp tài liệu thiết kế (FETCHING GATE — SCOPED RELOAD):** Theo [run_mode_rules.md](./run_mode_rules.md) §4:
+   - Đọc phần Giao diện (+ Logic/Dữ liệu khi cần) của FE *màn hiện tại*.
+   - Đọc phần Logic/Dữ liệu của các BE *trực tiếp* map màn này. Fact dùng chung (overview, BE contract map) lấy từ **Context Ledger** (đã dựng ở Step 01); **nhãn UI cụ thể do màn tự map đầy đủ ở Chốt 3** (không có glossary chung). KHÔNG đọc lại toàn bộ `_detailed_design` của *mọi* BE mỗi màn.
+   - Nếu màn hiện tại mâu thuẫn với Ledger → cập nhật 1 dòng vào Ledger + ghi chú (không reload toàn bộ).
+   - Quét tất cả exit points (các nút làm thoát màn như Submit, Hủy, Quay lại) và xác định màn hình đích tương ứng (theo [unit_classification_rules.md §4](./unit_classification_rules.md)).
+3. **Ánh xạ Nhãn Hiển Thị (LIỆT KÊ ĐẦY ĐỦ TỪNG ELEMENT — KHÔNG gom glossary chung):** 
+   - Điền "Nhật Ký Đọc File".
+   - Tra cứu phần Giao diện (`_detailed_design`) để ánh xạ chính xác `biến_kỹ_thuật` -> **Nhãn hiển thị UI (UI Label)** thực tế.
+   - **BẮT BUỘC liệt kê ĐẦY ĐỦ MỌI element của màn** (cấm "tương tự"/bỏ sót): từng control (input/checkbox/button…), tiêu đề/nhãn, placeholder, cột bảng, empty-state, banner, dialog xác nhận, toast, inline-error — mỗi chuỗi **verbatim từ DD + cite**. Đây là nguồn để Step 03 bung testcase → **thiếu element = thiếu testcase**. Chuỗi DD im lặng → `[TBD]` + Q&A (không bịa). Nhãn phải-giống-cross-screen lấy từ Bảng Override (Step 00 §1a), KHÔNG glossary Ledger.
+   - **Bề mặt mượn:** biên liệt kê = **cụm hành động** trong Delta Manifest (vẫn ĐẦY ĐỦ mọi element của cụm — không giảm độ sâu). Ghi 1 dòng `Base screen: OUT — host {slice}`; **CẤM** liệt kê element của màn host ngoài cụm ([borrowed_surface_rules.md §6](./borrowed_surface_rules.md)).
+4. **Lập Bảng Mapping Rule:**
+   - Đọc chỉ mục `references/kbkt-generation/`.
+   - **Ràng buộc Rule lõi (Core):** Luôn đưa các file trong `00-core/` (`test-coverage-checklist-rule.md`, `test-design-techniques-rule.md`, `e2e-traceability-rule.md`) vào Bảng Mapping — đánh dấu **"đã nạp qua Context Ledger"** (nạp 1 lần ở Step 01, xem [run_mode_rules.md §4](./run_mode_rules.md)), KHÔNG `view_file` lại ở đây.
+   - **Ràng buộc Rule Backend (BE):** Phân tích tài liệu thiết kế (`_detailed_design`) và SLICE. Nếu màn hình/chức năng có tiêu thụ API Backend, tương tác DB hoặc Cache -> đưa `10-be/backend-resilience-rule.md` vào Bảng Mapping và kích hoạt áp dụng (10 cases). Nếu là màn hình tĩnh/view-only không gọi API Backend -> đánh dấu không áp dụng, 0 cases. (File này thuộc rule lõi core, cũng lấy từ Ledger, không phải per-screen — chỉ *quyết định áp dụng hay không* là per-screen.)
+   - **Ràng buộc Rule UI:** Nếu là FE Unit, bắt buộc đưa toàn bộ 4 file trong `01-ui/` vào Bảng Mapping — cũng đánh dấu **"đã nạp qua Context Ledger"**, không `view_file` lại mỗi màn. **Bề mặt mượn:** `screen-default-display` → N/A **0 case**; `layout-visual`/`keyboard-navigation`/`responsive-zoom` áp **cho modal/banner của cụm**, không cho màn host; `09-data-grid`/`11-independent-filter` N/A nếu grid/filter thuộc host.
+   - **[!CAUTION] Ràng buộc Dynamic Data — GATE RIÊNG, KHÔNG ĐƯỢC GỘP VÀO BẢNG MAPPING RULE UI (workflow.md Quality Gate 3b):** Trước khi rời Chốt chặn 4, quét TOÀN BỘ control của màn tìm dấu hiệu Runtime-dependent — nhận diện qua: (a) filter/search gọi sang service/API khác để lấy danh sách, (b) checkbox/lựa chọn hiển thị dữ liệu lấy từ response của 1 unit khác (không phải hardcode trong UI), (c) field dùng làm khóa tra cứu (ID/mã) do hệ thống khác cấp phát, (d) field có ràng buộc UNIQUE/PRIMARY KEY ở DB. Có ít nhất 1 dấu hiệu thì BẮT BUỘC view_file đọc [dynamic_data_rules.md](./dynamic_data_rules.md) NGAY (không trì hoãn sang Step 03) và chạy thuật toán §2 để xác định Tier (0-Reuse/1-Seed API/2-Query DB/3-Insert DB/Unresolved) cho từng field trước khi sang Chốt chặn 6. Ghi kết quả phân loại (field, Tier, source_id) vào implementation_plan.md cùng Bảng Mapping Rule. Đã có Bảng Mapping Rule cho control UI KHÔNG có nghĩa là đã xong bước này — đây là 2 gate độc lập; bỏ sót gate này là nguyên nhân phổ biến khiến fixtures.yaml (Step 03) hardcode ID/mã tra cứu không có thật trong môi trường test.
+   - Khớp các control cụ thể của màn với rule tương ứng (ví dụ: Textbox -> `02-input/textbox-base-rule.md`) — đây là rule **per-screen thật** (phụ thuộc control màn có gì), luôn cần nạp mới.
+5. **Đọc Rule kiểm thử (PRE-FLIGHT GATE):**
+   - **RÀNG BUỘC:** Gọi tool `view_file` cho từng file Rule trong bảng Mapping **CHƯA có trong "Core rules đã nạp" của Context Ledger** (tức các file per-screen: `02-input/*`, `03-selection/*`, `04-dynamic-form/*`, `05-dependent-filter/*`, `06-validation/*`, `07-save-cancel/*`, `09-data-grid/*`, `10-be/*`, `11-independent-filter/*` — tùy control của màn). File `00-core/*`/`01-ui/*` đã có trong Ledger thì cite tên, KHÔNG `view_file` lại.
+6. **Tính toán số lượng case:**
+   - Vẽ Bảng Quyết Định (Decision Table) cho các logic rẽ nhánh phức tạp.
+    - **Cartesian Product & Decision Table (Vẽ Ma Trận Tổ Hợp):** Đối với các logic kết hợp phức tạp, rẽ nhánh IF-THEN, hoặc logic giao thoa dữ liệu (Multi-Source / Cross-System / Cross-Partner), bạn BẮT BUỘC phải vẽ Bảng Quyết Định (Decision Table) rõ ràng ngay trong bản Test Plan này.
+      - **[GATE multi-source]** Bề mặt gom dữ liệu từ ≥2 nguồn (đọc từ dependency map của màn) → Bảng PHẢI mở đầu bằng Cartesian **các nguồn đó × {0,1,M}**; thiếu ma trận nguồn = Chốt 6 chưa xong. Nhánh nghiệp vụ/lỗi là chiều orthogonal, không thay thế. Tên nguồn lấy runtime — KHÔNG hardcode (portability). **Bề mặt mượn:** GATE này **không** áp cho ma trận thuộc unit của host slice (vd ma trận trạng thái tổng do unit aggregation của host tính) — chỉ assert **transition đại diện** do delta sinh ra; ma trận đầy đủ → 1 dòng Coverage Debt trỏ host slice.
+      - **Tổ hợp nhỏ (≤ 30 dòng):** Bảng phải vét cạn tổ hợp Tích Đề-các (Cartesian Product) theo đúng kỹ thuật Cross-Source Combinatorial Testing: bao phủ mọi tổ hợp mức chọn của TỪNG nguồn màn gom, mỗi nguồn mức `0` (không chọn) / `1` (chọn 1) / `M` (chọn nhiều).
+      - **Tổ hợp lớn (> 30 dòng):** Được phép áp dụng chiến lược **Pairwise Testing (All-Pairs)** hoặc **Business-Critical** để tối ưu hóa và giảm số lượng kịch bản.
+      - **Quy tắc sinh Pairwise:** **CẤM TUYỆT ĐỐI** tự tính toán pairwise thủ công. Bạn **BẮT BUỘC** phải viết một script Python sử dụng thư viện `allpairspy` (cài đặt qua `pip install allpairspy` nếu hệ thống chưa có), định nghĩa đầy đủ các dimensions, values và constraints (ràng buộc loại trừ), sau đó thực thi script để xuất ra bảng ma trận Markdown chính xác nhất.
+      - Tuyệt đối KHÔNG được tự ý viết tắt, lược bỏ hay gộp chung các dòng tổ hợp trong bảng. Bảng này tuyệt đối KHÔNG dùng để liệt kê các validation trường đơn giản. Nếu không có ma trận tổ hợp đầy đủ (Cartesian hoặc Pairwise được sinh từ script), User sẽ Reject. Quy định này là bắt buộc cho màn hình có đặc điểm logic tương tự.
+   - **Quy tắc tính số lượng kịch bản xác định (Deterministic Calculation):** Tổng số lượng testcase bắt buộc phải bằng tổng số lượng kịch bản thực tế của tất cả các file rule được nạp cộng lại. **[BẮT BUỘC]** AI phải đọc trực tiếp metadata header `cases_count` trong frontmatter của từng file rule được nạp để lấy số lượng testcase chính xác của rule đó, cấm tự ý đếm thủ công gạch đầu dòng. Với mỗi trường dữ liệu/control, số lượng kịch bản của nó phải bằng tổng số kịch bản của các quy tắc áp dụng cho trường đó (ví dụ: Tên hồ sơ bắt buộc = textbox-base (21) + required-field (5) + maxlength (6) + security-input (7) + space-handling (7) = 46 cases). Cấm tự ý bịa thêm hoặc làm tròn số lượng.
+   - **Quy tắc tính số lượng kịch bản Chức năng (Nhóm 2):** Số lượng kịch bản Chức năng bắt buộc phải bằng: `[Số lượng dòng trong Ma Trận Quyết Định] + [Số lượng kịch bản nghiệp vụ đặc thù mô tả trong specs FE/BE]`.
+7. **Tự đối soát (Self-Reflection):**
+   - Đánh giá việc bao phủ tổ hợp dữ liệu.
+8. **Chốt chặn 8 — KHÔNG sinh checklist vào plan (ĐÃ BỎ):**
+   - `implementation_plan.md` **KHÔNG** chứa section "Checklist Kiểm Đếm" / danh sách `[ ]`. `X` (tổng số case dự kiến) đã có sẵn ở **Chốt chặn 6 (Math Forcing)** — KHÔNG tạo lại dưới dạng checklist.
+   - **Materialize 1-1** mỗi rule-case (và mỗi dòng Ma Trận Quyết Định Chốt 6) thành **1 dòng testcase độc lập** thực hiện ở [Step 03](../steps/step-03-write-testcase.md), KHÔNG ở plan (tránh bung dòng 2 lần).
+   - **Bề mặt mượn:** `X` = Σ(rule-cases × control delta) + Σ(case BE của `units:`); **control màn host = 0**. Không lặp verify của host slice.
+   - **Phân định Action-Verify (ghi 1 dòng trong plan, áp khi bung ở Step 03):** Màn trước → kịch bản verify màn đích đưa vào Kết quả mong muốn của hành động; Màn sau → chỉ đếm hành động nội tại (lọc/tìm/phân trang), không lặp verify màn trước.
+   - **[HARD CHECK — grep-able] Không lộ mã nội bộ (định nghĩa dùng cho Step 03 §10b):** mỗi dòng testcase viết bằng NHÃN hiển thị End-User, CẤM mã control/field/section/mode/unit (`SCR-*`/`WGT-*`/`HUB-*`, `A1`,`B1`,`F-01`..`F-08`,`T-01`..`T-07`,`N-0x`,`H-0x`,`D1`-`D4`,`E1`-`E3`,`C1`, `Section A-F`, `Mode A-B`, `BR_*`). Ngoại lệ: bảng "Danh sách UI Controls" (legend) + ref cuối dòng. **Lệnh quét (Step 03 chạy trên file markdown testcase, phải = 0 trên dòng testcase):** `grep -E '^(- \[ \]|\| \*\*KB)' <file> | grep -E '\b(F-0[1-8]|T-0[1-7]|N-0[1-4]|H-0[12]|A[12]|B[123]|C1|D[1-4]|E[1-3]|F[12])\b|Section [A-F]|Mode [A-B]|BR_'` (mã trong lệnh là mẫu — chỉnh theo DD dự án).
+9. **Ghi và Duyệt Plan (HITL GATE):**
+   - Append kế hoạch vào `implementation_plan.md` theo mẫu tại **[references/templates/plan_template.md](../references/templates/plan_template.md)**.
+   - **Dừng/defer theo `run_mode`** — áp [run_mode_rules.md §3](./run_mode_rules.md) (`full` = dừng duyệt; `batch` = defer, 9 chốt chạy im lặng, gộp Step 04; Math Check lệch → rớt về dừng-tại-màn).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/principles/testcase_generation_gates.md

@@ -0,0 +1,76 @@
+# TESTCASE GENERATION GATES — Các chốt chặn khi sinh kịch bản chi tiết
+
+> **Mục đích:** Quy định các chốt chặn đối soát tự động khi bung Math Forcing (Step 02) thành bảng 11 cột + triple-emit (Step 03).
+
+---
+
+## 1. Các Chốt Chặn Bắt Buộc
+
+### 1.1. PHASE 1: PRE-FLIGHT LOAD (Nạp dữ liệu trước khi sinh)
+1. **Format & Template:** Gọi `view_file` đọc `references/kbkt-generation/00-core/kbkt-format-rule.md` và `references/templates/slice_testcase_table_template.md`.
+1b. **GATE Plan-exists (per màn/operation):** Trước khi sinh dòng testcase đầu tiên của màn/operation `{SCR-ID}` hiện tại, xác nhận section Step 02 của **chính `{SCR-ID}` đó** ở `implementation_plan.md` đã có **Math Forcing** (phân rã control × rule + **tổng `X`**) và **policy `@risk/@exec` per rule-group** (Step 02b). **In `plan({SCR-ID}): X={math}`**. Thiếu section / thiếu `X` / thiếu policy → **DỪNG**, quay lại [Step 02](../steps/step-02-plan-screen.md) + 02b lập cho màn này. Step 03 bung ĐỦ `X` dòng testcase 1-1 (plan KHÔNG còn ≥X dòng `[ ]`). Mỗi màn (kể cả 2+) BẮT BUỘC có plan Step 02 riêng — CẤM gộp Step 02→03 hay ghi tắt "lấy từ bảng"; "output dài" không phải lý do bỏ bước (quá dài → chia nhiều lần ghi).
+2. **Reload Context:** Tải lại các phần liên quan (Tổng quan/Logic/Dữ liệu/Giao diện) trong `_detailed_design` của FE hiện tại và BE liên quan để chống trôi bộ nhớ.
+3. **Name Mapping:** *(bề mặt `ui`)* dùng chính xác tên hiển thị đã chốt trong phần Giao diện (`_detailed_design`) · *(bề mặt `service`)* dùng chính xác tên field request/response từ Contract Map (Step 02, [service_surface_rules.md §2.3](./service_surface_rules.md)) — không có nhãn UI.
+4. **Nạp Rule:** Gọi `view_file` đọc toàn bộ các file Rule kiểm thử đã liệt kê ở Step 02.
+4b. **Đối chiếu Dynamic Data Gate (BẮT BUỘC — không phải tùy chọn):** Xác nhận Step 02 đã chạy [dynamic_data_rules.md](./dynamic_data_rules.md) §2 cho mọi field Runtime-dependent trong màn hiện tại (workflow.md Quality Gate 3b). Nếu Step 02 bỏ sót (vd Plan chỉ có Bảng Mapping Rule UI mà không có bảng phân loại Tier) → **DỪNG NGAY**, quay lại chạy `dynamic_data_rules.md` trước khi viết bất kỳ dòng `overrides` nào trong `fixtures.yaml`. Đừng để việc "đã có Bảng Mapping Rule cho control UI" đánh lừa thành "đã xong Dynamic Data".
+4c. **Áp Bảng Override (audit thắng DD — precedence nội dung, BẮT BUỘC):** Nạp **Bảng Override** đã dựng ở [Step 00 §1a-c](../steps/step-00-shiftleft-gate.md) từ các GAP `Resolved` + verdict `stale-docs` của `{id}_qa_report.md`. **Luật:** khi `_detailed_design` (DD) mâu thuẫn với một mục trong Bảng Override → **audit thắng, DD thua**; CẤM sinh case theo mô tả DD đã bị audit đánh dấu stale/đã-gỡ (chỉ ghi theo canonical audit, hoặc `❌ REMOVED` giữ ID cho R8). ⚠️ Đây là điểm mù kinh điển: qa_report là **input oracle nội dung**, không phải "context tham khảo" — đọc DD mù quáng khi audit đã phán DD stale = nguồn lỗi số 1 (vd sinh case cho tính năng đã bị CR gỡ). Nếu chưa có Bảng Override (qa_report tồn tại nhưng chưa dựng) → quay lại Step 00 §1 dựng trước.
+
+4d. **GATE Delta Manifest (chỉ khi có bề mặt mượn):** xác nhận Context Ledger đã có **Delta Manifest đã được user ký** ở Step 01. Thiếu → **DỪNG**, quay lại Step 01. Manifest là biên duy nhất của ngân sách UI ([borrowed_surface_rules.md](./borrowed_surface_rules.md)).
+
+### 1.2. PHASE 2: GENERATION & VERIFICATION (Sinh và đối soát)
+5. **Ánh xạ 1-1 (Zero-Summarization Enforcer & Rule Compliance):**
+   - **Bắt buộc đọc quy tắc:** Phải gọi tool `view_file` đọc trực tiếp toàn bộ các file rule kiểm thử đã liệt kê ở Step 02 để nạp ngữ cảnh trước khi sinh testcase, cấm tự suy đoán.
+   - **Không được gộp testcase:** Mỗi quy tắc kiểm thử con (space handling, maxlength, required validation, button states, v.v.) phải là một hàng kịch bản độc lập trong bảng 11 cột, không được viết tóm tắt hoặc gộp dòng.
+   - Bung mỗi rule-case (theo `cases_count` của từng rule đã nạp + mỗi dòng Ma Trận Quyết Định) thành đúng 1 dòng testcase riêng biệt với ID liên tục. Cấm gộp dòng. Nguồn để bung = **phần Math Forcing Step 02 (Chốt 6)**; plan KHÔNG còn section Checklist / ≥X dòng `[ ]`.
+   - **Math Check Gate:** `X` = tổng math-forcing chốt ở Step 02 (Chốt 6, phân rã control × rule cases_count); `Y` = số dòng testcase thực tế đã ghi. Báo cáo rõ $X = Y$ ra chat. Nếu $X \neq Y$, bắt buộc phải viết lại hoặc bổ sung.
+6. **Bảng 11 cột E2E (VIEW):**
+   - Sinh kịch bản và vẽ bảng theo đúng mẫu tại `slice_testcase_table_template.md`, phân chia riêng biệt theo từng bề mặt: *(ui)* Màn hình Action · *(service)* Operation/Endpoint.
+   - Dưới mỗi bề mặt, phân 3 Khối: *(ui)* *Khối 1: Giao diện · Khối 2: Chức năng · Khối 3: ATTT* · *(service)* *Khối 1: Hợp đồng & Request Validation · Khối 2: Nghiệp vụ & E2E · Khối 3: Phân quyền & ATTT* (không có Khối Giao diện).
+   - **Cột `Exec`** (automate/manual/exploratory) điền từ annotation Step 02b.
+7. **Ngôn ngữ và truy vết E2E:**
+   - Dùng ngôn ngữ người dùng cuối (End-User Language), cấm mã hệ thống ở mô tả UI/Verify (theo [markdown_safety_rules.md §4](./markdown_safety_rules.md)).
+   - Áp dụng kiểm chứng đa tầng theo [e2e-traceability-rule.md](../references/kbkt-generation/00-core/e2e-traceability-rule.md).
+   - **[HARD CHECK] Tạo mới → kiểm lưu đủ trường DB:** cột Kết quả mong muốn phải liệt kê **từng trường** đã có dữ liệu (khác NULL/rỗng), kể cả bảng phụ thuộc. Dừng ở "có bản ghi"/"trạng thái = X" → Reject ([e2e-traceability-rule §1.1](../references/kbkt-generation/00-core/e2e-traceability-rule.md)).
+8. **Emit canonical `.feature` + `fixtures.yaml` (AUTOMATION GATE):**
+   - Mỗi dòng testcase **`@exec:automate` hoặc `@exec:exploratory`** → 1 `Scenario` (cùng `@id`) với đủ tag theo [automation_contract_rules.md](./automation_contract_rules.md) §2. Dòng `@exec:manual` **KHÔNG** sinh `Scenario` (ở lại markdown view).
+   - Mỗi dòng `@exec:automate` → 1 `dataset` trong `fixtures.yaml`; data truy về phần Dữ liệu của `_detailed_design` (R1). `@exec:exploratory` không có dataset xác định trước (ghi `note:`).
+   - **[HARD CHECK — grep-able] Cấm hardcode giá trị Loại 1 (FK/Lookup)/Loại 2 (Unique) trong `fixtures.yaml`:** trước khi ghi mỗi `dataset`/`fixture`, quét mọi field đã phân loại ở Dynamic Data Gate (4b) — nếu là Loại 1/2, giá trị PHẢI ở dạng cú pháp động (`$db.query(...)`/`$seed.create(...)`/`$seed.insert(...)`/`$uuid`/`$timestamp(...)`) theo [dynamic_data_rules.md §3](./dynamic_data_rules.md) + [automation_contract_rules.md](./automation_contract_rules.md), **KHÔNG** được là chuỗi/ID tĩnh tự đặt (vd `"PMT-2026-00451"`, `"M00ACME0001"` viết cứng). Mỗi `$db.query`/`$seed.*` phải trỏ `<source_id>` tồn tại trong `{qa_artifacts}/data_sources.yaml` — thiếu registry → DỪNG, báo thiếu, không tự bịa connection/API.
+   - Field Runtime-dependent (Loại 1/2 theo [dynamic_data_rules.md](./dynamic_data_rules.md)) dùng cú pháp động thay vì giá trị tĩnh — tham chiếu lại phân loại đã chốt ở Dynamic Data Gate (4b), KHÔNG phân loại lại tùy hứng ở Step 03.
+   - **[HARD CHECK — grep-able] Expected "verbatim" cấm chứa ký tự trang trí từ wireframe:** mọi chuỗi trong `Then` phải khớp mô tả text/i18n của DD, KHÔNG chép từ khung vẽ ASCII. Quét từng expected: có emoji (U+2600-27BF, U+1F300-1FAFF) hoặc ký tự khung (`│ ─ ┌ └ ├`) → bỏ, giữ phần chữ; icon thuộc `icon_bindings` của `ui_schema`, không thuộc nhãn ([no-hallucination-rule](../references/kbkt-generation/00-core/no-hallucination-rule.md) §Wireframe).
+   - Selector KHÔNG sinh ở đây (việc của qa-robot). Bỏ qua nếu `emit_automation: false`.
+9. **Tự đối soát chất lượng (Self-Audit + Sync Invariant Gate):**
+   - Quét kiểm tra sự tồn tại của 3 tiêu đề khối; ID kịch bản liên tục dạng `KB-{id}-{RunningNumber}` (R8).
+   - **Oracle-first theo bề mặt** (rule cứng [risk_based_allocation_rules §3](./risk_based_allocation_rules.md)): *(ui)* không dòng nào drive qua UI (`@scr` + step bấm/nhập, có phản hồi UI) mà thiếu `@oracle:ui` / cột Công cụ chỉ `Postman` · *(service)* mọi dòng có `@svc` + `@oracle:api`/`db`/`msg`, KHÔNG `@oracle:ui`, KHÔNG `@scr`.
+   - **[HARD CHECK — grep-able] Provenance giá trị:** mọi literal ràng buộc (maxlength/min-max, page-size, enum, mã lỗi, ngưỡng) trong cột Data/Kết quả khớp verbatim giá trị + vị trí trong part đã load; không truy được hoặc chép từ control khác → `[TBD]` + Q&A, cấm số tự đặt (R1 · [no-hallucination-rule §Value Provenance](../references/kbkt-generation/00-core/no-hallucination-rule.md)).
+   - **[HARD CHECK — grep-able] Expected deterministic:** cột Kết quả không chứa nhánh chưa-resolve (mẫu "… hoặc báo lỗi", "cắt hoặc …", "A/B") — mỗi Expected đúng 1 hành vi theo spec; spec chưa chốt → Q&A ([kbkt-format-rule §Chất lượng Expected](../references/kbkt-generation/00-core/kbkt-format-rule.md)).
+   - **[HARD CHECK — grep-able] Cấm Expected mơ hồ (blocklist):** quét cột Kết quả tìm cụm rỗng-nghĩa đứng một mình — "hiển thị đúng", "theo thiết kế", "khớp thiết kế", "đúng thiết kế", "hợp lệ", "có placeholder", "bình thường", "OK", "như mong đợi", **"đồng nhất", "cân đối", "logic", "hợp lý", "căn lề đều", "không xô lệch", "cho nhập", "nhận focus", "rỗng", "Empty state", "empty state", "Empty 1", "Empty 4"** (khi đứng một mình, không kèm message nguyên văn + CTA + thành phần). Có → thay bằng **hệ quả quan sát được cụ thể** (giá trị / text nguyên văn / trạng thái / vị trí đo được).
+   - **[HARD CHECK — đếm được] Độ phủ thành phần trong 1 Expected (chống liệt kê thiếu):** **Trigger cơ học (grep, không dựa tự-nhận-ra):** mọi case có `Ref` ∈ {`screen-default`, `grid-base`} HOẶC cột Mục đích/Trường hợp chứa 1 trong {`empty`, `Empty`, `panel`, `modal`, `banner`, `card`, `no-record`, `trạng thái rỗng`} → **BẮT BUỘC** chạy check này. Với case trigger: mở đúng block wireframe / bảng control của state đó trong DD, **đếm** mọi thành phần rời của nó (icon / tiêu đề / **mô tả** / message / dòng recap / **mỗi CTA** / control) = `N`, rồi đối chiếu Expected phải nêu đủ `N` (mỗi thành phần 1 mục có nội dung quan sát được), báo `N thành phần` ra chat. Sót (vd chỉ ghi tiêu đề+CTA, bỏ icon + mô tả) → **FAIL**, bổ sung trước khi ghi. CẤM tóm tắt block wireframe từ trí nhớ — phải soi từng dòng.
+   - **[HARD CHECK] Expected layout/visual phải nêu checkpoint đo được:** case `layout-visual`/`responsive-zoom`/`keyboard-nav` KHÔNG được ghi "khớp thiết kế"/"cân đối"/"đồng nhất" — phải mô tả **điều kiện quan sát cụ thể** (vd "8 cột thẳng hàng, KHÔNG cột nào tràn viewport, KHÔNG xuất hiện scroll ngang"; "focus đi tuần tự A→B→C→D"; "font-size/màu chữ header đồng nhất theo design token `--x`"). Không đo được từ spec/DS → `[TBD]` + Q&A.
+   - **[HARD CHECK — grep-able] Provenance TEXT hiển thị (chống bịa-cụ-thể):** mọi Expected khẳng định **một chuỗi hiển thị cụ thể** — placeholder, nhãn/label, option, message, empty-state, tiêu đề, tooltip — BẮT BUỘC 1 trong 2:
+     - (a) khớp **verbatim** một entry trong **UI Text Source Map** của Context Ledger (Step 01) **kèm cite inline** `(i18n: <key>)` hoặc `(DD §<x>)`; hoặc
+     - (b) `[TBD]` + Q&A **chỉ khi ĐÃ soi đủ 4 nguồn** (bảng control/Giao diện DD → wireframe → UX Spec → i18n) mà **tất cả im lặng**. **CẤM over-`[TBD]`**: hạ giá trị đang có nguồn xuống `[TBD]` chỉ vì mới xem i18n rỗng (vd `"Tất cả"` có ở DD F-01, `"Tìm theo tên / mã hồ sơ"` có ở DD F-05 → phải cite, KHÔNG [TBD]).
+     
+     **Grep cơ học:** mọi cụm trong ngoặc kép đứng sau `Placeholder`/`Label`/`Message`/`option`/`tiêu đề`/`tooltip` (hoặc chuỗi hiển thị bất kỳ trong `"..."` ở cột Kết quả) mà **KHÔNG** kèm `(i18n:` / `(DD` và **KHÔNG** phải `[TBD]` → **FAIL**, DỪNG, ép về `[TBD]` + Q&A. **CẤM tuyệt đối suy text từ "UI thường thấy"/prior** (vd tự đặt placeholder `"Tất cả"`, `"Nhập tên..."`) — đây chính là fabrication R1. Không tra được nguồn = KHÔNG có quyền viết text.
+     - Ngoại lệ: kiểm *sự tồn tại* control (không xét nội dung) phải phát biểu bằng trạng thái quan sát được ("ô placeholder hiển thị, nội dung [TBD]"), KHÔNG dùng "có placeholder" trống nghĩa.
+   - **[HARD CHECK — grep-able] Chất lượng cột "Các bước" (chống bước rỗng nghĩa):** mỗi bước phải tái lập được — nêu đủ **(control cụ thể theo Nhãn UI/endpoint) + (hành động) + (giá trị/tham chiếu Data Test nếu nhập) + (điểm quan sát nếu là bước verify)**. CẤM bước trống nghĩa đứng một mình: "Quan sát.", "Nhập.", "Click ô.", "Mở trang.", "Đối chiếu thiết kế.", "Kiểm tra." — không nêu *đối tượng nào / nhìn vào đâu*. Grep các bước ≤ 3 từ hoặc chỉ có động từ mà không có tân ngữ control → FAIL, viết lại (vd "Quan sát." → "Quan sát bảng danh sách sau khi load 47 bản ghi: đếm số cột header"). Bước cuối của case verify phải trỏ đúng thứ nguyên Expected sẽ assert.
+   - **[HARD CHECK — grep-able] Delta Scope Guard (chỉ khi có bề mặt mượn):** mỗi dòng testcase phải map về **1 dòng Delta Manifest** HOẶC là dòng **BE API-only** thuộc `units:`. Dòng nhắc control của màn host ngoài 2 nhóm đó → **FAIL**, xoá. Mỗi biên liên-slice chưa khai ([borrowed_surface_rules.md §5](./borrowed_surface_rules.md)) phải có **đúng 1 dòng Coverage Debt** (Mục 5.6) + assert **bất biến phủ định** ở biên; cấm im lặng bỏ.
+   - **[HARD CHECK] Cấm case trùng (duplicate detector):** sort các dòng theo `(control + hành vi + Kết quả)`; hai dòng cùng control mà Kết quả trùng nghĩa → hoặc phân biệt rõ hành vi (vd *enable* = cho nhập/không readonly ≠ *focus* = nhận viền focus; *clear chưa blur* ≠ *clear→blur→required*), hoặc gộp về 1. CẤM 2 KB khác số nhưng nội dung y hệt.
+   - **[HARD CHECK — grep-able] Exclusivity phản hồi lỗi (BẮT BUỘC mọi error-path, KHÔNG điều kiện):** MỌI dòng error-path (Expected có mã lỗi `BMS_*`/HTTP 4xx-5xx, HOẶC ref `error-response`/`inline-error`, HOẶC nêu 1 toast/inline lỗi) **BẮT BUỘC** chứa mệnh đề exclusivity tường minh: **"đúng 1 lỗi ... KHÔNG kèm/KHÔNG xuất hiện thông báo lỗi khác"**. **Grep cơ học:** dòng error-path mà cột Kết quả **thiếu** một trong các token {`đúng 1 lỗi`, `chỉ 1`, `không kèm`, `không xuất hiện thông báo khác`, `không lỗi generic`} → **FAIL**, bổ sung trước khi ghi. Đặc biệt phải khẳng định **lỗi cụ thể KHÔNG đi kèm lỗi generic** (vd 409 "đã thuộc composite khác" **không** kèm 400 "Dữ liệu không hợp lệ"; over-length **không** kèm "Hệ thống gián đoạn"). Bỏ điều kiện cũ "khi spec định nghĩa 1 lỗi" — mặc định 1 điều kiện = 1 lỗi; nếu spec thực sự cho phép nhiều lỗi đồng thời thì phải nêu rõ, nếu không → 1.
+   - **[HARD CHECK — grep-able] Không lộ mã hệ thống (`SCR-*`/`WGT-*`/`HUB-*`/...) trong Mục đích/Trường hợp/Bước thực hiện/UI:** áp dụng [markdown_safety_rules.md §4.2](./markdown_safety_rules.md) — quét và thay bằng tên End-User trước khi ghi file.
+   - **[HARD CHECK — grep-able] Không được bỏ tầng UI khỏi Expected Result (bề mặt `ui`):** Quét CƠ HỌC mọi dòng có cột "Công cụ" chứa `Chrome` (kể cả `Chrome+DevTools`, `Chrome+Mock`...) → cột "Kết quả mong muốn" **BẮT BUỘC chứa chuỗi literal `**UI:**`**. Dòng nào thiếu → BẮT BUỘC bổ sung `**UI:**` (đặt đầu tiên, đúng thứ tự UI → DB → API → Log theo `kbkt-format-rule.md`) trước khi ghi file.
+   - **[HARD CHECK — grep-able] Không được bỏ tầng oracle khỏi Expected Result (bề mặt `service`):** Quét CƠ HỌC mọi dòng có cột "Công cụ" chứa `Postman`/`RequestsLibrary` (không có `Chrome`) → cột "Kết quả mong muốn" **BẮT BUỘC chứa ≥1 chuỗi literal trong {`**API:**`, `**DB:**`, `**MSG:**`}** (và KHÔNG chứa `**UI:**`). Dòng nào chỉ ghi "trả 200" mà không assert body/schema/side-effect → oracle nông, phải bổ sung trước khi ghi file (xem [service_surface_rules.md §3](./service_surface_rules.md)).
+   - **[HARD CHECK — grep-able] Fixtures không hardcode Loại 1/2 (nhắc lại 4b/8):** grep mọi `fixtures.yaml` đã ghi tìm chuỗi ID/mã trông giống dữ liệu tra cứu tĩnh (số/mã kèm ULID-like, `subId`, `merchantCode`, ...) mà KHÔNG bọc trong `$db.query`/`$seed.*`/`$uuid`/`$timestamp` — có → phải sửa lại trước khi coi Step 03 hoàn tất, không để dồn sang Step 04.
+   - **[HARD CHECK — grep-able] Fixtures cấm placeholder mô tả + cấm prose field-input (enforce §58 automation_contract_rules):** trước khi coi Step 03 hoàn tất, chạy 2 lệnh trên `fixtures.yaml` đã ghi — **cả 2 phải RỖNG**:
+     - (1) Placeholder độ-dài `<… ký tự/chuỗi …>`: `grep -nE '<[^>]*(ký tự|chuỗi)[^>]*>' <fixtures.yaml>` → còn kết quả = FAIL (cấm MỌI nơi kể cả `note:` — dataset là JSON 1 dòng nên không lọc theo dòng được; note mô tả biên viết `99 ký tự`, KHÔNG bọc ngoặc `<>`). Biên độ dài PHẢI dùng notation `<ký-tự>×N` (vd `a×255`, `á×100`) hoặc giá trị thật.
+     - (2) Field-input viết dạng prose (phải tách `{field: value}`; phần động → `$db.query`/`fixture_ref`): `grep -nE '"input": "(<TÊN-FIELD-UI-CỦA-TARGET> *:)' <fixtures.yaml>` — `<TÊN-FIELD-UI>` là **MẪU, thay bằng tên field UI của target lấy từ DD/`ui_schema`** (KHÔNG hardcode field slice khác). Còn kết quả = FAIL, tách field. *(Prose `input:` mở đầu bằng precondition — `token:`/`mock`/`DB:`/`URL`/`body:`/`status:`/date — KHÔNG phải field-input, giữ nguyên.)*
+   - **[HARD CHECK — grep-able] Token phá bảng markdown (HTML tag thô) — BẮT BUỘC, chống vỡ bảng:** trước khi ghi file markdown testcase, chạy `grep -nE '"<[a-zA-Z/]' <file>` — **phải RỖNG**. Mọi payload HTML/XSS (`<script>`, `<b>`, `<img ...>`, `<script>alert(1)</script>`) trong cột "Các bước thực hiện"/"Kết quả mong muốn" PHẢI bọc backtick `` `<...>` `` (theo [markdown_safety_rules.md §2.1](./markdown_safety_rules.md)); để trần trong dấu nháy kép → trình render markdown diễn giải là HTML thật, **vỡ bảng từ dòng đó trở đi**. Còn kết quả → bọc backtick hết (sửa nhanh: `perl -i -pe 's/"(<[^"]*>[^"]*)"/` + "`" + `$1` + "`" + `/g' <file>`) rồi mới coi Step 03 hoàn tất.
+   - **Sync theo mô hình "1 số gốc + 2 phép chiếu"** ([automation_contract_rules.md §1](./automation_contract_rules.md) — CANONICAL, cite về đó, KHÔNG paraphrase khác đi):
+     - **Gate gốc (Math Check):** `Y == X` — `X` = tổng case **chốt cụ thể ở Step 02 Math Forcing** (sau mode; Step 02b chỉ dán nhãn Exec, KHÔNG đổi tổng), GỒM cả manual; `Y` = **tổng số dòng markdown** thực ghi (bao gồm cả manual). Báo `X = Y` ra chat.
+     - **Phép chiếu 1:** `count(@id distinct trong .feature) == A + E` — đếm dòng route sang `.feature` (A=automate, E=exploratory).
+     - **Phép chiếu 2:** `count(dataset trong fixtures) == A` (exploratory ghi `note:`, không dataset).
+     - `A/E/M` là **phân hoạch của `X` theo cột Exec** (mỗi dòng đúng 1 nhãn), chỉ đếm dòng route sang từng file — KHÔNG đếm lại tổng. **CẤM "3-way ==":** không gộp `X` với `A+E`/`A` thành 1 đẳng thức.
+   - **[HARD CHECK — cross-artifact, BẮT BUỘC]** chạy lệnh `comm` ở [automation_contract_rules §1](./automation_contract_rules.md) đối chiếu `.md`(Exec∈{automate,exploratory}) ↔ `.feature`(@id). **Sàn chống false-pass:** đếm `N_md` = số dòng grep được phía `.md`; `N_md==0` hoặc `N_md != A+E` → **FAIL** (grep trượt do format lệch — `comm` rỗng lúc này là rỗng-giả), sửa format/bổ sung trước; chỉ khi `N_md==A+E` mới tin `comm`. Ra @id thiếu → **DỪNG**, bổ sung (KHÔNG hạ manual, KHÔNG rebalance-drop). CẤM tính Sync nội bộ `.feature` (tautology).
+10. **Ghi Output & Dừng duyệt (HITL GATE):**
+   - Ghi cả 3 artifact vào `{qa_artifacts}` (markdown tuân thủ [principles/markdown_safety_rules.md](../principles/markdown_safety_rules.md)).
+   - **Dừng/defer theo `run_mode`** — áp [run_mode_rules.md §3](./run_mode_rules.md) (`full` = dừng duyệt từng màn; `batch` = in `X = Y` rồi auto-proceed, gộp Step 04; lệch Math Check/Sync → rớt về dừng-tại-màn).
+   - **Tự động chuyển tiếp:** Nếu đã hoàn thành màn cuối cùng, báo cáo hoàn tất và tự động chuyển sang [Step 04](../steps/step-04-finalize-testcase.md) (Không ghi trực tiếp mục 5.3/5.4/5.5 tại bước này).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/principles/unit_classification_rules.md

@@ -0,0 +1,49 @@
+# UNIT CLASSIFICATION & SCOPE RULES — Phân loại Unit + Kiểm soát phạm vi SLICE
+
+> **Mục đích:** Quy định cách phân loại các Unit, sắp xếp thứ tự luồng E2E, **và giới hạn phạm vi kiểm thử** trong file SLICE (§4).
+>
+> **Phạm vi bề mặt:** File này áp cho bề mặt **`ui`** (unit có màn hình — nhãn Action/Verify/Nav). Với bề mặt **`service`** (không giao diện: API/service/job/consumer) dùng bộ nhãn `[Operation]`/`[Effect]`/`[Downstream]` tại [service_surface_rules.md §1](./service_surface_rules.md) — KHÔNG áp §2 dưới đây.
+>
+> **⚠️ Áp dụng theo lane (từ Step 00):** File này chủ yếu cho lane `slice` (nhiều unit). **Lane `unit`** — chỉ có MỘT đơn vị `{id}`: **BỎ QUA §1 (khảo sát nhiều unit) và §3 (xếp thứ tự E2E liên-unit)**; §2 rút gọn (unit `{id}` mặc định `[Action]`); §4 phạm vi thu về chính `{id}` (mọi màn/logic ngoài `{id}` là "Out of scope").
+
+---
+
+## 1. Khảo sát Unit *(lane `slice`)*
+- Đọc danh sách `units` trong file SLICE (`{slices_root}/{id}-*.md`).
+- Đếm số lượng các Frontend Unit (bao gồm cả `SCR-` và `WGT-`). Cần đảm bảo Danh sách luồng E2E và Bảng Mapping liệt kê đầy đủ số lượng này, không được gộp chung các unit với nhau.
+- **[BẮT BUỘC ĐỐI CHIẾU PHẠM VI]:** Thực hiện đối chiếu phạm vi của tất cả Frontend và Backend Unit với mảng `units` của file SLICE và tuân thủ nguyên tắc giới hạn tại **§4** bên dưới.
+
+## 2. Đọc hiểu & Phân loại Unit
+- Dùng `view_file` đọc phần Tổng quan trong `_detailed_design` của **tất cả** Frontend Unit để nắm mục đích nghiệp vụ.
+- **[PHÂN LOẠI BẮT BUỘC]:** Đánh nhãn từng Frontend Unit thành 1 trong 3 loại:
+  - `[Action]` (Màn hành động chính): Chạy đầy đủ vòng lặp **Step 02 → Step 03**.
+  - `[Verify]` (Màn xác nhận kết quả): Xuất hiện sau khi submit để xác nhận (vd: hiển thị trên list). **KHÔNG chạy Step 02-03**; embed kết quả verify vào testcase của màn `[Action]` trước đó.
+  - `[Nav]` (điều hướng thuần — `WGT-`, **hoặc `SCR-` khi là màn host của bề mặt mượn**): Không own logic riêng của slice này. **KHÔNG chạy Step 02-03**; đưa vào Precondition. Vẫn phải dùng `list_dir` để liệt kê tài liệu (`_detailed_design`) của Unit này, nếu thiếu phải thông báo rõ.
+  - `[Delta Action]` (cụm hành động của slice chạy trên màn host của slice khác — **bề mặt mượn**): bề mặt test là **CỤM** (nút/modal/banner), KHÔNG phải màn. Chạy đầy đủ Step 02 → Step 03 cho cụm; màn host là `[Nav]`. Luật: [borrowed_surface_rules.md](./borrowed_surface_rules.md).
+  - **[CONTEXTUAL ROLE SHIFT]:** Nếu một Unit đóng vai trò hỗn hợp (vừa là màn xem danh sách `[Verify]` nhưng lại có chứa các tính năng tương tác độc lập như bộ lọc, phân trang, hoặc hành động riêng biệt), bắt buộc phải đánh nhãn kết hợp là `[Action / Verify]` để vừa đóng vai trò màn kiểm chứng kết quả của màn trước, vừa chạy đầy đủ Step 02 → Step 03 cho phần logic độc lập của chính nó (nhận diện qua việc đọc phần Tổng quan trong `_detailed_design`).
+
+## 3. Xác định Thứ tự E2E & Mapping Backend *(lane `slice` — lane `unit` bỏ qua)*
+- **[ORDERING RULE]:** Dựa vào chuỗi `demoable` trong file SLICE, xếp các unit `[Action]` và `[Verify]` theo đúng **chuỗi hành động**. TUYỆT ĐỐI KHÔNG suy diễn thứ tự dựa trên luồng UX Navigation (vd: Cấm xếp A trước B chỉ vì A có nút mở B, nếu A là màn xem kết quả còn B là màn tạo).
+- **[BẮT BUỘC KHỚP MÀN HÌNH ĐÍCH TỪ DEMOABLE]**: Phải phân tích từng bước chuyển hướng ký hiệu bằng mũi tên "→" trong chuỗi "demoable" của file SLICE. Ví dụ: "tạo composite → thấy nó trong list" nghĩa là màn hình danh sách (SCR-COMPOSITE-LIST) bắt buộc phải được khai báo là Màn hình đích (Target Screen) của màn hình tạo (SCR-COMPOSE). Mọi màn hình đích xuất hiện trong chuỗi demoable phải được kiểm tra việc quay về/hiển thị dữ liệu thành công trong kịch bản kiểm thử của màn trước đó.
+- Rà soát trường `story` trong file SLICE: Gán Backend Unit cho Frontend Unit có chung chính xác Epic/Story code. Backend nào không map thì đưa vào nhóm "Background".
+
+## 4. Kiểm soát phạm vi SLICE (Scope Boundary)
+
+> Tránh AI đi lạc sang màn hình ngoài phạm vi Vertical Slice.
+
+### 4.1 Đối chiếu phạm vi (Scope Checking)
+*   **[BẮT BUỘC ĐỐI CHIẾU PHẠM VI]**: *(lane `slice`)* Đối chiếu trực tiếp ID của màn hình đích với danh sách `units` trong file mô tả SLICE (tìm file bắt đầu bằng `{id}` trong thư mục `{slices_root}`, ví dụ: `SLICE-06-composite-create-list.md`). *(lane `unit`: phạm vi = chính `{id}`; mọi màn/logic ngoài `{id}` là "Out of scope".)*
+*   Nếu màn hình/unit đích KHÔNG nằm trong mảng `units` đó -> Bắt buộc gán nhãn `"Out of SLICE scope"` cho màn hình này.
+*   Cấm tuyệt đối việc lập test plan độc lập (Step 02/03) cho màn hình ngoài phạm vi đó.
+
+### 4.2 Kiểm thử hành động chuyển hướng (Redirection Verification)
+*   Đối với màn hình hành động (Màn trước): Nếu hành động đó dẫn đến sự chuyển hướng sang màn hình đích nằm ngoài SLICE, kịch bản kiểm thử của màn trước **vẫn phải có bước kiểm tra việc chuyển hướng thành công** trong Kết quả mong muốn (UI).
+    *   *Ví dụ:* Hiển thị thông báo toast success, hoặc URL trình duyệt thay đổi đúng địa chỉ màn hình đích.
+*   **TUYỆT ĐỐI KHÔNG** đi sâu vào lập testcase kiểm tra chi tiết các UI control hay logic nội tại của màn hình đích ngoài phạm vi đó.
+
+### 4.3 Bề mặt mượn (màn host của slice khác)
+
+*   Màn được `## What to build`/`demoable` nêu nhưng KHÔNG có trong `units:` → `[Nav]` host, **không phải** `"Out of SLICE scope"`; bề mặt test là cụm hành động trên đó.
+*   Màn host vào Precondition **đúng 1 dòng** (`Mở màn X thành công (đã có <state cần thiết>)`). **CẤM** case kiểm layout / bảng / tab / filter / empty-state của màn host.
+*   Phạm vi liên-slice + Delta Manifest + override 9 chốt: [borrowed_surface_rules.md](./borrowed_surface_rules.md).
+