@trungtamcongnghedigital/vsaf 1.0.0

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/references/templates/testspec_feature_template.feature

@@ -0,0 +1,93 @@
+# =====================================================================
+# TESTSPEC FEATURE TEMPLATE — Canonical machine-readable artifact
+# File: {id}_testspec.feature   ({id} = ID đầy đủ SLICE/unit, vd SLICE-06 / WGT-SIDEBAR)
+# Hợp đồng: ../../principles/automation_contract_rules.md (tag dictionary §2)
+# Sync Invariant: mỗi Scenario ⇔ 1 dòng markdown ⇔ cùng @id.
+# Selector KHÔNG nằm ở đây (qa-robot lấy từ ui_schema). Chỉ dùng Nhãn UI.
+# =====================================================================
+
+@{id}
+Feature: {Tên SLICE/Unit} — E2E system test
+  ID: {id}
+  Coverage gate: 100% luồng E2E qua các unit FE/BE (theo iron_rules R4)
+  Generated: {timestamp}
+
+  # ---- 1 Background cho toàn slice/unit (precondition + [Nav] units) ----
+  Background:
+    Given hệ thống ở môi trường "Staging" mạng ổn định
+    And user đã đăng nhập với quyền theo luồng E2E
+
+  # =================================================================
+  # MÀN HÌNH ACTION {STT}: {Tên màn} ({unit_id})
+  # =================================================================
+
+  # ---- KHỐI 1: GIAO DIỆN (UI) ----
+  @scr:{SCR-UNIT} @id:KB-{id}-01 @block:ui @tech:BVA @rule:textbox-base
+  @risk:P1 @exec:automate @target:robot @oracle:ui
+  Scenario: Email thiếu ký tự @ bị chặn (validation BVA)
+    Given user ở màn "{Tên màn}"
+    When user nhập "{Nhãn trường Email}" = "<email_invalid_no_at>"
+    And user bấm "{Nhãn nút Submit}"
+    Then UI: trường "{Nhãn trường Email}" viền đỏ, hiện lỗi "Email không đúng định dạng"
+
+  # ---- KHỐI 2: CHỨC NĂNG (FUNCTIONAL / E2E) ----
+  @scr:{SCR-UNIT} @id:KB-{id}-02 @block:functional @tech:EP @rule:save-button
+  @risk:P0 @exec:automate @target:robot @oracle:ui @oracle:api @oracle:db
+  Scenario: Tạo mới thành công toàn luồng UI → API → DB
+    Given user ở màn "{Tên màn}"
+    When user nhập dữ liệu hợp lệ từ fixture "<valid_compose_payload>"
+    And user bấm "{Nhãn nút Lưu}"
+    Then UI: chuyển sang màn "{Màn đích}", bản ghi mới ở dòng đầu danh sách
+    And API: POST "{endpoint}" trả HTTP 200
+    And DB: bảng "composite_requests" insert 1 bản ghi status "PENDING"
+
+  # BVA/EP nhiều giá trị cùng-logic → MỖI case 1 Scenario riêng (CẤM Scenario Outline/Examples).
+  # Chống trùng-lặp: giá trị input để ở fixtures.yaml (mỗi case 1 dataset), thân scenario chỉ khác giá trị nạp.
+  @scr:{SCR-UNIT} @id:KB-{id}-03 @block:functional @tech:BVA @rule:maxlength
+  @risk:P1 @exec:automate @target:robot @oracle:ui @oracle:api
+  Scenario: Biên maxlength "{Nhãn trường}" = 255 (giá trị lớn nhất hợp lệ)
+    Given user ở màn "{Tên màn}"
+    When user nhập "{Nhãn trường}" từ fixture "<maxlen_255>"
+    And user bấm "{Nhãn nút Lưu}"
+    Then UI: lưu thành công
+    And API: trả HTTP 200
+
+  @scr:{SCR-UNIT} @id:KB-{id}-04 @block:functional @tech:BVA @rule:maxlength
+  @risk:P1 @exec:automate @target:robot @oracle:ui @oracle:api
+  Scenario: Biên maxlength "{Nhãn trường}" = 256 (vượt giới hạn)
+    Given user ở màn "{Tên màn}"
+    When user nhập "{Nhãn trường}" từ fixture "<maxlen_256>"
+    And user bấm "{Nhãn nút Lưu}"
+    Then UI: chặn, báo "vượt độ dài"
+    And API: trả HTTP 400
+
+  # ---- KHỐI 3: PHÂN QUYỀN & ATTT (SECURITY) ----
+  @scr:{SCR-UNIT} @id:KB-{id}-05 @block:security @tech:EG @rule:security-input
+  @risk:P0 @exec:automate @target:robot @oracle:api
+  Scenario: Chặn IDOR — thao tác tài nguyên user khác
+    Given có token của "User A" và một resource_id thuộc "User B"
+    When gửi API request xem chi tiết resource_id bằng token User A
+    Then API: trả HTTP 403 Forbidden
+
+  # =================================================================
+  # (Lặp lại khối Màn hình Action cho từng unit [Action] tiếp theo,
+  #  ID @id chạy liên tục, không nhảy cóc — theo iron_rules R8)
+  # =================================================================
+
+  # =================================================================
+  # BIẾN THỂ SERVICE (no-UI): dùng @svc thay @scr, oracle API/DB/MSG/Log
+  # (không @oracle:ui). Given/When/Then là gọi request + quan sát
+  # side-effect, KHÔNG "user ở màn". Xem service_surface_rules.md.
+  # =================================================================
+  # OPERATION {STT}: {METHOD /path} ({unit_id})
+
+  # ---- KHỐI 2: NGHIỆP VỤ & E2E ----
+  @svc:{HUB-UNIT} @id:KB-{id}-10 @block:functional @tech:EG @rule:backend-resilience
+  @risk:P0 @exec:automate @target:robot @oracle:api @oracle:db @oracle:msg
+  Scenario: Idempotency — request trùng key chỉ tạo 1 giao dịch
+    Given có payload hợp lệ từ fixture "<valid_transfer>" và một "Idempotency-Key"
+    When gửi request tạo giao dịch lần 1
+    And gửi lại request với cùng "Idempotency-Key"
+    Then API: lần 2 trả HTTP 200 cùng "transferId" lần 1
+    And DB: bảng "transfers" chỉ có 1 bản ghi
+    And MSG: chỉ 1 event "transfer.created" được phát

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-00-shiftleft-gate.md

@@ -0,0 +1,45 @@
+# STEP 00: SHIFT-LEFT GATE (Tiền kiểm chất lượng spec + khung charter)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/iron_rules.md](../principles/iron_rules.md) (R1, R5, R7) · [principles/run_mode_rules.md](../principles/run_mode_rules.md)
+> **Vị trí:** Chạy ĐẦU TIÊN, TRƯỚC [Step 01](step-01-init-slice.md). Là cổng shift-left của School B + cổng định tuyến `run_mode`.
+
+## 1. Mục tiêu
+Bắt sự mơ hồ của spec **trước khi** thiết kế testcase (không sinh test trên nền mơ hồ), lập khung cho phần `exploratory`, **detect `input_type`** (slice vs unit đứng riêng) + **`surface_type`** (ui vs service/no-UI), và **resolve `run_mode` + định tuyến lane** (full / batch / delta).
+
+## 2. Các Bước Thực Hiện
+
+0a. **Detect `input_type` (GATE nhận diện — chạy TRƯỚC mọi thứ):** Với `{id}` người dùng truyền vào:
+   - Tìm file SLICE `{slices_root}/{id}-*.md`. **Tồn tại** → `input_type=slice` (nhiều unit, có xếp thứ tự E2E).
+   - Không có file SLICE nhưng tồn tại `{id}_detailed_design.md` (đơn vị trong WBS: HUB/WGT/SCR/MPF…) → `input_type=unit` (coi như "slice một unit" — Step 01 chạy nhánh unit, bỏ bước xếp thứ tự liên-unit).
+   - Không có cả hai → **DỪNG**, hỏi user: `{id}` không khớp file SLICE cũng không có `_detailed_design`; yêu cầu xác nhận ID hoặc chạy Stage 4a (DD) trước.
+   - In `input_type` đã chọn ra chat. Biến này quyết định nhánh ở Step 01 và được ghi vào Context Ledger.
+
+0a-bis. **Detect `surface_type` (GATE bề mặt — QUYẾT ĐỊNH Ở CẤP TEST-TARGET, KHÔNG per-unit):** Xác định **cả test-target** (nguyên slice, hoặc unit đứng riêng) là **`ui`** hay **`service`** — dựa trên: target có chứa **BẤT KỲ unit UI nào** (`SCR-*`/`WGT-*`, tức có phần Giao diện render được) hay không.
+   - **Target CÓ ≥1 unit UI → `surface_type=ui` cho TOÀN luồng.** E2E đi **tích hợp qua màn** (như cũ — [slice_planning_rules.md](../principles/slice_planning_rules.md) + [unit_classification_rules.md](../principles/unit_classification_rules.md)). **MỌI unit BE (HUB/MPF/INT/PMT-EXT…) là BACKEND của màn** — map theo story-code, verify bằng oracle API/DB **nhúng trong testcase của màn** (BE không map màn nào → nhóm Background). **TUYỆT ĐỐI KHÔNG** tách BE thành "service surface" riêng, **KHÔNG** chèn BE vào thứ tự E2E như một bề mặt độc lập.
+   - **`units:` không có unit UI → chạy [borrowed_surface_rules.md §1](../principles/borrowed_surface_rules.md) TRƯỚC khi kết luận `service`:** nếu `## What to build`/`demoable` nêu một màn `SCR-*`/`WGT-*` và cross-check host pass → `surface_type=ui`, màn đó = `[Nav]`, **bề mặt test = cụm hành động (KHÔNG phải màn)**. Cross-check fail → hỏi user, không đoán.
+   - **Target KHÔNG có unit UI nào và KHÔNG có bề mặt mượn → `surface_type=service`.** (Thuần BE: unit `HUB/MPF/INT` đứng riêng, hoặc slice toàn BE — batch/integration pipeline không màn.) Khi đó các unit BE mới thành operation ([service_surface_rules.md](../principles/service_surface_rules.md)). Đây chính là luật **"không có giao diện thì mới test API BE riêng"**.
+   - `input_type=unit`: 1 unit BE không màn → `service`; `SCR-*`/`WGT-*` → `ui`. Muốn test API 1 HUB riêng → chạy skill với chính `{id}` của HUB đó (target no-UI → service).
+   - Prefix ID chỉ là tín hiệu phụ — **đọc DD mới quyết định**. DD mơ hồ không rõ có UI hay không → **hỏi user 1 lần** (đừng đoán).
+   - **1 lần chạy generate = 1 target = MỘT `surface_type` duy nhất** (không có "slice trộn per-unit"). In `surface_type` (1 giá trị cho cả target) ra chat; ghi vào Context Ledger.
+
+0. **Resolve `run_mode` + định tuyến (GATE đầu):** Theo [run_mode_rules.md](../principles/run_mode_rules.md) §1–2.
+   - Resolve lane theo ưu tiên: ý định người dùng → `.bmm-config.yaml` `run_mode` → auto-detect → default `full`.
+   - **Auto-detect delta:** 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 ý → **BỎ QUA toàn bộ Step 00–03**, vào thẳng [Step 05 Nhánh A](step-05-roundtrip.md) (delta map + patch). Người từ chối → tiếp tục `full`/`batch`.
+   - Lane `batch`: ghi nhận "auto-proceed giữa các màn, gộp HITL về Step 04" để các step sau áp dụng.
+   - Lane `full`: hành vi như cũ, đầy đủ 4 HITL gate.
+   - In lane đã chọn ra chat trước khi tiếp tục.
+
+1. **Kiểm tra delegation tới `ntapp-qa-audit` + DỰNG BẢNG OVERRIDE (GATE precedence — bắt buộc):**
+   - Nếu đã tồn tại `{qa_artifacts}/{id}/{id}_qa_report.md` (output của `/ntapp-qa-audit`) → đọc TOÀN BỘ, nạp các quyết định đã chốt. **Scope + gap đã chốt trong audit là ràng buộc độ phủ bắt buộc — testcase KHÔNG được thu hẹp hơn audit.** Rồi làm 1a–1c dưới đây TRƯỚC khi sang bước 4.
+   - **1a. Dựng "Bảng Override" (audit → nội dung canonical):** Quét mọi GAP có trạng thái **`Resolved`** + mọi verdict gắn nhãn **`stale-docs`** / **`stale`** + phần intro/bối cảnh (vd "DD parts sinh trước CR → stale, chốt theo TechSpec/code"). Với mỗi mục, trích ra dòng: `{control / field / feature / enum} → {quyết định canonical}` (vd `composite.status → 5 enum, KHÔNG Draft`; `SCR-COMPOSE auto-save/localStorage draft → ĐÃ GỠ v3.0`; `merchantCode regex → ^[A-Za-z0-9_-]{0,20}$`). **In bảng này ra chat.**
+   - **1b. LUẬT PRECEDENCE (nội dung, không chỉ độ phủ):** Với bất kỳ control/field/feature nào có trong Bảng Override, **nội dung canonical của audit THẮNG `_detailed_design` (DD) tuyệt đối khi mâu thuẫn**. DD chỉ là nguồn cho phần audit *chưa* đụng tới. ⚠️ "Nạp làm context" KHÔNG đủ — audit là **oracle nội dung ràng buộc**, DD thua khi lệch.
+   - **1c. CẤM sinh case từ DD stale:** Nếu DD mô tả một tính năng/nhánh/trạng thái mà một GAP `Resolved` (hoặc verdict stale-docs) nói **đã gỡ / đã đổi**, thì **CẤM** sinh testcase theo mô tả DD đó. Chỉ được: (i) ghi case theo quyết định canonical của audit, hoặc (ii) đánh dấu `❌ REMOVED` (giữ slot ID cho R8, exec=N/A) nếu tính năng không còn. Ghi 1 dòng "GAP-DRIFT-*" vào Coverage Debt Ledger (Mục 5.6) nêu rõ DD nào stale so với CR/verdict nào. **KHÔNG bao giờ tin DD mù quáng khi audit đã phán DD stale.**
+   - Nếu **chưa** có và config `shiftleft_required: true` (Layer 3, mặc định `true`) → **DỪNG**, khuyến nghị user chạy `/ntapp-qa-audit {id}` trước. (Skill này KHÔNG tự làm audit — tránh trùng chức năng; chỉ là cổng kiểm tra.)
+   - Nếu config `shiftleft_required: false` → chạy **mini-audit nội bộ** (bước 2).
+2. **Mini-audit nội bộ (chỉ khi không có qa-audit):** Quét nhanh file `_detailed_design` các unit tìm nhập nhằng. **Bề mặt `ui`** — 4 loại: (a) error message thiếu, (b) nhánh logic chưa định nghĩa, (c) ràng buộc data mơ hồ, (d) UI-logic mâu thuẫn. **Bề mặt `service`** — thay (d) bằng nhập nhằng hợp đồng: (a) error catalog thiếu mã lỗi / HTTP status, (b) nhánh logic/decision chưa định nghĩa, (c) request contract mơ hồ (field required?/ràng buộc/enum), (d) state machine hoặc idempotency chưa khai (transition hợp lệ? xử lý request/message trùng?). Liệt kê mục `[TBD]` ra chat.
+3. **Gate quyết định:** Nếu số `[TBD]` chặn-luồng-chính > 0 → khuyến nghị làm rõ trước. Cho phép user chủ động bỏ qua (ghi nhận rủi ro).
+4. **Khung rủi ro "explore" (để MATERIALIZE, không charter):** Đánh dấu sẵn các vùng bất thường (timing/đồng thời/phiên, UX mới, spec còn `[TBD]` không chặn). Các vùng này **KHÔNG** đi charter — Step 02b/03 sẽ phân tích ra oracle xác định và viết thành **case scripted trong KHỐI 2/3** (gap-spec → dòng `[BR]` + Coverage Debt), theo [explore_and_consistency_rules.md](../principles/explore_and_consistency_rules.md) §3–§5. `exploratory` chỉ chừa cho quan sát thẩm mỹ thuần trong KHỐI 1.
+5. **Chuyển tiếp:** Đọc và thực thi [Step 01](step-01-init-slice.md). (Trừ khi đã định tuyến `delta` ở bước 0 → đã sang Step 05.)
+
+> **Quan hệ ecosystem:** Đây là vai trò shift-left tối thiểu *trong* skill. Nguồn chuẩn vẫn là `/ntapp-qa-audit` (Q&A handshake đầy đủ). Step 00 chỉ đảm bảo không bỏ qua shift-left và không scripted-hóa vùng bất định.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-01-init-slice.md

