@educa-corp/sdd-framework 0.9.6 → 0.9.7

package/core/commands/generate-tech-docs.md

@@ -13,6 +13,11 @@
 > của PRD (sẽ nổ context).
 
 ## Gate
+
+*Checkpoint: **chặn CỨNG** — ghi đè/mở rộng tech-doc gộp đã có. Doc chứa **§4.5.6 Test Selectors** do SA viết tay (xem `/map-testids`) và **§12 GAP Register** — cả hai không suy lại được từ BDD. `--yes` KHÔNG bỏ qua được (gate Bước 3a).*
+
+*Mức cứng chỉ áp khi trả lời **`Y`** (merge/mở rộng) cho một UC **đã có** nội dung trong doc. UC mới và **`N`** (bỏ qua UC) đi thẳng; doc chưa tồn tại cũng đi thẳng. 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ó.
@@ -92,7 +97,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ờ** |
 
@@ -100,6 +105,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ì**.
@@ -954,6 +965,35 @@ Nếu `tech_docs_dir` là **local** — tức không có `setup.spec_source` (si
 
 ## Output
 
+## Chạy lại — tech-doc gộp đã tồn tại *(mặc định MỞ RỘNG, không thay)*
+
+Doc gộp cấp PRD được viết dần theo từng UC, nên chạy lại là chuyện thường. Nhưng doc chứa hai
+phần **không suy lại được từ BDD**:
+
+| Phần | Ai tạo | Sinh lại được? |
+|---|---|:---:|
+| §1–§11 nội dung kỹ thuật của UC | lệnh này | ✅ |
+| **§4.5.6 Test Selectors** | **SA viết tay** *(đo thật: 28/28 doc dùng quy ước riêng)* | ❌ **không** |
+| **§12 GAP Register** | lệnh này, nhưng `[GAP: Gn]` đã được người xử lý | ❌ đổi là phá |
+
+**Khi một UC ĐÃ CÓ nội dung trong doc, in khối này trước khi merge** *(mức chặn CỨNG)*:
+
+```
+❌ UC{N} đã có nội dung trong: {tech-doc-path}
+   Hiện: @trace.revision {r} · @trace.status {status} · §4.5.6 có {n} row
+
+   Merge/mở rộng UC này có thể đụng:
+     • §4.5.6 Test Selectors — SA viết tay, /map-testids đã phải chặn CỨNG vì chính bảng này
+     • §12 GAP Register — mã [GAP: Gn] đang được /qc-analyze tham chiếu
+     • @trace.bdd_versions — hạ sai là cờ TECHDOC_STALE_VS_BDD tắt nhầm
+
+   Chỉ muốn thêm UC mới        → chọn N cho UC này, Y cho UC mới
+   §4.5.6 cần đổi thật          → /map-testids {UC-ID} (lệnh sở hữu bảng đó)
+   Doc lệch BDD, muốn soát lại  → /review-tech-docs {path}
+```
+
+> **UC MỚI (chưa có trong doc) đi thẳng, không chặn** — thêm section mới không đụng gì của ai.
+
 **Đọ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.
 

package/core/commands/learn.md

@@ -91,7 +91,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ờ** |
 
@@ -99,6 +99,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ì**.

package/core/commands/map-testids.md

@@ -33,7 +33,7 @@ patch, mọi element đều là `new`. Chỉ chạy Step 1 → 2 → 5.
 > **Cửa vào làn QC là `/qc-analyze`, KHÔNG phải `/qc-design-test`.** Trạm 3 tiêu thụ output của
 > trạm 1–2 (`REQUIREMENT_ANALYSIS.md` · `DOC_GAP.md` · `TEST_PLAN.md`); trỏ thẳng vào nó là chỉ
 > người ta nhảy vào giữa dây chuyền. Cả ba trạm đầu **không cần code**, nên nhánh QC vẫn song song
-> trọn vẹn với `/generate-code` — chỉ trạm 5 `/qc-run-test` mới cần code chạy được.
+> trọn vẹn với `/generate-code` — chỉ trạm 5 `/qc-design-script` mới cần code chạy được.
 >
 > Hai nhánh **không chờ nhau** vì cùng đọc một bản đã đóng băng, không đọc output của nhau.
 > Chạy sau code thì QC phải xếp hàng, và `/generate-code` không có gì để đọc nên sẽ tự sinh id
@@ -124,7 +124,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ờ** |
 
@@ -132,6 +132,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ì**.
@@ -301,7 +307,7 @@ Tạo hoặc cập nhật §4.5.6 (block platform tương ứng) trong tech-doc
   - **(b) Bảng.** Cập nhật bảng §4.5.6 của platform này (thêm block §4.5 cho platform nếu chưa có).
 - Nếu **chưa** tồn tại (pure brownfield) → ghi một file tối thiểu: header `@trace` (gồm `@trace.testid_attr`) + §4.5.6. `/generate-tech-docs` điền các section còn lại sau; nó không được ghi đè các id §4.5.6 mà lệnh này đã ghi.
 
-> **Vì sao (a) lệch thì DỪNG chứ không ghi đè.** `@trace.testid_attr` là *tên thuộc tính* mà **mọi** locator QC của PRD này bám vào (`/qc-run-test` đọc nó để cấu hình `get_by_test_id`). Ghi đè sai một lần là làm **trượt toàn bộ** script của PRD — và test sẽ đỏ với `element not found`, trông y hệt một bug sản phẩm, nên QC đi mở bug thay vì sửa selector. Lệch nghĩa là một trong hai đang sai: FE vừa đổi convention, hoặc `active_module` khai sai. Cả hai đều cần người nhìn, không đoán được từ đây.
+> **Vì sao (a) lệch thì DỪNG chứ không ghi đè.** `@trace.testid_attr` là *tên thuộc tính* mà **mọi** locator QC của PRD này bám vào (`/qc-design-script` đọc nó để cấu hình `get_by_test_id`). Ghi đè sai một lần là làm **trượt toàn bộ** script của PRD — và test sẽ đỏ với `element not found`, trông y hệt một bug sản phẩm, nên QC đi mở bug thay vì sửa selector. Lệch nghĩa là một trong hai đang sai: FE vừa đổi convention, hoặc `active_module` khai sai. Cả hai đều cần người nhìn, không đoán được từ đây.
 
 Mỗi row — **5 cột, đúng thứ tự của template** (`templates/tech-design.template.md` §4.5.6):
 
@@ -365,8 +371,8 @@ In ra ở report:
    Chạy /qc-design-test lại cho các UC đó.
 ```
 
-> **Chỉ `/qc-design-test`, KHÔNG phải "hoặc `/qc-run-test`"** *(G64 — lời nhắc cũ chỉ sai đường)*.
-> `/qc-run-test` dựng locator từ §4.5.6 **tươi** nên phần locator nó tự cứu — nhưng nó **không sửa**
+> **Chỉ `/qc-design-test`, KHÔNG phải "hoặc `/qc-design-script`"** *(G64 — lời nhắc cũ chỉ sai đường)*.
+> `/qc-design-script` dựng locator từ §4.5.6 **tươi** nên phần locator nó tự cứu — nhưng nó **không sửa**
 > id cũ đã nằm trong `.Test.md`. Ai chọn vế đó sẽ thấy test xanh trở lại và tưởng xong, trong khi tài
 > liệu test vẫn mô tả một element không còn mang id đó.
 

package/core/commands/propose-scenario.md

@@ -90,7 +90,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ờ** |
 
@@ -98,6 +98,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ì**.

package/core/commands/qc-analyze.md

@@ -6,7 +6,7 @@ ported_from: ai-automation-qc-base
 
 # /qc-analyze — QC Requirement Analysis
 
-> Stage 1 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review → qc-run-test → qc-report). Port từ qa-analyst của team QC. Markdown-first: không có script ở đây.
+> Stage 1 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review-testcase → qc-design-script → qc-review-script → qc-run-script → qc-report). Port từ qa-analyst của team QC. Markdown-first: không có script ở đây.
 
 ## Gate
 
@@ -93,7 +93,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ờ** |
 
@@ -101,6 +101,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ì**.
@@ -278,7 +284,7 @@ ngược về `{id}` của §12 để không đếm hai lần.
 Bạn là **QC Analyst** — stage đầu tiên của QC automation pipeline. Lấy requirement
 chính thức (PRD + BDD `.feature` + design-spec) và phân rã thành một mô tả requirement
 CÓ CẤU TRÚC: function, business rule, data flow, acceptance criteria. Bạn **không**
-viết test case chi tiết hay Python (đó là qc-design-test / qc-run-test).
+viết test case chi tiết hay Python (đó là qc-design-test / qc-design-script).
 
 Ranh giới với `/qc-plan`: bạn trả lời *"requirement là gì?"*; qc-plan trả lời *"rủi ro ở đâu,
 hỏi dev gì?"*. Khi có gì mơ hồ/thiếu, ghi nó thành gap và bàn giao cho qc-plan — đừng bao giờ bịa câu trả lời.
@@ -298,7 +304,7 @@ Thứ tự điển hình: spec-breakdown → business-rules / data-flow → acce
 File `.feature` chính thức đã định nghĩa scenario là `@trace.scenario={UC-ID}-SC{N}` với
 `@trace.business_rules`. Map mọi `BR-xx` / `AC-xx` bạn tạo ra tới `{UC-ID}-SC{N}` sở hữu nó
 và ghi lại mapping — **làm cho từng UC trong `uc_list`**, và `BR`/`AC` phải mang rõ UC của nó
-(một file phân tích giờ phủ nhiều UC, nên `BR-01` không còn tự phân biệt được là của UC nào) — qc-design-test và qc-run-test cần nó để gắn tag
+(một file phân tích giờ phủ nhiều UC, nên `BR-01` không còn tự phân biệt được là của UC nào) — qc-design-test và qc-design-script cần nó để gắn tag
 `@trace.verifies` cho test và ghi `qc_status` theo từng scenario.
 
 ## Guard — BR-tag *(phép so khớp cơ học, chạy SAU khi ghi file, TRƯỚC CHECKPOINT)*
@@ -347,7 +353,7 @@ tại — và không ai phát hiện được khi nó chết.
 > chạy như nhau mỗi lần.
 >
 > **Vì sao bỏ sót ở đây đắt nhất trong cả pipeline.** Không có `BR` → `/qc-plan` không xếp rủi ro
-> cho nó → `/qc-design-test` không viết test case → `/qc-run-test` không có gì chạy → báo cáo
+> cho nó → `/qc-design-test` không viết test case → `/qc-run-script` không có gì chạy → báo cáo
 > cuối nói *"coverage 100%"*. Con số đó tính trên mẫu số *"số scenario đã biết"*, không phải
 > *"số rule cần phủ"* — nên nó sai theo hướng nguy hiểm nhất: trông như đã xong.
 
@@ -547,7 +553,7 @@ một-file-mỗi-bước (không có file spec-breakdown / business-rules / data
    - Section **"Tài liệu đầu vào đã đọc để phân tích"** đặt ngay sau metadata — liệt kê **đủ** mọi
      file đã mở. Đây là căn cứ độ phủ: không có nó thì không ai phân biệt được *"đã đọc và không thấy"*
      với *"chưa đọc"*.
-   - Mức nặng nhất dùng từ **`🔴 Blocker`** (không phải `Critical`) — `/qc-run-test` đọc đúng từ này
+   - Mức nặng nhất dùng từ **`🔴 Blocker`** (không phải `Critical`) — `/qc-run-script` đọc đúng từ này
      để đặt *"scenario đang chờ PO"* vào sổ trace.
 3. **`{paths.refinement_dir}/{TICKET-ID}-qa-findings.yaml`** — **cùng dữ liệu gap**, ở định dạng Review Board đọc được. Xem §Bản findings dưới đây.
 

package/core/commands/qc-automation-assess.md

@@ -0,0 +1,356 @@
+---
+version: 1.0
+updated: 2026-09-16
+ported_from: ai-automation-qc-base
+---
+
+# /qc-automation-assess — Quyết định "cái nào máy chạy, cái nào phải tay"
+
+> Chạy **sau** `/qc-review-testcase` (chỉ nhận TC `APPROVED`) và **trước** `/qc-design-script`.
+> Ghi `AUTOMATION_ASSESSMENT.md` — bảng quyết định `Automatable: Y/N` kèm lý do chuẩn hoá, và là
+> **nguồn duy nhất** cho ba trạm sau.
+
+## Gate
+
+*Checkpoint: **chặn CỨNG** — ghi đè `AUTOMATION_ASSESSMENT.md` đã có → mất quyết định `Y/N` + nhãn lý do đã chốt, và XOÁ cột `Script file` do `/qc-design-script` điền (chỉ mục ngược duy nhất TC → file code). `--yes` KHÔNG bỏ qua được (gate Bước 3a).*
+
+*Mức cứng chỉ áp khi `AUTOMATION_ASSESSMENT.md` **đã tồn tại**. Lần đánh giá đầu không ghi đè gì, đi thẳng. 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 **TICKET-ID** (cả PRD) — khác `/qc-review-testcase` chạy theo UC-ID. `active_platform` + `qc_artifact_dir` do §Phạm vi QC phân giải.*
+
+## 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.
+
+---
+
+## Stamp phiên bản nguồn
+
+**BẮT BUỘC — đọc `.agent/steps/qc-stamp.md` và thực thi phần áp cho lệnh này**,
+rồi mới tiếp tục phần bên dưới.
+
+Nó có **hai vế**: §1 **ghi** khối `Nguồn & phiên bản` vào artifact lệnh này sinh ra ·
+§2 **so** stamp của artifact lệnh này ĐỌC với version hiện tại của spec.
+Bỏ vế ghi thì trạm sau không có gì để so; bỏ vế so thì stamp thành một con số không ai
+đọc — và một bộ TC lỗi thời sẽ chạy xanh rồi ghi `pass` **hợp lệ theo mọi phép kiểm**.
+
+---
+
+## Vì sao trạm này tồn tại
+
+Framework trước đây **ngầm định mọi test case đều automate được**: `/qc-run-test` nhận `.Test.md`
+rồi sinh script cho **tất cả**. Nhưng luôn có TC không nên hoặc không thể automate — OTP qua SMS,
+captcha, in ra máy in thật, màn hình đang redesign hàng tuần. Chúng vẫn bị sinh script, rồi
+`skip("lý do")`. Ba hệ quả:
+
+1. **Quyết định không được ghi lại.** Sáu tháng sau không ai biết TC đó skip vì *không automate
+   được* hay vì *quên*.
+2. **Không có số liệu.** Câu *"automation phủ bao nhiêu %?"* không trả lời được, vì mẫu số lẫn cả
+   TC không bao giờ định automate.
+3. **TC không automate được BIẾN MẤT khỏi tầm nhìn** — nằm trong file test case, có dòng `skip`,
+   và **không ai chạy tay nó cả**.
+
+Điểm 3 là nửa còn lại của lỗ hổng mà `/qc-run-manualtest` bịt: lệnh đó biết *cách* ghi kết quả
+chạy tay, còn trạm này cho nó biết **chạy tay những gì**.
+
+## Tiền điều kiện — chỉ nhận TC đã `APPROVED`
+
+Với mỗi UC của PRD, đọc `{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md` → dòng `**Verdict:**`.
+
+| Đọc được | Làm gì |
+|---|---|
+| `APPROVED` | đưa TC của UC đó vào lượt đánh giá |
+| `NEEDS_FIX` · không có file | **LOẠI khỏi lượt** — và **liệt kê ra trong report** kèm trạng thái thật |
+
+> **`%Automated/Total` tính trên mẫu số CHỈ GỒM TC đã đánh giá**, và in kèm số TC bị loại. Để
+> không ai đọc *"100%"* mà tưởng đã phủ cả PRD.
+>
+> Nguyên tắc: ***"chưa xét" khác "đã xét, sạch"*** — cùng tinh thần bảng phạm vi của
+> `steps/qc-scope.md`.
+
+## Skills
+
+Nạp **`{paths.qc_skills_dir}/qa-automation-assess/matrix.md`** — 6 tiêu chí đánh giá (trả lời
+tuần tự, dừng ở câu đầu tiên là "Có"), công thức ROI, bảng tín hiệu ổn định, 5 nhãn lý do chuẩn.
+**Không chép lại luật ở đây.**
+
+## Guard — Re-assessment tự động theo `DRIFT`
+
+Trước khi đánh giá, quét cột `status` trong sổ trace `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}-{active_platform}.tsv`.
+
+Với TC **đã có dòng** trong `AUTOMATION_ASSESSMENT.md` từ lượt trước mà scenario nó verify đang
+`DRIFT`:
+
+- gắn cờ **`🔄 Re-assess`** — quyết định `Y/N` cũ **không còn đáng tin**;
+- đánh giá lại **ngay trong lượt này** — không cần lịch định kỳ, không cần ai nhắc;
+- `Y → N` *(đã có script, giờ không nên automate nữa)*: **GIỮ** path cũ trong cột `Script file` +
+  ghi chú `⚠️ Script đã lỗi thời — cân nhắc gỡ ở lần /qc-design-script kế tiếp`. **KHÔNG tự xoá
+  file** — để người quyết định;
+- `N → Y`: cột vẫn `—`, chờ `/qc-design-script`.
+
+## Output
+
+Ghi **`{qc_artifact_dir}AUTOMATION_ASSESSMENT.md`** — cấp PRD, cùng chỗ `TEST_PLAN.md`. Khuôn đầy
+đủ ở `matrix.md` §Output format:
+
+| TC ID | UC | Automatable | Lý do (nếu N) | Trace SC | Script file | Ghi chú |
+|---|---|:---:|---|---|---|---|
+| `TC_LOGIN_001` | UC1 | Y | — | UC1-SC1 | `—` *(chưa qua qc-design-script)* | |
+| `TC_LOGIN_004` | UC1 | N | `Cần OTP/captcha thủ công` | UC1-SC4 | `—` *(không automate)* | Giữ trong bộ manual |
+
+Cột `Script file` **luôn khởi tạo `—`** ở lượt này — script chưa tồn tại.
+
+### `Automatable` sống ở ĐÚNG MỘT chỗ
+
+Quyết định này **KHÔNG** được chép vào `.Test.md`. Hai nơi ghi cùng một quyết định thì một nơi
+sẽ lệch, và lúc đó không ai biết nơi nào đúng — đúng lớp lỗi mà `R19` sinh ra để chặn.
+
+`skills/qc/qa-designer/shared/tc-metadata-format.md` chỉ **trỏ sang** file này, không chép giá trị.
+
+### Ba trạm tiêu thụ file này
+
+```
+/qc-design-script    → lọc Automatable: Y, chỉ sinh script cho chúng; rồi ĐIỀN cột Script file
+/qc-run-script       → ĐỌC cột Script file để biết chạy file nào — KHÔNG tự suy path
+/qc-run-manualtest   → lọc Automatable: N để biết phải hỏi những TC nào
+```
+
+> **Không có file này thì cả ba đứt cùng lúc**, và mắt xích thứ hai hỏng im lặng nhất:
+> `/qc-run-script` suy sai đường dẫn thì **chạy 0 test mà vẫn báo xanh**, rồi con số đó đi thẳng
+> vào `/qc-report` thành số liệu người ta tin.
+
+### Cảnh báo riêng — `P0` mà `Automatable: N`
+
+```
+⚠️ {k} TC Priority P0 không automate được: {danh sách + nhãn lý do}
+   Tính năng lõi không có smoke test tự động là rủi ro cho mục tiêu "phát hiện lỗi sớm mỗi build".
+   Cân nhắc IMPROVE-xxx để gỡ rào cản thay vì chấp nhận N vĩnh viễn.
+```
+
+## Chạy lại — `AUTOMATION_ASSESSMENT.md` đã tồn tại *(GIỮ quyết định, chỉ re-assess phần DRIFT)*
+
+Chạy lại trạm này là chuyện bình thường: TC mới thêm thì phải đánh giá. Nhưng file có **hai phần
+khác hẳn nhau**, và chỉ một phần sinh lại được:
+
+| Phần | Ai tạo | Sinh lại được? |
+|---|---|:---:|
+| Hàng TC · cột `Trace SC` | lệnh này | ✅ |
+| **Quyết định `Y/N` + nhãn lý do** | lệnh này, nhưng **người chốt/sửa lại** sau khi cân nhắc ROI | ❌ |
+| **Cột `Script file`** | **`/qc-design-script`** điền | ❌ ghi đè là mất chỉ mục ngược |
+
+**Đọc file cũ TRƯỚC khi ghi.** Với mỗi TC:
+
+| Tình huống | Xử lý |
+|---|---|
+| TC cũ, scenario **không** `DRIFT` | **GIỮ NGUYÊN** `Automatable` · nhãn lý do · `Script file` · ghi chú |
+| TC cũ, scenario **`DRIFT`** | gắn `🔄 Re-assess`, đánh giá lại 6 tiêu chí; xử cột `Script file` theo bảng ở §Guard |
+| TC **mới** | đánh giá mới, `Script file` = `—` |
+| TC cũ **không còn** trong `.Test.md` | **KHÔNG xoá hàng.** Ghi chú `⚠️ TC không còn trong .Test.md — kiểm xem đã bị gỡ có chủ ý chưa` |
+
+*Khai máy đọc: `bin/trace-schema.json` → `artifact_writers.enrolled.qc-automation-assess`.*
+
+> **Vì sao trạm này chặn CỨNG trong khi `/qc-review-testcase` thì không.** Biên bản soát là
+> **kết quả của một lượt đọc** — soát lại là đúng bản chất. Bảng này thì khác: nó là **quyết định
+> tích luỹ**, và một nửa của nó (`Script file`) do **lệnh khác** điền. Ghi đè là xoá công của hai
+> bên cùng lúc.
+
+## Self-Review *(trước khi in Report)*
+
+Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md`.
+
+- **Bịa:** mỗi `N` có nhãn lý do **từ danh sách chuẩn** (hoặc nhãn mới được khai ra), không phải
+  câu chung chung như *"lý do kỹ thuật"*?
+- **Nhảy bước:** đã đi hết 6 tiêu chí theo thứ tự cho từng TC, không nhảy sang kết luận?
+- **Số liệu:** `%Automated` là **phép chia thật** trên số hàng bảng, và mẫu số **không** gồm TC
+  bị loại vì UC chưa `APPROVED`?
+
+## 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-automation-assess Hoàn tất — {TICKET-ID} ({active_platform})
+Đánh giá: {n} TC   ({k} TC bị loại — UC chưa APPROVED: {danh sách})
+Kết quả : Y {a} · N {b}   → %Automated/Total: {a}/{n} = {pct}%
+Nhãn N  : {nhãn: số lượng, sắp giảm dần}
+Re-assess: {r} TC gắn 🔄 (DRIFT)   — đổi quyết định: {đ}
+⚠️ P0 + N: {p} TC   {danh sách nếu p > 0}
+File    : {qc_artifact_dir}AUTOMATION_ASSESSMENT.md
+Self-review: {✅ sạch | ⚠️ {n} điểm cần chú ý}
+Next    : /qc-design-script {TICKET-ID}   (TC Automatable: Y)
+          /qc-run-manualtest {UC-ID}      (TC Automatable: N)
+```