@educa-corp/sdd-framework 0.9.6 → 0.9.8

package/core/commands/qc-review-script.md

@@ -0,0 +1,342 @@
+---
+version: 1.0
+updated: 2026-09-16
+ported_from: ai-automation-qc-base
+---
+
+# /qc-review-script — QC Review Gate: script
+
+> **Trạm 7/9** của dây chuyền QC automation. Soát **code test + Page Object** đã sinh: khớp `.Test.md`, cấu trúc Page Object, assertion,
+> selector, hard-code. Cặp với `/qc-review-testcase` — hai lệnh, hai vai, không còn đoán.
+
+## Gate
+
+*Checkpoint: **không chặn** — lệnh ghi `REVIEW_SCRIPT_<FEATURE>.md`, là BIÊN BẢN của một lượt soát: sinh lại = soát lại, không trạng thái nào tích luỹ. Xem §Chạy lại.*
+
+# Gate — Quy trình vào chuẩn cho mọi lệnh
+
+Mọi lệnh PHẢI chạy gate này trước khi thực thi phần logic riêng của nó.
+
+## Bước 0 — Kiểm tra chế độ Sub-Agent
+
+Trước tiên, kiểm tra xem `$ARGUMENTS` có phải là payload JSON từ một orchestrator hay không:
+
+1. Thử parse `$ARGUMENTS` dưới dạng JSON.
+2. Nếu parse thành công **và** chứa `"_agent_mode": true`:
+   - **Bỏ qua hoàn toàn Bước 1, 2 và 3 của Gate này.**
+   - Đặt target file = `payload.target_file`
+   - Đặt loaded context = `payload.context` (KHÔNG chạy context-loader.md)
+   - Đặt phạm vi UC = `payload.uc_id` (chỉ xử lý UC này)
+   - Đặt line range = `payload.uc_section` (chỉ đọc đúng section đó của PRD)
+   - Đặt dimension = `payload.dimension` nếu có (lệnh review per-UC: chỉ review đúng lăng kính này)
+   - Đi thẳng tới phần logic riêng của lệnh.
+3. Nếu `$ARGUMENTS` không phải JSON hoặc không có `_agent_mode` → tiếp tục sang Bước 1 (chế độ thường).
+
+## Bước 0-B — Ghi nhận Model *(KHÔNG chặn)*
+
+*Bỏ qua nếu `_agent_mode: true` (sub-agent — orchestrator đã ghi nhận rồi).*
+
+Ghi lại **model mà bạn — agent đang chạy lệnh này — thực sự đang dùng**, rồi mang nó vào
+dòng `Model:` của report cuối (xem `report-footer`). Nếu bạn biết mình **không** phải một
+model Opus, gắn thêm cảnh báo ngay ở dòng đó.
+
+**KHÔNG hỏi người dùng. KHÔNG chờ. KHÔNG dừng.**
+
+> **Vì sao bước này từng là prompt chặn, và vì sao bỏ (GAPS-v3 G41):** bản cũ hiện khối
+> `⚙️ MODEL CHECK` rồi chờ `Y/S/N`. Ba vấn đề cùng chỉ một hướng:
+> **(1)** nó hỏi người dùng thứ mà **agent đã biết chính xác**;
+> **(2)** câu trả lời **không kiểm chứng được** — gõ `Y` xong vẫn đang chạy Haiku thì không
+> gì phát hiện;
+> **(3)** **cả `Y` lẫn `S` đều đi tiếp** — cách duy nhất để nó dừng là tự nguyện gõ `N`.
+> Tức nó **không chặn được ai**, mà tốn một lần chặn ở **mọi** lệnh. Một feature đi hết
+> pipeline dùng 20 lệnh; 30/32 lệnh chạy gate. Hai mươi lần bấm cho một tín hiệu tự-khai
+> không kiểm chứng được — và chính cái giá đó làm mòn CHECKPOINT ở Bước 3, cổng có giá trị thật.
+>
+> Khai báo trong report **mạnh hơn** hỏi: đúng nguồn (agent, không phải người), và nằm
+> **cạnh kết quả** để cân nhắc, thay vì nằm trước khi có kết quả để bấm cho xong.
+
+**Vẫn khuyến nghị Opus:** phân tích spec, review kiến trúc và sinh code đòi hỏi suy luận sâu;
+model nhỏ hơn dễ bỏ sót edge case và vi phạm kiến trúc. Đổi: `/model` → chọn Opus.
+
+## Bước 1 — Xác định Target File
+
+0. **Tách cờ trước khi resolve target.** `$ARGUMENTS` có thể lẫn các `--flag` (vd `--phase=integration`, `--comment`, `--fix`). **Loại bỏ mọi token bắt đầu bằng `--`** ra khỏi phần dùng để tìm target — chỉ giữ phần path/UC-ID/ticket. (Các flag đó do phần logic riêng của lệnh parse ở bước sau, KHÔNG phải tên file.)
+1. Nếu `$ARGUMENTS` (đã tách cờ) được cung cấp và trỏ tới một file tồn tại → dùng trực tiếp làm target.
+2. Nếu `$ARGUMENTS` là một **UC-ID / ticket ID / tên rút gọn** (không có path) → phân giải thành file bằng cách glob theo bố cục feature-package. `{prd-slug}` lúc này **chưa biết**, nên dùng wildcard `*` cho segment đó, và `**` đệ quy dưới `bdd/` để phủ hết các thư mục con theo platform (`bdd/web/`, `bdd/app/`, `bdd/system/`):
+   - **Lệnh BDD** (target là `.feature`): `{specs_dir}/{domain}/*/bdd/**/{UC-ID}*.feature` — hoặc `{specs_dir}/*/*/bdd/**/{UC-ID}*.feature` nếu domain cũng chưa biết. Nếu lệnh ngụ ý một platform/scope cụ thể (vd: system tech-doc cần BDD `system/`), ưu tiên kết quả trong thư mục con platform đó.
+   - **Lệnh PRD** (target là file PRD `{TICKET-ID}-{prd-slug}.md` — file `.md` duy nhất ở gốc feature folder, cạnh `bdd/`): `{specs_dir}/{domain}/*/{TICKET-ID}*.md` nếu biết TICKET-ID; nếu không, `{specs_dir}/{domain}/*/*.md` (khớp feature folder có id tương ứng), hoặc `{specs_dir}/*/*/*.md` nếu domain cũng chưa biết. *(Glob `*/*.md` ở cấp gốc folder chỉ khớp PRD — tech-docs/design-spec `.md` nằm sâu hơn trong thư mục con.)*
+   - **Lệnh tech-docs** — target là tech-doc **gộp cấp PRD** `{TICKET-ID}-tech-design.md` (MỘT doc phủ nhiều UC; danh sách UC nằm ở `@trace.ucs`). Vì tên file mang `{TICKET-ID}` chứ **không** mang `{UC-ID}`, phải tách trước khi glob:
+     - `$ARGUMENTS` là **UC-ID** (`{TICKET-ID}-UC{N}`) → lấy `{TICKET-ID}` = phần **trước** `-UC`, rồi glob `{specs_dir}/{domain}/*/tech-docs/{TICKET-ID}-tech-design.md`.
+     - `$ARGUMENTS` là **TICKET-ID** → glob trực tiếp như trên.
+     - Chưa biết domain → `{specs_dir}/*/*/tech-docs/{TICKET-ID}-tech-design.md`.
+     - Vẫn không khớp → glob rộng `{specs_dir}/*/*/tech-docs/*tech-design*.md` rồi liệt kê để người dùng chọn.
+     *(Đừng glob `{UC-ID}*-tech-design*.md` — nó nở thành `FT-001-UC1*-tech-design*.md` và **không bao giờ** khớp `FT-001-tech-design.md`.)*
+   - **Lệnh design-spec**: `{specs_dir}/{domain}/*/design-spec/{TICKET-ID}*.md`.
+
+   Khi một file khớp: đặt nó làm target **và** ghi lại `domain` + `prd_slug` từ path của nó (theo quy tắc trích xuất trong `context-loader.md` Bước 1 — `prd_slug` = segment đầu tiên sau `{specs_dir}/{domain}/`). Mọi path mà lệnh đọc/ghi về sau (BDD/tech-docs/design-spec/trace cùng cấp) đều dùng **`prd_slug` đã phân giải đó**, nên tất cả artifact nằm chung một feature package. Nếu nhiều file khớp (vd: nhiều platform), chọn theo platform/scope của lệnh hoặc liệt kê ra và hỏi.
+3. Nếu `$ARGUMENTS` rỗng hoặc không tìm thấy file khớp:
+   - Liệt kê các file trong thư mục liên quan của lệnh này (vd: `specs/*/*/*.md` — file PRD ở gốc mỗi feature folder — cho lệnh PRD, `specs/*/*/bdd/**/*.feature` cho lệnh BDD).
+   - Hiển thị danh sách cho người dùng và hỏi: "Bạn muốn làm việc với file nào? (Nhập số thứ tự hoặc tên file)"
+   - Chờ người dùng chọn rồi mới tiếp tục.
+
+## Bước 2 — Chạy Context Loader
+
+Nạp toàn bộ context của dự án bằng cách làm theo quy trình trong `steps/context-loader.md`.
+Lưu toàn bộ context đã nạp vào bộ nhớ để dùng xuyên suốt phiên làm việc của lệnh.
+
+## Bước 3 — CHECKPOINT
+
+*Bỏ qua nếu `_agent_mode: true`.*
+
+### 3a — Lệnh này có phải chặn không?
+
+| Mức | Lệnh nào | `--yes` bỏ qua được? |
+|---|---|:---:|
+| **Không chặn** | `/review-code` · `/validate-traces` · `/debug` — **KHÔNG phải vì read-only**: cả ba đều CÓ ghi file. Chúng không chặn vì thao tác ghi của chúng hoặc nằm sau một câu hỏi `(Y/N)`, hoặc nằm sau một cờ, hoặc là `append`/dựng-lại-được | — (vốn không có) |
+| **Chặn thường** | Mọi lệnh sinh/sửa artifact | ✅ |
+| **Chặn CỨNG** | Ghi đè file đã tồn tại · `--resume` áp findings · migrate · prune | ❌ **không bao giờ** |
+
+`--yes` trong `$ARGUMENTS` → bỏ qua CHECKPOINT mức *chặn thường*. (Bước 1 đã tách mọi token
+`--` khỏi phần resolve target, nên cờ này không ảnh hưởng việc tìm file.) Mở đường chạy
+headless: `claude -p "/generate-code UC1 --yes"`.
+
+> **Tên lệnh trong bảng trên có máy canh — `R19`.** Mỗi hàng bảng vừa nêu một mức vừa nêu
+> tên lệnh sẽ bị đối chiếu với `gate.checkpoint_levels`; lệch là build đỏ. Lý do có rule này:
+> ngày 2026-09-16 hai lệnh đổi mức, schema và `commands/*.tmpl` đều sửa, **build vẫn xanh**,
+> mà bảng này lẫn `rules/workflow.md` đều còn liệt chúng ở mức cũ. `R11` chỉ canh
+> `commands/*.tmpl` ↔ schema — *biết có máy canh không bằng biết máy canh **đến đâu***.
+
+> **KHÔNG tự suy mức từ bảng này.** Mỗi lệnh **tự khai** mức của nó ở một dòng `*Checkpoint: …*`
+> ngay dưới `## Gate` của chính nó — đọc dòng đó, đừng suy diễn. Bảng trên chỉ giải thích ba mức
+> **nghĩa là gì**.
+> Nguồn máy đọc: `bin/trace-schema.json` → `gate.checkpoint_levels`; `self-check` **R11** fail
+> build nếu nhãn trong file lệnh lệch với schema, hoặc nếu một lệnh `hard`/`none` thiếu nhãn.
+> *(Lệnh không có dòng nào = mức **chặn thường**, mặc định.)*
+
+> **Mức *không chặn* là thực thi đúng miễn trừ mà `rules/workflow.md` đã cấp từ trước** —
+> trước G41 file đó viết *"read-only commands may skip CHECKPOINT"* còn gate thì luôn đòi.
+> Hai file cùng được nạp vào mọi lệnh mà nói ngược nhau; agent theo cái nào là tuỳ lúc.
+
+### 3b — In gì
+
+**KHÔNG lặp lại những gì `[CTX LOADED]` vừa in.** Recap của context-loader (Bước 7) đã hiện
+Stack · Platform · Layers · CLAUDE.md · Dict · Entities · Lessons · Service · Status ngay phía
+trên. CHECKPOINT chỉ thêm **một** thông tin mới là `Target`.
+
+**Mọi thứ sạch** — recap báo `Status: FULL`, không cờ nào bật → in đúng hai dòng:
+
+```
+CHECKPOINT — Target: {resolved file path}
+Tiếp tục? (Y/N)
+```
+
+**Có bất thường** → thêm một dòng cho **mỗi** trạng thái, nặng nhất lên đầu:
+
+```
+CHECKPOINT
+🔴 Service  : unresolved — {lý do context-loader đã ghi}
+⚠️ CLAUDE.md: service overlay THIẾU — dùng root (code sinh ra có thể sai stack)
+⚠️ Target   : resolve bằng wildcard — {n} file khớp, chọn {file}
+⚠️ Module   : not configured — code sinh ra sẽ dùng default
+   Status   : PARTIAL — thiếu: {danh sách}
+   Target   : {resolved file path}
+Tiếp tục? (Y/N)
+```
+
+### 3c — Cờ nào bật, cờ nào KHÔNG
+
+Mỗi dòng ⚠️/🔴 phải ứng với một trạng thái **context-loader đã tính rồi** — không phát minh
+điều kiện mới, chỉ mang thứ đang bị giấu lên chỗ người dùng phải quyết định:
+
+| Bật cờ khi | Nguồn | Mức |
+|---|---|:---:|
+| `active_service = unresolved` | context-loader Bước 2b/2c/Fallback | 🔴 |
+| `Status = MINIMAL` | recap Bước 7 | 🔴 |
+| `Status = PARTIAL` | recap Bước 7 | ⚠️ |
+| CLAUDE.md thiếu, hoặc service overlay thiếu | context-loader Bước 3 | ⚠️ |
+| Target resolve qua wildcard, hoặc nhiều file khớp mà lệnh tự chọn | Bước 1 ở trên | ⚠️ |
+| `module` không cấu hình | recap Bước 7 | ⚠️ |
+
+**KHÔNG bật cờ cho:** `Lessons: chưa có` · `Dict: missing` · `Entities: missing`. Đó là
+*"dự án chưa điền"*, không phải *"có gì đó sai"* — chúng ở lại trong recap.
+
+> **Nguyên tắc một câu:** cờ dành cho thứ **framework không chắc chắn hoặc đã phải đoán**,
+> không dành cho thứ **người dùng chưa làm**. Đẩy hết mọi thứ lên thì CHECKPOINT lại đầy như
+> cũ, và ta quay về đúng chỗ xuất phát: một cổng luôn giống nhau thì bị lướt qua.
+
+### 3d — Chờ trả lời
+
+- "Y" → tiếp tục sang các bước riêng của lệnh.
+- "N" → dừng, hỏi người dùng muốn thay đổi gì.
+- Có `--yes` và mức *chặn thường* → coi như "Y", **nhưng vẫn IN khối CHECKPOINT** nếu có cờ
+  🔴/⚠️ (không chặn ≠ không báo — người đọc log sau này vẫn cần thấy).
+
+
+*Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID (`active_platform` + `qc_artifact_dir` do §Phạm vi QC phân giải). Đọc **code test + Page Object** của UC, và đọc `.Test.md` chỉ để **đối chiếu 1-1** — KHÔNG soát nội dung `.Test.md`, đó là việc của `/qc-review-testcase`.*
+
+## Context
+**BẮT BUỘC — đọc `.agent/steps/context-loader.md` và thực thi TOÀN BỘ quy trình trong đó**,
+rồi mới tiếp tục phần bên dưới.
+
+Bỏ qua bước này thì `{paths.*}`, `{tech_stack.*}`, `{conventions.*}`, guardrail từ
+`project-lessons`, và routing service (chế độ umbrella) đều **chưa được phân giải** — mọi
+placeholder bên dưới sẽ rỗng và lệnh sẽ đọc/ghi sai chỗ.
+
+## Phạm vi QC
+
+**BẮT BUỘC — đọc `.agent/steps/qc-scope.md` và thực thi TOÀN BỘ quy trình trong đó**,
+rồi mới tiếp tục phần bên dưới.
+
+Nó chốt bốn thứ mà mọi trạm QC đều cần: `TICKET-ID` · `active_platform` ·
+`qc_artifact_dir` · `uc_list` (kèm trạng thái BDD từng UC, và cờ `--force`).
+Bỏ qua thì artifact QC ghi vào **sai thư mục** và `qc_status` ghi vào **sai sổ trace** —
+cả hai đều xảy ra trong im lặng, không có bước nào phía sau bắt được.
+
+---
+
+## Role
+
+Bạn là **QC Reviewer — vai script**. Soát code test sau trạm sinh script.
+
+> **Vì sao lệnh này tồn tại tách riêng** *(Đợt 2 · b1)*. Trước đây `/qc-review` làm cả hai vai và
+> **tự đoán** vai nào bằng cách so ngày sửa file. Hậu quả nặng nhất không phải đoán sai — mà là
+> **trạm sau không đặt được điều kiện tiên quyết**: `REVIEW_<FEATURE>.md` không nói nó là kết quả
+> soát test case hay soát script, nên `/qc-run-script` không hỏi được *"script đã APPROVED chưa?"*.
+
+**KHÔNG tự sửa** code test hay Page Object. Chỉ nhận xét, chấm điểm, ra verdict — người sửa là
+trạm sinh script. *Reviewer tự sửa rồi tự duyệt là bỏ mất cái cổng.*
+
+## Skills (`{paths.qc_skills_dir}/qa-reviewer/`)
+
+**Nạp trước:**
+
+| File | Cho gì |
+|---|---|
+| `shared/read-doc-gap-inputs.md` | Nạp **đủ** mọi tài liệu nguồn theo bảng *Tài liệu đầu vào đã đọc* của `DOC_GAP.md` — soát mù thì kết luận "0 lỗi" là vô nghĩa |
+| `shared/review-file-template.md` | Khuôn file kết quả · thang điểm `XX/100` · luật ghi file · nguyên tắc *mặc định hoài nghi* |
+| `script/_shared/review-rules.md` | **Luật soát dùng chung**: R01–R07 · 4 mức severity · 4 verdict suy từ số đếm · phép kiểm cơ học · đường dẫn theo `§layout` |
+
+**Rồi chọn theo NỀN rồi theo TẦNG, nạp MỘT file** *(nền phân giải ở `steps/qc-scope.md` §2b)*:
+
+| `active_platform` | File |
+|---|---|
+| `web` · `webview` | `script/web/{functional,integration,e2e,non-functional}.md` |
+| `app` · `app-ios` · `app-android` | `script/mobile/{functional,integration,e2e,non-functional}.md` |
+| `system` | `script/api/{endpoint,auth,security}.md` |
+| *(mọi nền)* | `script/exploratory.md` — biên bản phiên khám phá, không phải code |
+
+> ⚠️ **Ba nền soát ba thứ khác nhau, không phải một checklist đổi tên.** Thứ tự locator của web
+> *(`getByRole` → … → css)* **không tồn tại** ở Appium *(`~accessibilityId` → `id` → `xpath`)*, và
+> lane `api` **không có locator lẫn wait** — nó có API Object với luật *"không `expect()` bên
+> trong"*. Nạp nhầm lane là đi tìm những thứ không tồn tại rồi kết luận "không có lỗi".
+
+> ⚠️ **KHÔNG nạp `shared/review-check-groups.md` và §*Kiểm tra cấu trúc TC*.** Hai thứ đó kiểm
+> **cấu trúc file test case** — áp vào một Page Object là bảo reviewer đi tìm `#### Expected Result`
+> trong code, rồi gắn nhãn lỗi cho thứ đáng lẽ không có ở đó.
+
+---
+
+## Review focus
+
+- **Khớp `.Test.md` 1-1?** Mỗi TC có đúng một test tương ứng; không test mồ côi, không TC bị bỏ.
+- **Page Object 3 lớp + BasePage gọn?** Logic điều hướng không rò vào file test.
+- **`expect()` chứ không phải bare assert?** Assertion phải nói được nó kỳ vọng gì khi đỏ.
+- **Không hard-code** URL · credential · timeout. Không chờ cứng (`waitForTimeout` · `browser.pause`).
+- **Locator theo thứ tự ưu tiên CỦA NỀN** — web `getByRole → … → css` · app `~accessibilityId → id → xpath` · api không có locator. Lấy từ §4.5.6, không dò DOM.
+- **100% TC đã script** — không còn TC ở trạng thái `Draft`.
+
+Sinh findings (mức độ + vị trí + cách sửa), chấm điểm, ra verdict.
+
+> **Chân thứ tư của hợp đồng test-id KHÔNG kiểm ở đây.** Phép so §4.5.6 ↔ `*.Test.md` chạy trên
+> file test case, nên nó thuộc `/qc-review-testcase` *(`bin/trace-schema.json` →
+> `testid_fourth_leg.checked_by`)*. Ở trạm script, locator dựng **lúc chạy** từ bảng tươi — nó tự
+> cứu, và đó là lý do chân này chưa bao giờ cần canh ở đây.
+
+## Output
+
+Ghi vào **`{qc_artifact_dir}test-cases/REVIEW_SCRIPT_<FEATURE>.md`** — **file riêng**, không chung
+với biên bản soát test case:
+
+```
+{qc_artifact_dir}test-cases/
+├── TC_<FEATURE>.Test.md
+├── REVIEW_<FEATURE>.md            ← /qc-review-testcase
+└── REVIEW_SCRIPT_<FEATURE>.md     ← lệnh này
+```
+
+⚠️ **Tên file review KHÔNG có đuôi `.Test.md`.** Đuôi đó là của file test case; gắn vào file
+review sẽ làm trạm sau nhặt nó lên như một file test case rồi cố sinh script từ một bảng điểm.
+
+> **Vì sao tách file thay vì chung một file phân biệt bằng cột `Tầng`** *(Đợt 2 · b1 · E2)*. Hai
+> lượt soát cách nhau vài trạm. Chung file thì lượt sau **đè** bảng chi tiết của lượt trước, và
+> quan trọng hơn: trạm tiêu thụ verdict phải đọc được verdict của **đúng vai nó cần** — chung file
+> thì lại phải đoán, tức là mang nguyên vấn đề cũ sang một chỗ mới.
+
+### Verdict — hợp đồng máy đọc được
+
+File **phải** chứa đúng một dòng theo khuôn này, ở §Tổng quan:
+
+```
+**Verdict:** APPROVED
+```
+hoặc
+```
+**Verdict:** REVISION_REQUIRED   ← hoặc REJECTED khi có BLOCKER
+```
+
+Verdict suy từ **số đếm lỗi**, không từ điểm — `≥1 BLOCKER` → `REJECTED` · `≥1 MAJOR` → `REVISION_REQUIRED` · chỉ MINOR/SUGGESTION → `APPROVED_WITH_SUGGESTIONS` · sạch → `APPROVED`. Xem `qa-reviewer/shared/review-file-template.md` §Verdict.
+
+> **Đây là contract, không phải định dạng cho đẹp.** `/qc-run-script` (Đợt 2 · b2) **DỪNG** khi
+> verdict là `REVISION_REQUIRED` / `REJECTED`, hoặc chưa có file này. Ngưỡng đi tiếp:
+> **`≥ APPROVED_WITH_SUGGESTIONS`** (`AGT-005:132`). Đổi chuỗi này là làm trạm đó mù — nên nếu phải
+> đổi, đổi ở cả hai nơi trong cùng một commit.
+
+### Chạy lại — ghi đè ở đây AN TOÀN, và đây là lý do
+
+`REVIEW_SCRIPT_<FEATURE>.md` là **biên bản của một lần soát**. Sinh lại = **soát lại**, đúng bản
+chất của nó — không có trạng thái nào tích luỹ qua các lần chạy, không ô nào người điền tay vào sau.
+
+*Khai máy đọc: `bin/trace-schema.json` → `artifact_writers.enrolled.qc-review-script.has_human_content = false`
+— và **R18 ép khai `why`** chính vì một ngoại lệ có chủ ý trông y hệt một chỗ sót.*
+
+> **⚠️ Khai lại nếu điều này hết đúng.** Có ai bắt đầu ghi vào biên bản thứ **không sinh lại được** —
+> chữ ký duyệt, một quyết định *"chấp nhận rủi ro"* — thì lệnh này **phải** lên
+> `checkpoint_levels.hard` và có §Chạy lại như `/qc-analyze`.
+>
+> *Lưu ý ngược lại: code test mà trạm này **soát** thì **có** phần QC sửa tay, và trạm sinh script
+> đã ở mức `hard` vì đúng lý do đó (G77). Trạm này chỉ an toàn ở phần nó **ghi**, không phải phần
+> nó **đọc**.*
+
+Khuôn đầy đủ + quy tắc ghi: `shared/review-file-template.md`. Hai điều bắt buộc:
+
+- **Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. Verdict **suy ra được** theo luật ở trên.
+- **Bảng Tổng quan THÊM một hàng mỗi vòng**, không ghi đè — đó là cách duy nhất thấy được điểm
+  có tăng không. Các bảng chi tiết thì ghi đè phần của vòng mình.
+
+## Self-Review *(trước khi in Report)*
+
+Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md` — **không chép lại ở đây**.
+
+- **Bịa:** mỗi finding trỏ được về **file + dòng cụ thể** trong code đang soát? Và **cấm dùng chính
+  field `quote` của finding làm bằng chứng cho nó** — mở lại file đọc lại đoạn đó.
+- **Nhảy bước:** đã đi hết bộ tiêu chí `script/*`, **không** trộn tiêu chí test case vào? Verdict
+  `APPROVED` phát ra **sau** khi soát đủ, không phải vì "trông ổn"?
+- **Số liệu:** số finding theo **bốn mức** (BLOCKER/MAJOR/MINOR/SUGGESTION) = đếm thật trên file vừa ghi, và verdict khớp đúng số đếm đó *(R06)*?
+
+> **Verdict của lệnh này là cổng cho trạm chạy.** Một `APPROVED` phát ra sớm cho chạy một bộ script
+> chưa đạt, và kết quả chạy đó đi thẳng vào `/qc-report` thành số liệu người ta tin.
+
+## Report
+
+**Đọc `.agent/steps/report-footer.md`** và áp đúng khuôn footer trong đó (Status Badge ·
+Output Artifacts · Next) cho report cuối, kèm khối bên dưới.
+
+```
+/qc-review-script Hoàn tất — {UC-ID} vòng #{N}
+Điểm  : {XX}/100  ({fail} FAIL × −5đ · {warn} WARN × −2đ){nếu có vòng trước: "   ← vòng #{N-1}: {YY}/100"}
+Verdict: {APPROVED | APPROVED_WITH_SUGGESTIONS | REVISION_REQUIRED | REJECTED} — {n} findings ({blk} BLOCKER · {maj} MAJOR · {min} MINOR · {sug} SUGGESTION)
+File  : {qc_artifact_dir}test-cases/REVIEW_SCRIPT_<FEATURE>.md (thêm 1 hàng vào bảng Tổng quan)
+Self-review: {✅ sạch | ⚠️ {n} điểm cần chú ý — liệt kê}
+Next (≥ APPROVED_WITH_SUGGESTIONS) : /qc-report {UC-ID}  rồi tạo PR
+     (REVISION_REQUIRED | REJECTED → sửa script bị gắn cờ, rồi chạy lại lệnh này)
+```

package/core/commands/{qc-review.md → qc-review-testcase.md}

@@ -1,14 +1,20 @@
 ---
 version: 1.0
-updated: 2026-06-11
+updated: 2026-09-16
 ported_from: ai-automation-qc-base
 ---
 
-# /qc-review — QC Review Gate (test case & script)
+# /qc-review-testcase — QC Review Gate: test case
 
-> Stage 4 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review → qc-run-test → qc-report). Port từ qa-reviewer của team QC. Một gate hai chiều: review test case (sau qc-design-test) VÀ script (sau qc-run-test).
+> Trạm 4/9 của dây chuyền QC automation (qc-analyze → qc-plan → qc-design-test → **qc-review-testcase** →
+> qc-automation-assess → qc-design-script → qc-review-script → qc-run-script ∥ qc-run-manualtest
+> → qc-report). Soát `.Test.md` do
+> `/qc-design-test` sinh: coverage · độ rõ · trace. Cặp với `/qc-review-script` — hai lệnh, hai vai.
 
 ## Gate
+
+*Checkpoint: **không chặn** — lệnh ghi `REVIEW_<FEATURE>.md`, là BIÊN BẢN của một lượt soát: sinh lại = soát lại, không trạng thái nào tích luỹ. Xem §Chạy lại.*
+
 # Gate — Quy trình vào chuẩn cho mọi lệnh
 
 Mọi lệnh PHẢI chạy gate này trước khi thực thi phần logic riêng của nó.
@@ -88,7 +94,7 @@ Lưu toàn bộ context đã nạp vào bộ nhớ để dùng xuyên suốt phi
 
 | Mức | Lệnh nào | `--yes` bỏ qua được? |
 |---|---|:---:|
-| **Không chặn** | Lệnh read-only: `/review-code` · `/validate-traces` · `/debug` · `/review-context` · `/review-tech-docs` | — (vốn không có) |
+| **Không chặn** | `/review-code` · `/validate-traces` · `/debug` — **KHÔNG phải vì read-only**: cả ba đều CÓ ghi file. Chúng không chặn vì thao tác ghi của chúng hoặc nằm sau một câu hỏi `(Y/N)`, hoặc nằm sau một cờ, hoặc là `append`/dựng-lại-được | — (vốn không có) |
 | **Chặn thường** | Mọi lệnh sinh/sửa artifact | ✅ |
 | **Chặn CỨNG** | Ghi đè file đã tồn tại · `--resume` áp findings · migrate · prune | ❌ **không bao giờ** |
 
@@ -96,6 +102,12 @@ Lưu toàn bộ context đã nạp vào bộ nhớ để dùng xuyên suốt phi
 `--` khỏi phần resolve target, nên cờ này không ảnh hưởng việc tìm file.) Mở đường chạy
 headless: `claude -p "/generate-code UC1 --yes"`.
 
+> **Tên lệnh trong bảng trên có máy canh — `R19`.** Mỗi hàng bảng vừa nêu một mức vừa nêu
+> tên lệnh sẽ bị đối chiếu với `gate.checkpoint_levels`; lệch là build đỏ. Lý do có rule này:
+> ngày 2026-09-16 hai lệnh đổi mức, schema và `commands/*.tmpl` đều sửa, **build vẫn xanh**,
+> mà bảng này lẫn `rules/workflow.md` đều còn liệt chúng ở mức cũ. `R11` chỉ canh
+> `commands/*.tmpl` ↔ schema — *biết có máy canh không bằng biết máy canh **đến đâu***.
+
 > **KHÔNG tự suy mức từ bảng này.** Mỗi lệnh **tự khai** mức của nó ở một dòng `*Checkpoint: …*`
 > ngay dưới `## Gate` của chính nó — đọc dòng đó, đừng suy diễn. Bảng trên chỉ giải thích ba mức
 > **nghĩa là gì**.
@@ -162,7 +174,7 @@ Mỗi dòng ⚠️/🔴 phải ứng với một trạng thái **context-loader
   🔴/⚠️ (không chặn ≠ không báo — người đọc log sau này vẫn cần thấy).
 
 
-*Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID (`active_platform` + `qc_artifact_dir` do §Phạm vi QC phân giải).  Phát hiện review mode từ `$ARGUMENTS`/context: review test-case `.Test.md` (sau design) hoặc review Python script (sau run). Đọc artifact từ `{qc_artifact_dir}` và source test/page-object đã sinh.*
+*Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID (`active_platform` + `qc_artifact_dir` do §Phạm vi QC phân giải). Đọc `.Test.md` từ `{qc_artifact_dir}test-cases/`. **KHÔNG** đi tìm file code test — đó là việc của `/qc-review-script`.*
 
 ## Context
 **BẮT BUỘC — đọc `.agent/steps/context-loader.md` và thực thi TOÀN BỘ quy trình trong đó**,
@@ -201,38 +213,38 @@ Bỏ vế ghi thì trạm sau không có gì để so; bỏ vế so thì stamp t
 > Nên `DOC_GAP.md` / `TEST_PLAN.md` đọc được ở đây phủ **cả PRD**: **lọc theo cột `UC`** để lấy
 > phần của UC đang làm. Đừng coi toàn bộ bảng gap là của UC này — sẽ chặn oan.
 
----
-
-
 ---
 
 ## Role
 
-Bạn là **QC Reviewer** — gate review dùng chung, chạy hai lần trong pipeline:
-1. **Sau qc-design-test** → review test-case `.Test.md` (coverage, độ rõ ràng, trace).
-2. **Sau qc-run-test** → review Python script / Page Object đã sinh.
+Bạn là **QC Reviewer — vai test case**. Soát `.Test.md` sau `/qc-design-test`.
+
+> **Vì sao lệnh này tồn tại tách riêng** *(Đợt 2 · b1)*. Trước đây `/qc-review` làm **cả hai vai**
+> và **tự đoán** đang ở vai nào bằng cách so ngày sửa file. Ba hậu quả: (1) so ngày là phép đo
+> thời gian, không phải ý định — sửa một dòng script hôm nay rồi gọi soát test case sẽ chọn sai
+> vai; (2) người chạy chỉ biết mình gọi vai nào **sau khi** đọc kết quả; (3) **nặng nhất** — trạm
+> sau không đặt được điều kiện tiên quyết, vì `REVIEW_<FEATURE>.md` không nói nó là kết quả của
+> vai nào.
 
-Phát hiện mode: nếu artifact target là `.Test.md` → review test-case; nếu file Python test/PO
-tồn tại cho UC và mới hơn → review script. Nếu mơ hồ, hỏi.
+**KHÔNG tự sửa** file TC. Chỉ nhận xét, chấm điểm, ra verdict — người sửa là `/qc-design-test`.
+*Reviewer tự sửa rồi tự duyệt là bỏ mất cái cổng.*
 
 ## Skills (`{paths.qc_skills_dir}/qa-reviewer/`)
 
-**Nạp trước — nhưng đúng vai:**
+**Nạp trước:**
 
-| File | Vai nào | Cho gì |
-|---|---|---|
-| `shared/read-doc-gap-inputs.md` | **cả hai** | Nạp **đủ** mọi tài liệu nguồn theo bảng *Tài liệu đầu vào đã đọc* của `DOC_GAP.md` — soát mù thì kết luận "0 lỗi" là vô nghĩa |
-| `shared/review-file-template.md` | **cả hai** | Khuôn file kết quả · thang điểm `XX/100` · luật ghi file · nguyên tắc *mặc định hoài nghi* |
-| ↳ §*Kiểm tra cấu trúc TC* của file đó | **chỉ vai 1** | Tầng kiểm các luật của trạm 3: ATOMIC 1-bullet · không ký tự `\|` · cụm từ mơ hồ · teardown đúng chỗ · marker ≠ oracle |
-| `shared/review-check-groups.md` | **chỉ vai 1** | **7 nhóm kiểm tra** chạy tuần tự · registry 46 nhãn lỗi · **7 mẫu-hay-thiếu** của Nhóm 6 · nền tảng ISTQB · anti-pattern |
+| File | Cho gì |
+|---|---|
+| `shared/read-doc-gap-inputs.md` | Nạp **đủ** mọi tài liệu nguồn theo bảng *Tài liệu đầu vào đã đọc* của `DOC_GAP.md` — soát mù thì kết luận "0 lỗi" là vô nghĩa |
+| `shared/review-file-template.md` | Khuôn file kết quả · thang điểm `XX/100` · luật ghi file · nguyên tắc *mặc định hoài nghi* |
+| ↳ §*Kiểm tra cấu trúc TC* của file đó | Tầng kiểm các luật của trạm 3: ATOMIC 1-bullet · không ký tự `\|` · cụm từ mơ hồ · teardown đúng chỗ · marker ≠ oracle |
+| `shared/review-check-groups.md` | **7 nhóm kiểm tra** chạy tuần tự · registry 46 nhãn lỗi · **7 mẫu-hay-thiếu** của Nhóm 6 · nền tảng ISTQB · anti-pattern |
 
-> ⚠️ **Vai 2 (soát code) KHÔNG nạp 7 nhóm kiểm tra.** Chúng kiểm **cấu trúc file test case** —
-> áp vào file Python là bảo reviewer đi tìm `#### Expected Result` trong một Page Object, rồi
-> gắn nhãn lỗi cho thứ đáng lẽ không có ở đó. Vai 2 dùng bộ tiêu chí riêng ở `script/*.md`.
+**Rồi chọn theo tầng, nạp MỘT file:**
+`test-case/{functional,e2e,integration,non-functional,exploratory}.md`
 
-**Rồi chọn theo vai + tầng, nạp MỘT file:**
-- Soát test-case: `test-case/{functional,e2e,integration,non-functional,exploratory}.md`
-- Soát script: `script/{functional,e2e,integration,non-functional,exploratory}.md`
+> ⚠️ **KHÔNG nạp `script/*.md`.** Bộ đó kiểm code; áp vào `.Test.md` là gắn nhãn lỗi cho thứ
+> đáng lẽ không có ở đó. Đó là việc của `/qc-review-script`.
 
 ---
 
@@ -244,10 +256,14 @@ tồn tại cho UC và mới hơn → review script. Nếu mơ hồ, hỏi.
 
 ```
 generate-code   → bake vào code          → T17/T18 canh
-qc-run-test     → dựng locator LÚC CHẠY  → đọc bảng tươi, tự cứu
+qc-run-script   → dựng locator LÚC CHẠY  → đọc bảng tươi, tự cứu
 qc-design-test  → chép vào .Test.md      → KHÔNG AI CANH   ← chỗ này
 ```
 
+*(Chân này do **lệnh này** canh — `bin/trace-schema.json` → `testid_fourth_leg.checked_by`. Khi
+`/qc-review` tách đôi, vai canh về `-testcase` vì phép so chạy trên `.Test.md`; `-script` không
+thừa hưởng nó.)*
+
 **Phạm vi — đọc trước khi làm gì.** Không có block §4.5 client trong tech-doc (dự án backend-only,
 hoặc chưa từng chạy `/map-testids`) → **im lặng hoàn toàn**, không kiểm gì. Cùng điều khoản phạm vi
 với `testid_contract`: *"hai rule nói 'chỗ nào đã hứa thì phải giữ', KHÔNG nói 'mọi chỗ đều phải có
@@ -278,7 +294,8 @@ là chặn nhầm loại.
 
 ## Review focus
 
-- **Test-case:** mọi `{UC-ID}-SC{N}` đã phủ? happy + negative + boundary? expected cụ thể? trace (`BR-xx` + `@trace.verifies` SC) có mặt? không có TC orphan?
+- Mọi `{UC-ID}-SC{N}` đã phủ? happy + negative + boundary? expected cụ thể? trace (`BR-xx` +
+  `@trace.verifies` SC) có mặt? không có TC orphan?
 - **`🚫 Block` còn hiệu lực không?** Mỗi TC mang `🚫 Block: [GAP-UC{N}-{nnn}]` → mở `../DOC_GAP.md`,
   đọc `Trạng thái` của hàng gap đó. **Gap đã `Answered` mà TC vẫn mang dấu ⇒ FINDING.**
 
@@ -291,13 +308,9 @@ là chặn nhầm loại.
   >
   > `/qc-design-test` §Guard 🚫 Block **tự gỡ** các dấu này khi chạy lại. Trạm này là **lưới bắt phía
   > sau** cho ca guard đó không chạy (TC sửa tay, hoặc gap được trả lời sau lần chạy trạm 3 cuối).
-- **Script:** khớp `.Test.md` 1-1? Page Object 3 lớp + BasePage gọn? `expect()` không phải bare assert? không hard-code URL/cred/timeout, không `time.sleep`, không Allure? selector theo priority (data-testid→role→…)? 100% TC đã script (không còn Draft)?
 
 Sinh findings (mức độ + vị trí + cách sửa), chấm điểm, ra verdict.
 
-**KHÔNG tự sửa** file TC hay code. Chỉ nhận xét và chấm điểm — người sửa là `/qc-design-test`
-(vai 1) hoặc `/qc-run-test` (vai 2). *Reviewer tự sửa rồi tự duyệt là bỏ mất cái cổng.*
-
 ## Output
 
 Ghi vào **`{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — đứng **cạnh** file TC vừa soát:
@@ -305,23 +318,46 @@ Ghi vào **`{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — đứng **c
 ```
 {qc_artifact_dir}test-cases/
 ├── TC_<FEATURE>.Test.md
-├── REVIEW_<FEATURE>.md            ← soát file trên
+├── REVIEW_<FEATURE>.md            ← soát file trên   (lệnh này)
 ├── TC_<FEATURE>_API.Test.md
-└── REVIEW_<FEATURE>_API.md        ← soát file trên
+└── REVIEW_<FEATURE>_API.md        ← soát file trên   (lệnh này)
 ```
 
 ⚠️ **Tên file review KHÔNG có đuôi `.Test.md`.** Đuôi đó là của file test case; gắn vào file
-review sẽ làm `/qc-run-test` nhặt nó lên như một file test case rồi cố sinh script từ một bảng điểm.
+review sẽ làm trạm sau nhặt nó lên như một file test case rồi cố sinh script từ một bảng điểm.
+
+> **Biên bản soát SCRIPT nằm ở file KHÁC** — `REVIEW_SCRIPT_<FEATURE>.md`, do `/qc-review-script`
+> ghi. Trước Đợt 2 hai vai ghi chung một file và phân biệt bằng cột `Tầng`; tách file là để hai
+> lượt soát cách nhau vài trạm **không đè lên nhau**, và để trạm sau đọc được verdict của **đúng**
+> vai nó cần.
+
+### Verdict — hợp đồng máy đọc được
+
+File **phải** chứa đúng một dòng theo khuôn này, ở §Tổng quan:
+
+```
+**Verdict:** APPROVED
+```
+hoặc
+```
+**Verdict:** REVISION_REQUIRED   ← hoặc REJECTED khi có BLOCKER
+```
+
+Verdict suy từ **số đếm lỗi**, không từ điểm — `≥1 BLOCKER` → `REJECTED` · `≥1 MAJOR` → `REVISION_REQUIRED` · chỉ MINOR/SUGGESTION → `APPROVED_WITH_SUGGESTIONS` · sạch → `APPROVED`. Xem `qa-reviewer/shared/review-file-template.md` §Verdict.
+
+> **Đây là contract, không phải định dạng cho đẹp.** `/qc-automation-assess` (Đợt 2 · b3) **loại**
+> khỏi lượt mọi TC chưa `APPROVED`. Đổi chuỗi này là làm trạm đó mù — nên nếu phải đổi, đổi ở cả
+> hai nơi trong cùng một commit.
 
 ### Chạy lại — ghi đè ở đây AN TOÀN, và đây là lý do
 
-*(Ba trạm QC khác — `/qc-analyze` · `/qc-design-test` · `/qc-run-test` — đều ở mức **chặn CỨNG** kèm
+*(Ba trạm QC khác — `/qc-analyze` · `/qc-design-test` · `/qc-design-script` — đều ở mức **chặn CỨNG** kèm
 §Chạy lại. Trạm này **không**, và đó là kết luận có chủ ý, không phải chỗ sót.)*
 
 `REVIEW_<FEATURE>.md` là **biên bản của một lần soát**. Sinh lại = **soát lại**, đúng bản chất của
 nó — không có trạng thái nào tích luỹ qua các lần chạy, không ô nào người điền tay vào sau.
 
-*Khai máy đọc: `bin/trace-schema.json` → `artifact_writers.enrolled.qc-review.has_human_content = false`
+*Khai máy đọc: `bin/trace-schema.json` → `artifact_writers.enrolled.qc-review-testcase.has_human_content = false`
 — và **R18 ép khai `why`** chính vì một ngoại lệ có chủ ý trông y hệt một chỗ sót.*
 
 > **⚠️ Khai lại nếu điều này hết đúng.** Có ai bắt đầu ghi vào biên bản thứ **không sinh lại được** —
@@ -332,14 +368,11 @@ nó — không có trạng thái nào tích luỹ qua các lần chạy, không
 > đã ở mức `hard` vì đúng lý do đó (G78). Trạm này chỉ an toàn ở phần nó **ghi**, không phải phần nó
 > **đọc**.*
 
-Khuôn đầy đủ + quy tắc ghi: `shared/review-file-template.md`. Ba điều bắt buộc:
+Khuôn đầy đủ + quy tắc ghi: `shared/review-file-template.md`. Hai điều bắt buộc:
 
-- **Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. Verdict **suy ra được**:
-  `≥80` VÀ không còn `FAIL` chặn → `APPROVED`; ngược lại `NEEDS_FIX`.
+- **Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. Verdict **suy ra được** theo luật ở trên.
 - **Bảng Tổng quan THÊM một hàng mỗi vòng**, không ghi đè — đó là cách duy nhất thấy được điểm
-  có tăng không. Các bảng chi tiết thì ghi đè phần của tầng mình.
-- **Hai vai ghi vào CÙNG một file**, phân biệt bằng cột `Tầng`. Chúng cách nhau một trạm, nên
-  hàng của vai sau **không được ghi đè** hàng của vai trước.
+  có tăng không. Các bảng chi tiết thì ghi đè phần của vòng mình.
 
 > **Vì sao cổng này phải ghi ra file** *(B13)*. Trước đây lệnh chỉ nói *"sinh findings"* — không
 > nói ghi đâu, dạng gì, và điểm là `A/B/C/D` **không có luật chấm**. Hệ quả: hai người soát ra
@@ -350,16 +383,16 @@ Khuôn đầy đủ + quy tắc ghi: `shared/review-file-template.md`. Ba điề
 
 Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md` — **không chép lại ở đây**.
 
-- **Bịa:** mỗi finding trỏ được về **dòng cụ thể** trong artifact đang soát — không phải nhận xét
+- **Bịa:** mỗi finding trỏ được về **dòng cụ thể** trong `.Test.md` đang soát — không phải nhận xét
   chung chung? Và **cấm dùng chính field `quote` của finding làm bằng chứng cho nó** — mở lại file
   đọc lại đoạn đó.
-- **Nhảy bước:** đã đi hết bộ tiêu chí của **đúng vai** (test-case hay script), không trộn hai
-  bộ? Verdict `APPROVED` phát ra **sau** khi soát đủ, không phải vì "trông ổn"?
-- **Số liệu:** số finding theo mức (critical/major/minor) = đếm thật trên file findings vừa ghi?
+- **Nhảy bước:** đã đi hết **7 nhóm kiểm tra**, không bỏ nhóm nào? Verdict `APPROVED` phát ra **sau**
+  khi soát đủ, không phải vì "trông ổn"?
+- **Số liệu:** số finding theo mức (critical/major/minor) = đếm thật trên file vừa ghi?
 
 > **Verdict của lệnh này là cổng cho trạm sau.** Một `APPROVED` phát ra sớm không chỉ sai ở đây —
-> nó mở đường cho `/qc-run-test` sinh script từ một bộ TC chưa đạt. Đây là chỗ self-review đắt
-> nhất nếu bỏ qua.
+> nó mở đường cho trạm script sinh code từ một bộ TC chưa đạt. Đây là chỗ self-review đắt nhất
+> nếu bỏ qua.
 
 ## Report
 
@@ -367,12 +400,11 @@ Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md` — *
 Output Artifacts · Next) cho report cuối, kèm khối bên dưới.
 
 ```
-/qc-review Hoàn tất — {UC-ID} ({soát test-case | soát script}) vòng #{N}
+/qc-review-testcase Hoàn tất — {UC-ID} vòng #{N}
 Điểm  : {XX}/100  ({fail} FAIL × −5đ · {warn} WARN × −2đ){nếu có vòng trước: "   ← vòng #{N-1}: {YY}/100"}
-Verdict: {APPROVED | NEEDS_FIX} — {n} findings ({crit} chặn)
+Verdict: {APPROVED | APPROVED_WITH_SUGGESTIONS | REVISION_REQUIRED | REJECTED} — {n} findings ({blk} BLOCKER · {maj} MAJOR · {min} MINOR · {sug} SUGGESTION)
 File  : {qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md (thêm 1 hàng vào bảng Tổng quan)
 Self-review: {✅ sạch | ⚠️ {n} điểm cần chú ý — liệt kê}
-Next (test-case APPROVED): /qc-run-test {UC-ID}
-Next (script APPROVED)   : /qc-report {UC-ID}  rồi tạo PR
-     (NEEDS_FIX → fix artifact bị gắn cờ, rồi chạy lại /qc-review {UC-ID})
+Next (≥ APPROVED_WITH_SUGGESTIONS) : /qc-design-script {UC-ID}
+     (REVISION_REQUIRED | REJECTED → sửa TC bị gắn cờ bằng /qc-design-test {UC-ID}, rồi chạy lại lệnh này)
 ```