@@ -0,0 +1,39 @@
+# STEP 01: KHỞI TẠO TEST PLAN (SLICE / UNIT)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/iron_rules.md](../principles/iron_rules.md) · [principles/run_mode_rules.md](../principles/run_mode_rules.md) §4 (Context Ledger)
+
+## 1. Mục tiêu
+Đọc input theo `input_type` (đã detect ở Step 00), phân tích cấu trúc Unit, (lane SLICE) lập thứ tự liên kết E2E tổng thể, và **dựng Context Ledger load-once** (fact dùng chung toàn slice/unit) để các màn sau scoped-reload, chống drift + reload dư.
+
+## 2. Các Bước Thực Hiện
+
+> **RẼ NHÁNH theo `input_type` (từ Step 00):**
+> - `input_type=slice` → chạy đầy đủ bước 1 → 6 (nhiều unit, có xếp thứ tự E2E).
+> - `input_type=unit` → **bỏ qua bước 1 và bước 3** (không có nhiều unit để khảo sát/xếp thứ tự). Chỉ có MỘT unit `{id}`; đi thẳng bước 2 (đọc Tổng quan của chính `{id}_detailed_design.md`) → bước 4 (Ledger rút gọn 1 unit) → bước 5 → bước 6. Ở bước 5, "Danh sách luồng E2E" thu về **luồng nội bộ của 1 unit** (các màn/hành động — hoặc operation nếu `service` — trong chính unit đó), "Mapping FE-BE" chỉ khớp FE ↔ BE mà chính unit này gọi.
+>
+> **RẼ NHÁNH theo `surface_type` (từ Step 00) — quyết định Ở CẤP TARGET, cả luồng đi CHUNG 1 nhánh:**
+> - `surface_type=ui` (target có ≥1 màn) → dùng bộ nhãn màn hình (Action/Verify/Nav) + [unit_classification_rules.md](../principles/unit_classification_rules.md). **Xếp thứ tự E2E theo MÀN**; **mọi unit BE là backend** (map theo story / Background), verify bằng oracle API/DB **trong testcase của màn** — **KHÔNG** đưa BE vào thứ tự như bề mặt riêng. Hành vi **y như trước khi có nhánh service**.
+> - `surface_type=ui` **+ bề mặt mượn** (`units:` toàn BE nhưng `What to build`/`demoable` nêu màn của slice khác) → màn host = `[Nav]`, bề mặt = **cụm hành động** `[Delta Action]`; ngân sách UI theo Delta Manifest, ngân sách BE theo `units:` — [borrowed_surface_rules.md](../principles/borrowed_surface_rules.md).
+> - `surface_type=service` (target KHÔNG có màn nào) → dùng bộ nhãn operation (`[Operation]`/`[Effect]`/`[Downstream]`) + [service_surface_rules.md](../principles/service_surface_rules.md) §1. Không có Giao diện; "luồng" = chuỗi operation/bước job; "Mapping FE-BE" đổi thành **Contract Map**.
+> - **KHÔNG có chế độ trộn 2 nhánh trong 1 lần chạy.** Slice có màn = `ui` toàn bộ; muốn test API 1 HUB riêng thì chạy skill trên chính HUB đó (target no-UI → service).
+
+1. **[lane SLICE] Khảo sát Unit:** Đọc danh sách các unit trong file SLICE theo [principles/unit_classification_rules.md](../principles/unit_classification_rules.md) (Mục 1).
+2. **Phân loại Unit:**
+   - *(`surface_type=ui`)* **lane SLICE:** phân loại vai trò từng unit (Action / Verify / Nav) theo [unit_classification_rules.md](../principles/unit_classification_rules.md) (Mục 2). **lane UNIT:** unit `{id}` mặc định `[Action]`; màn phụ điều hướng vào ghi nhận `[Nav]` nội bộ. Đọc phần Tổng quan trong `_detailed_design` của các FE Unit (lane UNIT: chính `{id}`) để nắm mục đích nghiệp vụ (chưa đọc Logic/Dữ liệu/Giao diện).
+   - *(`surface_type=service`)* phân loại vai trò theo [service_surface_rules.md §1](../principles/service_surface_rules.md): `[Operation]` (endpoint/operation đang test — lane UNIT: chính `{id}`), `[Effect]` (bảng DB/event/audit/state là đích verify → nhúng oracle), `[Downstream]` (service/đối tác được gọi → mock, đưa vào Precondition). Đọc phần Tổng quan trong `_detailed_design` để nắm mục đích nghiệp vụ (chưa đọc chi tiết Logic/Dữ liệu/Hợp đồng).
+3. **[lane SLICE] Xác định Thứ tự E2E:** Sắp xếp luồng và khớp nối backend unit theo [principles/unit_classification_rules.md](../principles/unit_classification_rules.md) (Mục 3). *(lane UNIT: bỏ qua — chỉ 1 unit, không có thứ tự liên-unit.)*
+4. **Dựng Context Ledger (LOAD-ONCE):** Theo [run_mode_rules.md](../principles/run_mode_rules.md) §4, tạo mục `## Context Ledger` trong `implementation_plan.md` gom **fact dùng chung toàn slice** (đọc 1 lần, dùng lại mọi màn):
+   - **Overview:** mục tiêu + danh sách unit kèm vai trò (lane SLICE: nhiều unit Action/Verify/Nav · lane UNIT: chỉ `{id}`).
+   - **Delta Manifest** *(chỉ khi có bề mặt mượn — [borrowed_surface_rules.md §2](../principles/borrowed_surface_rules.md)):* bảng cụm hành động + trích dẫn verbatim + control + oracle, kèm `host_screen` (= `[Nav]`) và `host_slice`. Đây là **biên duy nhất** của ngân sách UI.
+   - **BE contract map:** endpoint / story-code / bảng DB mà nhiều màn cùng tham chiếu (gom từ phần Ma trận đồng bộ / Tổng quan trong `_detailed_design` các BE liên quan — chỉ phần *dùng chung*). *(lane UNIT: chỉ các BE mà chính `{id}` gọi.)* **Với bề mặt `service` đây là Contract Map CHÍNH** (endpoint/request/response/error catalog/side-effect/state machine — theo [service_surface_rules.md §2.3](../principles/service_surface_rules.md)), không phải phần phụ.
+   - **UI Text Source Map (luật provenance — KHÔNG bảng glossary dùng chung):** ghi 1 dòng luật: generate CHỈ đọc DD + qa_report; mọi chuỗi hiển thị verbatim từ DD + cite; DD im lặng / chỉ i18n-key → `[TBD]`+Q&A; label-vs-code drift → runtime qa-robot assert. **Nhãn cụ thể KHÔNG gom về Ledger — mỗi màn tự liệt kê ĐẦY ĐỦ TỪNG element ở [Step 02](step-02-plan-screen.md) Chốt 3.** Nhãn phải-giống-nhau-cross-screen lấy từ Bảng Override (Step 00 §1a).
+   - **Core rules đã nạp:** `view_file` toàn bộ `references/kbkt-generation/00-core/*` MỘT LẦN. Ngoài ra: *(ui)* + toàn bộ `01-ui/*` nếu có ≥1 FE unit (lane UNIT: khi `{id}` là FE) · *(service)* + toàn bộ `10-be/*` (service surface LUÔN áp backend rules). Ghi danh sách file đã nạp vào Ledger; Step 02/03 tái dùng, KHÔNG `view_file` lại (xem [run_mode_rules.md §4](../principles/run_mode_rules.md)).
+   - **Data sources registry (BẮT BUỘC — forcing function chống bịa source_id):** MỞ & đọc `{qa_artifacts}/data_sources.yaml` NGAY tại bước này (registry dùng-chung nhiều slice, theo [dynamic_data_rules.md §4](../principles/dynamic_data_rules.md)). Ghi vào Ledger **bảng `source_id` khả dụng** kèm, với mỗi nguồn: connection (`env_prefix`), `create_api` operation + `reuse_check` (Tier 0) có sẵn. File KHÔNG tồn tại → ghi Ledger `data_sources: [CHƯA CÓ]` và cảnh báo "mọi field Loại 1/2 sẽ phải `[UNRESOLVED-BACKEND]` cho tới khi QA Lead khai registry". **CẤM** Step 03 viết bất kỳ `$db.query/$seed.*` với `source_id` không có trong bảng này.
+   - Nếu slice > 12 màn Action → ghi cảnh báo + khuyến nghị chunk sub-batch (6–8 màn/đợt). *(lane UNIT thường ít màn — bỏ qua cảnh báo này.)*
+5. **Tạo Implementation Plan:** Xuất thông tin dưới dạng `IsArtifact: true`, `ArtifactType: implementation_plan`, `RequestFeedback: true` gồm:
+   - **Context Ledger** (mục 4 ở trên).
+   - **Precondition:** *(ui)* danh sách unit `[Nav]` + tài liệu hiện có *(bề mặt mượn: màn host = ĐÚNG 1 dòng, cấm case kiểm màn)* · *(service)* danh sách `[Downstream]` cần mock + auth/token cần có + tài liệu (`_detailed_design`/integration spec) của chúng. *(lane UNIT: điều kiện vào chính `{id}`.)*
+   - **Danh sách luồng:** *(lane SLICE)* Thứ tự chuyển hướng các unit `[Action]`/`[Verify]` (ui) hoặc chuỗi `[Operation]` (service) dạng text · *(lane UNIT)* các màn/hành động (ui) hoặc operation/bước job (service) nội bộ trong chính `{id}` dạng text (Không vẽ sơ đồ).
+   - **Mapping FE-BE / Contract:** *(ui)* khớp FE-BE theo story code · *(service)* Contract Map (endpoint ↔ side-effect ↔ downstream) theo story code (lane UNIT: chỉ BE mà `{id}` gọi).
+6. **[HITL GATE - DỪNG CHỜ DUYỆT]:** In phân loại unit + Context Ledger ra chat (**có bề mặt mượn → in Delta Manifest, chờ user ký trước khi bung case**). Xác định bề mặt đầu tiên sẽ thực thi — unit `[Action]` (ui) hoặc `[Operation]` (service) (lane UNIT: chính `{id}`). Chờ User phê duyệt trước khi chuyển sang [Step 02](step-02-plan-screen.md). *(Gate này giữ ở MỌI lane — kể cả `batch` — vì là điểm chốt luồng.)*

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-02-plan-screen.md

