@educa-corp/sdd-framework 0.9.3 → 0.9.4

package/core/skills/qc/qa-designer/api/auth-sequence.md

@@ -0,0 +1,75 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/api-testcase-designer/api/flows/auth-sequence.md
+upstream_sha: 69d60c12fe6d641638132581cce1dc6c955354a6
+---
+# Flow — Auth Sequence (login → token → authenticated calls)
+
+Mô tả chuỗi gọi API liên tiếp liên quan đến xác thực.
+Load file này khi thiết kế TC cần thực hiện đăng nhập trước khi gọi endpoint chính.
+
+---
+
+## Chuỗi 1 — Login lấy token + gọi 1 endpoint
+
+```
+POST /auth/login  →  nhận access_token  →  <METHOD> <protected_endpoint>
+```
+
+**Khi dùng:** TC cần tài khoản đăng nhập trước khi thao tác (tạo/sửa/xóa resource).
+
+**Điểm verify:**
+1. Sau login: HTTP 200, `body.access_token` không rỗng.
+2. Sau gọi endpoint: status code kỳ vọng, body đúng schema.
+
+**TC pattern:** xem `templates/auth-chain.md` (TC AUTH-001).
+
+---
+
+## Chuỗi 2 — Token refresh
+
+```
+POST /auth/login  →  nhận access_token + refresh_token
+→  (sau khi access_token hết hạn)
+→  POST /auth/refresh  →  nhận access_token mới
+→  <METHOD> <protected_endpoint>  →  thành công
+```
+
+**Khi dùng:** API có cơ chế refresh token (nếu plan đề cập).
+
+**Điểm verify:**
+1. Login: nhận cả `access_token` và `refresh_token`.
+2. Gọi refresh: HTTP 200, `body.access_token` khác token cũ.
+3. Gọi endpoint bằng token mới: thành công.
+
+**TC negative liên quan:**
+- Dùng refresh_token hết hạn → 401.
+- Dùng refresh_token đã dùng lần trước (replay) → 401.
+
+---
+
+## Chuỗi 3 — Multi-role: cùng endpoint, khác role, khác kết quả
+
+```
+POST /auth/login (admin)   →  token_admin   →  <METHOD> <endpoint>  →  200/201
+POST /auth/login (teacher) →  token_teacher →  <METHOD> <endpoint>  →  200 hoặc 403
+POST /auth/login (student) →  token_student →  <METHOD> <endpoint>  →  403
+```
+
+**Khi dùng:** TC RBAC — verify phân quyền theo role.
+
+**Điểm verify:** mỗi role cần TC riêng; Expected ghi rõ mã cho từng role.
+
+**TC pattern:** Decision Table (role × endpoint → expected code).
+
+---
+
+## Ghi chú thiết kế TC
+
+- **Test isolation:** mỗi TC tự gọi login để lấy token riêng. Không dùng token từ TC khác.
+- **Token fixture (Python):** nếu nhiều TC cùng role, dùng `conftest.py` fixture
+  `logged_in_token_<role>` (session scope) để tránh login lặp lại khi chạy test.
+- **Expired token test:** tạo token expired sẵn trong `test_data/tokens.json` thay vì
+  đợi token tự hết hạn trong test.

package/core/skills/qc/qa-designer/api/common-headers.md

