@educa-corp/sdd-framework 0.5.0 → 0.7.0

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

@@ -1,41 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/`.
-In bảng `E2E-ID | Journey | Pri | Trace | Block` + bảng TC block. Bàn giao `qa-reviewer`.

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

@@ -1,68 +0,0 @@
----
-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: {paths.qc_dir}/exploratory/charters/<feature>_01.md, _02.md...
-Ideas file: {paths.qc_dir}/exploratory/ideas/<feature>.md
-Bảng tổng kết: STT | Charter | Tour | Risk | Time-box

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

@@ -1,43 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/TC_<FEATURE>.md`.
-
-## Output
-File TC functional + bảng `TC_ID | Title | Priority | Technique | Trace`. Bàn giao `qa-reviewer`.

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

@@ -1,45 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/`.
-In bảng TC + Trace matrix. Bàn giao `qa-reviewer`.

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

@@ -1,46 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/`. In bảng TC + Trace matrix + bảng TC block.
-Bàn giao `qa-reviewer` (test-case).

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

@@ -1,52 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/`. In bảng `TC_ID | Title | Priority | Tags | Trace`
-+ Trace matrix + bảng TC block. Bàn giao `qa-reviewer` (test-case).

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

@@ -1,42 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/`. Ưu tiên P0 cho định tuyến & tiền-dữ liệu. Bàn giao `qa-reviewer`.

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

