@educa-corp/sdd-framework 0.8.1 → 0.9.1

package/core/commands/validate-traces.md

@@ -190,6 +190,30 @@ Nhiều cờ scope cùng lúc → **DỪNG**, báo lỗi: chúng loại trừ nh
 
 `--prd`/`--uc` không phân giải được về một package/UC có thật → **DỪNG** và liệt kê ứng viên. **KHÔNG** âm thầm rơi về `all` (chạy toàn bộ khi người ta xin một phần là đốt 30 phút không ai muốn) và **KHÔNG** âm thầm audit rỗng (báo cáo "sạch" trên 0 row).
 
+**Token TRẦN (không mở đầu bằng `--`)** — vd `/validate-traces --reconcile-code LESS-06`:
+
+| Token trần trông như | Xử |
+|---|---|
+| **UC-ID** (`{TICKET}-UC{n}`) | coi là `--uc {token}` |
+| **TICKET-ID** phân giải được về đúng **một** feature-package | coi là `--prd {token}` |
+| không phân giải được, hoặc khớp **nhiều** package | **DỪNG**, liệt kê ứng viên |
+| có **cả** token trần **và** một cờ scope | **DỪNG** — hai nguồn phạm vi, không tự chọn hộ |
+
+Hai hàng đầu **phải in một dòng** nói rõ đã tự suy, để người dùng thấy mình vừa được hiểu thế nào:
+```
+ⓘ Hiểu `{token}` là `--prd {token}` ({domain}/{prd-slug}). Gõ cờ tường minh nếu ý khác.
+```
+
+> **Vì sao không để token trần rơi về `all` (phát hiện 2026-08-27, lượt dùng `--reconcile-code` đầu tiên).**
+> Gate Bước 1 loại mọi token `--` khỏi phần resolve target, và lệnh này **không có target file** — nên
+> token trần trước đây **bị bỏ hoàn toàn** ⇒ `scope` = `all`. Người dùng gõ `--reconcile-code LESS-06`
+> tin rằng đang chạy hẹp một PRD, trong khi lệnh sẽ **GHI vào sổ của cả 20+ PRD**, gồm cả phần của PO
+> khác. Đây đúng điều chính step này cấm hai dòng ở trên — *"KHÔNG âm thầm rơi về `all`"* — chỉ khác là
+> lỗ vào bằng cửa *"không có cờ nào"* thay vì cửa *"cờ không phân giải được"*.
+>
+> Với một lệnh **chỉ đọc** thì đó là đốt thời gian. Với `--reconcile-code` (có GHI) thì đó là ghi ra
+> ngoài phạm vi mà người dùng nghĩ mình đã yêu cầu — hạng nặng hơn hẳn.
+
 Lưu `scope` — mọi step sau dùng nó:
 
 | Step | Hẹp thế nào |
@@ -256,11 +280,26 @@ Kiểm tra mảng `services` có tồn tại trong `project-context.yaml` không
 Chạy checker xác định trên mọi trace dir đã phân giải ở Step 0:
 
 ```bash
-npx @educa-corp/sdd-framework --lint-trace --trace {all_trace_dirs, ngăn cách bởi dấu phẩy} --specs {paths.specs_dir}
+npx @educa-corp/sdd-framework --lint-trace --trace {all_trace_dirs, ngăn cách bởi dấu phẩy} --specs {paths.specs_dir} --code {code_roots, ngăn cách bởi dấu phẩy}
 ```
 
+**Dựng `code_roots` — bắt buộc truyền, đây là chìa khoá kho của T14:**
+
+| Chế độ | `code_roots` |
+|---|---|
+| **Umbrella** (có `services:`) | tập **duy nhất** mọi giá trị `path` xuất hiện trong `services:` — gồm cả `path` lồng trong `by_prd_slug`. Bỏ trùng (nhiều domain trỏ chung một submodule là chuyện thường). |
+| **Single-service** | `{paths.src_dir}` |
+| Không phân giải được cái nào | **truyền rỗng** — T14 tự bỏ qua và tự in một dòng nói rõ đã bỏ qua. **Đừng đoán** một thư mục nào đó: quét sai chỗ còn tệ hơn không quét. |
+
 *`bin/` sống trong package npm, không được cài vào project — nên `npx` là đường duy nhất. Không có mạng / npx fail → **bỏ qua step này**, in `⚠️ Chưa lint được sổ trace (npx không khả dụng) — kết quả dưới đây chưa được kiểm cấu trúc` vào report, rồi tiếp Step 1. Đừng để nó chặn cả lệnh.*
 