@@ -0,0 +1,61 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/api-testcase-designer/api/references/common-headers.md
+upstream_sha: 74f10a36bec7b40f4d9de2d0928798cb6fad0c2c
+---
+# Bảng tra cứu — Headers chuẩn
+
+Dùng khi điền mục **Test Data > Headers** trong TC API.
+Chỉ ghi header thực sự cần thiết cho TC đó; không copy toàn bộ bảng.
+
+---
+
+## Request headers thường dùng
+
+| Header | Giá trị điển hình | Khi nào cần |
+|---|---|---|
+| `Authorization` | `Bearer <access_token>` | Mọi endpoint yêu cầu auth |
+| `Content-Type` | `application/json` | POST / PUT có body JSON |
+| `Content-Type` | `multipart/form-data` | Upload file |
+| `Accept` | `application/json` | Luôn ghi khi API có thể trả nhiều format |
+| `Accept-Language` | `vi` hoặc `en` | Khi test response message theo ngôn ngữ |
+| `X-Request-ID` | `<uuid>` | Nếu API yêu cầu idempotency key |
+| `X-Tenant-ID` | `<tenant_id>` | Nếu LMS hỗ trợ multi-tenant |
+
+---
+
+## Response headers cần verify (ghi vào `[Verify]` step nếu TC liên quan)
+
+| Header | Verify khi |
+|---|---|
+| `Content-Type: application/json` | Mọi response trả JSON |
+| `Location: <url>` | POST 201 Created — verify URL tạo mới |
+| `Retry-After: <seconds>` | TC rate limit (429) |
+| `X-RateLimit-Remaining` | TC rate limit — verify còn bao nhiêu request |
+
+---
+
+## TC Negative liên quan header
+
+| Kịch bản | Header điều chỉnh | Expected |
+|---|---|---|
+| Không có Authorization | Bỏ header `Authorization` | 401 |
+| Token sai format | `Authorization: InvalidToken abc` | 401 |
+| Content-Type sai | `Content-Type: text/plain` (khi API cần JSON) | 400 hoặc 415 |
+| Token đúng nhưng sai role | Token của role không được phép | 403 |
+
+---
+
+## Quy ước ghi trong Test Data
+
+```
+Headers:
+  - Authorization: Bearer <valid_token_admin>
+  - Content-Type: application/json
+```
+
+- Dùng placeholder có tên rõ ràng: `<valid_token_admin>`, `<valid_token_teacher>`,
+  `<expired_token>`, `<token_wrong_role>` — không dùng `<token>` chung chung.
+- Không ghi header không liên quan đến TC (vd `User-Agent`, `Host`).

package/core/skills/qc/qa-designer/api/crud-sequence.md

