@anhth2/spec-driven-dev-plugin 0.9.2 → 0.11.0

package/core/skills/qc/qa-analyst/acceptance-criteria.md

@@ -0,0 +1,56 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Acceptance Criteria — Sinh tiêu chí chấp nhận
+
+Chuyển yêu cầu đã phân tích thành acceptance criteria (Given/When/Then) làm cơ sở thiết kế TC.
+
+## Khi nào trigger
+- "viết acceptance criteria cho [X]" / "định nghĩa tiêu chí pass"
+- Sau spec-breakdown + business-rules, là bước cuối của qa-analyst
+- Cần điều kiện chấp nhận rõ ràng để qa-designer trace TC ngược về
+
+## Khi KHÔNG trigger
+- Cần bóc tách spec → dùng spec-breakdown
+- Cần thiết kế test case chi tiết (steps cụ thể) → dùng qa-designer
+- Cần phân tích rủi ro → dùng qa-planner
+
+---
+
+## Phase 1 — Tổng hợp
+
+Gom đầu vào từ spec-breakdown, business-rules, data-flow:
+- Mỗi chức năng/luồng → một nhóm acceptance criteria.
+- Mỗi business rule (BR-xx) → ít nhất một AC kiểm chứng.
+
+---
+
+## Phase 2 — Viết AC
+
+Dùng format Given/When/Then, mỗi AC kiểm chứng MỘT điều:
+
+```
+AC-01 (chức năng / BR-xx):
+  Given <tiền điều kiện>
+  When  <hành động + dữ liệu cụ thể>
+  Then  <kết quả mong đợi CỤ THỂ>
+```
+
+Bắt buộc phủ:
+- Happy path (điều kiện hợp lệ).
+- Negative (vi phạm validation / authorization).
+- Boundary (giá trị biên của giới hạn trong business-rules).
+- Alternate flow (luồng phụ trong data-flow).
+
+Mỗi AC gắn mã trace: chức năng + BR-xx để TC sau này map 1-1.
+
+---
+
+## Output
+
+- Danh sách AC dạng Given/When/Then, có mã trace về chức năng và business rule.
+- Bảng ma trận: BR / chức năng × AC để xác nhận không bỏ sót.
+- Đây là đầu vào trực tiếp cho `qa-designer` (mỗi AC → ≥1 test case) và `qa-reviewer` (đối chiếu coverage).

package/core/skills/qc/qa-analyst/business-rules.md

@@ -0,0 +1,55 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Business Rules — Trích xuất luật nghiệp vụ
+
+Trích xuất và liệt kê toàn bộ business rule, điều kiện và ràng buộc từ yêu cầu.
+
+## Khi nào trigger
+- "liệt kê business rule cho [X]" / "feature này có luật nghiệp vụ gì"
+- Sau spec-breakdown, khi cần làm rõ logic điều kiện trước khi thiết kế TC
+- Feature có nhiều điều kiện AND/OR, phân quyền, tính toán, giới hạn
+
+## Khi KHÔNG trigger
+- Cần bóc tách tổng thể spec → dùng spec-breakdown
+- Cần luồng dữ liệu → dùng data-flow
+- Cần phân tích rủi ro / lập test plan → thuộc qa-planner (skill test-plan)
+
+---
+
+## Phase 1 — Quét
+
+1. Đọc spec đã bóc tách (output của spec-breakdown) hoặc tài liệu gốc.
+2. Quét tìm: điều kiện ("nếu… thì…"), ràng buộc field, giới hạn (min/max, rate limit),
+   quy tắc phân quyền, công thức tính, quy tắc trạng thái, default value.
+
+---
+
+## Phase 2 — Cấu trúc hoá
+
+Mỗi rule ghi dưới dạng bảng:
+
+| ID | Rule | Điều kiện | Kết quả | Nguồn | Ghi chú/Ưu tiên |
+|---|---|---|---|---|---|
+| BR-01 | … | … | … | spec §x | … |
+
+Phân loại rule:
+- VALIDATION: ràng buộc input (định dạng, bắt buộc, độ dài, range).
+- AUTHORIZATION: ai được làm gì.
+- CALCULATION: công thức, làm tròn, đơn vị.
+- STATE: điều kiện chuyển trạng thái hợp lệ vs cấm.
+- LIMIT: rate limit, quota, concurrent.
+
+Với rule có nhiều điều kiện kết hợp → gợi ý dựng **Decision Table** (đầu vào cho qa-designer).
+
+---
+
+## Output
+
+- Bảng business rule có ID (BR-xx) để TC trace ngược về.
+- Rule MÂU THUẪN / KHÔNG RÕ → ghi vào `DOC_GAPS.md` (loại CONTRADICTORY / AMBIGUOUS,
+  cột "Ảnh hưởng" trỏ BR-xx) rồi ghi vào `DOC_GAPS.md`.
+- Gợi ý các rule cần Decision Table / BVA khi sang qa-designer.