+> **Vì sao `--code` (G60).** Trước nó, checker xác định duy nhất mở file thật của dự án chỉ nhận
+> `--trace` và `--specs` — nó **không thể thấy code**, nên ca *"code đã có tag mà sổ ghi
+> `implemented_by` trống"* không có một mắt xác định nào canh. T14 là chiều ngược đó, ở mức
+> **WARN**: nó **không được** chặn lệnh này, vì nợ tồn ở project đang chạy sẽ đỏ khắp nơi ở lần
+> đầu và người ta sẽ tắt cổng — mất luôn T1–T13 thật.
+> Cờ `LEDGER_BEHIND_CODE` ở Step 2b là bản LLM của cùng phép kiểm; `--reconcile-code` là đường ra.
+
 **Exit 0 → tiếp Step 1.**
 
 **Exit 1 → DỪNG NGAY.** Đừng nạp, đừng tính `status`, đừng ghi lại gì:
@@ -334,9 +373,23 @@ Với mỗi row có `service` ∈ (`unrouted`, `unresolved`), tra lại `service
 > `unrouted` → path. Không sửa tay, không sinh lại BDD. Không có bước này thì `unrouted` **đọng lại
 > vĩnh viễn** — đúng bệnh `TBD` mà G1/G28 đã chỉ ra.
 
-### Step 2b — Reverse audit (bắt tag mồ côi)
+### Step 2b — Reverse audit (hai câu hỏi trên cùng một lượt quét)
+
+*Step 2 đi chiều **spec → code** (mỗi row TSV, SC đó implement tới đâu). Step này đi **chiều ngược** — bắt lớp lỗi mà Step 2 cấu trúc không thể thấy.*
 
-*Step 2 đi chiều **spec → code** (mỗi row TSV, SC đó implement tới đâu). Step này đi **chiều ngược** — bắt lớp lỗi mà Step 2 cấu trúc không thể thấy: code trỏ vào một scenario **không còn tồn tại**. Xảy ra khi gen lại BDD làm một SC biến mất (gộp / đổi số / xoá) trong khi code implement nó vẫn nằm đó, vẫn được caller gọi.*
+**Một lượt quét, HAI câu hỏi.** Đừng dừng ở câu đầu:
+
+| | Câu hỏi | Bắt được gì |
+|---|---|---|
+| **A** | *"Tag này trỏ vào SC có tồn tại không?"* | code trỏ vào scenario **đã bị xoá** → `ORPHANED` / `TRACE_ORPHAN` |
+| **B** | *"Sổ có biết SC này đã có code chưa?"* | code đã làm mà **sổ chưa ghi** → `LEDGER_BEHIND_CODE` |
+
+> **Vì sao câu B phải nằm ở đây, và vì sao nó từng thiếu (G60).** Bản trước chỉ có câu A. Câu B dùng
+> **đúng dữ liệu đã nạp trong bộ nhớ** — không phát sinh thêm một lần I/O nào — nên bỏ nó là bỏ
+> không vì lý do gì. Và không có nó thì lớp lỗi *"làm rồi mà không ghi sổ"* **không có một mắt nào
+> canh**: `self-check` R1 hỏi *"ai được phép ghi"* (`implemented_by` có producer ⇒ xanh), còn
+> `lint-trace` trước T14 thì không thấy được code. Đo trên một project thật: **504 scenario** có code
+> mà sổ ghi trống, làm dashboard đếm thiếu **28 điểm** phủ code.
 
 **Quét (gộp vào cùng lượt quét code của Step 5b — không thêm pass mới):** dưới `{code_base_package}` (CLAUDE.md §2) + `{paths.src_dir}`, thu mọi `@trace.implements={UC-ID}-SC{N}`; trong thư mục test thu mọi `@trace.verifies={UC-ID}-SC{N}`.
 
@@ -352,6 +405,24 @@ Với mỗi tag, hỏi: `SC{N}` đó có tồn tại trong `.feature` của đú
 
 Không tìm thấy tag mồ côi nào → bỏ qua im lặng.
 
+#### Câu B — sổ có theo kịp code chưa?
+
+Với mỗi `@trace.implements={UC-ID}-SC{N}` mà `SC{N}` **có** trong `.feature` (tức đã qua câu A):
+
+| Điều kiện | Cờ | Ý nghĩa |
+|---|---|---|
+| Row TSV tồn tại **và** `implemented_by != —` | *(sạch)* | Sổ khớp kho |
+| Row TSV tồn tại **nhưng** `implemented_by == —` | `LEDGER_BEHIND_CODE` 🟠 | **Làm rồi mà không ghi sổ.** Row đang hiện `UNTRACKED`, dashboard đếm thiếu, và `/generate-code` sẽ coi là "chưa làm" rồi sinh lại |
+| Không có row TSV nào | — | Step 2 đã thêm row `UNTRACKED` từ `.feature`; lượt sau sẽ vào hàng trên |
+
+**Ghi lại cho mỗi cờ:** `sc_id` · `platform` (từ tên file sổ) · danh sách file code mang tag · và **`has_verifies`** = có `@trace.verifies` cho đúng SC đó hay không. Field cuối là thứ quyết định `--reconcile-code` điền row đó thành *có test* hay *chưa test* — thu ngay ở đây vì lượt quét này đã đọc cả hai loại tag.
+
+**Nguyên nhân thường gặp, nêu luôn trong report** để người đọc không phải đoán: `/generate-code` dừng ở cổng build nên §Write Trace State chưa chạy; hoặc dev sửa tay cho build pass rồi commit mà không chạy lại lệnh.
+
+**Cờ này 🟠 KHÔNG chặn PR** — xem lý do ở Step 7 (`ledger_behind_code_count`). Đường ra là `--reconcile-code` (Step 5f).
+
+Không tìm thấy row nào lệch → bỏ qua im lặng.
+
 ### Step 3 — Tính `status` theo từng scenario
 
 Áp dụng quy tắc theo thứ tự ưu tiên (first-match-wins):
@@ -562,6 +633,66 @@ Parse `$ARGUMENTS`:
 
 Không đụng `dev_selftest`/`qc_status` (luật G28 không áp: **không có logic nào đổi** — đó chính là tiền đề của realign).
 
+### Step 5f — Reconcile code mode *(chỉ chạy khi có `--reconcile-code`)*
+
+*Đường ra cho cờ `LEDGER_BEHIND_CODE` (Step 2b câu B). Không có nó thì cờ đó **không bao giờ sạch được**: `implemented_by` chỉ `/generate-code` ghi, mà nó thấy row đã có code là skip — nên lối ra duy nhất là ép sinh lại code cho hàng loạt scenario đã làm xong. Đúng vòng lặp đóng mà `--realign` được viết ra để mở, chỉ ở một cột khác.*
+
+`--reconcile-code` (không tham số → mọi row `LEDGER_BEHIND_CODE` **trong scope** của Step 0-A; dùng `--domain`/`--prd`/`--uc` để hẹp lại).
+
+**Điền từ bằng chứng — 5 cột, không hơn:**
+
+| Cột | Lấy từ đâu |
+|---|---|
+| `implemented_by` | tên class/hàm mang `@trace.implements` cho SC đó (nhiều file → nối bằng `,`, đúng khuôn `/generate-code` đang ghi) |
+| `gen_ver` | copy `spec_ver` của **chính row đó** *(không phải version hiện tại của `.feature` — code sinh ra từ bản nào thì `spec_ver` lúc này là bản đó; Step 2 vừa đồng bộ nó)* |
+| `fe_phase` | **`integrated`** nếu file code có wire adapter thật theo §4.5.4 · `ui` nếu còn `@trace.mock_for`/mock adapter · `—` cho `system`. **Không suy được** → để `—`, đừng đoán. *(Vocabulary chỉ có `ui` \| `integrated` — nhớ hậu tố **-ed**. Dạng không -ed thuộc về cờ `--phase=integration`, không phải cột này.)* |
+| `test_count` · `test_classes` | **CHỈ khi `has_verifies` = true** (Step 2b đã thu). Số test + tên class lấy từ file mang `@trace.verifies`. `has_verifies` = false → **để trống**, tuyệt đối không điền 0-giả hay tên class phỏng đoán |
+
+> ### ⚠️ Luật cứng: KHÔNG set `status`
+>
+> Điền xong 5 cột rồi **để Step 3 tự tính** `status`. Đây không phải chi tiết kỹ thuật — nó là điều
+> quyết định lệnh này hữu ích hay có hại.
+>
+> Có **hai loại bằng chứng, hai người ghi**: `@trace.implements` = *"đã làm"* (do `/generate-code`) ·
+> `@trace.verifies` = *"đã kiểm"* (do `/dev-gen-test`). **Không được suy cái này ra cái kia.**
+>
+> Đo trên một project thật: trong 910 row lệch, **446 có cả hai** ⇒ Step 3 tính ra `OK`; **464 chỉ
+> có cái thứ nhất** ⇒ Step 3 tính ra `GAP`, tức **lộ ra 464 chỗ thiếu test** đang bị chữ `UNTRACKED`
+> che. Nếu lệnh này tự viết `status = OK` thì 464 scenario chưa ai kiểm lên dashboard thành xong hết,
+> và **cổng chặn PR — thứ tồn tại để bắt đúng loại lỗi này — mở cửa cho hàng chưa kiểm.**
+>
+> `/generate-code` đã phát biểu cùng luật này cho chính nó: *"`status` được tính bởi
+> `/validate-traces` — không set ở đây."* Lệnh ghi bù cũng không được là ngoại lệ.
+
+**Ba rào an toàn — bắt buộc, cùng khuôn Step 5e:**
+
+1. **Chỉ chạm row đang `LEDGER_BEHIND_CODE`.** Từ chối mọi row khác. Row `DRIFT`/`ORPHANED`/`GAP`/`OK` đã có `implemented_by` — ghi lên đó là ghi đè việc của `/generate-code`, không phải ghi bù. In:
+   ```
+   ❌ Từ chối reconcile {sc_id}: row này đang {status}, không phải LEDGER_BEHIND_CODE.
+      --reconcile-code chỉ điền vào row TRỐNG mà code đã có tag. Row này có chuyện khác.
+   ```
+2. **Chỉ ghi 5 cột trên.** **Guard sau-ghi:** đọc lại TSV, diff với bản trước; có bất kỳ ô nào **khác** ngoài 5 cột đã định (kể cả `status`, `last_updated` của row không thuộc phạm vi) → **khôi phục file** và dừng.
+3. **In chính xác từng file + từng row đã sửa**, kèm cột nào điền giá trị gì và **bằng chứng nào**:
+   ```
+   📓 Đã ghi bù {n} row:
+      {UC-ID}-{platform}.tsv:{dòng}  {sc_id}
+        implemented_by ← {ClassName.method}      (từ {file}:{dòng})
+        gen_ver        ← {spec_ver}
+        fe_phase       ← {ui | integrated | —}
+        test_count     ← {n} · test_classes ← {…}   (từ @trace.verifies ở {file})   [hoặc: bỏ trống — không có @trace.verifies]
+   ```
+   Ghi bù im lặng là ghi bù không kiểm chứng được.
+
+**Không đụng** `dev_selftest`/`qc_status`/`qc_owner`/`qc_blocked_by`: luật G28 không áp vì **không có logic nào đổi** — code đã nằm đó từ trước, ta chỉ ghi lại sự thật vào sổ. Hạ tín hiệu nghiệm thu ở đây là trừng phạt một lượt dọn dẹp.
+
+**Sau khi ghi, chạy tiếp Step 3 → Step 6 → Step 7 như thường** để `status` được tính lại và aggregate phản ánh số mới. In cảnh báo ở report:
+```
+ℓ Coverage sẽ NHẢY sau lượt này — code {cũ}% → {mới}%, test {cũ}% → {mới}%.
+  Đây KHÔNG phải việc mới làm được: là việc đã làm rồi mà sổ chưa ghi. Và {n} row
+  chuyển sang GAP là {n} chỗ thiếu test vừa lộ ra — phần "xấu đi" trên giấy chính
+  là phần trước đó đang bị che.
+```
+
 ### Step 5c — BDD version drift check
 
 *Đối xứng với Step 4 (PRD drift). Trước đây tầng BDD là tầng DUY NHẤT không có cờ drift — dù `/generate-code` vẫn ghi `@trace.bdd_version` vào code và JSON report vẫn lưu nó. Dữ liệu có, chỉ thiếu phép so.*
@@ -692,6 +823,18 @@ fe_integrated    = rows where fe_phase == integrated  # FE đã wire adapter th
 # công việc CHƯA XONG dù status có thể đã là OK (có code + có test trên mock).
 orphaned_count   = rows where status == ORPHANED     # code còn, scenario đã bị xoá khỏi .feature (Step 2b/Rule 0)
 trace_orphan_count = số tag @trace.implements/@trace.verifies trỏ vào SC không tồn tại VÀ không có row TSV (Step 2b)
+ledger_behind_code_count = số row có @trace.implements trong code mà cột implemented_by còn trống
+                   (Step 2b câu B). 🟠 — "làm rồi mà không ghi sổ". Sạch bằng --reconcile-code.
+                   # KHÔNG vào gate.blocking, và đây là quyết định có chủ ý — đừng "sửa":
+                   #   (1) gate.blocking nghĩa hẹp là CODE ĐANG HỎNG. Ở đây code hoàn toàn đúng
+                   #       và đang chạy; chỉ có sổ nói sai về nó. Cùng ranh giới mà R9(e) giữ.
+                   #   (2) Nợ tồn khi mới bật: mọi project đang chạy đều đã có sẵn hàng trăm row
+                   #       loại này (đo thật: 504 scenario / 910 row ở một project) ⇒ cờ chặn mới
+                   #       sẽ đỏ khắp nơi ở lần đầu ⇒ người ta tắt cổng ⇒ mất luôn 4 cờ 🔴 thật.
+                   #   (3) Nhưng nó vẫn PHẢI thấy được: in mỗi lần chạy + counter ở summary, và
+                   #       bản xác định của cùng phép kiểm là lint-trace T14 (cũng WARN).
+                   # Team nào đã dọn sạch nợ tồn thì tự thêm counter này vào gate.blocking kèm
+                   # `why` — self-check R13(e) canh việc đó.
 prd_untracked_edit_count = số file PRD có nội dung đổi kể từ `sha_at_audit` mà `Version` KHÔNG đổi
                    (Step 3.9). 🔴 — có người sửa ngoài đường chính thức, nên MỌI phán đoán version
                    của Step 4/5 trên file đó đang dựa vào một nhãn không còn đúng.
@@ -797,6 +940,7 @@ Schema:
     "fe_integrated": 0,
     "orphaned_count": 0,
     "trace_orphan_count": 0,
+    "ledger_behind_code_count": 0,
     "prd_untracked_edit_count": 0,
     "prd_drift_count": 0,
     "prd_stale_ref_count": 0,
@@ -1007,6 +1151,16 @@ Schema:
         "fix": "sửa sc_id cho đúng SC hiện có, HOẶC xoá code/test nếu không còn cần"
       }
     ],
+    "ledger_behind_code": [
+      {
+        "sc_id": "<SC-ID>",
+        "platform": "web | app | system | webview | …",
+        "files": ["<file code mang @trace.implements cho SC này>"],
+        "has_verifies": false,
+        "would_become": "OK | GAP",
+        "fix": "/validate-traces --reconcile-code   (điền implemented_by/gen_ver/fe_phase từ tag; test_count CHỈ khi có @trace.verifies; KHÔNG set status)"
+      }
+    ],
     "techdoc_drift": [
       {
         "uc_id": "<UC-ID>",
@@ -1242,6 +1396,23 @@ Trace orphan (tag trỏ vào SC không tồn tại, KHÔNG có row .tsv nào):
     (Không lệnh nào khác bắt được cái này — row .tsv đã bị xoá bởi version cũ,
      hoặc tag ghi sai id ngay từ đầu.)
 
+{khối dưới CHỈ in khi ledger_behind_code_count > 0 — else bỏ cả khối}
+🟠 LEDGER_BEHIND_CODE — làm rồi mà sổ chưa ghi ({n} scenario):
+     {UC}-UC1-SC3 (web)  code: {File.method}                   → sẽ thành OK
+     {UC}-UC1-SC4 (web)  code: {File.method}   chưa có test     → sẽ thành GAP
+     … {n} scenario, gom theo PRD: {LESS-06} 76 · {LESS-09} 65 · …
+   Code đã có tag @trace.implements, nhưng cột implemented_by còn trống ⇒ các row này
+   đang hiện UNTRACKED. Dashboard đếm THIẾU, và /generate-code coi là "chưa làm" nên
+   sẽ sinh lại thứ đã có.
+   Nguyên nhân thường gặp: /generate-code dừng ở cổng build nên §Write Trace State
+   chưa chạy (build fail 3 lần → "KHÔNG ghi trace" là đường thoát hợp lệ), rồi dev
+   sửa tay cho build pass và commit mà không chạy lại lệnh.
+   → /validate-traces --reconcile-code            (cả scope hiện tại)
+     /validate-traces --reconcile-code --domain {d}  (dọn từng domain cho dễ soi)
+   ⚠️  {n} trong số này CHƯA có @trace.verifies → chúng sẽ thành GAP, không phải OK.
+       Đó là số ĐÚNG: chỗ thiếu test vừa lộ ra, không phải chỗ mới hỏng.
+   🟠 KHÔNG chặn PR — code đang chạy đúng, chỉ sổ nói sai về nó.
+
 🔴 PRD_UNTRACKED_EDIT — nội dung PRD đổi mà nhãn Version KHÔNG đổi ({n} file):
   specs/payment/create-invoice/PAY01-create-invoice.md   Version 1.3 (không đổi từ lần audit)
     Bằng chứng : git status — sửa CHƯA commit
@@ -1311,6 +1482,10 @@ Routing chưa chốt ({service_unrouted_count} scenario) — 🟠 KHÔNG chặn
       và đóng dấu incorporated + archived/ — không phải làm tay bước nào).
 
 Recommendations:
+  - /validate-traces --reconcile-code  cho LEDGER_BEHIND_CODE 🟠  ← CHẠY CÁI NÀY TRƯỚC
+      ↳ Nó chỉ ghi sổ theo tag đã có trong code, không sinh code. Chạy trước thì
+        UNTRACKED/GAP bên dưới mới là số thật; chạy /generate-code trước sẽ sinh lại
+        thứ đã tồn tại và có thể ghi đè code đang chạy.
   - /generate-code {UC-ID}       cho scenario DRIFT và UNTRACKED
   - /dev-gen-test {UC-ID}        cho GAP (thiếu test)
   - /generate-bdd {prd-file}     cho PRD_DRIFT 🟠 (changelog CÓ nêu UC này)

package/core/skills/qc/qa-analyst/DOC_GAPS.template.md

@@ -0,0 +1,63 @@
+---
+version: 1.1
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
+---
+
+# Gap Analysis – <FEATURE>
+
+> File ghi lại các **khoảng trống của tài liệu** mà `qa-analyst` phát hiện sau khi
+> phân tích. Là đầu vào để hỏi dev/BA và cho `qa-planner`. Mỗi gap có ID `GAP-xx`
+> để business rule (BR-xx), acceptance criteria (AC-xx) và test case trace ngược về.
+
+| Trường | Giá trị |
+|---|---|
+| Feature | `<FEATURE>` |
+| Project / Service | `<project or service name / domain>` |
+| Tài liệu nguồn | `<đường dẫn / link PRD / user story>` |
+| Người phân tích | qa-analyst |
+| Ngày phân tích | `<YYYY-MM-DD>` |
+| Tổng số gap | `<N>` (Blocker: x · High: y · Medium: z · Low: w) |
+| Trạng thái chung | 🔴 Blocked / 🟡 Cần làm rõ / 🟢 Đủ rõ để thiết kế TC |
+
+---
+
+## Bảng Gap
+
+| ID | Loại | Mô tả gap | Vị trí (mục/nguồn) | Ảnh hưởng (chức năng / BR / AC) | Mức độ | Người trả lời | Trạng thái | Câu trả lời |
+|---|---|---|---|---|---|---|---|---|
+| GAP-01 | MISSING | … | spec §x | chức năng A / BR-02 | 🔴 Blocker | Dev/BA | Open | — |
+| GAP-02 | AMBIGUOUS | … | mockup màn hình Y | AC-03 | 🟠 High | BA | Open | — |
+| GAP-03 | CONTRADICTORY | … | §2 vs §5 | BR-04 | 🟠 High | BA | Open | — |
+| GAP-04 | ASSUMPTION | … (giả định AI tự đưa, cần xác nhận) | — | chức năng B | 🟡 Medium | Dev | Open | — |
+
+### Loại gap
+- **MISSING** – thông tin/chức năng/field/rule chưa được mô tả.
+- **AMBIGUOUS** – mô tả mơ hồ, có ≥ 2 cách hiểu.
+- **CONTRADICTORY** – các phần tài liệu mâu thuẫn nhau.
+- **ASSUMPTION** – giả định do qa-analyst tự suy ra, cần dev/BA xác nhận.
+- **OPEN QUESTION** – câu hỏi mở cần trả lời trước khi thiết kế/triển khai.
+
+### Mức độ
+🔴 Blocker (chặn thiết kế TC) · 🟠 High · 🟡 Medium · 🟢 Low
+
+---
+
+## Quy ước cập nhật
+- `qa-analyst` tạo & điền gap khi phân tích; **không tự bịa câu trả lời** cho gap Blocker.
+- Khi có phản hồi dev/BA: điền cột *Câu trả lời*, đổi *Trạng thái* → `Answered`.
+- Còn gap 🔴 Blocker `Open` ⇒ **chưa** chuyển sang `qa-designer`; đẩy sang `qa-planner`
+  (skill `questions-for-dev`) để chốt câu hỏi.
+
+---
+
+## ⚠️ Checklist bắt buộc trước khi lưu file
+
+Trước khi lưu `DOC_GAPS.md`, kiểm tra **từng hàng** trong bảng gap:
+
+- [ ] **9 cột đủ** – đúng thứ tự: `ID | Loại | Mô tả gap | Vị trí (mục/nguồn) | Ảnh hưởng (chức năng / BR / AC) | Mức độ | Người trả lời | Trạng thái | Câu trả lời`
+- [ ] **Cột Vị trí không rỗng** – phải có tham chiếu cụ thể đến mục trong tài liệu nguồn (vd `§3 UC4 BR25`, `Appendix B loại 7`, `§4.b Screen 3`). Đây là cột hay bị bỏ thiếu nhất → gây lệch toàn bộ cột sau.
+- [ ] **Cột Ảnh hưởng = BR/AC references** – KHÔNG phải mức độ severity. Ví dụ đúng: `BR25, BR26 / AC-F01-33`. Nếu thấy "Blocker" / "High" ở đây → đang bị lệch cột.
+- [ ] **Cột Mức độ có emoji** – bắt buộc dùng: `🔴 Blocker` / `🟠 High` / `🟡 Medium` / `🟢 Low`. Không được ghi text thuần.
+- [ ] **Cột Người trả lời = vai trò** (PO / BA / Dev / Design / Content / DPO / QC Lead). Nếu thấy "Open" ở đây → đang bị lệch cột.
+- [ ] **Cột Trạng thái = Open / Answered**. Nếu thấy "—" ở đây → đang bị lệch cột.

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

@@ -1,9 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
-upstream_path: skills/qa-tc-analyst/acceptance-criteria.md
-upstream_sha: 516f35cf78102d27aa5639bfb2818274399800c0
+ported_from: ai-automation-qc-base
 ---
 
 # Acceptance Criteria — Sinh tiêu chí chấp nhận
@@ -54,7 +52,7 @@ Mỗi AC gắn mã trace: chức năng + BR-xx để TC sau này map 1-1.
 ## Output
 
 Ghi vào **mục Acceptance Criteria** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`