@@ -0,0 +1,122 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/api-testcase-designer/api/flows/crud-sequence.md
+upstream_sha: 65bf214d9f9beabe3c40b8697ba7c058adfd8bb5
+---
+# Flow — CRUD Sequence (create → read → update → delete)
+
+Mô tả các chuỗi gọi API CRUD phụ thuộc nhau.
+Load file này khi TC cần tạo resource trước khi thao tác sửa/xóa/đọc chi tiết.
+
+---
+
+## Chuỗi 1 — Create → Read
+
+```
+POST <resource>       →  HTTP 201, nhận body.id
+→  GET <resource>/{id}  →  HTTP 200, body đúng data đã tạo
+```
+
+**Khi dùng:** Verify GET trả đúng data sau khi tạo; kiểm tra data persistence.
+
+**Điểm verify:**
+1. POST: HTTP 201, `body.id` tồn tại và không rỗng.
+2. GET bằng `id` từ bước 1: HTTP 200; các field chính (name, status…) = giá trị đã gửi lúc POST.
+
+**TC pattern:**
+- 1 TC happy cho chuỗi (P0).
+- Tách TC riêng nếu cần test GET với ID không tồn tại (P1).
+
+---
+
+## Chuỗi 2 — Create → Update → Read
+
+```
+POST <resource>         →  HTTP 201, nhận id
+→  PUT <resource>/{id}   →  HTTP 200/204
+→  GET <resource>/{id}   →  HTTP 200, body = data đã update
+```
+
+**Khi dùng:** Verify update áp dụng đúng, không mất dữ liệu không liên quan.
+
+**Điểm verify:**
+1. POST: `body.id` tồn tại.
+2. PUT: HTTP 200 hoặc 204 (theo contract).
+3. GET sau PUT: field đã update = giá trị mới; field không update = giá trị cũ (unchanged).
+
+**TC negative liên quan:**
+- PUT với ID không tồn tại → 404.
+- PUT với body vi phạm validation → 400.
+- PUT sau khi resource đã ở trạng thái không cho sửa (vd đã publish) → 409/422.
+
+---
+
+## Chuỗi 3 — Create → Delete → Read
+
+```
+POST <resource>         →  HTTP 201, nhận id
+→  DELETE <resource>/{id} →  HTTP 200/204
+→  GET <resource>/{id}    →  HTTP 404
+```
+
+**Khi dùng:** Verify xóa thực sự xóa resource (không còn truy cập được).
+
+**Điểm verify:**
+1. POST: HTTP 201, `body.id` tồn tại.
+2. DELETE: HTTP 200 hoặc 204.
+3. GET sau DELETE: HTTP 404.
+
+**TC negative liên quan:**
+- DELETE với ID không tồn tại → 404.
+- DELETE resource đang được tham chiếu (foreign key) → 409/422 (nếu API có bảo vệ).
+
+---
+
+## Chuỗi 4 — List + Pagination
+
+```
+POST <resource> x N lần   →  tạo N bản ghi
+→  GET <resource>?page=1&limit=<L>  →  trả đúng L bản ghi + pagination
+→  GET <resource>?page=2&limit=<L>  →  trang tiếp theo đúng
+```
+
+**Khi dùng:** TC pagination — verify tổng bản ghi, số trang, dữ liệu mỗi trang.
+
+**Điểm verify:**
+1. `body.total` = N (tổng bản ghi đã tạo).
+2. `body.data.length` = L (số bản ghi trên trang).
+3. Trang 2: `body.data` không trùng trang 1.
+
+---
+
+## Chuỗi 5 — Dependent resource (parent → child)
+
+```
+POST <parent>            →  HTTP 201, nhận parent_id
+→  POST <child>?parentId=<parent_id>  →  HTTP 201, nhận child_id
+→  GET <parent>/{parent_id}           →  body.children chứa child_id
+```
+
+**Khi dùng:** Resource con phụ thuộc resource cha (vd: buổi học phụ thuộc lớp học).
+
+**Điểm verify:**
+1. POST parent: `body.id` tồn tại.
+2. POST child với `parentId`: HTTP 201.
+3. GET parent: `body.children` (hoặc trường tương đương) chứa child đã tạo.
+
+**TC negative liên quan:**
+- POST child với `parentId` không tồn tại → 404.
+- POST child với parent đã bị xóa/đóng → 422/409.
+
+---
+
+## Ghi chú thiết kế TC
+
+- **Cleanup:** Mỗi TC trong chuỗi CRUD cần xóa data đã tạo ở cuối (teardown).
+  Ghi rõ bước cleanup trong Test Steps: `**[Action]** Xóa resource id=<id> (cleanup)`.
+- **ID dependency:** Khi TC sau cần ID từ TC trước, ghi rõ trong Preconditions:
+  `Đã có <resource> với id=<test_id> trong DB`.
+- **Không nối TC thành chuỗi:** Mỗi TC vẫn độc lập; nếu cần data sẵn → tạo trong
+  Preconditions/fixture, không phụ thuộc TC khác đã chạy trước.

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

