@educa-corp/sdd-framework 0.9.3 → 0.9.4

package/core/skills/qc/qa-designer/functional/api.md

@@ -1,13 +1,15 @@
 ---
 version: 1.0
-updated: 2026-06-11
+updated: 2026-09-04
 ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/api-testcase-designer.md
+upstream_sha: 211c18728baf029a7572f0ffb161e92a933fa8fb
 ---
 
 # Test Case — Functional API (không qua UI)
 
-Skill **tự chứa** để viết TC kiểm thử một API endpoint ở mức chức năng (request → response).
-Chỉ cần load file này.
+Viết TC kiểm thử một API endpoint ở mức chức năng (request → response).
+Nạp cùng `shared/` (khuôn + độ chính xác + từ điển hành động) và `../api/` (mẫu + bảng tra).
 
 ## Khi nào trigger
 - "viết test case cho API [method] [path]" — verify contract, validation, mã lỗi của endpoint
@@ -18,28 +20,95 @@ Chỉ cần load file này.
 
 ---
 
-## Format file `TC_<FEATURE>.md` (bắt buộc)
-- 1 file/feature · mỗi TC **1 concept** · metadata **list** (không bảng/emoji): Title · Feature ·
-  Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
-- **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; không có BR → `⚠️ Chưa có Business Rule`.
-- **🚫 Block:** TC phụ thuộc gap vẫn viết đủ + `[GAP-xx](DOC_GAP.md) — lý do`.
-- **Test Data:** dạng **list** (request cụ thể: method/path/headers/body). **Steps:** `[Action]`/`[Verify]`.
-  **Expected:** 1 bullet nêu rõ **status code + field response cần chốt** (không ✅/❌).
-- Cuối file: **Trace matrix** (BR↔TC, ⚠️ TC thiếu BR) + **bảng TC bị block** · bỏ nội dung gạch ngang.
+## Format file TC
 
-## Kỹ thuật áp dụng
-- Mỗi field request → **EP** (phân vùng valid/invalid) + **BVA** (biên độ dài/giá trị).
-- Tổ hợp điều kiện (auth × param × state) → **Decision Table**.
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
+
+## Đầu vào — sáu trường bắt buộc cho mỗi endpoint
+
+Trước khi viết TC, mỗi endpoint phải biết đủ **sáu** thứ. Thiếu bất kỳ trường nào → **hỏi, đừng đoán**:
+
+| # | Trường | Lấy ở đâu |
+|---|---|---|
+| 1 | Endpoint (method + path) | tech-doc gộp §4 Hợp đồng API |
+| 2 | Auth / role được phép | §4 + PRD phần phân quyền |
+| 3 | Schema request (field · kiểu · bắt buộc · ràng buộc) | §4 |
+| 4 | Response thành công (mã + schema) | §4 |
+| 5 | **Các mã lỗi** và body lỗi | §4 + §8 Xử lý lỗi & biên |
+| 6 | Side-effect (ghi DB, phát event) | §6 Điểm tích hợp |
+
+Trường 5 và 6 là hai chỗ hay thiếu nhất. Thiếu 5 → không viết được nhóm negative. Thiếu 6 →
+side-effect không ai verify, và lỗi mất dữ liệu lọt qua toàn bộ dây chuyền.
+
+## Kỹ thuật ISTQB cho tầng API *(CTFL v4.0)*
+
+| Tình huống | Kỹ thuật |
+|---|---|
+| Tham số có kiểu / phạm vi / định dạng | **EP + BVA** |
+| Tổ hợp điều kiện (quyền × trạng thái × input) | **Decision Table** |
+| Spec mỏng, nghi có lỗi tiềm ẩn | **Error Guessing** |
+
+- **EP/BVA từng tham số**: valid + invalid (thiếu · sai kiểu · vượt biên · rỗng · quá dài).
+  Mỗi phân vùng một TC. Số giá trị biên (3 hay 4) tra `../shared/precision-rules.md` §7.
+- **Decision Table cho phân quyền**: điều kiện = (role, sở hữu resource, trạng thái resource)
+  → hành động = mã trạng thái. **Mỗi rule một TC**, kể cả rule mà kết quả là "không làm gì".
+- **Error Guessing theo mã trạng thái** — phủ đủ mã **áp dụng được** cho endpoint đó:
+
+| Mã | Khi nào |
+|---|---|
+| 400 | thiếu / sai tham số |
+| 401 | thiếu hoặc sai token |
+| 403 | đúng token, sai quyền |
+| 404 | resource không tồn tại |
+| 409 | trùng giá trị unique |
+| 422 | validate nghiệp vụ (đúng định dạng, sai luật) |
+| 5xx | lỗi hệ thống / dịch vụ phụ thuộc |
+
+Bảng đầy đủ + nghĩa trong ngữ cảnh: `../api/http-status-codes.md`. **401 ≠ 403** — trộn hai cái
+là bỏ mất một lớp bảo mật khỏi phạm vi test.
+
+## Thứ tự viết
+
+**1. Positive → 2. Negative → 3. Edge → 4. Implicit.**
+
+Bước 4 nạp `../shared/implicit-scenarios.md` — 7 tình huống bắt buộc nghĩ tới (rate limit ·
+đồng thời · hết hạn phiên · trạng thái rỗng · dữ liệu tối đa · ký tự đặc biệt · ghi log).
+Áp cho **mọi** nhóm TC, không riêng nhóm edge.
+
+**Trước khi viết TC mới**: nạp `../shared/duplicate-check-procedure.md` — grep từ khoá trong file
+TC hiện có. Một TC "email đã tồn tại" có thể đã nằm ở nhóm Validation của file giao diện.
+
+## Năm luật chất lượng *(để reviewer không phải trả lại)*
+
+1. **Title ≤ 60 ký tự**, nêu được cả tình huống lẫn kết quả.
+2. **Test Steps ≥ 2 bước.** Chỉ một hành động → thêm bước `[Verify]` quan sát kết quả.
+3. **Expected Result đo được** — cấm cụm mơ hồ. Phép thử: *hai QC đọc có ra cùng một kết luận
+   pass/fail không?* Danh sách 9 cụm bị cấm: `../shared/precision-rules.md` §1.
+4. **Test Data ghi note kỹ thuật**: `EP: valid`, `BVA: biên trên`, `DT: rule 3`.
+5. **Priority có nghĩa cố định**: P0 = chặn phát hành · P1 = smoke · P2 = regression.
 
 ## Phase 1 — Clarify
 Endpoint (method/path/auth/role/content-type) · request (path/query/body schema: field, kiểu, bắt buộc, ràng buộc) ·
 response (schema thành công + các mã lỗi 4xx/5xx + body lỗi) · side-effect (nếu cần verify → cân nhắc `integration/api`).
 