-(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAP.md`):
+(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`):
 
 - Danh sách AC dạng Given/When/Then, có mã trace về chức năng, business rule (BR-xx)
   và scenario chính thức `{UC-ID}-SC{N}` của `.feature`.

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

@@ -1,9 +1,7 @@
 ---
 version: 1.0
-updated: 2026-08-25
-ported_from: ui-automation-testing
-upstream_path: skills/qa-tc-analyst/business-rules.md
-upstream_sha: 0d5f01257c30182d1c98835303640775d360a3da
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
 ---
 
 # Business Rules — Trích xuất luật nghiệp vụ
@@ -27,38 +25,6 @@ Trích xuất và liệt kê toàn bộ business rule, điều kiện và ràng
 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.
-3. **Checklist ràng buộc field — kiểm tra TẤT CẢ field (kể cả tuỳ chọn / optional):**
-   - [ ] `minlength` / `maxlength` — PRD có nêu không? Nếu không → GAP (MISSING)
-   - [ ] Ký tự được phép — chữ, số, tiếng Việt có dấu, ký tự đặc biệt, khoảng trắng?
-   - [ ] Trim khoảng trắng đầu/cuối — có hay không?
-   - [ ] Format đặc biệt — email, SĐT, ngày tháng, v.v.
-   > ⚠️ **Field tuỳ chọn (optional) vẫn phải kiểm tra đủ 4 mục trên.** "Không bắt buộc nhập" KHÔNG đồng nghĩa với "không có ràng buộc". Đây là nguồn gốc hay bị bỏ sót khi phân tích.
-
-4. **Checklist đặc biệt — hay bị bỏ sót khi đọc BDD/PRD:**
-
-   **a. Routing table — đọc cả 2 chiều:**
-   - [ ] Với MỖI rule "nếu đủ điều kiện → bỏ qua / nếu thiếu → vào": đánh dấu cả 2 nhánh cần test
-   - [ ] Routing table N loại tài khoản × M màn → duyệt từng ô, không bỏ dòng nào
-
-   **b. Liệt kê hết variant:**
-   - [ ] Spec đề cập nhiều provider/platform/giá trị liệt kê (Google/Facebook, Lớp 1-6...)? → ghi từng variant ra
-   - [ ] Với mỗi variant: behavior hoặc content có khác nhau không? Nếu có → đánh dấu cần TC riêng
-
-   **c. Telemetry/event analytics:**
-   - [ ] Liệt kê TẤT CẢ event name được nhắc trong BDD/PRD cho UC này
-   - [ ] Với mỗi event: trigger khác nhau? → cần TC riêng
-   - [ ] Có field nhạy cảm (SĐT, PII) KHÔNG ĐƯỢC vào event? → cần TC verify âm riêng
-
-   **d. Privacy/security assertions âm:**
-   - [ ] Spec có nói "KHÔNG ghi", "KHÔNG hiển thị", "chỉ đọc", "KHÔNG vào event"? → ghi ra, cần TC riêng
-   - [ ] "Read-only + che X/hiện Y" → 2 TC riêng: (1) hiển thị đúng che/hiện, (2) không chỉnh sửa được
-
-   **e. Validation kế thừa từ UC/AC khác:**
-   - [ ] Spec có reference "chuẩn hoá theo ACx", "logic tương tự UCy", "validation như màn Z"? → đọc UC/AC đó
-   - [ ] Liệt kê TẤT CẢ scenario normalization của UC nguồn chưa có trong UC hiện tại
-
-   **f. AC có sub-cases:**
-   - [ ] Mỗi AC dạng "(1)...→...; (2)...→...; (3)...→..." → đếm số sub-cases, mỗi sub-case 1 TC
 
 ---
 