package/core/skills/qc/qa-analyst/data-flow.md

@@ -0,0 +1,60 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Data Flow — Phân tích luồng dữ liệu
+
+Phân tích luồng dữ liệu, input/output, state và điểm tích hợp của feature.
+
+## Khi nào trigger
+- "phân tích data flow cho [X]" / "dữ liệu đi qua đâu"
+- Feature có nhiều bước, qua nhiều màn hình/API/DB, hoặc tích hợp Kafka/service khác
+- Cần xác định điểm tích hợp trước khi thiết kế integration/e2e TC
+
+## Khi KHÔNG trigger
+- Chỉ cần bóc tách spec tổng quan → dùng spec-breakdown
+- Chỉ cần luật nghiệp vụ → dùng business-rules
+- Thiết kế integration TC → dùng qa-designer/integration
+
+---
+
+## Phase 1 — Lập bản đồ
+
+Với mỗi luồng nghiệp vụ, xác định:
+1. ĐIỂM BẮT ĐẦU: actor/sự kiện kích hoạt + dữ liệu đầu vào.
+2. CÁC CHẶNG: UI → API → service → DB → message queue → service ngoài.
+3. BIẾN ĐỔI: dữ liệu được tạo/sửa/xoá/validate ở mỗi chặng.
+4. ĐIỂM KẾT THÚC: output, side-effect (email, notification, audit log).
+
+---
+
+## Phase 2 — Mô tả
+
+Thể hiện luồng dạng bước tuần tự hoặc sơ đồ text:
+
+```
+[User submit form]
+   → POST /api/... (payload: ...)
+   → Service validate (rule BR-xx)
+   → DB insert bảng X
+   → Kafka topic Y (event Z)
+   → UI hiển thị kết quả / trạng thái
+```
+
+Đánh dấu cho mỗi chặng:
+- INTEGRATION POINT (nơi cần integration test).
+- STATE CHANGE (dữ liệu/trạng thái thay đổi → cần verify + cleanup).
+- FAILURE POINT (nơi có thể lỗi: timeout, validation fail, partial commit).
+
+---
+
+## Output
+
+- Sơ đồ/list luồng dữ liệu cho mỗi kịch bản chính.
+- Danh sách integration point + state change + failure point.
+- Chặng nào luồng/hành vi chưa rõ (vd lỗi xử lý ra sao, retry, partial commit) →
+  ghi vào `DOC_GAPS.md` (loại MISSING / OPEN QUESTION).
+- Gợi ý loại test cần cho từng điểm (gui-feature / integration / e2e) khi sang qa-designer.
+- Dữ liệu/trạng thái cần chuẩn bị & cleanup → đầu vào fixture cho qa-runner.

package/core/skills/qc/qa-analyst/spec-breakdown.md