@@ -0,0 +1,231 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/api-testcase-designer/api/templates/endpoint.md
+upstream_sha: 7b38edd94e5efd37ff561f53cff92adedabaff7f
+---
+
+> **VIẾT LẠI, không copy** *(B12)*. Bản upstream ra đời **trước** luật ATOMIC (đội QC chốt
+> 2026-07-09) nên mỗi mẫu của nó gộp nhiều kết cục vào một `**Expected:**` nối bằng `;`, và
+> dùng hệ mã `API-<FEATURE>-001` khác với `TC_<FEATURE>_NNN` mà phần còn lại dùng.
+>
+> Port nguyên là **dạy AI làm ngược luật vừa chốt** — mẫu cụ thể luôn thắng luật trừu tượng.
+> Nội dung phủ (5 nhóm ca) giữ nguyên; cấu trúc TC theo `shared/tc-metadata-format.md`.
+
+# Khuôn TC — một endpoint đơn
+
+Mẫu khi viết TC cho 1 endpoint (GET / POST / PUT / DELETE). Thay mọi `<placeholder>` bằng giá
+trị thật từ `TEST_PLAN.md` + hợp đồng API §4 của tech-doc gộp.
+
+Phủ **5 nhóm ca**: happy · validation · auth thiếu token · auth sai quyền · not found.
+Mã lỗi tra ở `http-status-codes.md`; header tra ở `common-headers.md`.
+
+---
+
+## Nhóm ca 1 — Happy case
+
+⚠️ **Một request thành công sinh RA NHIỀU kết cục → nhiều TC độc lập.** Upstream gộp
+`HTTP 201; body.id = x; bản ghi có trong DB` vào một dòng — đó là **ba** kết cục:
+
+### TC_<FEATURE>_001 — <METHOD> <path> trả về <success_code>
+
+- **Title:** <METHOD> <path> với request hợp lệ trả về <success_code>
+- **Feature:** <TICKET-ID> — <Tên feature>
+- **Priority:** P0
+- **Status:** Draft
+- **Author:** AI
+- **Tags:** api, happy-path, <feature-tag>
+- **Trace:** BR-xx
+- **@trace.verifies:** {UC-ID}-SC{N}
+
+#### Preconditions
+- Tài khoản role `<role>` đã có token hợp lệ.
+- <Dữ liệu nền cần có, vd "đã tồn tại course id = 123">
+
+#### Test Data
+- Method: <GET|POST|PUT|DELETE>
+- Path: `<path>`
+- Headers:
+  - Authorization: Bearer `<valid_token_<role>>`
+  - Content-Type: application/json
+- Body:
+  ```json
+  { "<field1>": "<valid_value>", "<field2>": "<valid_value>" }
+  ```
+
+#### Test Steps
+1. **[Action]** Gửi `<METHOD> <path>` với headers và body trên.
+2. **[Verify]** Đọc status code của response.
+
+#### Expected Result
+- HTTP `<success_code>`
+
+#### Teardown
+- `DELETE <base_path>/{body.id}` — xoá bản ghi vừa tạo *(chỉ khi TC này tạo bản ghi thật)*
+
+### TC_<FEATURE>_002 — body response chứa `<key_field>` đúng
+
+- **Title:** <METHOD> <path> — body response có `<key_field>` = `<expected_value>`
+- **Feature:** <TICKET-ID> — <Tên feature>
+- **Priority:** P0
+- **Status:** Draft
+- **Author:** AI
+- **Tags:** api, happy-path, <feature-tag>
+- **Trace:** BR-xx
+- **@trace.verifies:** {UC-ID}-SC{N}
+
+#### Preconditions
+- *(copy nguyên từ TC_001 — mỗi TC tách là testcase ĐỘC LẬP, giữ FULL steps)*
+
+#### Test Data
+- *(copy nguyên từ TC_001)*
+
+#### Test Steps
+1. **[Action]** Gửi `<METHOD> <path>` với headers và body trên.
+2. **[Verify]** Đọc trường `<key_field>` trong body response.
+
+#### Expected Result
+- `body.<key_field>` = `<expected_value>`
+
+#### Teardown
+- `DELETE <base_path>/{body.id}` *(chỉ khi TC này tạo bản ghi thật)*
+
+### TC_<FEATURE>_003 — side-effect được ghi
+
+*Chỉ viết khi có side-effect cần verify. Nếu side-effect nằm ở DB/Kafka, TC này thuộc
+**nhóm Integration API/DB/Kafka**, không thuộc nhóm Endpoint.*
+
+- **Title:** <METHOD> <path> — bản ghi xuất hiện trong `<bảng>` với id = body.id
+- **Priority:** P0
+- **Tags:** api, integration, <feature-tag>
+- **Trace:** BR-xx
+
+#### Expected Result
+- `<bảng>.id` = `body.id` AND `<bảng>.<cột>` = `<giá trị>`
+
+> ✅ Bullet compound `A AND B` ở đây **hợp lệ**: cả hai vế nói về **cùng một** kết cục
+> ("bản ghi đã được ghi đúng"). Còn `HTTP 201; body.id = x` là **hai** kết cục — phải tách.
+> Phép soi nhanh: bullet nối bằng `;`, hoặc nối một khẳng định với một phủ định, là 2 kết cục.
+
+---
+
+## Nhóm ca 2 — Validation: field bắt buộc để trống
+
+### TC_<FEATURE>_004 — thiếu `<required_field>` trả về 400
+
+- **Title:** POST <path> — thiếu `<required_field>` trả về 400
+- **Priority:** P1
+- **Status:** Draft
+- **Author:** AI
+- **Tags:** api, negative, validation, ep
+- **Trace:** BR-xx
+
+#### Test Data
+- Method: POST
+- Path: `<path>`
+- Headers:
+  - Authorization: Bearer `<valid_token_<role>>`
+  - Content-Type: application/json
+- Body: `{ }` — bỏ hẳn `<required_field>`
+
+#### Test Steps
+1. **[Action]** Gửi POST không có `<required_field>`.
+2. **[Verify]** Đọc status code.
+
+#### Expected Result
+- HTTP 400
+
+**Thông báo lỗi là một TC RIÊNG** — nội dung thông báo là oracle khác với mã trạng thái:
+
+### TC_<FEATURE>_005 — thông báo lỗi nêu đúng field thiếu
+
+#### Expected Result
+- `body.message` contains `"<chuỗi nguyên văn từ PRD/tech-doc>"`
+
+> ⚠️ Chuỗi này phải **có thật** trong PRD hoặc tech-doc của **chính feature này**. Chưa chốt →
+> để trống + gắn `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md)`, **đừng bịa oracle**.
+
+*Mỗi field bắt buộc là một cặp TC như trên. Field có ràng buộc độ dài/khoảng giá trị → thêm TC
+BVA riêng, số giá trị biên tra ở `../shared/precision-rules.md` §7.*
+
+---
+
+## Nhóm ca 3 — Auth: không có token
+
+### TC_<FEATURE>_006 — thiếu Authorization header trả về 401
+
+- **Priority:** P0
+- **Tags:** api, negative, auth, security
+- **Trace:** BR-xx
+
+#### Test Data
+- Method: <METHOD>
+- Path: `<path>`
+- Headers: Content-Type: application/json — **bỏ hẳn** `Authorization`
+
+#### Test Steps
+1. **[Action]** Gửi `<METHOD> <path>` không kèm header `Authorization`.
+2. **[Verify]** Đọc status code.
+
+#### Expected Result
+- HTTP 401
+
+*Biến thể theo `common-headers.md` §"TC Negative liên quan header": token sai định dạng → 401 ·
+`Content-Type` sai → 400 hoặc 415. Mỗi cái một TC.*
+
+---
+
+## Nhóm ca 4 — Auth: đúng token, sai quyền
+
+### TC_<FEATURE>_007 — token role `<wrong_role>` trả về 403
+
+- **Priority:** P0
+- **Tags:** api, negative, auth, security
+- **Trace:** BR-xx
+
+#### Test Data
+- Headers: Authorization: Bearer `<valid_token_<wrong_role>>`
+
+#### Test Steps
+1. **[Action]** Gửi `<METHOD> <path>` bằng token của role không được phép.
+2. **[Verify]** Đọc status code.
+
+#### Expected Result
+- HTTP 403
+
+> **401 vs 403 là hai chuyện khác nhau** — 401 = chưa xác thực được anh là ai; 403 = biết anh
+> là ai nhưng anh không được phép. Trộn hai cái là bỏ mất một lớp bảo mật khỏi phạm vi test.
+
+---
+
+## Nhóm ca 5 — Not found
+
+### TC_<FEATURE>_008 — ID không tồn tại trả về 404
+
+- **Priority:** P1
+- **Tags:** api, negative, not-found
+- **Trace:** BR-xx
+
+#### Test Data
+- Method: <GET|PUT|DELETE>
+- Path: `<base_path>/<nonexistent_id>` (vd `/api/v1/courses/999999`)
+- Headers: Authorization: Bearer `<valid_token_<role>>`
+
+#### Test Steps
+1. **[Action]** Gửi `<METHOD>` với ID chắc chắn không tồn tại trong hệ thống.
+2. **[Verify]** Đọc status code.
+
+#### Expected Result
+- HTTP 404
+
+---
+
+## Nhắc lại ba luật hay bị bỏ
+
+1. **Placeholder có tên rõ nghĩa** — `<valid_token_admin>`, `<expired_token>`,
+   `<token_wrong_role>`; **không** dùng `<token>` chung chung *(`common-headers.md` §Quy ước)*.
+2. **`#### Teardown` là section riêng, KHÔNG phải bullet của Expected Result.** TC tạo bản ghi
+   thật thì bắt buộc có; TC chỉ GET hoặc chỉ cấu hình mock thì **không cần**.
+3. **Mọi TC tách vẫn giữ FULL Test Steps** — lặp đủ bước để tới trạng thái assert. Không cắt
+   bước theo từng bullet, không đánh `(1/N)`, không hậu tố `001a`/`001b`.