@@ -84,10 +50,10 @@ Với rule có nhiều điều kiện kết hợp → gợi ý dựng **Decision
 ## Output
 
 Ghi vào **mục Business Rules** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`
-(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAP.md`):
+(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`):
 
 - Bảng business rule có ID (BR-xx) để TC trace ngược về.
 - Gợi ý các rule cần Decision Table / BVA khi sang qa-designer.
 
-Rule MÂU THUẪN / KHÔNG RÕ → ghi vào `{paths.qc_dir}/{UC-ID}/DOC_GAP.md`
+Rule MÂU THUẪN / KHÔNG RÕ → ghi vào `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md`
 (loại CONTRADICTORY / AMBIGUOUS, cột "Ảnh hưởng" trỏ BR-xx).

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

@@ -1,9 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
-upstream_path: skills/qa-tc-analyst/data-flow.md
-upstream_sha: fc0fc3d0f8010e3fb266c16b132eff1b23641a8f
+ported_from: ai-automation-qc-base
 ---
 
 # Data Flow — Phân tích luồng dữ liệu
@@ -55,7 +53,7 @@ Thể hiện luồng dạng bước tuần tự hoặc sơ đồ text:
 ## Output
 
 Ghi vào **mục Data Flow** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`
-(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAP.md`):
+(KHÔNG tạo file riêng — qc-analyze chỉ trả 2 file: `REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`):
 
 - 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.
@@ -63,4 +61,4 @@ Ghi vào **mục Data Flow** của `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.
 - Dữ liệu/trạng thái cần chuẩn bị & cleanup → đầu vào fixture cho qa-runner.
 
 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 `{paths.qc_dir}/{UC-ID}/DOC_GAP.md` (loại MISSING / OPEN QUESTION).
+ghi vào `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md` (loại MISSING / OPEN QUESTION).

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

@@ -1,9 +1,7 @@
 ---
 version: 1.0
-updated: 2026-08-25
-ported_from: ui-automation-testing
-upstream_path: skills/qa-tc-analyst/spec-breakdown.md
-upstream_sha: 4a5fb9334fef1fdc3ac5e899e0463c643af80dad
+updated: 2026-06-11
+ported_from: ai-automation-qc-base
 ---
 
 # Spec Breakdown — Bóc tách yêu cầu
@@ -29,7 +27,7 @@ Bóc tách spec/PRD/user story thô thành mô tả yêu cầu có cấu trúc c
    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_GAP.md` (gap GAP-xx).
+4. Đánh dấu phần MƠ HỒ / THIẾU → ghi vào `DOC_GAPS.md` (gap GAP-xx).
 
 ---
 
@@ -39,7 +37,7 @@ 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. Với **mỗi field input** (kể cả tuỳ chọn): kiểm tra đủ `minlength`/`maxlength`, ký tự cho phép, trim, format. Field thiếu bất kỳ mục nào → ghi gap MISSING vào `DOC_GAP.md`.
+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.
@@ -50,14 +48,14 @@ F. GIẢ ĐỊNH & CÂU HỎI MỞ: điều suy ra được vs điều cần dev
 
 ⚠️ `/qc-analyze` chỉ ghi **ĐÚNG 2 FILE** cho mỗi UC, đặt trong thư mục QC **lộ ra ngoài**
 `{paths.qc_dir}/{UC-ID}/` (mặc định `docs/{UC-ID}/` — KHÔNG để trong `.agent/` ẩn):
-`REQUIREMENT_ANALYSIS.md` + `DOC_GAP.md`. KHÔNG tách mỗi bước phân tích thành file riêng.
+`REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`. KHÔNG tách mỗi bước phân tích thành file riêng.
 
 Phần spec-breakdown là **mục đầu tiên** của `REQUIREMENT_ANALYSIS.md`:
 - 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 `{paths.qc_dir}/{UC-ID}/DOC_GAP.md`
-(theo `{paths.qc_skills_dir}/qa-analyst/DOC_GAP.template.md`), mỗi gap có ID `GAP-xx`.
+Đồng thời ghi mọi khoảng trống phát hiện vào `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md`
+(theo `{paths.qc_skills_dir}/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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — E2E Journey
@@ -18,7 +18,7 @@ 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)`.
+- 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.

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Test Charter — Exploratory

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Explore-to-Functional Pipeline

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Functional API (không qua UI)
@@ -22,7 +22,7 @@ Chỉ cần load file này.
 - 1 file/feature · mỗi TC **1 concept** · metadata **list** (không bảng/emoji): Title · Feature ·
   Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
 - **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; không có BR → `⚠️ Chưa có Business Rule`.
-- **🚫 Block:** TC phụ thuộc gap vẫn viết đủ + `[GAP-xx](DOC_GAP.md) — lý do`.
+- **🚫 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.

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Functional GUI Feature (đa màn hình)
@@ -22,7 +22,7 @@ Skill **tự chứa** để viết TC functional cho feature có luồng span
 - 1 file/feature · mỗi TC **1 concept** · metadata **list** (không bảng/emoji): Title · Feature ·
   Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
 - **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; không có BR → `⚠️ Chưa có Business Rule`.
-- **🚫 Block:** TC phụ thuộc gap vẫn viết đủ + `[GAP-xx](DOC_GAP.md) — lý do`.
+- **🚫 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.
 

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Functional GUI Screen (1 màn hình)
@@ -22,7 +22,7 @@ Skill **tự chứa** để viết TC functional cho 1 màn hình đơn lẻ (we
 - 1 file/feature · mỗi TC **1 concept** · metadata **list** (mỗi trường 1 dòng, không bảng/emoji):
   Title · Feature · Priority(P0/P1/P2) · Status(Draft) · Author(AI) · Tags · Trace · 🚫 Block(nếu có).
 - **Trace:** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)`; TC không có BR → `⚠️ Chưa có Business Rule`.
-- **🚫 Block:** TC phụ thuộc gap **vẫn viết đủ** + `[GAP-xx](DOC_GAP.md) — lý do`; chưa chạy tới khi gap Answered.
+- **🚫 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.

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Integration API
@@ -20,7 +20,7 @@ verify luồng dữ liệu & contract giữa các thành phần. Chỉ cần loa
 ---
 
 ## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)` (TC chặn vẫn viết đủ).
+- 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.
 

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Integration DB
@@ -18,7 +18,7 @@ insert/update/soft-delete đúng giá trị, side-effect, toàn vẹn. Chỉ c
 ---
 
 ## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
+- 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.
 

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Integration GUI ↔ Backend
@@ -19,7 +19,7 @@ lỗi từ server, đồng bộ trạng thái hai chiều. Chỉ cần load file
 ---
 
 ## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
+- 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.