@@ -0,0 +1,57 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Spec Breakdown — Bóc tách yêu cầu
+
+Bóc tách spec/PRD/user story thô thành mô tả yêu cầu có cấu trúc cho QC.
+
+## Khi nào trigger
+- "phân tích spec/PRD cho feature [X]" / "bóc tách yêu cầu"
+- Nhận tài liệu thô (PRD, user story, mô tả Figma, email) cần làm rõ trước khi thiết kế TC
+- Là bước ĐẦU TIÊN của pipeline, trước qa-planner
+
+## Khi KHÔNG trigger
+- Cần phân tích rủi ro / what-if → dùng qa-planner
+- Cần trích riêng business rule → dùng business-rules
+- Cần thiết kế test case → dùng qa-designer
+
+---
+
+## Phase 1 — Thu thập
+
+1. Đọc toàn bộ tài liệu nguồn QC cung cấp (PRD, user story, mockup, ghi chú).
+2. **Bỏ qua văn bản gạch ngang (strikethrough)** — đó là nội dung đã huỷ, KHÔNG đưa
+   vào phân tích/BR/AC. Với file Confluence/HTML/MHTML: phát hiện qua thẻ `<s>`,
+   `<strike>`, `<del>` hoặc style `text-decoration: line-through`.
+3. Xác định: feature name, actor/role, mục tiêu nghiệp vụ, phạm vi (in/out scope).
+4. Đánh dấu phần MƠ HỒ / THIẾU → ghi vào `DOC_GAPS.md` (gap GAP-xx).
+
+---
+
+## Phase 2 — Bóc tách
+
+Tách yêu cầu thành các khối:
+
+A. TỔNG QUAN: mục tiêu, actor, giá trị nghiệp vụ.
+B. CHỨC NĂNG: list từng chức năng (visible + ẩn + integration point).
+C. INPUT/OUTPUT: mỗi chức năng có input gì, output gì, ràng buộc field.
+D. TRẠNG THÁI & LUỒNG: các state, điều kiện chuyển, happy path + alternate flow.
+E. PHỤ THUỘC: hệ thống/API/module liên quan.
+F. GIẢ ĐỊNH & CÂU HỎI MỞ: điều suy ra được vs điều cần dev/BA xác nhận.
+
+---
+
+## Output
+
+File Markdown mô tả yêu cầu có cấu trúc (đặt trong `docs/<project>/<feature>/`):
+- Bảng chức năng + input/output/constraint
+- Sơ đồ/list luồng chính & phụ
+- Danh sách giả định và câu hỏi mở (đánh dấu rõ điều CHƯA chắc)
+
+Đồng thời ghi mọi khoảng trống phát hiện vào `docs/<project>/<feature>/DOC_GAPS.md`
+(theo `.claude/skills/qa-analyst/DOC_GAPS.template.md`), mỗi gap có ID `GAP-xx`.
+
+Kết thúc bằng gợi ý: feature đã đủ rõ để chuyển sang `qa-planner` (phân tích rủi ro) chưa.

package/core/skills/qc/qa-designer/e2e/journey.md

@@ -0,0 +1,41 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — E2E Journey
+
+Skill **tự chứa** để viết TC end-to-end: hành trình đầu→cuối xuyên nhiều màn/module
+(mở → nhập → submit → verify tạo + định tuyến + đồng bộ + hiển thị). Chỉ cần load file này.
+
+## Khi nào trigger
+- "viết E2E cho [feature]" / nở danh sách journey trong TEST_PLAN thành TC chi tiết đầu-cuối
+
+## Khi KHÔNG trigger
+- Test 1 màn/field → `functional/*` · test riêng 1 điểm tích hợp → `integration/*`
+
+---
+
+## 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_GAPS.md)`.
+- **Test Data** dạng list (tài khoản/role, dữ liệu lớp/buổi…) · **Steps** `[Action]`/`[Verify]` xuyên các màn ·
+  **Expected** 1 bullet = chuỗi verify point (tạo thành công, mã đúng, định tuyến đúng, đồng bộ đúng, hiển thị danh sách).
+- ID journey `E2E-<FEATURE>-NN` · cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+
+## Kỹ thuật áp dụng
+- **Use Case/Scenario:** mỗi journey = main + alternate + exception flow.
+- **Decision Table** để chọn journey đại diện cho mỗi nhánh của **trục bao phủ** (vd Đối tượng × Bộ phận xử lý × lớp/buổi × role × CRM).
+- **Verify points chung** (V1…Vn) áp cho mọi journey · **end-to-end data** (nhập màn A → hiện đúng màn B/DB/hệ thống ngoài).
+
+## Phase 1 — Clarify
+Lấy danh sách journey + trục bao phủ + verify points từ TEST_PLAN · mỗi journey: actor/role, tiền điều kiện
+(data + tài khoản), bước chính, kết quả/định tuyến kỳ vọng · journey nào phụ thuộc gap Blocker.
+
+## Phase 2 — Write
+Mỗi journey → 1 TC bám Format; Expected = chuỗi verify point; chuẩn bị tiền điều kiện & cleanup, mỗi journey độc lập.
+**Journey phụ thuộc gap vẫn viết + 🚫 Block: GAP-xx**, định tuyến ghi "dự kiến theo BR". Trace BR.
+
+## Output
+File TC e2e (hoặc nhóm E2E trong file feature) trong `docs/<project>/<feature>/`.
+In bảng `E2E-ID | Journey | Pri | Trace | Block` + bảng TC block. Bàn giao `qa-reviewer`.