@@ -0,0 +1,29 @@
+# STEP 02: LẬP PLAN CHO BỀ MẶT TEST (MÀN HÌNH hoặc OPERATION)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/iron_rules.md](../principles/iron_rules.md) (đặc biệt R1, R5) · [principles/run_mode_rules.md](../principles/run_mode_rules.md) §3–4.
+
+## 1. Mục tiêu
+Lập **Math Forcing (phân rã số case theo control × rule)** + Test Plan cho **bề mặt hiện tại** — màn hình (`surface_type=ui`) hoặc operation/endpoint (`surface_type=service`). KHÔNG bung checklist ≥N dòng vào plan (materialize 1-1 ở Step 03 — xem Chốt 8).
+
+> **VÒNG LẶP PER-MÀN (BẮT BUỘC):** Step 02 chạy cho **ĐÚNG MỘT màn/operation/cụm hành động** — chính bề mặt đang tới lượt trong thứ tự E2E (Step 01). Làm xong Step 02 của màn này thì đi thẳng **02b → 03 cho CHÍNH màn này** rồi MỚI quay lại Step 02 cho màn kế. **CẤM** lập plan (Step 02) cho nhiều màn cùng lúc rồi mới chạy 02b/03 hàng loạt — mỗi màn là một chu trình khép kín `02 → 02b → 03`. Đây là điểm mù tái diễn khi output dài: "dài quá" KHÔNG bao giờ là lý do gộp pha xuyên màn; dài thì chia nhiều lần ghi.
+
+## 2. Các Bước Thực Hiện
+
+> **RẼ NHÁNH theo `surface_type` (từ Step 00 / Ledger):**
+> - **`surface_type=service` (không giao diện)** → chạy **9 chốt chặn service** tại **[principles/service_surface_rules.md §2](../principles/service_surface_rules.md)** (Contract Map thay Ánh xạ Nhãn UI; rule 10-be + request-validation tầng payload; case từ error catalog / state machine / idempotency / resilience). **BỎ** mục 3 (Ánh xạ Nhãn Giao diện) bên dưới. Sau đó vẫn sang [Step 02b](step-02b-risk-allocation.md) → [Step 03](step-03-write-testcase.md).
+> - **`surface_type=ui` (mặc định)** → chạy 9 chốt chặn UI dưới đây.
+> - **`surface_type=ui` + bề mặt mượn** → vẫn 9 chốt UI, nhưng **bề mặt = cụm hành động** và Chốt 3/4/6/8 áp override tại [borrowed_surface_rules.md §6](../principles/borrowed_surface_rules.md); màn host chỉ là Precondition.
+
+**Nhánh `ui` — 9 chốt chặn tại [principles/slice_planning_rules.md](../principles/slice_planning_rules.md):**
+
+1. **Nạp trí nhớ E2E:** Xác định Màn hình/Widget hiện tại từ `implementation_plan.md` + **Context Ledger** (fact dùng chung — không đọc lại) (Chốt chặn 1).
+2. **Nạp tài liệu thiết kế (SCOPED RELOAD):** Theo [run_mode_rules.md](../principles/run_mode_rules.md) §4 — dùng `view_file` đọc **chỉ** phần Giao diện (+ phần Logic/Dữ liệu khi cần) trong `_detailed_design` của FE *màn hiện tại* và BE *trực tiếp* map màn đó. Fact dùng chung (slice overview, BE contract map) lấy từ **Context Ledger** (nhãn cụ thể do màn tự map đầy đủ ở Chốt 3, không glossary chung), KHÔNG reload toàn bộ `_detailed_design` của *mọi* BE lại (Chốt chặn 2).
+3. **Ánh xạ Nhãn Giao diện (LIỆT KÊ ĐẦY ĐỦ TỪNG ELEMENT):** Điền "Nhật Ký Đọc File" và ánh xạ **MỌI** element của màn (control/tiêu đề/placeholder/cột bảng/empty-state/banner/dialog/toast/inline-error) sang **Nhãn hiển thị UI** verbatim + cite DD (Chốt chặn 3). KHÔNG gom về glossary chung; **thiếu element = thiếu testcase ở Step 03**.
+4. **Lập Bảng Mapping Rule:** Khớp các control thực tế với file rule tương ứng trong `references/kbkt-generation/` (Chốt chặn 4). `00-core/*` + `01-ui/*` đánh dấu "đã nạp qua Context Ledger" (Step 01), không phải load mới.
+5. **Nạp Rule kiểm thử:** BẮT BUỘC dùng `view_file` cho từng file Rule **per-screen chưa có trong Ledger** (control-specific: `02-input/*`, `03-selection/*`, ...) trong bảng Mapping để nạp ngữ cảnh (Chốt chặn 5).
+6. **Tính toán số lượng case:** Sử dụng Decision Table/Math Forcing để tính tổng số testcase tối thiểu (Chốt chặn 6). Nếu tổ hợp lớn (> 30 dòng), thực hiện viết và chạy script Python dùng `allpairspy` để sinh ma trận tối ưu.
+7. **Tự đối soát (Self-Reflection):** Rà soát độ bao phủ tổ hợp đa nguồn (Chốt chặn 7).
+8. **Chốt chặn 8 — KHÔNG sinh checklist vào plan (ĐÃ BỎ):** Plan KHÔNG có section Checklist / danh sách `[ ]`. `X` (tổng math-forcing) lấy từ **Chốt chặn 6**. Chỉ ghi kèm **phân định Action-Verify** + (định nghĩa) HARD CHECK grep cho Step 03 (xem [slice_planning_rules.md](../principles/slice_planning_rules.md) Chốt 8). Materialize 1-1 mỗi rule-case (và mỗi dòng Ma Trận Quyết Định) → 1 dòng testcase thực hiện ở [Step 03](step-03-write-testcase.md); Math Check `X = Y` (`Y` = số dòng testcase).
+9. **Ghi và duyệt Plan (HITL GATE):** Nối tiếp (append) Kế hoạch vào `implementation_plan.md` theo đúng định dạng tại **[references/templates/plan_template.md](../references/templates/plan_template.md)** (Chốt chặn 9). **Dừng/defer theo `run_mode`** — áp [run_mode_rules.md §3](../principles/run_mode_rules.md) (`full` = dừng duyệt + narrate; `batch` = defer + checkpoint im lặng → gộp Step 04).
+   - *Chuyển tiếp:* Thực thi [Step 02b](step-02b-risk-allocation.md) để gán **policy `@risk/@exec` per rule-group** (từ Math Forcing), rồi sang [Step 03](step-03-write-testcase.md).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-02b-risk-allocation.md

