@educa-corp/sdd-framework 0.9.3 → 0.9.4

package/core/skills/qc/qa-reviewer/test-case/exploratory.md

@@ -1,7 +1,9 @@
 ---
 version: 1.0
-updated: 2026-06-11
+updated: 2026-09-04
 ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-reviewer/exploratory-test-reviewer.md
+upstream_sha: 4e068bb896739b977a6a5b1f638010d498c46aef
 ---
 
 # Review Charter — Exploratory
@@ -18,6 +20,30 @@ Review chất lượng test charter trước khi QC chạy session.
  
 ---
  
+## Trọng tâm review — tầng Exploratory
+
+- **Charter có mục tiêu đo được**: nêu rõ vùng thăm dò · tour áp dụng · rủi ro nhắm tới ·
+  time-box. Thiếu time-box → charter không kết thúc được.
+- **Không trùng vùng đã có TC scripted**: thăm dò chỗ đã phủ bằng TC là tiêu thời gian mà không
+  tăng thông tin → `[DUPLICATE]`.
+- **Phát hiện phải chuyển được thành TC**: mỗi phát hiện đáng giữ phải đủ thông tin để
+  `explore-to-functional` biến thành TC chính thức. Không đủ → yêu cầu bổ sung, đừng bỏ.
+
+*Charter **không phải** file TC — luật cấu trúc TC (ATOMIC, không bảng) **không áp** ở đây. Chỉ
+áp khi charter đã chuyển thành TC.*
+- **Phân nhóm & `Type`** *(Nhóm 3 riêng của tầng này)*: charter thuộc nhóm **Exploratory**, không
+  trộn với TC scripted. Một charter ôm nhiều vùng rủi ro → `[SPLIT_NEEDED]`.
+
+## 7 nhóm kiểm tra
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-check-groups.md`** — bộ xương 7 nhóm
+> chạy tuần tự · registry nhãn lỗi dùng chung · 7 mẫu-hay-thiếu của Nhóm 6 · nền tảng ISTQB ·
+> anti-pattern. Nhóm 5 (Nội dung TC) trỏ tiếp sang `shared/review-file-template.md`.
+>
+> Dưới đây chỉ là phần **riêng của tầng này**.
+
+---
+
 ## Phase 1 — Read
  
 Đọc tất cả charter .md trong folder chỉ định + feature description nếu có.
@@ -37,7 +63,30 @@ Review chất lượng test charter trước khi QC chạy session.
  
 ---
  
+## Phase 3 — Coverage tổng thể
+
+*(Suy ra cho tầng này — bản gốc không có.)*
+
+| Trục | Kỳ vọng tối thiểu |
+|---|---|
+| Vùng | Mỗi vùng rủi ro nêu trong TEST_PLAN có ≥1 charter |
+| Tour | Không dùng lặp một tour cho mọi charter — mỗi tour soi một góc khác |
+| Chuyển đổi | Mỗi phát hiện mức P0/P1 đã có đường thành TC chính thức |
+
+---
+
 ## Output
- 
-Mỗi charter: ✅ PASS | 🔧 REWORK | ✂️ SPLIT | 🔗 MERGE + feedback cụ thể
-Overall assessment + charter bổ sung nếu có gap
+
+**Ghi vào `{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — đứng cạnh file TC vừa soát.
+Nạp `../shared/review-file-template.md` để lấy khuôn + quy tắc ghi (tích luỹ theo vòng, chỉ sửa
+hàng của tầng mình, KHÔNG ghi đè tầng khác).
+
+Mỗi tiêu chí: ✅ PASS | ⚠️ WARN | ❌ FAIL + evidence cụ thể (charter ID)
+
+**Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
+**Verdict:** `điểm ≥ 80` VÀ không còn `FAIL` chặn → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+
+Mỗi charter: ✅ PASS | 🔧 REWORK | ✂️ SPLIT | 🔗 MERGE + feedback cụ thể.
+Charter bổ sung nếu còn gap.
+
+**KHÔNG tự sửa file TC** — chỉ nhận xét, chấm điểm, nêu cụ thể sửa gì. Người sửa là `/qc-design-test`.

package/core/skills/qc/qa-reviewer/test-case/functional.md

@@ -1,7 +1,9 @@
 ---
 version: 1.0
-updated: 2026-06-11
+updated: 2026-09-04
 ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-reviewer/ui-test-reviewer.md
+upstream_sha: 54f81eb6a132d3fb331f18ce0f1a7eb3a9cf19df
 ---
 
 # Review Test Case — Functional
@@ -10,7 +12,7 @@ Review bộ functional TC và đánh giá chất lượng.
  
 ## Khi nào trigger
 - "review TC cho [Feature]" / "check coverage"
-- Sau khi qa-designer xong, trước khi PO approve hoặc trước khi qa-runner
+- Sau khi qa-designer xong, trước khi PO approve hoặc trước khi /qc-run-test
  
 ## Khi KHÔNG trigger
 - Review Python script → dùng qa-reviewer
@@ -18,6 +20,32 @@ Review bộ functional TC và đánh giá chất lượng.
  
 ---
  
+## Trọng tâm review — tầng Functional / GUI
+
+- **Assertion hiển thị đo được**: cấm *"hiển thị đúng"* — phải nêu element / nhãn / chuỗi / màu
+  cụ thể. Thiếu → `[VAGUE_EXPECTED]`.
+- **EP + BVA từng field có ràng buộc**: mỗi phân vùng một TC; biên đủ 3 hoặc 4 giá trị tuỳ dạng
+  ràng buộc (`../../qa-designer/shared/precision-rules.md` §7). Thiếu → `[GAP]`.
+- **Bảng quyết định cho logic nhiều điều kiện**: có ≥2 điều kiện → **tự dựng bảng** để đếm N rule
+  tối thiểu (sau khi gộp don't-care); thiếu TC so với N → `[DT_COVERAGE_GAP]`.
+- **State Transition**: element có vòng đời phải phủ transition hợp lệ **và** transition bị cấm.
+  Thiếu nhánh cấm → `[GAP]`.
+- **Phân nhóm GUI vs Functional** *(Nhóm 3 riêng của tầng này)*: GUI = chỉ hiển thị tĩnh, không
+  đổi trạng thái · Functional = có hành động / validate / luồng. Sai nhóm → `[WRONG_GROUP]`;
+  một TC gánh cả hai → `[SPLIT_NEEDED]`.
+- **`Type` khớp nội dung**: Happy Path (luồng chính lý tưởng) · Positive (input hợp lệ → xử lý
+  đúng) · Negative (input sai → chặn & báo lỗi) · Edge (biên/cực trị). Lệch → `[WRONG_TYPE]`.
+
+## 7 nhóm kiểm tra
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-check-groups.md`** — bộ xương 7 nhóm
+> chạy tuần tự · registry nhãn lỗi dùng chung · 7 mẫu-hay-thiếu của Nhóm 6 · nền tảng ISTQB ·
+> anti-pattern. Nhóm 5 (Nội dung TC) trỏ tiếp sang `shared/review-file-template.md`.
+>
+> Dưới đây chỉ là phần **riêng của tầng này**.
+
+---
+
 ## Phase 1 — Clarify
  
 1. Đọc tất cả .Test.md trong folder được chỉ định
@@ -55,22 +83,42 @@ D. ANTI-PATTERN:
  
 ---
 
-## Checklist format file `.md` (đối chiếu skill layer qa-designer)
+## Phase 3 — Coverage tổng thể
+
+Sau khi duyệt hết từng TC, kiểm **bộ TC** có đủ bốn nhóm không:
 
-- **Metadata:** đủ Title, Feature, Priority, Status, Author, Tags, **Trace**; Priority `P0/P1/P2` (không emoji); Status `Draft` text thuần; mỗi trường 1 dòng riêng.
-- **Trace:** mỗi TC link `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; TC không có BR → phải có ⚠️ cảnh báo (không để trống/`—`).
-- **TC bị block:** TC phụ thuộc gap có dòng `🚫 Block: [GAP-xx]`; cuối file có **Trace matrix** (BR↔TC) + **bảng TC bị block** (Gap↔TC).
-- **Test Data:** dạng list (`- **Trường:** giá trị`), không dùng bảng.
-- **Test Steps:** phân biệt `[Action]`/`[Verify]`; KHÔNG có `- *Expected:* ...` sau mỗi bước.
-- **Expected Result:** 1 dòng bullet `-`, cụ thể; KHÔNG `✅ PASS/❌ FAIL`; không viết "hoạt động bình thường".
-- **KHÔNG** có section `#### Python Test Mapping`.
-- **1 concept/TC**; phân nhóm GUI / Functional.
+| Nhóm | Kỳ vọng tối thiểu |
+|---|---|
+| Display | Mỗi section / vùng giao diện có ≥1 TC |
+| Validation | Mỗi field có ràng buộc: required + BVA (3 hoặc 4 TC) + định dạng nếu có |
+| State | Mỗi element có ≥2 trạng thái: ≥1 TC trạng thái đầu + ≥1 TC chuyển trạng thái |
+| Interaction | Mỗi hành động (click / hover / bàn phím) ≥1 TC |
+
+Thiếu nhóm nào → bảng **Coverage gaps** của file review, kèm `[GAP]` + mã TC đề xuất bổ sung.
 
 ---
- 
+
+## Kiểm tra cấu trúc file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-file-template.md`** §*Kiểm tra cấu trúc
+> TC* — luật ATOMIC 1-bullet · không ký tự `|` · 9 cụm từ mơ hồ · teardown đúng chỗ · marker ≠
+> oracle · 6 dấu vết hỏng sau khi chạy script tách. **Không lặp lại ở đây.**
+>
+> Luật gốc mà trạm 3 phải theo nằm ở `qa-designer/shared/tc-metadata-format.md` +
+> `precision-rules.md`. **Cổng và luật phải đọc từ cùng một chỗ** — giữ hai bản là tự tạo lại
+> chỗ chúng lệch nhau, và cổng lệch thì nó đánh trượt file làm đúng.
+
 ## Output
- 
-Mỗi tiêu chí: ✅ PASS | ⚠️ PARTIAL | ❌ MISSING + evidence cụ thể
-Score: A (excellent) / B (good) / C (needs improvement) / D (redo)
+
+**Ghi vào `{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — đứng cạnh file TC vừa soát.
+Nạp `../shared/review-file-template.md` để lấy khuôn + quy tắc ghi (tích luỹ theo vòng, chỉ sửa
+hàng của tầng mình, KHÔNG ghi đè tầng khác).
+
+Mỗi tiêu chí: ✅ PASS | ⚠️ WARN | ❌ FAIL + evidence cụ thể
+
+**Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
+**Verdict:** `điểm ≥ 80` VÀ không còn `FAIL` chặn → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+
 Đề xuất TC cần thêm/sửa/xoá, sắp theo priority. Liệt kê TC thiếu Trace BR (⚠️) cần bổ sung.
 
+**KHÔNG tự sửa file TC** — chỉ nhận xét, chấm điểm, nêu cụ thể sửa gì. Người sửa là `/qc-design-test`.

package/core/skills/qc/qa-reviewer/test-case/integration.md

@@ -1,7 +1,9 @@
 ---
 version: 1.0
-updated: 2026-06-11
+updated: 2026-09-04
 ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-reviewer/integration-test-reviewer.md
+upstream_sha: 639b54afb68df83b22168581c5c57b0f91d9cf6a
 ---
 
 # Review Test Case — Integration
@@ -10,7 +12,7 @@ Review bộ TC tích hợp (GUI↔Backend, API, DB) và đánh giá chất lư
 
 ## Khi nào trigger
 - "review TC integration cho [Feature]" / "check TC tích hợp"
-- Sau khi qa-designer/integration/* xong, trước khi qa-runner
+- Sau khi qa-designer/integration/* xong, trước khi /qc-run-test
 
 ## Khi KHÔNG trigger
 - Review TC functional 1 màn/endpoint → `test-case/functional`
@@ -18,6 +20,30 @@ Review bộ TC tích hợp (GUI↔Backend, API, DB) và đánh giá chất lư
 
 ---
 
+## Trọng tâm review — tầng Integration
+
+- **Verify CẢ HAI phía**: mỗi handshake phải assert trạng thái của **Module A và Module B** +
+  tầng dữ liệu (DB/cache nhất quán). Chỉ verify một phía → `[GAP]`.
+- **Phủ đủ chế độ lỗi**: happy → một bên lỗi (suy giảm mềm) → timeout / mất mạng → dữ liệu cũ /
+  tranh chấp → tương thích ngược. Thiếu nhánh lỗi → `[GAP]`.
+- **Di trú DB phải có TC rollback**, không chỉ chiều tiến. Thiếu → `[GAP]` **mức cao**.
+- **Chuỗi API**: phủ lỗi một-phần (bước 2 trượt khi bước 1 đã commit) + tính idempotent.
+- **Mock hợp lý**: **không mock cả hai bên** — mock hết thì TC không còn kiểm gì. Kỹ thuật
+  State Transition / bảng quyết định phải khớp loại integration.
+- **Phân nhóm & `Type`** *(Nhóm 3 riêng của tầng này)*: TC integration thuộc nhóm **Nghiệp vụ**,
+  **không có** nhóm GUI. `Type` khớp nội dung. Sai nhóm → `[WRONG_GROUP]`; `Type` lệch →
+  `[WRONG_TYPE]`; một TC gánh nhiều cặp module → `[SPLIT_NEEDED]`.
+
+## 7 nhóm kiểm tra
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-check-groups.md`** — bộ xương 7 nhóm
+> chạy tuần tự · registry nhãn lỗi dùng chung · 7 mẫu-hay-thiếu của Nhóm 6 · nền tảng ISTQB ·
+> anti-pattern. Nhóm 5 (Nội dung TC) trỏ tiếp sang `shared/review-file-template.md`.
+>
+> Dưới đây chỉ là phần **riêng của tầng này**.
+
+---
+
 ## Phase 1 — Clarify
 
 1. Đọc tất cả TC integration trong folder chỉ định; xác định loại: GUI↔Backend / API / DB
@@ -46,24 +72,50 @@ C. QUALITY:
 - TC concurrency: mô tả rõ 2+ request đồng thời + kết quả kỳ vọng?
 
 D. FORMAT & TRACE:
-- Metadata đủ; Trace `[BR-xx]` hoặc `⚠️ Chưa có Business Rule`; `🚫 Block: [GAP-xx]` nếu bị chặn?
-- Cuối file có Trace matrix + bảng TC block?
+- Metadata đủ; Trace `[BR-xx]` hoặc `⚠️ Chưa có Business Rule`; `🚫 Block: [GAP-UC{N}-{nnn}]` nếu bị chặn?
+- Cuối file có **Trace matrix** (BR ↔ TC ↔ SC) + **danh sách** TC bị block — cả hai **dạng danh sách, KHÔNG bảng** (file TC không được có ký tự `|` — luật B12)?
 - Steps phân biệt `[Action]`/`[Verify]`; Expected 1 bullet; KHÔNG `✅/❌` inline.
 
 ---
 
-## Checklist format file `.md`
+## Phase 3 — Coverage tổng thể
+
+*(Bản gốc không có mục này cho tầng integration — bảng dưới suy ra từ chính các trục phủ ở
+§Trọng tâm review trên.)*
 
-- **Test Data:** dạng list; ghi rõ endpoint/payload/bảng cần kiểm tra.
-- **Expected (DB):** phải có dạng `bảng.cột = giá trị` + query kiểm tra + cleanup instruction.
-- **Expected (API):** ghi mã HTTP + cấu trúc response + downstream effect.
-- **Expected (GUI):** ghi API gọi + biểu hiện UI (message/state/list cập nhật).
+| Trục | Kỳ vọng tối thiểu |
+|---|---|
+| Happy | Mỗi cặp Module A ↔ Module B có ≥1 TC verify **cả hai phía** |
+| Failure | Mỗi cặp có ≥1 TC một-bên-lỗi (suy giảm mềm) |
+| Timeout | Mỗi lời gọi qua mạng có ≥1 TC timeout / mất mạng |
+| Rollback | Mỗi thao tác ghi có ≥1 TC rollback — **không chỉ chiều tiến** |
+
+Điền vào bảng **Coverage handshake (Integration)** ở cuối file review.
 
 ---
 
+## Kiểm tra cấu trúc file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-file-template.md`** §*Kiểm tra cấu trúc
+> TC* — luật ATOMIC 1-bullet · không ký tự `|` · 9 cụm từ mơ hồ · teardown đúng chỗ · marker ≠
+> oracle · 6 dấu vết hỏng sau khi chạy script tách. **Không lặp lại ở đây.**
+>
+> Luật gốc mà trạm 3 phải theo nằm ở `qa-designer/shared/tc-metadata-format.md` +
+> `precision-rules.md`. **Cổng và luật phải đọc từ cùng một chỗ** — giữ hai bản là tự tạo lại
+> chỗ chúng lệch nhau, và cổng lệch thì nó đánh trượt file làm đúng.
+
 ## Output
 
-Mỗi tiêu chí: ✅ PASS | ⚠️ PARTIAL | ❌ MISSING + evidence (TC ID / điểm tích hợp)
-Score: A (excellent) / B (good) / C (needs improvement) / D (redo)
+**Ghi vào `{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — đứng cạnh file TC vừa soát.
+Nạp `../shared/review-file-template.md` để lấy khuôn + quy tắc ghi (tích luỹ theo vòng, chỉ sửa
+hàng của tầng mình, KHÔNG ghi đè tầng khác).
+
+Mỗi tiêu chí: ✅ PASS | ⚠️ WARN | ❌ FAIL + evidence cụ thể (TC ID / điểm tích hợp)
+
+**Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
+**Verdict:** `điểm ≥ 80` VÀ không còn `FAIL` chặn → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+
 Điểm tích hợp thiếu TC; TC Expected mờ nhạt; TC DB thiếu cleanup.
-Kết luận: sẵn sàng cho `qa-runner` chưa.
+Điền thêm bảng **Coverage handshake (Integration)** ở cuối file review.
+
+**KHÔNG tự sửa file TC** — chỉ nhận xét, chấm điểm, nêu cụ thể sửa gì. Người sửa là `/qc-design-test`.

package/core/skills/qc/qa-reviewer/test-case/non-functional.md

@@ -1,7 +1,9 @@
 ---
 version: 1.0
-updated: 2026-06-11
+updated: 2026-09-04
 ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-reviewer/nfr-test-reviewer.md
+upstream_sha: 5747c7a6bdfaaea1ff3e958688b38b3aeaf9b15a
 ---
 
 # Review Test Case — Non-Functional
@@ -10,7 +12,7 @@ Review bộ TC phi chức năng (performance, security, accessibility, compatibi
 
 ## Khi nào trigger
 - "review TC non-functional cho [Feature]" / "check TC hiệu năng/bảo mật/accessibility"
-- Sau khi qa-designer/non-functional xong, trước khi qa-runner
+- Sau khi qa-designer/non-functional xong, trước khi /qc-run-test
 
 ## Khi KHÔNG trigger
 - Review TC chức năng → `test-case/functional`
@@ -18,6 +20,35 @@ Review bộ TC phi chức năng (performance, security, accessibility, compatibi
 
 ---
 
+## Trọng tâm review — tầng NFR
+
+- **Tiêu chí đo lường BẮT BUỘC**: mỗi TC có **ngưỡng + đơn vị + điều kiện môi trường**
+  (`P95 < X ms` · `error rate < Y%` · `contrast ≥ 4.5:1` · `Lighthouse a11y ≥ 90`).
+  Thiếu ngưỡng → `[VAGUE_EXPECTED]`. Đơn vị chuẩn theo domain:
+  `../../qa-designer/shared/precision-rules.md` §3.
+- **Đúng loại + đúng công cụ**: `Type` ∈ {Load · Stress · Spike · Security · A11y · i18n}; có
+  công cụ phù hợp (k6 / ZAP / axe-core…) + marker đúng
+  (`@pytest.mark.performance|security|a11y|i18n`).
+- **Phủ theo loại**: Performance có baseline + hồ sơ đồng thời · Security phủ OWASP áp dụng được
+  (A01/A03/A07…) · A11y phủ **bàn phím + trình đọc màn hình**, không chỉ axe-core tự động ·
+  i18n có tiếng Việt dấu đặc biệt (ộ/ề/ắ) + emoji + tràn chữ.
+- **Môi trường**: NFR không chạy CI thường → TC phải ghi rõ môi trường riêng (load-test /
+  staging) và lịch chạy (nightly / trước phát hành). Thiếu → `[MISSING_DATA]`.
+- **Phân nhóm & `Type`** *(Nhóm 3 riêng của tầng này)*: TC NFR thuộc nhóm **NFR**, **không có**
+  nhóm GUI. `Type` phải là một trong {Load · Stress · Spike · Security · A11y · i18n}. Sai nhóm →
+  `[WRONG_GROUP]`; `Type` không thuộc tập trên → `[WRONG_TYPE]`; một TC đo nhiều loại NFR →
+  `[SPLIT_NEEDED]`.
+
+## 7 nhóm kiểm tra
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-check-groups.md`** — bộ xương 7 nhóm
+> chạy tuần tự · registry nhãn lỗi dùng chung · 7 mẫu-hay-thiếu của Nhóm 6 · nền tảng ISTQB ·
+> anti-pattern. Nhóm 5 (Nội dung TC) trỏ tiếp sang `shared/review-file-template.md`.
+>
+> Dưới đây chỉ là phần **riêng của tầng này**.
+
+---
+
 ## Phase 1 — Clarify
 
 1. Đọc tất cả TC non-functional trong folder chỉ định; xác định loại: performance / security / accessibility / compatibility
@@ -49,25 +80,53 @@ C. ENVIRONMENT & DATA:
 - Cleanup / teardown sau mỗi TC (đặc biệt security test)?
 
 D. FORMAT & TRACE:
-- Metadata đủ; Trace `[BR-xx]` / SLA source rõ; `🚫 Block: [GAP-xx]` nếu bị chặn?
+- Metadata đủ; Trace `[BR-xx]` / SLA source rõ; `🚫 Block: [GAP-UC{N}-{nnn}]` nếu bị chặn?
 - Steps phân biệt `[Action]`/`[Verify]`; Expected 1 bullet; KHÔNG `✅/❌` inline?
-- Cuối file có Trace matrix + bảng TC block?
+- Cuối file có **Trace matrix** (BR ↔ TC ↔ SC) + **danh sách** TC bị block — cả hai **dạng danh sách, KHÔNG bảng** (file TC không được có ký tự `|` — luật B12)?
 
 ---
 
-## Checklist format file `.md`
+## Phase 3 — Coverage tổng thể
 
-- **Expected:** PHẢI có `ngưỡng + đơn vị + công cụ đo` — không có → ❌ MISSING.
-- **Performance TC:** ghi `concurrent users`, `data volume`, `target response time`.
-- **Security TC:** ghi `attack vector`, `input payload`, `expected block/response`.
-- **Accessibility TC:** ghi `WCAG version + level`, `tool (axe/lighthouse)`.
-- **Compatibility TC:** ghi `browser/OS version + device/resolution`.
+*(Bản gốc không có mục này cho tầng NFR — bảng dưới suy ra từ chính các trục phủ ở §Trọng tâm
+review trên.)*
+
+| Loại NFR | Kỳ vọng tối thiểu |
+|---|---|
+| Performance | Có baseline + ≥1 hồ sơ tải đồng thời, cả hai có ngưỡng + đơn vị |
+| Security | Phủ các mục OWASP **áp dụng được** cho tính năng này (A01/A03/A07…) |
+| Accessibility | Bàn phím **và** trình đọc màn hình — không chỉ axe-core tự động |
+| i18n | Tiếng Việt dấu đặc biệt + emoji + tràn chữ |
+| Compatibility | Các nền / trình duyệt mà PRD nêu |
+
+Loại nào PRD **không** yêu cầu → ghi `N/A` kèm lý do, **đừng bỏ trống**: ô trống không phân biệt
+được *"không áp dụng"* với *"quên kiểm"*.
+Điền vào bảng **Chi tiết NFR** ở cuối file review.
 
 ---
 
+## Kiểm tra cấu trúc file TC
+
+> **Nạp `{paths.qc_skills_dir}/qa-reviewer/shared/review-file-template.md`** §*Kiểm tra cấu trúc
+> TC* — luật ATOMIC 1-bullet · không ký tự `|` · 9 cụm từ mơ hồ · teardown đúng chỗ · marker ≠
+> oracle · 6 dấu vết hỏng sau khi chạy script tách. **Không lặp lại ở đây.**
+>
+> Luật gốc mà trạm 3 phải theo nằm ở `qa-designer/shared/tc-metadata-format.md` +
+> `precision-rules.md`. **Cổng và luật phải đọc từ cùng một chỗ** — giữ hai bản là tự tạo lại
+> chỗ chúng lệch nhau, và cổng lệch thì nó đánh trượt file làm đúng.
+
 ## Output
 
-Mỗi tiêu chí: ✅ PASS | ⚠️ PARTIAL | ❌ MISSING + evidence (TC ID)
-Score: A (excellent) / B (good) / C (needs improvement) / D (redo)
+**Ghi vào `{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — đứng cạnh file TC vừa soát.
+Nạp `../shared/review-file-template.md` để lấy khuôn + quy tắc ghi (tích luỹ theo vòng, chỉ sửa
+hàng của tầng mình, KHÔNG ghi đè tầng khác).
+
+Mỗi tiêu chí: ✅ PASS | ⚠️ WARN | ❌ FAIL + evidence cụ thể (TC ID)
+
+**Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
+**Verdict:** `điểm ≥ 80` VÀ không còn `FAIL` chặn → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+
 Danh sách TC Expected mờ nhạt (thiếu ngưỡng); loại non-functional thiếu coverage.
-Kết luận: sẵn sàng cho `qa-runner` chưa; ghi rõ TC nào cần môi trường đặc biệt.
+Ghi rõ TC nào cần môi trường đặc biệt. Điền thêm bảng **Chi tiết NFR** ở cuối file review.
+
+**KHÔNG tự sửa file TC** — chỉ nhận xét, chấm điểm, nêu cụ thể sửa gì. Người sửa là `/qc-design-test`.

package/core/skills/qc/qa-runner/e2e.md

@@ -26,7 +26,7 @@ Skill **tự chứa**: convert journey `.Test.md` → Python pytest + Playwright
 
 ## Phase 2 — Generate
 Mỗi journey → 1 test; bọc từng bước `with step("…")`; cuối journey verify đủ V1…Vn (tạo/mã/định tuyến/đồng bộ/danh sách).
-Journey còn phụ thuộc gap → tạo test `@pytest.mark.skip(reason="GAP-xx")` hoặc xfail.
+Journey còn phụ thuộc gap → tạo test `@pytest.mark.skip(reason="GAP-UC{N}-{nnn}")` hoặc xfail.
 
 ## Phase 3 — Verify
 `py_compile` + `pytest --collect-only -q` · chạy (môi trường staging + CRM) · cập nhật Status TC.

package/docs/02-concepts/pipeline-steps/09-validate-traces.md

@@ -40,7 +40,7 @@ Traceability chỉ có giá trị khi **kiểm được**. Bước này cho mộ
 | Artifact | Nội dung |
 |----------|----------|
 | Ma trận coverage spec ↔ code ↔ test | Trạng thái từng SC + `code_coverage` tổng |
-| `{trace_dir}/trace-report.json` | Bản máy đọc cho **panel VS Code** ("Spec Driven Docs Tools") — bị **ghi đè** mỗi lần chạy |
+| `{trace_dir}/trace-report.json` | Bản máy đọc cho **panel VS Code** ("SDD Board") — bị **ghi đè** mỗi lần chạy |
 | `{trace_dir}/trace-history.jsonl` | **Nhật ký append-only** — mỗi lần chạy ghi thêm 1 dòng *delta*. Đây là **dữ liệu**, không phải mirror: **phải commit**, mất là mất vĩnh viễn |
 | Cờ audit | 6 cờ drift + 4 cờ 🔴 chặn PR + `PRD_UNTRACKED_EDIT` 🔴 (không chặn) + 2 cờ ⓘ (bảng dưới) |
 | Hàng đợi | Đếm PRD change request còn `Open` kèm **số ngày chờ** (Step 7b) |

package/docs/04-reference/trace-schema.md

@@ -240,7 +240,7 @@ Ca thứ hai là lý do consumer **phải** chuẩn hoá tập bị ảnh hưở
 
 ## Xuất JSON cho panel
 
-`trace-report.json` giữ enum `status` **đúng 4 giá trị** `OK`/`DRIFT`/`GAP`/`UNTRACKED` — VS Code extension "Spec Driven Docs Tools" sống ngoài repo framework và switch trên field này. Row `ORPHANED` xuất ra là `"status": "DRIFT"` + `"orphaned": true`; panel cũ hiện nó như DRIFT (đúng nghĩa, không im lặng), panel mới đọc `orphaned` để hiện nhãn riêng. **TSV giữ nguyên chữ `ORPHANED`** — TSV là nguồn-sự-thật.
+`trace-report.json` giữ enum `status` **đúng 4 giá trị** `OK`/`DRIFT`/`GAP`/`UNTRACKED` — VS Code extension "SDD Board" sống ngoài repo framework và switch trên field này. Row `ORPHANED` xuất ra là `"status": "DRIFT"` + `"orphaned": true`; panel cũ hiện nó như DRIFT (đúng nghĩa, không im lặng), panel mới đọc `orphaned` để hiện nhãn riêng. **TSV giữ nguyên chữ `ORPHANED`** — TSV là nguồn-sự-thật.
 
 ---
 

package/docs/explain/00-setup-ai-first.md

@@ -44,7 +44,7 @@ Mọi command sau đều đọc `project-context.yaml` + `CLAUDE.md` + `domain-k
 5. **Step 3 · project-context.yaml** — copy từ `templates/project-context.yaml`, điền `{{PLACEHOLDER}}`. Umbrella: verify/sửa `services` (path phải khớp tên submodule thật — generator để placeholder `TODO-…`).
 6. **Step 4 · business-dictionary.md** — Canonical Terms / Banned Terms / Enum Registry. *(Umbrella skip — sống trong spec submodule.)*
 7. **Step 5 · core-entities.md** — entity catalog máy-đọc-được (field, invariant, relationship). *(Umbrella skip.)*
-8. **Step 6 · VS Code extension** — khuyến nghị cài "Spec Driven Docs Tools" (Review Board + Living Docs UI).
+8. **Step 6 · VS Code extension** — khuyến nghị cài "SDD Board" (Review Board + Living Docs UI).
 9. **Step 7 · Verify** — checklist theo `project_type` (file/folder tồn tại; umbrella check submodule init).
 
 ---

package/docs/plans/qc-implementation-log.md

@@ -1512,6 +1512,148 @@ xem bản mới có bắt thêm gap thật hay không.
 
 ---
 
+# ✅ B12 — Rà trạm viết kịch bản kiểm thử theo bản gốc
+
+Đi theo đúng thứ tự dây chuyền: xong trạm 1 và 2 (B11) thì tới trạm 3 — **trạm quyết định có
+test hay không có test**.
+
+## Hai điều rà ra
+
+**① Trạm này chưa hề được đụng trong cả đợt merge.** Bản đồ port ghi **21/21 file gốc ở trạng
+thái "chưa quyết"**. 11 kỹ năng đang chạy đến từ **một nguồn khác** (`lms_autotest`), không phải
+từ đội QC.
+
+| | File | Dòng |
+|---|---|---|
+| Bản gốc đội QC | 21 | **2.509** |
+| Framework | 11 | **496** *(~20%)* |
+
+**② Một lỗi im lặng, cùng lớp với `DOC_GAPS` / `DOC_GAP`:**
+
+| Ai | Nói tên file là |
+|---|---|
+| 2 kỹ năng | `TC_<FEATURE>.md` |
+| 1 kỹ năng | `TC_<FEATURE>_API.md` |
+| **4 kỹ năng** | **không nêu tên gì cả** |
+| Lệnh thiết kế · lệnh chạy · lệnh soát · module Playwright *(13 chỗ)* | `*.Test.md` |
+
+**Trạm thiết kế ghi ra thứ trạm chạy không tìm thấy.** Và không có gì báo lỗi — file vẫn nằm
+đó, trạm sau chỉ đơn giản không thấy.
+
+Framework có **phương pháp** (EP/BVA/bảng quyết định, danh sách nhóm TC); bản gốc có **chi
+tiết** (cấm từ mơ hồ, khuôn TC, từ điển hành động, bảng tra mã HTTP). Đúng khuôn đã gặp ở B1.
+
+## Bốn quyết định
+
+| # | Chốt | Nghĩa cho người dùng |
+|---|---|---|
+| **1** | **Luật ATOMIC, có cả chế độ tách tối đa** | Mỗi test case đúng **một** dòng kết quả mong đợi. Nhiều điểm kiểm → tách thành nhiều TC độc lập |
+| **2** | **Bỏ bảng trong file test case** | Toàn bộ dạng danh sách, không ký tự `\|` — kể cả mục Tổng hợp và Trace Matrix |
+| **3** | **Hai file, chia theo "có qua giao diện"** | mặc định → file giao diện (6 nhóm) · `--api` → file API (2 nhóm) · `--all` → cả hai |
+| **4** | **Lấy trọn 7 file luật chung + cả nhánh API, nhưng VIẾT LẠI 2 file mẫu** | 1.523 dòng |
+
+## Chỗ suýt tự bắn vào chân mình
+
+Nhánh API của bản gốc có 2 file **test case mẫu**. Đọc kỹ thì chúng viết **trước** luật ATOMIC
+(đội QC chốt 2026-07-09, và văn bản ghi rõ *"ĐẢO rule cũ"*):
+
+```
+MẪU GỐC (cũ hơn luật)                  ĐÃ VIẾT LẠI
+**Expected:**                           #### Expected Result
+- HTTP 201; body.id = x;                - HTTP 201 AND body.id exists
+  bản ghi có trong DB
+     ▲ ba kết cục nối bằng ";"         → TC_002: body.<field> = <giá trị>
+  mã: API-<FEATURE>-001                → TC_003: DB có bản ghi id = body.id
+     ▲ hệ mã khác                       mã: TC_<FEATURE>_NNN
+```
+
+**Lấy nguyên hai file này là dạy AI làm ngược đúng cái luật vừa chốt** — vì mẫu cụ thể luôn
+thắng luật trừu tượng. Đã viết lại cả hai, và kiểm bằng máy: **13/13 khối kết quả mong đợi có
+đúng 1 dòng**.
+
+Cũng bỏ 26 dòng là **bản nháp cũ** của chính họ: một bảng tra mã lỗi 14 dòng nằm gọn trong bảng
+95 dòng, một file chuỗi gọi 12 dòng nằm gọn trong hai file dài hơn. Lấy cả hai là có hai bảng
+tra cùng một thứ, rồi chúng lệch nhau.
+
+## Bốn thứ giờ mới có
+
+| Luật | Nó chặn điều gì |
+|---|---|
+| **Cấm 9 cụm từ mơ hồ** | *"hiển thị đúng"* · *"hoạt động bình thường"* · *"không lỗi"* → bắt viết giá trị đo được. Phép thử: **hai QC đọc có ra cùng một kết luận đỗ/trượt không?** |
+| **Khuôn TC + luật ATOMIC** | Mỗi TC một kết cục; mẫu đầy đủ; 5 bẫy khi đánh số lại hàng loạt |
+| **Cây quyết định chọn tầng** | ~12 ví dụ phân biệt: *"dropdown có placeholder"* = giao diện, *"dropdown hiện đúng N mục từ API"* = tích hợp |
+| **Từ điển hành động** | Một hành động **một** từ: Click (web) / Tap (mobile) / Enter (nhập) — cấm dùng Type, Input, Fill lẫn lộn |
+
+Thêm **kiểm trùng lặp** — thứ framework trước đây **không có gì cả**. Nó quan trọng hơn sau khi
+bật chế độ tách tối đa: 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. Nên kiểm trùng phải chạy **trước** khi tách.
+
+Và B11 vừa gom mọi UC vào **một thư mục** — nên **trùng chéo UC** giờ mới thực sự nhìn thấy
+được, và mới thực sự xảy ra. Hai UC của cùng tính năng rất hay dùng lại một luật nghiệp vụ;
+gặp thì trỏ trace về UC nguồn, **không viết lại**.
+
+## Chín bản của một luật → một bản
+
+Khối *"Format file TC"* trước đây **bị chép ở 9 kỹ năng** và câu chữ đã lệch nhau. Giờ một
+bản dùng chung, 9 kỹ năng trỏ về. **Cùng bệnh 5-bản mà B11 vừa chữa** — và lần này nó không
+tiết kiệm dòng, nó chỉ bỏ đi khả năng chín bản nói khác nhau.
+
+Cũng bỏ chữ **"hoặc"**: hai kỹ năng từng ghi *"file riêng **hoặc** gộp trong file feature"*.
+Chữ "hoặc" nghĩa là AI tự chọn mỗi lần một kiểu — nên hai lần chạy cùng một tính năng có thể ra
+hai cấu trúc thư mục khác nhau.
+
+## Hai lần bị máy bắt lỗi — và đó là điểm sáng
+
+**Lần 1 — self-check chặn.** Tôi dồn phần `@trace.testid_attr` sang file dùng chung, làm lệnh
+không còn nhắc tag nữa. Rule R3 đỏ ngay: *"schema khai `qc-design-test` là consumer nhưng lệnh
+KHÔNG nhắc tới nó"*. Đúng — tôi gộp quá tay. Đã trả lại ở lệnh.
+
+**Lần 2 — bộ test chặn.** `qc-scope.md` (B11) được 5 lệnh nạp, nên nó bị nướng 5 bản vào 5 file
+lệnh. Cộng thêm phần B12, tổng vượt ngưỡng: **1203 KB / ngưỡng 1200**. Framework đã có cơ chế
+cho đúng ca này (đọc-lúc-chạy thay vì nướng vào), chỉ là chưa dùng cho file đó. Chuyển xong:
+**1174 KB**.
+
+> Cả hai lỗi đều là **lỗi của tôi**, và **cả hai đều do máy bắt, không phải do tôi đọc lại**.
+> Đây chính là lập luận cho mục còn treo 2b: thứ có máy canh thì không đi lệch.
+
+## Bịt một điểm mù của chính bộ máy canh
+
+Cập nhật bản đồ port xong, self-check **xanh** — nhưng `functional/api.md` nhận nội dung port mà
+**không đóng dấu nguồn gốc** nào. Đọc lại luật thì rõ vì sao: nó so dấu với bản đồ **khi file có
+khai**. File không khai gì thì nó im lặng.
+
+Đã thêm một nhánh mới: **target đã port thì PHẢI khai** nguồn gốc, không chỉ "khai đúng nếu có
+khai". Và **thử cháy thật** cả hai góc (bỏ cả hai dòng · bỏ một dòng) — kêu đúng cả hai lần.
+
+Mất dấu nguồn gốc ở file đích nghĩa là: bản đồ biết file này port từ đâu, còn **người mở file
+thì không** — và lần đồng bộ sau, mọi thứ thành đoán.
+
+## Đã kiểm chứng
+
+| Phép kiểm | Kết quả |
+|---|---|
+| Dựng lại toàn bộ | 41/41 ✅ |
+| Bộ kiểm tra nội bộ | sạch (giờ có **17** nhánh luật) ✅ |
+| Bộ test tự động | **199/199** ✅ |
+| Tổng kích thước lệnh | 1174 KB / ngưỡng 1200 ✅ |
+| Tên file cũ còn sót | **0** |
+| Lệnh "in bảng" trong kỹ năng thiết kế | **0** |
+| Dấu vết mẫu cũ trong nhánh API | **0** |
+| Khối kết quả mong đợi đúng 1 dòng | **13/13** |
+| Entry "chưa quyết" của trạm này | **21 → 0** |
+| Target đã port có đủ dấu nguồn gốc | **23/23** |
+| File mới tới đủ ba tầng (nguồn → đóng gói → đang chạy) | **13/13/13** |
+
+## Cố ý chưa làm
+
+| Việc | Vì sao |
+|---|---|
+| **Máy kiểm cấu trúc file test case** | Vẫn là năng lực mới, và vẫn chờ kết quả phép thử của trạm 1. Nhưng B12 làm nó **rẻ hơn hẳn**: cả hai luật mới đều **đếm được** — "0 ký tự `\|`" và "1 dòng mỗi kết quả". Nếu phép thử kết luận cần máy kiểm thì làm một lượt cho cả file gap và file test case |
+| **4 file tầng test của bản gốc** *(ui · e2e · integration · nfr — 935 dòng)* | Đã ghi `skipped` **kèm lý do**, không để "chưa quyết". Framework tách tầng UI thành 3 kỹ năng theo cây quyết định thay vì một file 341 dòng; phần khuôn TC và độ chính xác **đã tách ra dùng chung**. Còn lại là phần khai kiến trúc agent — framework không có. Đối chiếu nội dung từng tầng để dành |
+| **3 trạm còn lại** | Đi theo thứ tự dây chuyền. Trạm soát là trạm kế tiếp, và nó **tiêu thụ** đúng chuẩn B12 vừa đặt ra — làm sau là đúng thứ tự |
+
+---
+
 # Tổng kết
 
 | | Quyết định ở B7 | Bằng chứng | |
@@ -1554,7 +1696,7 @@ rồi, giờ bắt nó **so** với hai tài liệu kia"*. Không nạp thêm fi
 
 # Các bước còn lại
 
-**Mười hai bước B0–B11 đã xong.** Không còn bước nào đang chờ quyết định để bắt đầu.
+**Mười ba bước B0–B12 đã xong.** Không còn bước nào đang chờ quyết định để bắt đầu.
 
 Nhưng có **hai việc chưa validate** và **bốn món nợ** — xem §Còn treo ở cuối.
 Mô tả kế hoạch gốc nằm ở [`qc-merge-plan.md`](qc-merge-plan.md).
@@ -1568,7 +1710,7 @@ Mô tả kế hoạch gốc nằm ở [`qc-merge-plan.md`](qc-merge-plan.md).
 Sau mỗi bước, toàn bộ hệ thống được dựng lại và kiểm tra tự động:
 
 - 41/41 mẫu lệnh dựng thành công
-- Bộ kiểm tra nội bộ báo sạch
+- Bộ kiểm tra nội bộ báo sạch (17 nhánh luật sau B12)
 - Nội dung mới đã lan đủ ba tầng: bản nguồn → bản đóng gói → bản đang chạy
 - **9** dấu nguồn gốc đều được kiểm chứng khớp với file gốc thật
 - Báo khói đã **thử cháy thật** cả 5 nhánh — không giao một cái chưa bao giờ kêu
@@ -1579,7 +1721,7 @@ Sau mỗi bước, toàn bộ hệ thống được dựng lại và kiểm tra
 
 | # | Câu | Mức | Ai quyết |
 |---|---|---|---|
-| **1** | Chạy thử trên một tính năng thật — **mười hai bước, chưa một lần chạy**. Sau B11 phép thử này còn quan trọng hơn: nó là cách duy nhất biết bản cấp tính năng có bắt được mâu thuẫn chéo UC, và có theo đúng template hay không. Ước lượng chi phí của tôi đã sai 3 lần, đều ước thấp | 🔴 chưa validate | bạn (cần spec thật) |
+| **1** | Chạy thử trên một tính năng thật — **mười ba bước, chưa một lần chạy**. Sau B11 phép thử này còn quan trọng hơn: nó là cách duy nhất biết bản cấp tính năng có bắt được mâu thuẫn chéo UC, và có theo đúng template hay không. Ước lượng chi phí của tôi đã sai 3 lần, đều ước thấp | 🔴 chưa validate | bạn (cần spec thật) |
 | **2** | Đưa nhật ký cho đội QC xem — họ là chủ sở hữu các kỹ năng này, và định dạng họ nhận đã đổi **hai lần** (B9 rồi B11) | 🟠 | bạn |
 | **2b** | **Máy kiểm cấu trúc file gap** — bệnh *"không theo template"* vẫn chưa có gì chặn bằng máy. Hiện chỉ có chỉ thị bằng văn xuôi, tức **cùng loại** với câu chỉ đường đã thất bại, chỉ mạnh hơn | 🟠 chưa chữa | bạn (sau khi chạy thử B11) |
 | **2c** | `Blocker` ↔ `Critical` — đổi trạm chạy test đọc `Critical` (một dòng) thay vì bắt đội QC đổi thói quen. Kết quả hôm trước cho thấy đổi từ ngữ của họ làm **tăng** khả năng lệch | 🟡 | bạn |