package/core/skills/qc/qa-designer/exploratory/charter.md

@@ -0,0 +1,68 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Gen Test Charter — Exploratory
+ 
+Sinh bộ test charter + SFDIPOT test ideas + What-If scenarios cho exploratory session.
+ 
+## Khi nào trigger
+- "generate charter cho [Feature]" / "chuẩn bị exploratory session"
+- Trước khi bắt đầu exploratory session
+- Feature mới chưa ai khám phá, hoặc feature có risk cao
+ 
+## Khi KHÔNG trigger
+- Cần sinh functional TC từ spec → dùng qa-designer-gui-screen / qa-designer-gui-feature
+- Cần khám phá feature rồi CHUYỂN ĐỔI thành functional TC → dùng explore-to-functional
+- Cần review charter đã viết → dùng qa-reviewer/test-case/exploratory
+ 
+---
+ 
+## Phase 1 — Clarify
+ 
+Thu thập:
+1. Feature name + mô tả ngắn
+2. Tester level — junior / mid / senior (ảnh hưởng charter complexity)
+3. Time-box — 30 / 60 / 90 phút
+4. Môi trường — staging / production-like
+5. Đã có functional TC coverage chưa (nếu có → exploratory focus vào edge case NGOÀI spec)
+ 
+---
+ 
+## Phase 2 — Analyze
+ 
+Áp dụng SFDIPOT 7 dimension:
+S - Structure: thành phần/module/page liên quan
+F - Function: chức năng chính + phụ + ẩn
+D - Data: edge data, boundary, empty, max, special chars
+I - Interface: UI, API, integration point
+P - Platform: browser, OS, device, network
+O - Operations: ai dùng, khi nào, tần suất
+T - Time: timeout, expiry, concurrent, timezone
+ 
+Với mỗi dimension: 3-5 test idea CỤ THỂ.
+ 
+Brainstorm 15-20 "What If" scenarios bất thường:
+double click, network drop, 2 tab, back button, idle 2h, emoji input, device rotate...
+ 
+---
+ 
+## Phase 3 — Write
+ 
+Sinh 3-5 charter, mỗi charter gồm:
+- Format: "Explore <target> With <resource> To discover <information>"
+- Whittaker Tour phù hợp (Money/FedEx/Saboteur/Couch Potato/Intellectual/...)
+- Risk level: HIGH / MEDIUM / LOW
+- Time-box: 30 / 60 / 90 phút
+ 
+Sinh 10-15 câu hỏi cho dev/BA (assumptions, edge case, error handling, security)
+ 
+---
+ 
+## Output
+ 
+Charter files: docs/<project>/exploratory/charters/<feature>_01.md, _02.md...
+Ideas file: docs/<project>/exploratory/ideas/<feature>.md
+Bảng tổng kết: STT | Charter | Tour | Risk | Time-box

package/core/skills/qc/qa-designer/exploratory/explore-to-functional.md