@@ -1,39 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/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`.

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

@@ -1,40 +0,0 @@
----
-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 `{paths.qc_dir}/{UC-ID}/test-cases/`. Mỗi TC nêu API liên quan + biểu hiện UI. Bàn giao `qa-reviewer`.

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

@@ -1,40 +0,0 @@
----
-version: 1.0
-updated: 2026-06-11
-ported_from: ai-automation-qc-base
----
-
-# Test Case — Integration Kafka (Message/Event)
-
-Skill **tự chứa** để viết TC tích hợp qua Kafka: producer phát event đúng, consumer xử lý
-đúng, đảm bảo ordering/idempotency/retry. Chỉ cần load file này.
-
-## Khi nào trigger
-- Action sinh event Kafka (vd tạo ticket → phát event sang service/CRM); verify topic/payload/thứ tự/khử trùng
-
-## Khi KHÔNG trigger
-- Tích hợp đồng bộ qua API → `integration/api` · verify DB → `integration/db`
-
----
-
-## 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 (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.
-
-## Kỹ thuật áp dụng
-- **Message/event:** verify topic, key, payload schema, điều kiện phát.
-- **Ordering & idempotency:** thứ tự theo key, message trùng/out-of-order.
-- **Error/Retry:** consumer lỗi → retry/DLQ.
-
-## Phase 1 — Clarify
-Topic/key/payload + điều kiện phát (khi nào phát/không) · consumer xử lý gì + side-effect + idempotent ·
-yêu cầu ordering · xử lý trùng/out-of-order/lỗi (retry, DLQ).
-
-## Phase 2 — Write
-Nhóm TC: phát đúng topic+payload (happy) → điều kiện không phát → consumer xử lý đúng → message trùng (idempotent)
-→ out-of-order → consumer lỗi → retry/DLQ → ordering theo key. Setup/teardown consumer test.
-Mỗi TC bám Format; trace BR; gap chặn → 🚫 Block.
-
-## Output
-File TC trong `{paths.qc_dir}/{UC-ID}/test-cases/`. Mỗi TC ghi topic, key, payload cần verify + hành vi consumer. Bàn giao `qa-reviewer`.

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

@@ -1,40 +0,0 @@
----
-version: 1.0
-updated: 2026-06-11
-ported_from: ai-automation-qc-base
----
-
-# Test Case — Non-Functional
-
-Skill **tự chứa** để viết TC phi chức năng: performance, security, accessibility, compatibility.
-Trọng tâm "hệ thống hoạt động TỐT thế nào". Chỉ cần load file này.
-
-## Khi nào trigger
-- Yêu cầu hiệu năng/tải, bảo mật, accessibility, tương thích; feature có SLA, dữ liệu nhạy cảm, hoặc data lớn
-
-## Khi KHÔNG trigger
-- Kiểm thử chức năng theo đặc tả → `functional/*` · tích hợp module → `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 · **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.
-
-## 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.
-- **Security:** authZ/role (truy cập trái phép → chặn), injection, PII (SĐT) không lộ, session/timeout, rate limit.
-- **Accessibility:** keyboard nav, focus, label/aria, contrast (WCAG).
-- **Compatibility:** trình duyệt/thiết bị/độ phân giải mục tiêu.
-
-## Phase 1 — Clarify
-Loại non-functional + tiêu chí đo (ngưỡng cụ thể: thời gian, số user, WCAG level) · môi trường & công cụ
-(load tool, scanner, axe/lighthouse) · dữ liệu/tải mẫu.
-
-## Phase 2 — Write
-Mỗi TC bám Format; **Expected có ngưỡng pass + công cụ đo**; đánh dấu TC cần môi trường/data đặc biệt.
-Trace BR; gap chặn → 🚫 Block.
-
-## Output
-File TC non-functional trong `{paths.qc_dir}/{UC-ID}/test-cases/`. Mỗi TC ghi tiêu chí đo + ngưỡng + công cụ. Bàn giao `qa-reviewer`.

package/skills/qc/qa-planner/test-plan.md

@@ -1,120 +0,0 @@
----
-version: 1.0
-updated: 2026-06-11
-ported_from: ai-automation-qc-base
----
-
-# Lập Test Plan
-
-Tổng hợp **output của qa-analyst** thành **Test Plan** cho một feature.
-
-**Đầu vào (bắt buộc, chỉ 2 nguồn — đúng 2 file qa-analyst trả ra):**
-1. `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md` — chức năng, BR-xx, AC-xx, data flow (qa-analyst).
-2. `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md` — bảng gap GAP-xx, mức độ, gap Blocker (qa-analyst).
-
-## Khi nào trigger
-- "lập test plan cho [Feature]" / "viết test plan"
-- Sau khi qa-analyst xong (đã có REQUIREMENT_ANALYSIS + DOC_GAPS)
-- Trước khi qa-designer thiết kế chi tiết TC — test plan là khung định hướng
-
-## Khi KHÔNG trigger
-- Chưa có REQUIREMENT_ANALYSIS / DOC_GAPS → chạy qa-analyst trước
-- Thiết kế test case chi tiết (.Test.md) → dùng qa-designer
-- Bóc tách yêu cầu/spec, lập danh sách gap → dùng qa-analyst
-
----
-
-## Phase 1 — Thu thập đầu vào
-
-1. Đọc `REQUIREMENT_ANALYSIS.md`: nắm chức năng, các BR-xx và AC-xx, data flow,
-   integration/failure point.
-2. Đọc `DOC_GAPS.md`: lấy danh sách gap, đặc biệt **gap Blocker còn Open** → đây là
-   nguồn cho cột "Phụ thuộc" và cho Entry criteria.
-3. Map mỗi nhóm BR sang **layer test** của qa-designer: functional/gui-screen,
-   gui-feature, api, integration, e2e/journey, non-functional.
-4. **Bỏ qua nội dung gạch ngang** (đã loại ở qa-analyst) — không đưa vào plan.
-
----
-
-## Phase 2 — Lập Test Plan
-
-Điền đủ template bên dưới. Nguyên tắc:
-- Mỗi **vùng test** map về BR-xx cụ thể, gắn **Layer + Loại test + Priority + ước lượng TC**;
-  hiển thị **rule chi tiết** ngay trong bảng (cột riêng, dùng `<br>` cho nhiều rule).
-- **Priority theo rủi ro suy ra từ BR + gap:** core function / logic định tuyến / sinh
-  mã / tiền-dữ liệu = P0.
-- Vùng/journey còn phụ thuộc **gap Blocker** → ghi rõ cột "Phụ thuộc" (GAP#); Entry
-  criteria yêu cầu đóng các gap đó trước khi thiết kế TC.
-- Liệt kê **E2E journey** đầy đủ (mỗi journey: tiền điều kiện, kết quả/định tuyến kỳ
-  vọng, BR, phụ thuộc, priority) + bộ **verify point chung** sau submit.
-- Mục Rủi ro: rút trực tiếp từ gap Blocker + các BR logic phức tạp.
-
----
-
-## Output — Template `TEST_PLAN.md`
-
-Đặt tại `{paths.qc_dir}/{UC-ID}/TEST_PLAN.md`:
-
-```markdown
-# Test Plan – <Feature>
-
-| Trường | Giá trị |
-|---|---|
-| Feature / Project / Module | … |
-| Người lập | qa-planner |
-| Ngày / Phiên bản | … |
-| Nguồn | REQUIREMENT_ANALYSIS · DOC_GAPS |
-
-## 1. Mục tiêu
-Mục tiêu test của feature (1–3 câu).
-
-## 2. Phạm vi
-- **In scope:** chức năng/BR được test.
-- **Out of scope:** phần để tài liệu/feature khác; nội dung gạch ngang đã loại.
-
-## 3. Test items theo vùng & độ ưu tiên
-Bảng — mỗi vùng kèm rule chi tiết + metadata:
-
-| # | Vùng test | Rule chi tiết | Layer (qa-designer) | Loại test | Pri | Ước lượng |
-|---|---|---|---|---|---|---|
-| ① | <vùng> | **BR-xx:** … <br>**BR-yy:** … | functional/gui-screen | Functional/Negative | P0 | n |
-| … | … | … | … | … | … | … |
-
-> Tổng ước lượng sơ bộ: ~N test case (+ E2E).
-
-### 3.1 Danh sách E2E đầy đủ
-Verify points chung (sau Submit): V1 tạo thành công · V2 mã/ID đúng · V3 hiển thị danh
-sách · V4… · Trục bao phủ: <các chiều tổ hợp>.
-
-| ID | Journey | Tiền điều kiện | Kết quả kỳ vọng | BR | Phụ thuộc | Pri |
-|---|---|---|---|---|---|---|
-| E2E-XX-01 | … | … | … | BR-… | GAP# | P0 |
-
-## 4. Cách tiếp cận (Test approach)
-Kỹ thuật áp dụng: EP+BVA, Decision Table (cho logic điều kiện), state/lookup,
-integration, negative/exploratory; tự động hoá theo `CLAUDE.md` (Playwright + pytest-playwright + Trace + pytest-html).
-
-## 5. Tiêu chí Vào / Ra
-- **Entry:** gap Blocker (trong DOC_GAPS) đã Answered; doc phụ thuộc sẵn sàng; môi trường + tài khoản role.
-- **Exit:** pass P0=100%, P1≥95%; không còn defect Blocker/Critical; mọi BR/AC được trace; báo cáo pytest-html + Playwright Trace.
-
-## 6. Rủi ro (risk-based)
-| Rủi ro | Ảnh hưởng | Mức | Giảm thiểu |
-(rút từ gap Blocker + BR logic phức tạp)
-
-## 7. Dữ liệu & Môi trường
-Tài khoản các role, dữ liệu mẫu (biên/edge), môi trường staging.
-
-## 8. Deliverables
-Test case `.Test.md`, script Playwright/pytest + Page Object, báo cáo pytest-html + Playwright Trace.
-
-## 9. Lịch trình (milestone phụ thuộc gap)
-| Mốc | Điều kiện | Trạng thái |
-M0 phân tích → M1 đóng gap → M2 thiết kế TC → M3 review TC → M4 chạy → M5 review script.
-
-## 10. Trạng thái hiện tại
-Blocked/Ready + phần có thể làm sớm (không phụ thuộc gap Blocker).
-```
-
-Kết thúc bằng: tóm tắt số vùng test + tổng TC ước lượng + trạng thái (Ready/Blocked dựa
-trên gap Blocker còn Open) và gợi ý bước kế tiếp (bàn giao qa-designer khi đã Ready).