package/core/skills/qc/qa-designer/api/http-status-codes.md

@@ -0,0 +1,102 @@
+---
+version: 1.0
+updated: 2026-09-04
+ported_from: ui-automation-testing
+upstream_path: skills/qa-tc-designer/api-testcase-designer/api/references/http-status-codes.md
+upstream_sha: a82baa99350f63955245764a6aa57c9dca6d055f
+---
+# Bảng tra cứu — HTTP Status Codes
+
+Dùng để điền chính xác mã lỗi vào cột Expected của TC API.
+Tra theo nhóm (2xx/4xx/5xx) hoặc theo tình huống.
+
+---
+
+## 2xx — Thành công
+
+| Mã | Tên | Dùng khi | Expected điển hình |
+|---|---|---|---|
+| 200 | OK | GET, PUT thành công; login | Body chứa data/resource |
+| 201 | Created | POST tạo bản ghi mới | Body chứa `id` + resource mới |
+| 204 | No Content | DELETE thành công; PUT không trả body | Body rỗng |
+
+---
+
+## 4xx — Lỗi phía client
+
+| Mã | Tên | Dùng khi | Expected điển hình |
+|---|---|---|---|
+| 400 | Bad Request | Body/params sai format, thiếu field bắt buộc, giá trị không hợp lệ | `body.message` hoặc `body.errors` mô tả field lỗi |
+| 401 | Unauthorized | Không có token, token hết hạn, token sai | `body.message` = "Unauthorized" hoặc "Token invalid/expired" |
+| 403 | Forbidden | Token hợp lệ nhưng không đủ quyền (sai role) | `body.message` = "Forbidden" hoặc "Access denied" |
+| 404 | Not Found | Resource ID không tồn tại | `body.message` = "Not found" |
+| 409 | Conflict | Tạo trùng bản ghi (unique constraint) | `body.message` mô tả field trùng |
+| 422 | Unprocessable Entity | Business rule validation (vd: ngày end < ngày start) | `body.errors` liệt kê vi phạm |
+| 429 | Too Many Requests | Vượt rate limit | `Retry-After` header; body thông báo limit |
+
+---
+
+## 5xx — Lỗi phía server (không test chủ động; ghi vào TC edge nếu plan đề cập)
+
+| Mã | Tên | Ghi chú |
+|---|---|---|
+| 500 | Internal Server Error | Không nên trigger trong test bình thường; ghi vào TC nếu plan có scenario |
+| 503 | Service Unavailable | Chỉ test trong integration/availability scope |
+
+---
+
+## Mapping tình huống → mã (LMS Edupia)
+
+| Tình huống | Mã kỳ vọng | Ghi chú |
+|---|---|---|
+| Login đúng | 200 | Body có `access_token` |
+| Login sai password | 401 hoặc 400 | Xác nhận lại với dev |
+| Tạo mới thành công | 201 | Body có `id` |
+| Lấy danh sách | 200 | Body có `data[]` + `pagination` |
+| Lấy 1 record hợp lệ | 200 | Body có đầy đủ fields |
+| Xóa thành công | 200 hoặc 204 | Xác nhận lại với dev |
+| Field bắt buộc để trống | 400 | `body.errors` có field name |
+| Vượt độ dài tối đa | 400 | `body.errors` có field name + giới hạn |
+| Format sai (email/phone) | 400 | `body.errors` mô tả format |
+| Token không có | 401 | — |
+| Token hết hạn | 401 | — |
+| Role không đủ quyền | 403 | — |
+| ID không tồn tại | 404 | — |
+| Tên/code trùng | 409 | Xác nhận field unique với dev |
+| Ngày end trước ngày start | 422 | Business rule validation |
+
+---
+
+## Cấu trúc body lỗi chuẩn (tham khảo)
+
+```json
+// 400 / 422 — validation error
+{
+  "statusCode": 400,
+  "message": "Validation failed",
+  "errors": [
+    { "field": "name", "message": "Trường này là bắt buộc" },
+    { "field": "startDate", "message": "Ngày bắt đầu không được để trống" }
+  ]
+}
+
+// 401 — unauthorized
+{
+  "statusCode": 401,
+  "message": "Unauthorized"
+}
+
+// 403 — forbidden
+{
+  "statusCode": 403,
+  "message": "Forbidden resource"
+}
+
+// 404 — not found
+{
+  "statusCode": 404,
+  "message": "Resource not found"
+}
+```
+
+> Cấu trúc thực tế có thể khác — xác nhận với dev/API spec trước khi điền vào TC.

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