@@ -0,0 +1,43 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Explore-to-Functional Pipeline
+
+Skill **tự chứa**: khám phá feature (chưa/thiếu spec) → draft TC → QC review → feed
+requirement → chuyển thành functional TC chính thức. Chỉ cần load file này.
+
+## Khi nào trigger
+- Feature KHÔNG có tài liệu/spec (legacy, take-over) hoặc spec mơ hồ/thiếu
+- Cần bootstrap bộ TC nhanh cho hệ thống đang chạy · "khám phá [X] rồi tạo TC"
+
+## Khi KHÔNG trigger
+- Feature có spec rõ → `functional/gui-screen`/`gui-feature` trực tiếp
+- Chỉ cần charter cho session → `exploratory/charter`
+
+---
+
+## Phase 1 — Explore (AI tự chạy)
+Dựa trên mô tả feature: list TẤT CẢ chức năng (visible + ẩn + integration point) · mỗi chức năng
+identify input/output/state/side-effect · sinh DRAFT TC (1 happy + 2–3 edge mỗi chức năng) ·
+"what if" mỗi chức năng · list chức năng liên quan QC chưa nêu. → ĐỢI QC phản hồi.
+
+## Phase 2 — QC Review + Bổ sung
+Đợi QC confirm đúng/sai, thêm business edge case, cung cấp context → sửa → draft v2. → ĐỢI QC confirm/paste requirement.
+
+## Phase 3 — Feed Requirement (nếu có)
+So requirement vs draft: requirement chưa phủ → thêm TC · TC sai logic → sửa expected · thêm Trace BR ·
+chỉnh Priority theo business. Không có requirement → giữ draft Phase 2.
+
+## Phase 4 — Convert to Functional (format chuẩn)
+Chuyển draft → TC chính thức bám **format file `TC_<FEATURE>.md`**:
+- Metadata **list**: Title · Feature · Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags ·
+  **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có BR → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx]` nếu chặn.
+- **Test Data** dạng list · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet cụ thể.
+- Phân nhóm GUI/Functional · cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
+- Đặt file `docs/<project>/<feature>/TC_<FEATURE>.md`.
+
+## Output
+File TC functional + bảng `TC_ID | Title | Priority | Technique | Trace`. Bàn giao `qa-reviewer`.

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

@@ -0,0 +1,45 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# 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.
+
+## Khi nào trigger
+- "viết test case cho API [method] [path]" — verify contract, validation, mã lỗi của endpoint
+
+## Khi KHÔNG trigger
+- Test qua giao diện → `functional/gui-screen`/`gui-feature`
+- Luồng dữ liệu API ↔ DB/service khác → `integration/api` · message/event → `integration/kafka`
+
+---
+
+## 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_GAPS.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.
+
+## 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**.
+
+## 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`).
+
+## Phase 2 — Write
+- Nhóm TC: happy (200 + schema đúng) → validation (400 từng field, dùng 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.
+
+## Output
+File TC (`TC_<FEATURE>_API.md` hoặc gộp trong file feature) trong `docs/<project>/<feature>/`.
+In bảng TC + Trace matrix. Bàn giao `qa-reviewer`.

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

@@ -0,0 +1,46 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Functional GUI Feature (đa màn hình)
+
+Skill **tự chứa** để viết TC functional cho feature có luồng span ≥ 2 màn hình
+(wizard, master-detail, popup→list). Chỉ cần load file này.
+
+## Khi nào trigger
+- "viết test case cho feature [X]" mà flow đi qua nhiều màn/route, truyền state giữa bước
+
+## Khi KHÔNG trigger
+- Gọn trong 1 màn → `functional/gui-screen` · API thuần → `functional/api`
+- Hành trình nghiệp vụ đầu-cuối + đồng bộ hệ thống → `e2e/journey`
+
+---
+
+## 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_GAPS.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.
+
+## Kỹ thuật áp dụng
+- **Use Case** cho flow tổng: main (P0) → alternate (P1) → exception (negative).
+- **Decision Table** cho điểm rẽ nhánh (điều kiện qua bước/nhảy màn).
+- **State Transition** nếu có trạng thái xuyên bước (draft→submitted…).
+- **EP/BVA** cho field trên từng màn.
+
+## Phase 1 — Clarify
+Liệt kê các màn/route + thứ tự điều hướng · state/dữ liệu truyền giữa màn (giữ/reset khi back) ·
+điểm rẽ nhánh · platform · CRUD scope · cleanup.
+
+## Phase 2 — Write
+- Nhóm TC: GUI từng màn → **điều hướng** (forward/back/giữ-reset state, deep-link) → happy path xuyên flow → negative.
+- Đặc biệt phủ: back có mất dữ liệu không, dữ liệu bắt buộc để qua bước sau, hủy giữa flow.
+- Mỗi TC bám khối Format; trace BR; gap chặn → 🚫 Block.
+
+## Output
+File `TC_<FEATURE>.md` trong `docs/<project>/<feature>/`. In bảng TC + Trace matrix + bảng TC block.
+Bàn giao `qa-reviewer` (test-case).

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

@@ -0,0 +1,52 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Functional GUI Screen (1 màn hình)
+
+Skill **tự chứa** để viết TC functional cho 1 màn hình đơn lẻ (web/mobile). Chỉ cần load file này.
+
+## Khi nào trigger
+- "viết test case cho màn hình [X]" — feature gọn trong 1 screen (1 page web / 1 Activity/VC)
+
+## Khi KHÔNG trigger
+- Flow span ≥ 2 màn → `functional/gui-feature`
+- API không qua UI → `functional/api`
+- Tích hợp 2+ module → `integration/*` · hành trình đầu-cuối → `e2e/journey`
+
+---
+
+## 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_GAPS.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.
+
+## 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`).
+- Logic nhiều điều kiện / cascade dropdown / permission → **Decision Table** (mỗi rule = 1 TC).
+- Element/đối tượng có trạng thái enabled/disabled, vòng đời → **State Transition** (chuyển đổi hợp lệ + cấm).
+- Luồng thao tác trên màn → **Use Case** (main P0 → alternate P1 → exception negative).
+
+## Phase 1 — Clarify
+Platform (web Playwright/mobile) · screen+route · domain (form-crud/listing/auth/settings) · CRUD scope ·
+mutating actions OK? · cleanup policy. Thiếu → hỏi trước khi viết.
+
+## Phase 2 — Explore
+Dump element: buttons, inputs, dropdowns, table headers, modal states. Mỗi element →
+chức năng (input/action/display/nav) · constraint (required/min-max/format/enabled) · state change · câu hỏi "what if".
+
+## Phase 3 — Write
+- **Nhóm 1 GUI:** title → buttons → inputs → date picker → dropdowns → bảng (header→row count→checkbox→từng cột) → pagination.
+- **Nhóm 2 Functional:** filter (đơn→combined) → search → reset → pagination → data integrity → actions → negative.
+- Phủ implicit: rate limit, concurrent, session, empty state, max data, special chars.
+- 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 `docs/<project>/<feature>/`. In bảng `TC_ID | Title | Priority | Tags | Trace`
++ Trace matrix + bảng TC block. Bàn giao `qa-reviewer` (test-case).

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

@@ -0,0 +1,42 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Integration API
+
+Skill **tự chứa** để viết TC tích hợp qua API: caller → API → service/DB/hệ thống ngoài,
+verify luồng dữ liệu & contract giữa các thành phần. Chỉ cần load file này.
+
+## Khi nào trigger
+- Test điểm tích hợp API ↔ service backend / hệ thống ngoài (vd LMS ↔ CRM)
+- Verify dữ liệu sau gọi API lan tới chặng tiếp (DB/event)
+
+## Khi KHÔNG trigger
+- Chỉ verify request/response 1 endpoint → `functional/api`
+- Verify riêng trạng thái DB → `integration/db` · message/event → `integration/kafka`
+
+---
+
+## 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_GAPS.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.
+
+## Kỹ thuật áp dụng
+- **Interface/Contract:** verify schema request/response giữa caller↔callee.
+- **Data flow verification:** theo sơ đồ data flow, mỗi chặng verify dữ liệu biến đổi đúng.
+- **Decision Table** khi định tuyến/đồng bộ phụ thuộc nhiều điều kiện.
+- **Error/Retry/Timeout/Concurrency:** failure point, thao tác đồng thời (sinh số không trùng).
+
+## Phase 1 — Clarify
+Chuỗi tích hợp (caller→API→service/DB/API ngoài) · contract mỗi interface · điều kiện định tuyến/đồng bộ
+(vd điều kiện đổ CRM) · failure point (timeout, lỗi service ngoài, partial commit).
+
+## Phase 2 — Write
+Nhóm TC: happy (dữ liệu đúng đầu→cuối) → contract negative (input sai → mã lỗi đúng) → failure/timeout/retry
+→ 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 `docs/<project>/<feature>/`. Ưu tiên P0 cho định tuyến & tiền-dữ liệu. Bàn giao `qa-reviewer`.

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

@@ -0,0 +1,39 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Integration DB
+
+Skill **tự chứa** để viết TC verify **trạng thái dữ liệu trong DB** sau action:
+insert/update/soft-delete đúng giá trị, side-effect, toàn vẹn. Chỉ cần load file này.
+
+## Khi nào trigger
+- Kiểm tra bản ghi DB sau thao tác (tạo ticket → ghi đúng bảng/cột); soft-delete, default, audit log
+
+## Khi KHÔNG trigger
+- Chỉ verify response API → `functional/api`/`integration/api` · message/event → `integration/kafka`
+
+---
+
+## 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_GAPS.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.
+
+## Kỹ thuật áp dụng
+- **State/DB verification:** verify bản ghi sau action (giá trị từng cột, flag, timestamp).
+- **Data flow:** dữ liệu từ input lan tới DB đúng. **Decision Table** nếu ghi phụ thuộc điều kiện.
+
+## Phase 1 — Clarify
+Bảng & cột bị ảnh hưởng + giá trị kỳ vọng · loại thao tác (insert/update/soft-delete/cascade) ·
+side-effect (audit log, timestamp, người tạo/sửa) · cleanup/rollback dữ liệu test.
+
+## Phase 2 — Write
+Nhóm TC: ghi đúng giá trị (happy) → default/null đúng → update không đụng cột khác → soft-delete (flag đúng)
+→ audit log → ràng buộc/unique (negative). Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
+
+## Output
+File TC trong `docs/<project>/<feature>/`. 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`.

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

@@ -0,0 +1,40 @@
+---
+version: 1.0
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Test Case — Integration GUI ↔ Backend
+
+Skill **tự chứa** để viết TC tích hợp UI ↔ backend: UI gọi API đúng, render đúng kết quả/
+lỗi từ server, đồng bộ trạng thái hai chiều. Chỉ cần load file này.
+
+## Khi nào trigger
+- UI phản ánh đúng dữ liệu/lỗi backend (lookup, list, validate server-side); UI gọi đúng API + xử lý response
+
+## Khi KHÔNG trigger
+- Chỉ test layout/element tĩnh 1 màn → `functional/gui-screen`
+- Chỉ test API không qua UI → `functional/api`/`integration/api`
+
+---
+
+## 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_GAPS.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.
+
+## Kỹ thuật áp dụng
+- **Data flow UI→API→UI:** verify request gửi đúng + render response đúng.
+- **Error handling:** lỗi server (4xx/5xx) → message UI đúng. **State:** loading/empty/error.
+
+## Phase 1 — Clarify
+Điểm UI gọi backend (action→API) · mapping response→hiển thị (list/dropdown/message) ·
+trạng thái loading/empty/error · debounce/cancel khi đổi input.
+
+## Phase 2 — Write
+Nhóm TC: UI render đúng dữ liệu backend (happy) → empty state → lỗi server → message đúng → loading state
+→ đổi input reset/cancel request → đồng bộ sau action (tạo xong → list cập nhật). Locator ưu tiên data-testid/role.
+Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
+
+## Output
+File TC trong `docs/<project>/<feature>/`. Mỗi TC nêu API liên quan + biểu hiện UI. Bàn giao `qa-reviewer`.