+*Có `TEST_PLAN.md` đủ sáu trường trên → bỏ qua Phase 1, sang thẳng Phase 2.*
+
 ## Phase 2 — Write
-- Nhóm TC: happy (200 + schema đúng) → validation (400 từng field, dùng EP/BVA) → auth (401/403)
+- Nhóm TC: happy (mã thành công + schema) → validation (400 từng field, EP/BVA) → auth (401/403)
   → not found (404) → edge (payload lớn, ký tự đặc biệt, rate limit).
-- Mỗi TC bám khối Format; Expected ghi status code + phần body verify; trace BR; gap chặn → 🚫 Block.
+- Mỗi TC bám mẫu `../api/endpoint.md`; chuỗi nhiều bước bám `../api/auth-chain.md`.
+- **Không hardcode URL / thông tin đăng nhập.** Placeholder có tên rõ nghĩa
+  (`<valid_token_admin>`, không phải `<token>`).
 
 ## Output
-File TC (`TC_<FEATURE>_API.md` hoặc gộp trong file feature) trong `{qc_artifact_dir}test-cases/`.
-In bảng TC + Trace matrix. Bàn giao `qa-reviewer`.
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>_API.Test.md` — **Nhóm 1 Endpoint**.
+
+File này chỉ sinh khi có cờ `--api` hoặc `--all`. Mẫu TC: `../api/endpoint.md` · chuỗi auth: `../api/auth-chain.md` · tra mã: `../api/http-status-codes.md` · header: `../api/common-headers.md`.
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/functional/gui-feature.md

@@ -18,13 +18,14 @@ Skill **tự chứa** để viết TC functional cho feature có luồng span
 
 ---
 
-## Format file `TC_<FEATURE>.md` (bắt buộc)
-- 1 file/feature · mỗi TC **1 concept** · metadata **list** (không bảng/emoji): Title · Feature ·
-  Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
-- **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; không có BR → `⚠️ Chưa có Business Rule`.
-- **🚫 Block:** TC phụ thuộc gap vẫn viết đủ + `[GAP-xx](DOC_GAP.md) — lý do`.
-- **Test Data:** dạng **list** (không bảng). **Steps:** `[Action]`/`[Verify]`, không `*Expected:*`/bước. **Expected:** 1 bullet cụ thể.
-- Cuối file: **Trace matrix** (BR↔TC, ⚠️ TC thiếu BR) + **bảng TC bị block** · không `#### Python Test Mapping` · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật áp dụng
 - **Use Case** cho flow tổng: main (P0) → alternate (P1) → exception (negative).