@@ -17,11 +17,14 @@ Skill **tự chứa** để viết TC end-to-end: hành trình đầu→cuối x
 
 ---
 
-## 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 (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.
+## 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/Scenario:** mỗi journey = main + alternate + exception flow.
@@ -34,8 +37,10 @@ Lấy danh sách journey + trục bao phủ + verify points từ TEST_PLAN · m
 
 ## 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.
+**Journey phụ thuộc gap vẫn viết + 🚫 Block: [GAP-UC{N}-{nnn}]**, định tuyến ghi "dự kiến theo BR". Trace BR.
 
 ## Output
-File TC e2e (hoặc nhóm E2E trong file feature) trong `{qc_artifact_dir}test-cases/`.
-In bảng `E2E-ID | Journey | Pri | Trace | Block` + bảng TC block. Bàn giao `qa-reviewer`.
+
+Ghi vào `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` — **Nhóm 6 E2E**. Mỗi journey một TC; tiền điều kiện · kết quả/định tuyến kỳ vọng · BR · phụ thuộc gap · priority ghi dạng trường danh sách.
+
+**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/exploratory/charter.md

@@ -66,3 +66,5 @@ Sinh 10-15 câu hỏi cho dev/BA (assumptions, edge case, error handling, securi
 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
+
+*(Charter KHÔNG phải file TC — luật "không bảng" chỉ áp cho `*.Test.md`. Charter chuyển thành TC ở `explore-to-functional.md`, lúc đó mới theo luật đó.)*

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

@@ -32,12 +32,15 @@ So requirement vs draft: requirement chưa phủ → thêm TC · TC sai logic
 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`**:
+Chuyển draft → TC chính thức bám **format file `TC_<FEATURE>.Test.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.
+  **Trace** `[BR-xx](../REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có BR → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-UC{N}-{nnn}]` 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 `{qc_artifact_dir}test-cases/TC_<FEATURE>.md`.
+- Đặt file `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` (nhóm 3 Functional).
 
 ## Output
-File TC functional + bảng `TC_ID | Title | Priority | Technique | Trace`. Bàn giao `qa-reviewer`.
+
+Ghi TC đã chuyển thành functional vào `{qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md` — **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`.