@@ -0,0 +1,38 @@
+# STEP 02b: RISK-BASED ALLOCATION (Risk tier + Exec routing)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/risk_based_allocation_rules.md](../principles/risk_based_allocation_rules.md) · [principles/automation_contract_rules.md](../principles/automation_contract_rules.md) · [principles/explore_and_consistency_rules.md](../principles/explore_and_consistency_rules.md) (Oracle phủ định + Surface Invariant + TBD-escape)
+> **Vị trí:** Chạy SAU [Step 02](step-02-plan-screen.md) đã duyệt (plan/Math Forcing có rồi), TRƯỚC [Step 03](step-03-write-testcase.md). Per màn `[Action]`, trong vòng lặp.
+
+## 1. Mục tiêu
+Gán **policy cho từng rule-group** (mỗi control × rule trong Math Forcing Step 02) hai thuộc tính `@risk` (P0/P1/P2) và `@exec` (automate/manual/exploratory) + `@oracle`/`@target`, để Step 03 áp xuống từng dòng testcase khi bung (tag `.feature` + cột `Exec`).
+
+## 2. Các Bước Thực Hiện
+
+1. **Đọc mode:** Lấy `risk_mode` từ config cascade (Layer 3 `.bmm-config.yaml`, mặc định `exhaustive`). In rõ mode đang dùng ra chat.
+2. **Chấm `@risk`:** Với mỗi rule-group, gán P0/P1/P2 theo Likelihood × Impact ([risk_based_allocation_rules.md](../principles/risk_based_allocation_rules.md) §2). Security luôn ≥ P1 (IDOR/SQLi = P0).
+3. **Gán `@exec` + `@oracle` + `@target`:** Theo bảng chính sách §3–§4. Mỗi `automate` phải có ≥1 oracle tự động + `@target` (mặc định `robot`).
+3b. **Surface Invariant + Oracle phủ định (`view_file` [explore_and_consistency_rules.md](../principles/explore_and_consistency_rules.md) §1–§3):**
+   - Lập **Surface Inventory** cho bề mặt hiện tại: *(ui)* dùng bảng bề mặt UI (§2.1: Search/Filter, List/Grid, Có phân quyền, Action ghi, Filter+list cùng màn, Dependent select, Field maxlength) · *(service)* dùng bảng bề mặt service tại [service_surface_rules.md §4](../principles/service_surface_rules.md) (Write op, Money op, Idempotent/consumer, Query/list, Có phân quyền, State-changing, Gọi downstream). Liệt kê bất biến bắt buộc + data đối nghịch phải seed cho từng loại. Ghi vào `implementation_plan.md`.
+   - Với mỗi rule-group (và case đối nghịch của nó), ép **oracle phủ định bất biến** (§1): cấm kỳ vọng nông kiểu "list có dữ liệu là pass"; phải nêu **con số + điều kiện phủ định**. Spec im lặng → `[TBD]` + Q&A, không bịa.
+   - Case bị chặn do spec gap → **TBD-escape** (§3): **viết case scripted** (`@exec:automate`/`manual`) trong KHỐI 2/3 với **expected = contract canonical** (chú thích `[BR]`) hoặc `[TBD]`; kèm 1 mục Q&A blocking + 1 dòng Coverage Debt Ledger (Mục 5.6, in ở Step 04). **KHÔNG** hạ xuống `exploratory`, KHÔNG để case bốc hơi.
+4. **Áp mode + rebalance ngân sách:**
+   - `exhaustive`: giữ nguyên `cases_count` mọi rule (không cắt).
+   - `risk-gated`: cắt P2 visual/display về smoke subset (phần dư **drop hẳn**, KHÔNG đẩy `exploratory`). **Ghi rõ công thức trừ** ra chat (vd `46 − 9 = 37`) để Math Check Gate ở Step 03 dùng đúng số kỳ vọng.
+   - **Rebalance ([§6](../principles/risk_based_allocation_rules.md)):** validation single-field cùng-logic viết **N `Scenario` riêng per-case** (data nạp từ `fixtures.yaml`, count không đổi — CẤM `Scenario Outline`); ghim chiều integration/behavior (filter-correctness, cross-actor, volume, error-code side-effect, stale-state) = P0/P1 — cấm risk-gated cắt, cấm rút về 1 case oracle nông.
+5. **Gán policy per rule-group:** Ghi vào bảng **Math Forcing** trong `implementation_plan.md` — mỗi (control × rule) 1 dòng policy (default + ngoại lệ sub-split) theo định dạng tại [risk_based_allocation_rules.md](../principles/risk_based_allocation_rules.md) §5. Step 03 áp policy này xuống từng dòng testcase khi bung (điền cột Độ ưu tiên/Exec). KHÔNG cần checklist ≥N dòng trong plan.
+   ```
+   <control> × <rule> → P0/P1/P2 · automate/manual · @oracle:… (trừ <sub-case>, vd hiển thị placeholder/label = P2·automate; visual zoom/font = P2·manual)
+   ```
+6. **Materialize rủi ro "explore" vào KHỐI 2/3 (KHÔNG tách charter):** Mọi heuristic CH-FLEX/CH-CMP ([explore_and_consistency_rules.md](../principles/explore_and_consistency_rules.md) §4–§5) và mọi rủi ro timing/đồng thời/phiên/[TBD] phải **phân tích ra oracle xác định** rồi viết thành **dòng testcase scripted** (`@exec:automate`/`manual`) trong **KHỐI 2 (Functional/E2E resilience)** hoặc **KHỐI 3 (Security/RBAC)** ở Step 03 — vd double-submit→đúng 1 bản ghi, đa tab→409, session timeout→401, degraded→banner+header. **KHÔNG** gom thành charter, **KHÔNG** để `@exec:exploratory` sinh section riêng. Chỉ chừa `exploratory` cho quan sát thẩm mỹ thuần (nằm trong KHỐI 1 UI).
+7. **Self-Audit Allocation Gate:**
+   - Mọi mục đã có đủ `@risk` + `@exec` (+ `@target` nếu automate). Không sót.
+   - Không có P0 nào là `exploratory`.
+   - **Không còn rủi ro nào được đẩy sang charter/khối exploratory riêng:** mọi mục timing/đồng thời/phiên/[TBD] đã nằm trong KHỐI 2/3 dạng scripted. Nếu còn mục `exploratory` → nó phải là visual thuần trong KHỐI 1, ngược lại → gate FAIL, phân tích lại ra oracle.
+   - **Oracle-first theo bề mặt:** *(ui)* **UI-first** — mọi mục test được qua UI có `@oracle:ui` (rule cứng §3); không có mục drive UI mà oracle backend-only. *(service)* **API-first** ([service_surface_rules.md §3](../principles/service_surface_rules.md)) — mọi mục có `@oracle:api` (hoặc `@oracle:db`/`@oracle:msg` khi là job/consumer không trả HTTP); CẤM `@oracle:ui` (không có UI); CẤM oracle nông "trả 200 là pass" (phải assert body/schema + side-effect).
+   - **Rebalance (§6):** cụm ≥2 mục single-field cùng-logic viết per-case (N `Scenario`/dòng riêng, data ở fixtures — KHÔNG gom Outline); mọi chiều integration/behavior đạt `cases_count` rule nguồn, không có chiều nào chỉ 1 case oracle "list hiển thị".
+   - **Surface Invariant (explore §2.2):** in bảng đối soát `<bề mặt> × <bất biến> → <@id case | THIẾU>`. Còn ô `THIẾU` → bổ sung case (hoặc TBD-escape §3 nếu chặn vì spec gap) trước khi sang Step 03.
+   - Số case kỳ vọng (sau mode) được tính lại và ghi ra chat — đây là `X` cho Math Check Gate của Step 03.
+8. **Chuyển tiếp:** KHÔNG có HITL gate riêng (annotation nằm trong plan đã duyệt). Đọc và thực thi [Step 03](step-03-write-testcase.md) cho **màn hiện tại** (chính màn vừa annotate). **KHÔNG** annotate 02b gộp cho nhiều màn, và KHÔNG bỏ qua Step 03 của màn hiện tại để nhảy sang màn khác — mỗi màn khép kín `02 → 02b → 03` rồi mới sang màn kế (theo vòng lặp per-màn ở Step 03 §11).
+
+> **Lưu ý không lấn việc:** Bước này KHÔNG sinh testcase, KHÔNG sinh selector. Chỉ annotate. Việc render `.feature`/markdown/fixtures là của Step 03–04.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-03-write-testcase.md