@@ -42,5 +43,7 @@ Liệt kê các màn/route + thứ tự điều hướng · state/dữ liệu tr
 - Mỗi TC bám khối Format; trace BR; gap chặn → 🚫 Block.
 
 ## Output
-File `TC_<FEATURE>.md` trong `{qc_artifact_dir}test-cases/`. In bảng TC + Trace matrix + bảng TC block.
-Bàn giao `qa-reviewer` (test-case).
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` — **Nhóm 3 Functional** (luồng đa màn trong cùng một feature).
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/functional/gui-screen.md

@@ -18,14 +18,14 @@ Skill **tự chứa** để viết TC functional cho 1 màn hình đơn lẻ (we
 
 ---
 
-## Format file `TC_<FEATURE>.md` (bắt buộc)
-- 1 file/feature · mỗi TC **1 concept** · metadata **list** (mỗi trường 1 dòng, không bảng/emoji):
-  Title · Feature · Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
-- **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; TC không có BR → `⚠️ Chưa có Business Rule`.
-- **🚫 Block:** TC phụ thuộc gap **vẫn viết đủ** + `[GAP-xx](DOC_GAP.md) — lý do`; chưa chạy tới khi gap Answered.
-- **Test Data:** dạng **list** (`- **Trường:** giá trị`), không bảng.
-- **Test Steps:** `**[Action]**` / `**[Verify]**`, KHÔNG `- *Expected:*` sau bước. **Expected:** 1 bullet cụ thể (không ✅/❌).
-- Phân nhóm GUI/Functional · cuối file: **Trace matrix** (BR↔TC, ⚠️ TC thiếu BR) + **bảng TC bị block** · KHÔNG `#### Python Test Mapping` · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật áp dụng
 - Field có ràng buộc (độ dài/số/ngày) → **EP** (mỗi phân vùng 1 TC, tag `ep`) + **BVA** (4 TC min−1/min/max/max+1, tag `bva`).
@@ -48,5 +48,7 @@ chức năng (input/action/display/nav) · constraint (required/min-max/format/e
 - Mỗi TC bám khối Format trên; trace BR; TC chặn bởi gap → 🚫 Block.
 
 ## Output
-File `TC_<FEATURE>.md` trong `{qc_artifact_dir}test-cases/`. In bảng `TC_ID | Title | Priority | Tags | Trace`
-+ Trace matrix + bảng TC block. Bàn giao `qa-reviewer` (test-case).
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` — **Nhóm 1 GUI** · **Nhóm 2 Validation** · **Nhóm 3 Functional**.
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/integration/api.md

@@ -19,10 +19,14 @@ verify luồng dữ liệu & contract giữa các thành phần. Chỉ cần loa
 
 ---
 
-## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)` (TC chặn vẫn viết đủ).
-- **Test Data** dạng list · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet nêu rõ chặng verify (response/bản ghi/event).
-- Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật áp dụng
 - **Interface/Contract:** verify schema request/response giữa caller↔callee.
@@ -39,4 +43,7 @@ Nhóm TC: happy (dữ liệu đúng đầu→cuối) → contract negative (inpu
 → concurrency → điều kiện đồng bộ (đổ/không đổ). Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
 
 ## Output
-File TC integration trong `{qc_artifact_dir}test-cases/`. Ưu tiên P0 cho định tuyến & tiền-dữ liệu. Bàn giao `qa-reviewer`.
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>_API.Test.md` — **Nhóm 2 Integration API/DB/Kafka**. Ưu tiên P0 cho định tuyến & tiền-dữ liệu. Chuỗi gọi phụ thuộc nhau: `../api/crud-sequence.md`.
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/integration/db.md

@@ -17,10 +17,14 @@ insert/update/soft-delete đúng giá trị, side-effect, toàn vẹn. Chỉ c
 
 ---
 
-## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
-- **Test Data** dạng list (giá trị input) · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet nêu rõ **bảng.cột = giá trị**.
-- Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật áp dụng
 - **State/DB verification:** verify bản ghi sau action (giá trị từng cột, flag, timestamp).
@@ -35,5 +39,7 @@ Nhóm TC: ghi đúng giá trị (happy) → default/null đúng → update khôn
 → audit log → ràng buộc/unique (negative). Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
 
 ## Output
-File TC trong `{qc_artifact_dir}test-cases/`. Ghi rõ query kiểm tra DB + yêu cầu cleanup;
-không hardcode ID, chuẩn bị/dọn data qua fixture. Bàn giao `qa-reviewer`.
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>_API.Test.md` — **Nhóm 2 Integration API/DB/Kafka**. Ghi rõ query kiểm tra DB + yêu cầu cleanup; không hardcode ID, chuẩn bị/dọn data qua fixture (3 mức teardown: `../shared/precision-rules.md` §8).
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/integration/gui.md

@@ -18,10 +18,14 @@ lỗi từ server, đồng bộ trạng thái hai chiều. Chỉ cần load file
 
 ---
 
-## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
-- **Test Data** dạng list · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet (API liên quan + biểu hiện UI kỳ vọng).
-- Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật áp dụng
 - **Data flow UI→API→UI:** verify request gửi đúng + render response đúng.
@@ -37,4 +41,7 @@ Nhóm TC: UI render đúng dữ liệu backend (happy) → empty state → lỗi
 Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
 
 ## Output
-File TC trong `{qc_artifact_dir}test-cases/`. Mỗi TC nêu API liên quan + biểu hiện UI. Bàn giao `qa-reviewer`.
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` — **Nhóm 4 Integration (qua UI)**. Đây là tầng verify dòng dữ liệu API → giao diện, nên **vẫn thuộc file giao diện**: bỏ UI đi thì TC mất nghĩa.
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/integration/kafka.md

@@ -17,10 +17,14 @@ Skill **tự chứa** để viết TC tích hợp qua Kafka: producer phát even
 
 ---
 
-## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
-- **Test Data** dạng list (payload) · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet nêu **topic + field payload / hành vi consumer**.
-- Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật áp dụng
 - **Message/event:** verify topic, key, payload schema, điều kiện phát.
@@ -37,4 +41,7 @@ Nhóm TC: phát đúng topic+payload (happy) → điều kiện không phát →
 Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
 
 ## Output
-File TC trong `{qc_artifact_dir}test-cases/`. Mỗi TC ghi topic, key, payload cần verify + hành vi consumer. Bàn giao `qa-reviewer`.
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>_API.Test.md` — **Nhóm 2 Integration API/DB/Kafka**. Mỗi TC ghi topic, key, payload cần verify + hành vi consumer.
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/non-functional.md

@@ -17,10 +17,14 @@ Trọng tâm "hệ thống hoạt động TỐT thế nào". Chỉ cần load fi
 
 ---
 
-## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
-- **Test Data** dạng list · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet có **ngưỡng đo cụ thể** (không "nhanh/ổn định").
-- Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+## Format file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md`** — khuôn TC, luật
+> ATOMIC (1 kết cục = 1 TC), cách phân nhóm, hai file `.Test.md`, Trace + `@trace.verifies`,
+> `🚫 Block`, dòng `Test-ID attribute`. **Không lặp lại luật format ở đây.**
+>
+> Khi viết Expected Result / Test Data: nạp thêm `shared/precision-rules.md` (cấm từ mơ hồ,
+> đơn vị, toán tử) + `shared/action-keywords-glossary.md` (một hành động một từ).
 
 ## Kỹ thuật / loại
 - **Performance:** response time dưới tải mục tiêu; danh sách lớn (max data); pagination; concurrency.
@@ -37,4 +41,7 @@ Mỗi TC bám Format; **Expected có ngưỡng pass + công cụ đo**; đánh d
 Trace BR; gap chặn → 🚫 Block.
 
 ## Output
-File TC non-functional trong `{qc_artifact_dir}test-cases/`. Mỗi TC ghi tiêu chí đo + ngưỡng + công cụ. Bàn giao `qa-reviewer`.
+
+Ghi vào file theo cùng câu hỏi phân file *"verify được mà không cần UI?"*: a11y · responsive · touch-target → `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` **Nhóm 5 NFR**; tải/hiệu năng/bảo mật ở tầng API → `{qc_artifact_dir}test-cases/TC_<FEATURE>_API.Test.md`. Mỗi TC ghi tiêu chí đo + ngưỡng + công cụ, đơn vị theo `../shared/precision-rules.md` §3.
+
+**Dạng danh sách, KHÔNG bảng** — file TC không được có ký tự `|` (`shared/tc-metadata-format.md` §Nguyên tắc format file). Cuối file: Trace matrix + danh sách TC bị block, cũng dạng danh sách. Bàn giao `/qc-review`.

package/core/skills/qc/qa-designer/shared/action-keywords-glossary.md

@@ -0,0 +1,91 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/shared/action-keywords-glossary.md
+upstream_sha: df56df91eea42342537ccf67b5946df32d98dbf4
+---
+# Action Keywords Glossary — Từ Điển Chuẩn
+
+> **Quy tắc:** Mỗi hành động chỉ dùng **1 từ duy nhất** trong toàn bộ tài liệu TC. Không dùng Enter/Type/Input xen kẽ. Không dùng Verify/Assert/Check lẫn lộn.
+
+---
+
+## Nhóm 1 — UI Actions (Web & Mobile)
+
+| Từ chuẩn | Dùng khi nào | Không dùng thay thế |
+|---|---|---|
+| **Click** | Nhấn vào element trên Web (button, link, checkbox, radio) | Press, Hit, Select (cho button) |
+| **Tap** | Nhấn vào element trên Mobile | Click (cho mobile) |
+| **Enter** | Nhập văn bản vào input field / textarea | Type, Input, Fill, Write |
+| **Select** | Chọn option trong dropdown / listbox | Choose, Pick |
+| **Check** | Tick vào checkbox | Enable, Mark |
+| **Uncheck** | Bỏ tick checkbox | Disable, Unmark |
+| **Scroll** | Cuộn trang/container theo chiều dọc | Swipe (cho web) |
+| **Swipe** | Vuốt màn hình trên Mobile | Scroll (cho mobile) |
+| **Hover** | Di chuột vào element (hiện tooltip/dropdown) | Mouse over |
+| **Clear** | Xóa nội dung field | Delete, Empty |
+| **Upload** | Tải file lên qua input file | Attach, Import |
+| **Download** | Tải file về | Save, Export |
+| **Navigate to** | Mở URL / chuyển trang | Go to, Open URL |
+| **Refresh** | Tải lại trang | Reload |
+| **Wait for** | Chờ element/condition xuất hiện | Sleep, Pause |
+
+---
+
+## Nhóm 2 — Verification Actions
+
+| Từ chuẩn | Dùng khi nào | Không dùng thay thế |
+|---|---|---|
+| **Verify** | Kiểm tra trong test steps — kết quả trung gian | Assert, Check, Confirm |
+| **Assert** | Kết quả cuối (Expected Result) — điều kiện pass/fail | Verify (ở Expected), Check |
+| **Observe** | Ghi nhận trạng thái hiện tại (không pass/fail) | See, Notice |
+
+> **Phân biệt Verify vs Assert:**
+> - Trong **Test Steps**: dùng `[Verify]` → "Verify: Error message 'Email không hợp lệ' hiển thị dưới field"
+> - Trong **Expected Result**: dùng `Assert` → "Assert: HTTP 201, body.id tồn tại, body.email = email đã gửi"
+
+---
+
+## Nhóm 3 — API Actions
+
+| Từ chuẩn | Dùng khi nào | Không dùng thay thế |
+|---|---|---|
+| **Send** | Gửi HTTP request | Call, Hit, Invoke |
+| **GET** | HTTP GET request | Fetch, Read |
+| **POST** | HTTP POST request | Create, Submit |
+| **PUT** | HTTP PUT request | Update (toàn bộ) |
+| **PATCH** | HTTP PATCH request | Update (một phần) |
+| **DELETE** | HTTP DELETE request | Remove |
+| **Receive** | Nhận response từ server | Get response |
+| **Authenticate** | Thực hiện xác thực (login/token) | Login (trong API context) |
+
+---
+
+## Nhóm 4 — Test Setup / Teardown
+
+| Từ chuẩn | Dùng khi nào |
+|---|---|
+| **Setup** | Chuẩn bị dữ liệu / trạng thái trước test |
+| **Teardown** | Dọn dẹp sau test (xóa dữ liệu, reset state) |
+| **Login as** | Đăng nhập với role cụ thể: "Login as Teacher" |
+| **Logout** | Đăng xuất |
+| **Reset** | Đưa hệ thống về trạng thái ban đầu |
+| **Seed** | Tạo dữ liệu test (fixtures) trước khi chạy TC |
+
+---
+
+## Nhóm 5 — Trạng thái kỳ vọng (Expected keywords)
+
+| Từ chuẩn | Dùng khi nào | Không dùng |
+|---|---|---|
+| **displays** | UI hiển thị element/text | shows, appears, renders |
+| **is visible** | Element có thể nhìn thấy | is shown, is displayed |
+| **is enabled** | Element có thể tương tác | is active, is available |
+| **is disabled** | Element không thể tương tác | is inactive, is grayed out |
+| **is empty** | Field không có giá trị | is blank, is clear |
+| **contains** | Text/list chứa giá trị cụ thể | has, includes |
+| **equals** | Giá trị bằng chính xác | is, matches (cho exact match) |
+| **returns** | API trả về response | gives, sends back |
+| **persists** | Dữ liệu được lưu vào DB | saves, stores |
+| **navigates to** | Trình duyệt chuyển sang URL/màn mới | redirects to, goes to |

package/core/skills/qc/qa-designer/shared/duplicate-check-procedure.md

@@ -0,0 +1,105 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/shared/duplicate-check-procedure.md
+upstream_sha: c59357a56b289bb9fb7fae8490db37109209cb3a
+---
+# Duplicate Check Procedure
+
+> **Bắt buộc thực hiện** trước khi viết TC mới. TC trùng lặp làm tăng thời gian chạy, gây nhầm lẫn kết quả, và không tăng coverage.
+
+---
+
+## Định nghĩa TC trùng lặp
+
+Hai TC là **trùng** khi **cả 3** điều kiện sau đều giống nhau:
+1. **Điều kiện kiểm tra** (condition) — cùng scenario
+2. **Preconditions** — cùng trạng thái đầu vào
+3. **Test Data** — cùng partition/boundary value
+
+> Nếu chỉ khác tên/title nhưng nội dung giống → **trùng**.
+> Nếu cùng scenario nhưng khác role/data partition → **không trùng** (là 2 TC hợp lệ).
+
+---
+
+## Quy trình kiểm tra (3 bước)
+
+### Bước 1 — Grep title keywords trong file TC hiện tại
+
+Trước khi viết TC mới, tìm kiếm title keywords trong toàn bộ file:
+
+```bash
+# Tìm TC có chứa từ khóa scenario sắp viết
+grep -i "<từ_khóa_scenario>" {qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md
+```
+
+Ví dụ: Sắp viết TC "Nhập email không hợp lệ":
+```bash
+grep -i "email\|invalid\|không hợp lệ" {qc_artifact_dir}test-cases/TC_LOGIN.Test.md
+```
+
+### Bước 2 — So sánh preconditions + test data
+
+Nếu grep tìm thấy TC tương tự, so sánh:
+
+| Yếu tố | TC hiện có | TC sắp viết | Kết luận |
+|---|---|---|---|
+| Condition | Nhập email sai format | Nhập email sai format | Giống |
+| Precondition | Chưa login | Chưa login | Giống |
+| Test Data | `abc@` | `abc@` | Giống → **TRÙNG** |
+| Test Data | `abc@` | `abc` (không có @) | Khác partition → **KHÔNG TRÙNG** |
+
+### Bước 3 — Quyết định
+
+| Kết quả so sánh | Hành động |
+|---|---|
+| Trùng hoàn toàn (cả 3 yếu tố) | Không viết TC mới — sử dụng TC cũ |
+| Cùng condition, khác data/partition | Viết TC mới (hợp lệ) — thêm vào nhóm TC đó |
+| Cùng condition, khác platform (Web/App) | **KHÔNG trùng** — mỗi nền một thư mục (`{qc_dir}/{TICKET-ID}/web/` vs `/app/`) và mỗi nền phải tự đạt full coverage. Trùng logic giữa hai nền là **chủ đích** |
+| Không tìm thấy tương tự | Viết TC mới bình thường |
+
+---
+
+## Trường hợp đặc biệt
+
+### TC "uniqueness check" (kiểm tra trùng lặp dữ liệu)
+- **Chỉ viết** khi spec có ràng buộc uniqueness rõ ràng (vd: "email phải là duy nhất", "tên lớp không được trùng trong cùng giáo viên").
+- **Không viết** dựa trên suy đoán — cần có AC hoặc BR tường minh trong `{paths.specs_dir}`.
+
+### TC kế thừa logic từ UC khác
+- Nếu scenario giống UC khác đã có TC → **không viết lại**, ghi trace reference về UC nguồn.
+- Ví dụ: "Validation SĐT ở UC3 kế thừa logic UC2" → Trace: `BR-UC2-BR15`, ghi note "logic tương tự UC2".
+
+---
+
+## Áp dụng theo file — grep ở đâu
+
+Chỉ có **hai** file TC cho mỗi (tính năng × nền), chia theo *"verify được mà không cần UI?"*:
+
+| File | Chứa nhóm | Phạm vi grep khi kiểm trùng |
+|---|---|---|
+| `TC_<FEATURE>.Test.md` | GUI · Validation · Functional · Integration-qua-UI · NFR · E2E | **Toàn file** — trùng hay xảy ra giữa nhóm GUI và nhóm Functional |
+| `TC_<FEATURE>_API.Test.md` | Endpoint · Integration API/DB/Kafka | Toàn file — so cả **endpoint + method + phân vùng dữ liệu** |
+
+**Grep CẢ HAI file khi chưa chắc**, vì cùng một hành vi có thể đã được viết ở tầng khác: một
+TC "email đã tồn tại" có thể nằm ở nhóm Validation (qua UI) **hoặc** ở file API (409 Conflict).
+Hai cái đó **không trùng** — chúng test hai tầng khác nhau — nhưng phải biết cả hai tồn tại để
+không viết cái thứ ba.
+
+## Trùng chéo UC — chỗ mới xuất hiện
+
+Trước đây mỗi UC một thư mục riêng, nên TC của UC1 và UC2 không bao giờ gặp nhau. Giờ
+**mọi UC của một PRD nằm chung một thư mục `test-cases/`** — nên trùng chéo UC vừa **nhìn thấy
+được**, vừa **thực sự xảy ra**.
+
+Hai UC của cùng một PRD rất hay dùng lại một luật nghiệp vụ (validate số điện thoại, quyền
+truy cập, trạng thái hết hạn). Khi gặp:
+
+- **KHÔNG viết lại TC.** Ghi `Trace` trỏ về `BR-xx` của UC nguồn + một dòng ghi chú
+  *"logic tương tự {UC-ID}, đã phủ ở TC_<FEATURE>_NNN"*.
+- Chỉ viết TC mới khi **phân vùng dữ liệu hoặc tiền đề khác** — lúc đó không phải trùng.
+
+> **Vì sao gạch này quan trọng hơn sau khi bật chế độ tách tối đa.** Tách tối đa nhân số TC lên
+> (ví dụ thật: 82 → 130). Nhân một TC trùng lên 5 mảnh thì thành 5 TC trùng — và không ai đếm
+> được nữa. Kiểm trùng phải chạy **trước** khi tách, không phải sau.

package/core/skills/qc/qa-designer/shared/implicit-scenarios.md

@@ -0,0 +1,22 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/shared/implicit-scenarios.md
+upstream_sha: 6eb801a137ef4dfda97870c1eb36db62f3c782bc
+---
+# Implicit Scenarios (Bắt buộc nghĩ tới)
+
+**Với mọi TC ở mọi lane, luôn xét thêm các tình huống sau:**
+
+| Tình huống | Gợi ý kỹ thuật |
+|---|---|
+| Rate limiting / spam click | EP: vượt ngưỡng → block/error |
+| Concurrent / race condition | 2 request song song cùng resource |
+| Session / auth timeout | Hết hạn giữa chừng → redirect login |
+| Empty state | List rỗng, 0 kết quả, chưa có dữ liệu |
+| Max data | Trường đạt giới hạn ký tự/số lượng tối đa |
+| Ký tự đặc biệt | Emoji · Unicode · tiếng Việt có dấu · SQL injection attempt |
+| Audit / log | Hành động quan trọng có ghi log đúng không |
+
+> Không cần tạo TC riêng cho tất cả — đánh giá mức độ rủi ro: P0/P1 → viết TC, P2/P3 → ghi chú trong Test Data.