@@ -0,0 +1,52 @@
+# STEP 03: VIẾT TESTCASE (TRIPLE-EMIT: .feature + markdown + fixtures)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/iron_rules.md](../principles/iron_rules.md) (đặc biệt R2, R3) · [principles/automation_contract_rules.md](../principles/automation_contract_rules.md) (Triple-Emit + tag dictionary).
+> **Tiền điều kiện:** [Step 02b](step-02b-risk-allocation.md) đã gán **policy `@risk/@exec/@oracle/@target` per rule-group** (trong Math Forcing của plan).
+
+## 1. Mục tiêu
+Bung **Math Forcing + rule-list** (đã có policy `@risk/@exec` per rule-group từ Step 02b) thành **3 artifact đồng bộ** cho màn hình hiện tại: bảng testcase 11 cột (markdown view — bung 1-1 mỗi rule-case + mỗi dòng Ma Trận Quyết Định, áp policy xuống cột Độ ưu tiên/Exec), `{id}_testspec.feature` (canonical), và bổ sung dataset vào `{id}_fixtures.yaml`.
+
+## 2. Các Bước Thực Hiện
+Thực hiện theo các chốt chặn quy định tại **[principles/testcase_generation_gates.md](../principles/testcase_generation_gates.md)**:
+
+1. **Pre-flight Load:** Đọc `references/kbkt-generation/00-core/kbkt-format-rule.md` và `references/templates/slice_testcase_table_template.md` (Mục 1.1).
+1b. **GATE Plan-exists (per MÀN/OPERATION — BẮT BUỘC, in kết quả):** Trước khi viết dòng testcase đầu tiên của **màn/operation hiện tại `{SCR-ID}`**, xác nhận section Step 02 của **chính `{SCR-ID}` đó** trong `implementation_plan.md` đã có **phần Math Forcing (Chốt chặn 6)**: công thức phân rã (control → rule kèm `cases_count` → subtotal) + **tổng `X`** cho màn (theo [slice_planning_rules.md](../principles/slice_planning_rules.md) Chốt 6 + Chốt 8). In ra chat `plan({SCR-ID}): X={tổng math-forcing của màn đó}`. Nếu **thiếu section Step 02 của màn này** HOẶC **không có `X`/không có phân rã** → **DỪNG NGAY**, quay lại [Step 02](step-02-plan-screen.md) lập Math Forcing cho màn này TRƯỚC, rồi mới emit. **Step 03 chịu trách nhiệm bung ĐỦ `X` dòng testcase 1-1** (mỗi rule-case + mỗi dòng Ma Trận Quyết Định = 1 dòng) — plan KHÔNG còn section Checklist/≥X dòng `[ ]`. ⚠️ Điểm mù tái diễn: khi output đã dài, agent hay gộp Step 02→03 của màn thứ 2+ và bỏ plan — "output dài" KHÔNG bao giờ là lý do bỏ bước; quá dài thì chia nhiều lần ghi, cấm cắt. Mỗi màn PHẢI có plan Step 02 riêng như màn đầu tiên.
+2. **Tải lại Context (SCOPED):** Theo [run_mode_rules.md](../principles/run_mode_rules.md) §4 — *(ui)* tải lại phần Giao diện (+ Logic/Dữ liệu) của FE *màn hiện tại* và BE map · *(service)* tải lại phần Logic/Dữ liệu/**Hợp đồng API** của operation hiện tại và `[Downstream]` map. Fact dùng chung lấy từ **Context Ledger** để chống trôi bộ nhớ mà không reload toàn bộ.
+3. **Ánh xạ Control / Field:** *(ui)* dùng đúng Nhãn hiển thị từ phần Giao diện · *(service)* dùng đúng tên field request/response từ **Contract Map** (Step 02, service_surface_rules §2.3) — KHÔNG có nhãn UI để ánh xạ.
+3c. **Chốt TEXT hiển thị TỪ NGUỒN (chống bịa):** Trước khi viết bất kỳ Expected có **chuỗi hiển thị** (placeholder/label/option/message/empty-state/tiêu đề/tooltip), tra **UI Text Source Map** trong Context Ledger (Step 01). Có giá trị resolved → ghi **verbatim + cite** `(i18n: <key>)`/`(DD §x)`; i18n key rỗng/chưa dịch → ghi `[TBD]` + thêm 1 mục Q&A. **CẤM tự đặt text theo prior/"UI thường thấy"** (vd placeholder `"Tất cả"`, `"Nhập tên..."`) — không có trong map và không phải [TBD] thì KHÔNG được viết text. (Enforce cơ học ở [testcase_generation_gates.md](../principles/testcase_generation_gates.md) HARD CHECK "Provenance TEXT hiển thị".)
+4. **Nạp Rule:** Đọc toàn bộ các file Rule kiểm thử đã liệt kê trong bảng Mapping Rule ở Step 02.
+5. **Materialize Testcase 1-1 (Zero-Summarization):** Từ **phần Math Forcing Step 02 (Chốt 6)** (phân rã control → rule kèm `cases_count`) + danh sách *"Testcase Bắt Buộc"* của từng rule đã nạp, bung mỗi rule-case (kể cả mỗi dòng Ma Trận Quyết Định) thành **1 dòng testcase độc lập**, ID liên tục, KHÔNG gộp. Đối soát **Math Check `X = Y`** — `X` = tổng math-forcing chốt ở Step 02, `Y` = số dòng testcase thực ghi (Mục 1.2 - 5). (Plan KHÔNG còn section Checklist — nguồn bung là Math Forcing + rule-list.)
+6. **Viết bảng E2E 11 cột (VIEW):** Vẽ bảng 3 khối theo template `slice_testcase_table_template.md`. **Cột `Exec`** lấy từ annotation Step 02b (Mục 1.2 - 6).
+   - *(ui)* 3 khối = UI / Functional / ATTT theo từng Màn hình Action; Expected result phân lớp **UI:/API:/DB:/Log:**; cột Công cụ = `Chrome`.
+   - *(service)* 3 khối = **Hợp đồng & Request Validation / Nghiệp vụ & E2E / Phân quyền & ATTT** theo từng Operation; Expected result phân lớp **API:/DB:/MSG:/Log:** (KHÔNG có UI:); cột Công cụ = `Postman`/`RequestsLibrary`; khối "Danh sách UI Controls" đổi thành "Danh sách Endpoint/Operation & Hợp đồng".
+7. **Truy vết E2E:** Áp dụng kiểm chứng đa tầng theo [e2e-traceability-rule.md](../references/kbkt-generation/00-core/e2e-traceability-rule.md): *(ui)* UI → API → DB → UI đích · *(service)* Request → API(status+body) → DB/side-effect → MSG/event → Log(audit).
+7b. **GATE Đối chiếu Bảng Override (audit thắng DD — bắt buộc, TRƯỚC khi emit):** Với **mỗi** dòng testcase vừa map, nếu control/field/feature/enum của nó nằm trong **Bảng Override** dựng ở [Step 00 §1a](step-00-shiftleft-gate.md), thì `Kết quả mong muốn` + `Data Test` **phải khớp quyết định canonical của audit**, KHÔNG theo `_detailed_design` khi hai nguồn lệch (luật precedence Step 00 §1b). Nếu phát hiện dòng nào đang mô tả tính năng/trạng thái mà audit đã phán **đã gỡ/đã đổi** → sửa về canonical hoặc đánh dấu `❌ REMOVED` (exec=N/A, giữ ID cho R8) theo Step 00 §1c. **In ra chat danh sách dòng đã đối chiếu + dòng đã sửa theo override.** Lệch mà không sửa = vi phạm R1.
+8. **Emit `.feature` (CANONICAL):** CHỈ sinh các `Scenario` cho dòng testcase nào có `@exec:automate` hoặc `@exec:exploratory` (bỏ qua các dòng `@exec:manual`) vào `{qa_artifacts}/{id}/{id}_testspec.feature` theo [testspec_feature_template.feature](../references/templates/testspec_feature_template.feature). Gắn đủ tag theo dictionary ([automation_contract_rules.md](../principles/automation_contract_rules.md) §2): `<@surface> @id @block @tech @rule @risk @exec [@target] @oracle` — trong đó `<@surface>` = **`@scr:<unit_id>`** (ui) hoặc **`@svc:<unit_id>`** (service). Bước `Given/When/Then`: *(ui)* thao tác trên màn qua Nhãn UI · *(service)* gọi request/nhận response/quan sát side-effect (không "user ở màn"). **Mỗi case = 1 `Scenario` tường minh riêng — CẤM `Scenario Outline`/`Examples`** (kể cả BVA/EP cùng-logic: viết N `Scenario`, chống trùng bằng cách nạp giá trị từ `fixtures.yaml` mỗi case 1 dataset — [automation_contract_rules §1](../principles/automation_contract_rules.md)). Cùng `@id` với dòng markdown.
+9. **Emit `fixtures.yaml` (DATA):** Với mỗi dòng `@exec:automate`/`@exec:exploratory`, thêm 1 `dataset` cho `@id` vào `{qa_artifacts}/{id}/{id}_fixtures.yaml` theo [fixtures_template.yaml](../references/templates/fixtures_template.yaml). **Cách ghi data theo [automation_contract_rules.md §1 "Inline-value vs fixture_ref"](../principles/automation_contract_rules.md):** giá trị field TĨNH dùng-1-lần (validation/BVA/security/space) → **ghi thẳng inline** `data: {…}` trên dòng dataset, KHÔNG tạo fixture tên riêng; chỉ dùng `fixture_ref` cho data **dùng chung ≥2 dataset / payload phức tạp / động** (Loại 1-2 → `$db.query/$seed.*` theo [dynamic_data_rules.md](../principles/dynamic_data_rules.md)). Mục `fixtures[]` chỉ chứa các key thoả điều kiện đó — CẤM fixture chỉ-dùng-1-lần cho giá trị tĩnh. Giá trị truy về phần Dữ liệu (`_detailed_design`) (R1), thiếu → `[TBD]`. **Cột "Data Test" markdown ghi CHÍNH giá trị đó** (vd `name: "   "`) cho case inline, hoặc `fixture: {key}` khi trỏ fixture dùng chung — KHÔNG bịa tên fixture chưa định nghĩa. **Gate động:** trước khi viết bất kỳ `$db.query/$seed.*`, đối chiếu bảng `source_id` registry đã nạp ở Ledger (Step 01) — không khớp → DỪNG, KHÔNG bịa; ưu tiên `reuse_check`/`create_api` sẵn có thay vì tự chế SQL.
+10. **Sync Invariant + Self-Audit (Mục 1.2 - 8) — mô hình "1 số gốc + 2 phép chiếu" ([automation_contract_rules.md §1](../principles/automation_contract_rules.md) CANONICAL):** Quét 3 khối tồn tại; áp:
+   - **Gate gốc (Math Check):** `Y == X` — `X` = tổng case **chốt cụ thể ở Step 02 Math Forcing** (GỒM cả manual; Step 02b chỉ dán nhãn Exec, không đổi tổng), `Y` = **tổng** dòng markdown thực ghi (KỂ CẢ manual). Báo `X = Y` ra chat.
+   - **Phép chiếu 1:** `count(Scenario/@id trong .feature) == A + E` — *đếm bao nhiêu dòng route sang* `.feature` (A=automate, E=exploratory).
+   - **Phép chiếu 2:** `count(dataset trong fixtures.yaml) == A` (exploratory chỉ `note:`, không dataset; manual không sang `.feature`/fixtures).
+   - `A/E/M` là **phân hoạch của `X` theo cột Exec** (mỗi dòng mang đúng 1 nhãn), KHÔNG đếm lại tổng. **CẤM** viết "3-way ==" gộp `X` với `A+E`/`A`. Lệch bất kỳ đâu → sửa (KHÔNG hạ manual, KHÔNG drop @id).
+10b. **QUÉT CƠ HỌC anti-pattern (bắt buộc, trước HITL — "quét để bắt", không dựa "đọc để nhớ"):** Rà toàn bộ dòng testcase vừa sinh của màn/operation hiện tại, bắt và SỬA 4 mẫu lỗi kinh điển trước khi ghi:
+   - **(a) Expected mơ hồ:** cấm cụm rỗng nghĩa đứng một mình — "hiển thị đúng", "theo thiết kế", "đúng thiết kế", "hợp lệ", "có placeholder", "bình thường", "OK". Mỗi expected phải nêu **hệ quả quan sát được cụ thể** (giá trị / text nguyên văn / trạng thái). Vi phạm [kbkt-format-rule](../references/kbkt-generation/00-core/kbkt-format-rule.md) → sửa ngay.
+   - **(b) Thiếu phân lớp:** case có ghi DB/API/side-effect nhưng expected chỉ 1 lớp → bổ sung đủ theo thứ tự ưu tiên *(ui)* **UI → API → DB → Log** (dòng UI bắt buộc khi có hệ quả UI) · *(service)* **API → DB → MSG → Log**. Case chạm màn mà thiếu dòng `UI:` = lỗi.
+   - **(c) Case trùng:** sort theo `(control + hành vi + expected)`; hai dòng cùng control mà expected 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. CẤM 2 KB khác số nhưng nội dung y hệt.
+   - **(d) Value/text không truy nguồn:** mọi `N` (maxlength: tách **N_spec** nghiệp vụ vs **N_attr** DOM theo [maxlength-rule](../references/kbkt-generation/02-input/maxlength-rule.md)), message lỗi, placeholder, empty-state phải **verbatim từ spec/canonical** HOẶC **`[TBD]` + Q&A** — CẤM ghi mô tả tự chế ("có placeholder"), CẤM bịa text/icon không có trong nguồn.
+   - **(e) Mã nội bộ lọt nội dung (BẮT BUỘC quét — theo [slice_planning_rules.md §8 HARD CHECK](../principles/slice_planning_rules.md)):** dòng testcase phải dùng NHÃN hiển thị, KHÔNG chứa mã control/section/mode/unit (`F-0x`,`T-0x`,`A1`,`B1`,`Section A-F`,`Mode A-B`,`SCR-*`…). Chạy lệnh quét ở §8 trên file markdown vừa ghi (bỏ qua bảng legend + ref cuối dòng); còn kết quả → sửa hết trước bước 11.
+   - In ra chat số dòng đã quét + số dòng sửa theo từng nhóm (a/b/c/d). Còn vi phạm → sửa hết rồi mới sang bước 11.
+10c. **KIỂM ĐỊNH TUYẾN dynamic-data (BẮT BUỘC — chống gán sai `source_id` theo miền field, [dynamic_data_rules.md §2b](../principles/dynamic_data_rules.md)):** Sau khi ghi `fixtures.yaml` của màn, đối chiếu **từng dataset động** với bảng `sub_system → source_id` dựng từ `data_sources.yaml` của project. Bắt 3 vi phạm §2b: (i) mọi field động gán CÙNG 1 source (default lười); (ii) field sub-system X trỏ `source_id` owner ≠ X; (iii) sub-system không có source trong registry mà không đánh `[UNRESOLVED-BACKEND]`. Vi phạm → **DỪNG**, route lại từng field (cross-source ghi từng field riêng; mock/degraded ghi rõ) rồi mới sang bước 11; in số dòng vi phạm + đã sửa ra chat.
+   - *Trợ giúp cơ học (grep) — **thay token theo `data_sources.yaml` của CHÍNH project**, mẫu dưới là ví dụ project BMS (PMT/PCM/Policy), KHÔNG phải luật cứng:*
+   ```bash
+   # (1) field của sub-system B (<tokenB>) nhưng gán source của sub-system A mà thiếu source đúng của B → FAIL
+   grep -nE '<tokenB>' {id}_fixtures.yaml | grep -iE '<sourceA>' | grep -viE '<sourceB>|mock|degraded'
+   # (2) sub-system C không có source trong registry, coi như thật (không mock) mà thiếu [UNRESOLVED-BACKEND] → FAIL
+   grep -nE '<tokenC>' {id}_fixtures.yaml | grep -vE '^[0-9]+:[[:space:]]*#' | grep -viE 'UNRESOLVED|mock|degraded|no source|không có source'   # bỏ dòng comment (lưu ý grep -n có tiền tố "NN:")
+   # Ví dụ BMS: <tokenB>=productCode|PCM ; <sourceA>=pmt_profile|pmt_pending ; <sourceB>=pcm_catalog ; <tokenC>=Policy|chính sách
+   ```
+11. **Ghi file & Dừng duyệt (HITL GATE):** Ghi cả 3 artifact (markdown + `.feature` + `fixtures.yaml`) vào `{qa_artifacts}/{id}/` (Tuân thủ [principles/markdown_safety_rules.md](../principles/markdown_safety_rules.md) cho markdown). **Dừng/defer theo `run_mode`** — áp [run_mode_rules.md §3](../principles/run_mode_rules.md) (`full` = dừng duyệt từng màn; `batch` = in `X = Y` rồi auto-proceed, HITL gộp về Step 04; lệch Math Check/Sync → rớt về dừng-tại-màn).
+   - *Chuyển tiếp (VÒNG LẶP PER-MÀN — BẮT BUỘC tuần tự):* Nếu **CÒN** màn/operation chưa xử lý → **quay lại [Step 02](step-02-plan-screen.md) cho MÀN KẾ TIẾP** và chạy TRỌN chuỗi `02 → 02b → 03` cho riêng màn đó (plan/Math Forcing → policy @risk/@exec → triple-emit → HITL) TRƯỚC khi đụng tới màn sau. **TUYỆT ĐỐI KHÔNG** gom Step 02 (+02b) cho nhiều màn rồi mới quay lại emit Step 03 hàng loạt — mỗi màn là **một chu trình khép kín**. Chỉ khi **đã emit xong bề mặt CUỐI CÙNG** mới tự động chuyển sang [Step 04](step-04-finalize-testcase.md).
+   - *Legacy:* Nếu config `emit_automation: false` → chỉ ghi markdown (bỏ bước 8–9), hành vi như bản cũ.
+
+> **Bridge robot theo bề mặt (ghi để không lệch với `/ntapp-qa-robot`):** dòng `@exec:automate` bề mặt **`service`** → qa-robot sinh keyword **RequestsLibrary vẫn tổ chức POM** (mỗi endpoint/operation = 1 "service object" đóng vai page-object, tách khỏi test case như POM tách locator); **KHÔNG cần `ui_schema_{id}.json`**. Do đó `fixtures.yaml#automation_prereq` cho service khai `base_url` + `auth` + `api_contract` + `mocks` (các `[Downstream]`) thay cho `ui_schema_required` — theo [service_surface_rules.md §5](../principles/service_surface_rules.md).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-04-finalize-testcase.md

@@ -0,0 +1,26 @@
+# STEP 04: HOÀN THIỆN DATA SETUP VÀ QUẢN LÝ LỖI (FINALIZATION)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/iron_rules.md](../principles/iron_rules.md) · [principles/run_mode_rules.md](../principles/run_mode_rules.md) §3 (batch review).
+
+## 1. Mục tiêu
+Hoàn thiện dữ liệu mồi, môi trường, quy trình defect; **đóng gói + kiểm tính toàn vẹn cả 3 artifact** (markdown + `.feature` + `fixtures.yaml`); in Coverage Debt Ledger.
+
+## 2. Các Bước Thực Hiện
+Thực hiện các quy định tại **[principles/finalization_rules.md](../principles/finalization_rules.md)** + [automation_contract_rules.md](../principles/automation_contract_rules.md):
+
+1. **Đọc dữ liệu thiết kế:** Đọc lại file testcase đã sinh và phần Dữ liệu trong `_detailed_design` của các BE Unit trong SLICE.
+2. **Nạp cấu trúc Template:** Đọc mẫu mục 5.3/5.4/5.6 trong `references/templates/slice_testcase_table_template.md`. (KHÔNG còn Mục 5.5 charter.)
+3. **Hoàn thiện `fixtures.yaml` (DATA canonical):** Hợp nhất toàn bộ `fixtures[]`/`datasets[]` các bề mặt đã sinh; điền `environment` (base_url, mocks). Điền `automation_prereq` theo bề mặt: *(ui)* `ui_schema_required` liệt kê `ui_schema_{id}.json` qa-robot cần · *(service)* `base_url` + `auth` + `api_contract` + `mocks` (các `[Downstream]` cần stub — theo [service_surface_rules.md §5](../principles/service_surface_rules.md)); KHÔNG cần `ui_schema`. Thiếu → `[TBD]`.
+4. **Hoàn thiện Mục 5.3 (Data Setup VIEW):** Tóm tắt người-đọc, trỏ canonical về `fixtures.yaml` (cấm ghi chung chung).
+5. **Hoàn thiện Mục 5.4 (Defect Management):** Điền tổng số kịch bản scripted `{total_tcs}`; để trống chỉ số chạy thực tế (sẽ được [Step 05 round-trip](step-05-roundtrip.md) điền từ `results/`).
+6. **(BỎ Mục 5.5 charter):** Skill **KHÔNG** còn sinh section charter. Rủi ro CH-CMP (§4) / CH-FLEX (§5) / gap-spec (§3) đã được Step 02b/03 materialize thành **case scripted trong KHỐI 2/3** (đếm vào `{total_tcs}`). Nếu còn sót mục `@exec:exploratory` không phải visual thuần KHỐI 1 → quay lại Step 02b phân tích ra oracle, KHÔNG đẩy sang charter.
+6b. **In Mục 5.6 (Coverage Debt Ledger):** Theo [explore_and_consistency_rules.md](../principles/explore_and_consistency_rules.md) §3 — liệt kê mọi bất biến đang **nợ** vì spec/contract gap (`<bề mặt × bất biến> · gap-id · @id case [BR] tương ứng · Q&A blocking`). Bắt buộc in ra chat để User thấy rõ chỗ nợ, không bị ru ngủ bởi "màu xanh automation". Ledger rỗng → ghi "Không có nợ coverage".
+7. **Final Sync Audit (toàn slice) — gate gốc + 2 phép chiếu ([automation_contract_rules §1](../principles/automation_contract_rules.md) CANONICAL):** Kiểm **gate gốc `Y == X`** (tổng dòng markdown, kể cả manual) + **phép chiếu 1** (`count(@id .feature) == A+E`) + **phép chiếu 2** (`count(dataset fixtures) == A`) trên toàn file. Mọi `@id` xuất hiện đồng thời ở `.feature` + bảng markdown + (nếu automate) `fixtures.datasets`. ID liên tục, không nhảy cóc (R8). In bảng đối soát ra chat.
+   - **[HARD CHECK — cross-artifact, cổng terminal]** chạy lệnh `comm` ở [automation_contract_rules §1](../principles/automation_contract_rules.md) — kèm **sàn chống false-pass** (`N_md == A+E`; `N_md==0` → FAIL, KHÔNG PASS). `comm` rỗng (thật) mới PASS. CẤM đếm nội bộ `.feature` (tautology). Lệch → bổ sung @id thiếu, KHÔNG hạ manual.
+   - **[HARD CHECK — định tuyến dynamic-data, cổng terminal]** chạy lại kiểm §2b của [step-03 §10c](step-03-write-testcase.md) trên `fixtures.yaml` TOÀN slice (đối chiếu từng dataset động với bảng `sub_system → source_id` dựng từ `data_sources.yaml` — [dynamic_data_rules.md §2b](../principles/dynamic_data_rules.md)): field trỏ source sai owner sub-system, hoặc sub-system no-source không đánh `[UNRESOLVED-BACKEND]` → FAIL. Vi phạm → DỪNG, route lại theo §2b rồi mới PASS.
+8. **Kiểm tra tính toàn vẹn file:** Cập nhật 5.3/5.4/5.6 vào cuối markdown (Tuân thủ [principles/markdown_safety_rules.md](../principles/markdown_safety_rules.md)).
+9. **Báo cáo hoàn tất + Batch Review Gate (theo lane):** In đường dẫn cả 3 artifact + thống kê (`automate/manual/exploratory`, số ui_schema còn thiếu cho automation) ra chat.
+   - **Lane `batch`:** đây là **HITL gate gộp duy nhất** cho phần testcase. Trước khi mở, **bắt buộc** Math Check (R2) + Sync Invariant 3 chiều PASS *toàn slice* (đã guard ở Step 02/03). In **bảng tổng hợp đầy đủ mọi màn / mọi `@id`** rồi bật `RequestFeedback: true`, DỪNG chờ User duyệt 1 lần (xem [run_mode_rules.md](../principles/run_mode_rules.md) §3).
+   - **Lane `full`:** từng màn đã duyệt ở Step 03 → ở đây chỉ chốt finalize (giữ HITL finalize như cũ).
+   - Gợi ý bước kế: `/ntapp-qa-robot {id}` (chạy automate) hoặc [Step 05](step-05-roundtrip.md) (round-trip).

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/steps/step-05-roundtrip.md

@@ -0,0 +1,25 @@
+# STEP 05: ROUND-TRIP (Delta update + Result ingestion)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_generate_manual_testcase.md)
+> **Tuân thủ:** [principles/incremental_update_rules.md](../principles/incremental_update_rules.md) · [principles/iron_rules.md](../principles/iron_rules.md) (R6)
+> **Vị trí:** (a) **Entry-mode `delta`** — vào THẲNG đây từ [Step 00](step-00-shiftleft-gate.md) khi auto-detect 3 artifact đã tồn tại (bỏ qua Step 01–04, xem [run_mode_rules.md](../principles/run_mode_rules.md) §5); hoặc (b) chạy SAU [Step 04](step-04-finalize-testcase.md) như bước tùy chọn khi đã có `results/` từ qa-robot.
+> **Fallback:** nếu delta phủ rộng (>40% màn / đổi cấu trúc luồng E2E) → KHÔNG dùng delta, chuyển về `full`/`batch`.
+
+## 1. Mục tiêu
+Đóng vòng lifecycle: cập nhật delta khi SLICE/spec đổi, và nuốt ngược kết quả automation để điền Mục 5.4 + chọn regression.
+
+## 2. Các Bước Thực Hiện
+
+### Nhánh A — Delta update (slice/spec đổi)
+1. Phát hiện thay đổi so với artifact hiện có theo [incremental_update_rules.md](../principles/incremental_update_rules.md) §1 (unit thêm/gỡ, nhãn Giao diện, logic/dữ liệu).
+2. In **delta map** (`@id`/`@rule`/`@scr` bị ảnh hưởng) ra chat trước khi sửa.
+3. Regen đúng phần delta trên cả 3 artifact (`.feature`, markdown, `fixtures.yaml`); đánh dấu `@regression` các case logic đổi.
+4. Chạy lại **Math Check Gate (R2)** + **Sync Invariant 3 chiều** trên toàn file; đảm bảo ID liên tục (R8).
+
+### Nhánh B — Result ingestion (có results/ từ qa-robot)
+5. Đọc `results/output.xml` (read-only) → map test ↔ `@id`.
+6. Điền `{pass_tcs}`/`{fail_tcs}`/`{skip_tcs}` vào Mục 5.4 markdown từ kết quả thật.
+7. Gắn `@regression` cho case `@exec:automate` PASS ổn định → liệt kê tập regression guard ra chat (đầu vào cho `/bmad-testarch-ci`).
+8. Báo cáo: tổng case, tỉ lệ pass, danh sách `@id` cần chạy lại chọn lọc (nếu delta).
+
+> **Ranh giới (R6):** Chỉ ghi canonical vào `{qa_artifacts}`; chỉ ĐỌC `results/` của code repo; KHÔNG thực thi test, KHÔNG sửa Robot code.

package/skills/NTAPP/.agent/skills/NTAPP-qa-generate-testcase/workflow.md

@@ -0,0 +1,114 @@
+# WORKFLOW: NTAPP QA GENERATE SLICE TESTCASE (E2E + AUTOMATION-READY)
+
+## Goal
+Sinh kịch bản kiểm thử E2E cho một **SLICE** (nhiều unit) HOẶC một **đơn vị đứng riêng** (`{id}` = HUB/WGT/SCR/MPF… — tính năng không gom vào SLICE), đạt Coverage Gate 100% luồng E2E, **theo School B**: shift-left → risk-based allocation → **triple-emit** (`.feature` canonical + markdown view + `fixtures.yaml`) để output dùng trực tiếp cho automation qua `/ntapp-qa-robot`.
+
+> **Hai lane input** (auto-detect ở Step 00): `slice` — có file `{slices_root}/{id}-*.md` → phối hợp nhiều unit + xếp thứ tự E2E · `unit` — không có file SLICE nhưng có `{id}_detailed_design.md` → coi như "slice một unit", bỏ bước xếp thứ tự liên-unit, giữ nguyên triple-emit + risk allocation + per-screen. **Mọi định danh dùng chung một khóa `{id}`** = ID đầy đủ (vd `SLICE-06` / `WGT-SIDEBAR`); output luôn nằm dưới `{qa_artifacts}/{id}/`.
+
+## Your Role
+Bạn điều phối một **Senior QA Engineer** chạy vòng lặp qua các chốt chặn (PRE-FLIGHT GATE, HITL GATE). Toàn bộ workflow tuân thủ [`principles/iron_rules.md`](./principles/iron_rules.md) + [`principles/automation_contract_rules.md`](./principles/automation_contract_rules.md) + [`principles/run_mode_rules.md`](./principles/run_mode_rules.md). **CẤM TUYỆT ĐỐI đọc trước tài liệu bước sau hoặc thực thi bước tiếp khi bước trước chưa Approve** — *trừ khi lane `batch` đã defer HITL (auto-proceed có kiểm soát) hoặc lane `delta` đi entry tắt; mọi internal checkpoint (Math Check, Sync Invariant) vẫn enforce.*
+
+## Run Mode (3 lane — xem [principles/run_mode_rules.md](./principles/run_mode_rules.md))
+Lane điều chỉnh *tần suất dừng người* (HITL) + *phạm vi reload* + *điểm vào*; **KHÔNG** nới Iron Rules / độ phủ.
+
+| Lane | HITL gate | Reload | Khi dùng |
+|---|---|---|---|
+| `full` *(default)* | 4 (E2E + Plan + per-screen + finalize) | per-screen đầy đủ | Slice mới quan trọng, governance/audit |
+| `batch` | **2** (E2E flow + batch review cuối) — auto-proceed giữa màn | scoped (Context Ledger) | Lặp nhanh, ít gián đoạn |
+| `delta` | **0–1** (in delta-map, 1 OK) | chỉ tài liệu delta | Re-run trên slice đã có 3 artifact |
+
+## Workflow Steps
+```
+[Input: {id}  → lane SLICE nếu có {slices_root}/{id}-*.md · lane UNIT nếu chỉ có {id}_detailed_design.md]
+       │
+       ▼
+0. steps/step-00-shiftleft-gate.md  (Detect input_type + surface_type(ui|service) + Resolve run_mode + auto-detect delta · Shift-left: ambiguity / delegate qa-audit)
+       │
+       ├─[run_mode=delta · 3 artifact đã tồn tại]──────────────► 5. step-05-roundtrip.md (Nhánh A: delta-map → patch) ──► Output
+       │
+       ▼ (full / batch)
+1. steps/step-01-init-slice.md  (lane SLICE: đọc SLICE → luồng E2E nhiều unit · lane UNIT: 1 unit, bỏ xếp thứ tự liên-unit · surface ui→màn / service→operation · map FE-BE / Contract · DỰNG Context Ledger load-once)
+       │
+       ▼ [HITL GATE: Duyệt luồng E2E + Ledger]  (giữ ở mọi lane)
+┌── VÒNG LẶP PER-MÀN: mỗi màn/operation chạy TRỌN 2 → 2b → 3 rồi MỚI sang màn kế (cấm gom 2+2b nhiều màn) ──┐
+2. steps/step-02-plan-screen.md  (Test Plan cho ĐÚNG 1 màn hiện tại · ui→9 chốt slice_planning · service→9 chốt service_surface · scoped reload)
+       │
+       ▼ [HITL GATE: Duyệt Plan]  (full: dừng · batch: defer, checkpoint im lặng)
+2b. steps/step-02b-risk-allocation.md  (Gán @risk + @exec/@oracle/@target CHO CHÍNH MÀN ĐÓ; mode exhaustive|risk-gated)
+       │
+       ▼
+3. steps/step-03-write-testcase.md  (TRIPLE-EMIT cho MÀN ĐÓ: .feature + bảng 11 cột + fixtures.yaml · scoped reload)
+       │
+       ▼ [HITL GATE: chuyển màn]  (full: dừng · batch: auto-proceed)
+└── CÒN màn/operation? → quay lại 2 cho MÀN KẾ (khép kín 1 chu trình/màn). HẾT màn → xuống 4 ──────────────┘
+4. steps/step-04-finalize-testcase.md  (Hợp nhất fixtures, Coverage Debt Ledger 5.6, Final Sync Audit · batch: HITL review GỘP cuối)
+       │
+       ▼ (tùy chọn) 5. steps/step-05-roundtrip.md  (Delta update + nuốt results/ từ qa-robot)
+       │
+       ▼
+[Output 3 artifact tại {qa_artifacts}/{id}/]
+  - {id}_testspec.feature                      (CANONICAL → automation)
+  - {id}_detailed_test_manual_testcase.md      (VIEW → QA ký + qa-robot parse)
+  - {id}_fixtures.yaml                          (DATA máy-đọc)
+  (Ngoại lệ: {qa_artifacts}/data_sources.yaml — registry dùng CHUNG nhiều slice/unit, KHÔNG nằm trong {id}/)
+       │
+       ▼ [Bridge] /ntapp-qa-robot {id}  → sinh Robot POM + EXECUTE (chỉ dòng Exec=automate)
+```
+
+> **VÒNG LẶP PER-MÀN (IRON — mọi lane):** Sau Step 01, xử lý **tuần tự từng màn/operation một**. Với mỗi màn chạy KHÉP KÍN chuỗi `Step 02 (plan/Math Forcing) → Step 02b (policy @risk/@exec) → Step 03 (triple-emit + HITL)` rồi MỚI chuyển sang màn kế. **CẤM batch theo pha** — không lập plan (02) cho toàn bộ màn trước rồi mới emit (03) hàng loạt. Lane `batch` chỉ hoãn *điểm dừng người* (HITL), KHÔNG cho phép gộp pha xuyên màn. Enforce cơ học: Step 03 §1b (GATE plan-exists per-màn) + Step 03 §11 (loop-back về Step 02 khi còn màn).
+
+## Quality Gates Map
+1. **Shift-left Gate (Step 00):** Có `qa-audit` report hoặc mini-audit; không thiết kế test trên spec mơ hồ.
+2. **HITL GATE (Duyệt E2E Flow - Step 01):** Dừng chờ User duyệt luồng E2E + Context Ledger. *(Giữ ở mọi lane.)*
+3. **Missing File Guard (Step 02):** Báo lỗi và dừng nếu thiếu file `_detailed_design` của unit.
+3b. **Dynamic Data Gate (Step 02 — [BẮT BUỘC, KHÔNG ĐƯỢC BỎ QUA]):** Với MỌI field Runtime-dependent (filter/search gọi service khác, checkbox/lựa chọn lấy từ danh sách API khác, ID/mã do hệ thống khác cấp phát dùng làm điều kiện tra cứu, field `UNIQUE`/`PRIMARY KEY`) — bắt buộc `view_file` đọc [principles/dynamic_data_rules.md](./principles/dynamic_data_rules.md) và chạy thuật toán §2 để phân loại Tier trước khi tính case ở Chốt chặn 6 của Step 02. Đây là gate **tách riêng** khỏi Bảng Mapping Rule UI (`kbkt-generation/**`) — KHÔNG được coi là đã xong chỉ vì đã có Mapping Rule cho control UI. Bỏ qua gate này là nguyên nhân phổ biến khiến `fixtures.yaml` hardcode ID/mã tra cứu không có thật trong môi trường Staging.
+4. **HITL GATE (Duyệt Plan - Step 02):** `full` dừng chờ duyệt Plan (Math Forcing + Bảng Mapping Rule + Dynamic Data) · `batch` defer (checkpoint im lặng).
+5. **Allocation Gate (Step 02b):** Mọi mục có đủ `@risk`+`@exec`; không P0 nào exploratory; oracle-first đúng bề mặt (`ui`→`@oracle:ui`/`@scr` · `service`→`@oracle:api`/`@svc`, cấm `@oracle:ui`); tính `X` (số case sau mode). *(Internal — mọi lane.)*
+6. **Automation Emit + Sync Invariant Gate (Step 03):** áp mô hình **"1 số gốc + 2 phép chiếu"** ([automation_contract_rules.md §1](./principles/automation_contract_rules.md) — CANONICAL): **gate gốc `Y == X`** (`X` = tổng Math Forcing chốt ở Step 02/02b, `Y` = tổng dòng markdown KỂ CẢ manual); phép chiếu 1 `count(@id .feature) == A+E`; phép chiếu 2 `count(dataset fixtures) == A`. Tag đầy đủ; **fixtures.yaml không hardcode field Loại 1/2 đã phân loại ở Gate 3b** (phải dùng `$db.query`/`$seed.create`/`$uuid`/`$timestamp` + có `data_sources.yaml` tương ứng). **[HARD CHECK cross-artifact]** so `.md`(Exec∈{automate,exploratory}) ↔ `.feature`(@id) bằng `comm` (automation_contract_rules §1) — kèm **sàn chống false-pass** (`N_md == A+E`; `N_md==0` → FAIL, không PASS); CẤM đếm nội bộ `.feature` (tautology); `comm` không rỗng → DỪNG, bổ sung @id thiếu. *(Internal — mọi lane; lệch ở `batch` → rớt về dừng-tại-màn.)*
+7. **HITL GATE (Chuyển màn - Step 03):** `full` dừng duyệt từng màn · `batch` auto-proceed (gộp về Gate 8).
+8. **Final Sync Audit + Batch Review (Step 04):** Mọi `@id` đồng bộ 3 artifact; ID liên tục (R8); prereq automation thiếu được liệt kê (*ui*: `ui_schema` · *service*: `base_url`/`auth`/`api_contract`/`mocks`). **Cổng terminal chạy lại HARD CHECK cross-artifact** (`comm` `.md` Exec∈{automate,exploratory} ↔ `.feature` @id phải rỗng, kèm sàn `N_md==A+E`). `batch`: là **HITL review gộp duy nhất** (gate gốc `Y==X` + 2 phép chiếu PASS toàn slice trước khi mở).
+
+## Bản đồ Luật theo Step (chỉ nạp luật liên quan — tiết kiệm context)
+> `iron_rules.md` + `run_mode_rules.md` là **xuyên suốt** (mọi step ngầm tuân). Bảng dưới chỉ liệt kê luật **đặc thù** cần `view_file` thêm cho từng step — KHÔNG nạp cả 10 principle mỗi bước.
+
+| Step | Principle đặc thù cần nạp | Reference / template |
+|---|---|---|
+| 00 shift-left | — *(chỉ xuyên suốt)* | — |
+| 01 init slice | `unit_classification_rules` (ui, gồm §4 scope) **hoặc** `service_surface_rules §1` (service) · **`borrowed_surface_rules` (khi `units:` toàn BE mà `What to build`/`demoable` nêu màn của slice khác)** | — |
+| 02 plan screen/op | *(ui)* `slice_planning_rules` · `unit_classification §4` · `markdown_safety §4` **hoặc** *(service)* `service_surface_rules §2` · `markdown_safety §4` · **`dynamic_data_rules` (BẮT BUỘC nạp riêng, xem Quality Gate 3b — cả ui lẫn service, dù không có field nào "trông giống" unique/FK)** | `templates/plan_template.md` · `kbkt-generation/**` (ui: control rule · service: 10-be + request-validation) |
+| 02b risk alloc | `risk_based_allocation_rules` · `explore_and_consistency_rules` (Oracle phủ định + Surface Invariant §2 + TBD-escape §3) · *(service)* `service_surface_rules §3–§4` (API-first oracle + Surface Inventory service) | — |
+| 03 write testcase | `testcase_generation_gates` · `automation_contract_rules` (tag `@scr`/`@svc` theo bề mặt) · `markdown_safety_rules` · **`dynamic_data_rules` (đối chiếu lại khi viết `overrides` trong `fixtures.yaml` — xem Quality Gate 6)** · *(service)* `service_surface_rules §5` (bridge) | `templates/slice_testcase_table_template.md` · `templates/testspec_feature_template.feature` · `templates/fixtures_template.yaml` · `kbkt-generation/00-core/*` |
+| 04 finalize | `finalization_rules` · `automation_contract_rules` · `markdown_safety_rules` · `explore_and_consistency_rules` (§4-§5 materialize KHỐI 2/3 + Coverage Debt Ledger §3) | — (KHÔNG dùng charter template) |
+| 05 round-trip | `incremental_update_rules` | — |
+
+## Configuration Resolution
+Resolve config theo cascade 3 layer:
+1. **Layer 1 (Resolve `{project-root}`):** Tìm thư mục chứa `_bmad/` hoặc `.git/` từ `cwd`.
+2. **Layer 2 (BMad config):** Đọc `{project-root}/_bmad/bmm/config.yaml` lấy `project_name` và `stage_5_build_verify`.
+3. **Layer 3 (Override/Fallback):** Đọc `{project-root}/.bmm-config.yaml` mục `ntapp-qa-generate-testcase:`. Nếu thiếu, default `qa_artifacts` = `{project-root}/_bmad-output/Stage_5_Build_Verify/test`.
+
+### Runtime Variables
+- `project_name`: Header tài liệu.
+- `qa_artifacts`: Đường dẫn ghi output file.
+- `id`: **khóa định danh duy nhất** — ID đầy đủ của SLICE (vd `SLICE-06`) hoặc đơn vị đứng riêng (vd `WGT-SIDEBAR`, `HUB-01`). Mọi tên file/thư mục output đều dẫn xuất từ đây (`{qa_artifacts}/{id}/{id}_*`).
+- `input_type`: `slice` \| `unit` — resolve ở Step 00 (xem quy tắc detect). Điều khiển nhánh Step 01.
+- `slices_root`: Thư mục chứa file SLICE đầu vào (Mặc định: `{stage_5_build_verify}/slices`). Chỉ dùng khi `input_type=slice`.
+
+### Cờ cấu hình mới (Layer 3 `.bmm-config.yaml` mục `ntapp-qa-generate-testcase:`)
+- `run_mode` *(`full`\|`batch`\|`delta`, default `full`)*: lane chạy — giảm ceremony / incremental / scoped reload (xem [run_mode_rules.md](./principles/run_mode_rules.md)). Override được bằng ý định trong câu lệnh; `delta` còn auto-detect khi 3 artifact đã tồn tại.
+- `emit_automation` *(bool, default `true`)*: bật triple-emit (`.feature` + `fixtures.yaml`). `false` → chỉ markdown (legacy).
+- `risk_mode` *(`exhaustive`\|`risk-gated`, default `exhaustive`)*: độ bung case theo risk (xem [risk_based_allocation_rules.md](./principles/risk_based_allocation_rules.md)).
+- `shiftleft_required` *(bool, default `true`)*: bắt buộc có `qa-audit` report hoặc mini-audit ở Step 00.
+- `automation_target` *(`robot`\|`playwright`, default `robot`)*: đích mặc định cho `@target`.
+
+## Output Naming (Triple-Emit)
+- **Mọi output riêng của 1 SLICE/unit nằm dưới `{qa_artifacts}/{id}/`** (không còn flat trực tiếp dưới `{qa_artifacts}/`). `{id}` = ID đầy đủ (SLICE-06 / WGT-SIDEBAR) → tên file slice cũ (`SLICE-06_*`) giữ nguyên, không đổi.
+- **Test Plan (Nháp):** Lưu trực tiếp vào `{qa_artifacts}/{id}/{id}_implementation_plan.md` (Không lưu tệp phụ).
+- **Canonical (Gherkin):** Ghi đè `{qa_artifacts}/{id}/{id}_testspec.feature`.
+- **View (Manual Testcase):** Ghi đè `{qa_artifacts}/{id}/{id}_detailed_test_manual_testcase.md`.
+- **Data (Fixtures):** Ghi đè `{qa_artifacts}/{id}/{id}_fixtures.yaml`.
+- **Q&A audit report (đọc từ `/ntapp-qa-audit`):** `{qa_artifacts}/{id}/{id}_qa_report.md`.
+- **Ngoại lệ dùng chung nhiều slice/unit (KHÔNG nest):** `{qa_artifacts}/data_sources.yaml` (registry dynamic data — xem `principles/dynamic_data_rules.md`).
+- Tất cả canonical-only (R6) — ghi đè, không archive/_vN.
+
+

package/skills/NTAPP/.agent/skills/NTAPP-qa-robot/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: ntapp-qa-robot
+description: 'Từ kịch bản manual testcase đã chốt (bảng 11 cột có `Exec`, hoặc 10 cột khi không có cột đó), tự động sinh mã nguồn kiểm thử Robot Framework chuẩn POM (Page Object Model) rồi chạy test + self-heal. Map chính xác 1-1 mỗi bước manual thành Robot keyword; locator đọc từ source code FE, với ui_schema_{id}.json làm checklist control; cấm Sleep, bắt buộc Smart Wait; FAIL do locator thì retry self-healing ≤3 lần. Hỗ trợ cả bề mặt no-UI (RequestsLibrary Service Object). Output: code repo tests/, actions/pageObject/ (ui) hoặc actions/serviceObject/ (service), datatest/, results/. Sử dụng khi người dùng nói "tạo automation test", "generate robot test", "/generate_robot_test", "viết script automation".'
+---
+
+# NTAPP QA Robot Automation Generator
+
+Sinh bộ mã nguồn Robot Framework Automation chuẩn POM từ manual testcase đã chốt, kết hợp tài liệu thiết kế L2/L3 + UI Semantic Schema / Contract Map, rồi tự chạy và self-heal.
+
+> **Hai bề mặt (xác định ở Step 01):**
+> - **`ui`** (`Chrome`, `@scr`, có `ui_schema`) → **Selenium POM** (nav-by-click R9, self-heal R7).
+> - **`service`** (no-UI: `RequestsLibrary`, `@svc`, không `ui_schema`) → **RequestsLibrary POM** (1 endpoint = 1 Service Object). Cấm `Sleep`, async dùng `Wait Until Keyword Succeeds` (R7s).
+
+> **Input tại `{qa_artifacts}/{id}/`:**
+> - `{id}_detailed_test_manual_testcase.md` (Bảng manual bắt buộc): Lọc cột `Exec = automate` (R2).
+> - `{id}_testspec.feature` (Gherkin + tag): Canonical khi lệch `.md`. Vắng -> propagate nhãn sẵn có, thiếu ghi `N/A`, cấm bịa (R1).
+> - `{id}_fixtures.yaml` (Dữ liệu mồi + prereq): Vắng -> đọc cột "Data Test" ở step 01 bước 6b.
+
+> **Bốn rule quan trọng (chi tiết tại [principles/iron_rules.md](./principles/iron_rules.md)):**
+> - **R6**: Đọc tại spec repo, ghi tại `{code_repo_root}` (không mặc định `cwd`).
+> - **R10**: Deferred-Run Safety Gate (hoãn chạy nhóm nhạy cảm -> `Pending`).
+> - **R11**: Anti-stub (assert đúng kết quả thực tế, cấm test generic).
+> - **R16**: Đồng bộ tăng dần từng case khi chạy lại, bảo toàn locator đã self-heal.
+
+Đọc đầy đủ và tuân theo: `./workflow.md`

package/skills/NTAPP/.agent/skills/NTAPP-qa-robot/agents/agent_robot_generator.md

@@ -0,0 +1,18 @@
+# SYSTEM INSTRUCTION: SENIOR AUTOMATION ENGINEER (ROBOT FRAMEWORK)
+
+## [B] - BACKGROUND
+Bạn là Senior Automation Engineer / Robot Framework Architect. Framework chỉ đạt chuẩn khi **dễ bảo trì, mở rộng, tái sử dụng cao** — code chạy được nhưng khó bảo trì là nợ, không phải thành quả.
+
+## [M] - MISSION
+Chuyển đổi **100%** kịch bản Manual Testcase đã chốt (`{id}_detailed_test_manual_testcase.md` — 11 cột khi có cột `Exec`, 10 cột khi không) thành mã Robot Framework chuẩn POM, dựa trên tài liệu thiết kế L2/L3 + `ui_schema` / Contract Map. Bạn là người tiêu thụ trực tiếp các artifact đó.
+
+## [A] - ACTIONS
+Toàn bộ quy tắc thực thi nằm ở [Iron Rules](../principles/iron_rules.md) — **KHÔNG tóm tắt lại ở đây** (persona tóm tắt rule là nguồn drift). Năm thứ định hình cách bạn làm việc:
+1. **Map 1-1, không tóm tắt** (R2) — không bỏ scenario nào trong automation scope, kể cả UI gesture như blur/paste/double-click.
+2. **Không bịa** (R1 · R5) — data/locator/endpoint kế thừa nguyên văn từ nguồn; thiếu thì `[TBD]` + báo, KHÔNG hallucinate.
+3. **Rẽ nhánh theo `surface_type`** — `ui` → Page Object + locator (R7); `service` → Service Object + Contract Map (R7s), không browser/locator.
+4. **POM là gate cứng** (R4) — `.robot` chỉ gọi keyword; locator/URL/SQL nằm ở `.resource`.
+5. **Đặt tên theo [Coding Convention](../references/automation/auto_coding_convention.md)** — tên keyword tiếng Anh (không ngoại lệ), tên Test Case mang mã manual nguyên văn, biến locator UPPER_SNAKE, spacing ≥2 space, không `=` khi gán.
+
+## [D] - DELIVERABLES
+Mã nguồn theo đúng path ở [workflow §Output Naming](../workflow.md) + cấu trúc ở [Framework Structure](../references/automation/auto_framework_structure.md): `actions/pageObject/` hoặc `actions/serviceObject/`, `tests/`, `datatest/`.