@educa-corp/sdd-framework 0.9.3 → 0.9.5

package/docs/04-reference/commands.md

@@ -74,7 +74,7 @@ Mọi lệnh chạy chung một **Gate** (model check → target → context-loa
 | `/generate-code` | `.feature` approved + tech-design | Code + `.trace/*.tsv` | Dev |
 | `/review-code` | Code | Findings (read-only) | Dev/Lead |
 | `/fix-bug` | Bug report | Fix + regression test | Dev |
-| `/map-testids` | UI code | testid map (FE) | Dev |
+| `/map-testids` | design-spec + BDD (`--from-code`: + UI code) | §4.5.6 Test Selectors + `@trace.testid_attr` | Người viết tech-doc (`--from-code`: Dev) |
 | `/debug` | Mô tả lỗi | Phân tích (read-only) | Dev |
 
 ## 7 · Dev self-test

package/docs/04-reference/trace-schema.md

@@ -94,6 +94,44 @@ public ScoreDto calculate(...) { }
 | `@trace.revision` | integer, bump mỗi lần sửa — nguồn của `TECHDOC_DRIFT` |
 | `@trace.status` | `draft` / `in-review` / `approved` — cổng của `/generate-code` DS3 |
 | `@trace.api_source` | `existing` → chế độ reverse-document, bỏ cổng T7 |
+| `@trace.testid_attr` | **TÊN THUỘC TÍNH** chứa test-id (`data-testid` · `data-test` · `testID` · `ValueKey`…) — **một** giá trị cho cả doc. Khác **GIÁ TRỊ** test-id từng element, cái đó ở §4.5.6. Ghi bởi `/map-testids`; đọc bởi `/generate-code` (emit lên element) và các lệnh `qc-*` (cấu hình locator). |
+
+### Hợp đồng test-id — được máy canh (`testid_contract`)
+
+Bảng **§4.5.6 Test Selectors** trong tech-doc là hợp đồng FE↔QC: **3 lệnh đọc**
+(`generate-code`, `qc-run-test`, `qc-design-test`), **2 lệnh ghi** (`generate-tech-docs`,
+`map-testids`). Hai rule của `lint-trace` canh nó:
+
+| Rule | Kiểm gì | Mức |
+|---|---|:---:|
+| **T15** | Mọi SC ở cột *"Phục vụ SC"* phải có thật trong `.feature` của nền đó | 🔴 error |
+| **T16** | Có block §4.5 (nền client) mà header thiếu hẳn `@trace.testid_attr` | 🔴 error |
+| | …có nhưng còn ở dạng placeholder `{…}` (chưa chạy `/map-testids`) | ⚠️ warn |
+| **T17** | Id đã khai ở §4.5.6 mà **không có trong code** — FE chưa gắn / gắn sai / element đã đổi *(cần `--code`)* | ⚠️ warn |
+| **T18** | Id nằm trong code mà **không có trong §4.5.6 nào** — gắn ngoài hợp đồng *(cần `--code`)* | ⚠️ warn |
+
+> **T17/T18 là WARN, không ERROR.** Id đoán từ thiết kế không sống sót 100%: lúc implement, dev
+> có thể gộp hai element thành một component hoặc tách một thành hai. Đây là **nợ cần thấy**,
+> không phải cái sai chặn người.
+>
+> T18 là **lưới bắt phía sau** cho quyết định ở `/generate-code`: khi §4.5.6 rỗng, lệnh đó cảnh
+> báo rồi **để người quyết** thay vì chặn cứng — chính vì có T18 bắt những id tạm sinh ra ở đó,
+> nên "vẫn sinh" không tạo nợ vô hình.
+>
+> Thiếu `--code` → in `T17/T18 BỎ QUA` tường minh, **không im lặng báo sạch**. Code chưa có id
+> nào của thuộc tính đó (UI chưa viết) → im lặng, không phán "FE chưa gắn" cho cả bảng.
+
+> **Phạm vi neo vào sự tồn tại của hợp đồng.** Doc không có §4.5 client → **không kiểm gì**.
+> Dự án backend-only, hay dự án chưa từng chạy `/map-testids`, im lặng hoàn toàn. Hai rule nói
+> *"chỗ nào đã hứa thì phải giữ"*, không nói *"mọi chỗ đều phải có hợp đồng"*. Dòng mẫu của
+> template (còn `{…}`) cũng được bỏ qua — nếu không thì tech-doc vừa sinh ra đã đỏ.
+>
+> **Không vào `gate.blocking`** — đây là nợ cần thấy, không phải cái sai chặn PR. Cùng nhóm với
+> `TECHDOC_DRIFT` / `BDD_DRIFT`; 13/17 cờ audit hiện tại cũng không chặn.
+
+Khối `testid_contract` trong `bin/trace-schema.json` khai hai rule này kèm `why`, và
+`self-check` **R8e** báo lỗi nếu `lint-trace.js` không thực sự phát ra chúng — nửa *"máy canh"*
+của luật *"khai tường minh + để máy canh"*.
 
 ---
 
@@ -240,7 +278,7 @@ Ca thứ hai là lý do consumer **phải** chuẩn hoá tập bị ảnh hưở
 
 ## Xuất JSON cho panel
 
-`trace-report.json` giữ enum `status` **đúng 4 giá trị** `OK`/`DRIFT`/`GAP`/`UNTRACKED` — VS Code extension "Spec Driven Docs Tools" sống ngoài repo framework và switch trên field này. Row `ORPHANED` xuất ra là `"status": "DRIFT"` + `"orphaned": true`; panel cũ hiện nó như DRIFT (đúng nghĩa, không im lặng), panel mới đọc `orphaned` để hiện nhãn riêng. **TSV giữ nguyên chữ `ORPHANED`** — TSV là nguồn-sự-thật.
+`trace-report.json` giữ enum `status` **đúng 4 giá trị** `OK`/`DRIFT`/`GAP`/`UNTRACKED` — VS Code extension "SDD Board" sống ngoài repo framework và switch trên field này. Row `ORPHANED` xuất ra là `"status": "DRIFT"` + `"orphaned": true`; panel cũ hiện nó như DRIFT (đúng nghĩa, không im lặng), panel mới đọc `orphaned` để hiện nhãn riêng. **TSV giữ nguyên chữ `ORPHANED`** — TSV là nguồn-sự-thật.
 
 ---
 

package/docs/explain/00-setup-ai-first.md

@@ -44,7 +44,7 @@ Mọi command sau đều đọc `project-context.yaml` + `CLAUDE.md` + `domain-k
 5. **Step 3 · project-context.yaml** — copy từ `templates/project-context.yaml`, điền `{{PLACEHOLDER}}`. Umbrella: verify/sửa `services` (path phải khớp tên submodule thật — generator để placeholder `TODO-…`).
 6. **Step 4 · business-dictionary.md** — Canonical Terms / Banned Terms / Enum Registry. *(Umbrella skip — sống trong spec submodule.)*
 7. **Step 5 · core-entities.md** — entity catalog máy-đọc-được (field, invariant, relationship). *(Umbrella skip.)*
-8. **Step 6 · VS Code extension** — khuyến nghị cài "Spec Driven Docs Tools" (Review Board + Living Docs UI).
+8. **Step 6 · VS Code extension** — khuyến nghị cài "SDD Board" (Review Board + Living Docs UI).
 9. **Step 7 · Verify** — checklist theo `project_type` (file/folder tồn tại; umbrella check submodule init).
 
 ---

package/docs/explain/11-map-testids.md

@@ -1,69 +1,70 @@
-[← /review-code](10-review-code.md) · [Explain Home](README.md) · [Next: /dev-gen-test →](12-dev-gen-test.md)
-
-# 11 · `/map-testids` — Dán test-id ổn định cho UI (FE)
-
-> **Một câu.** Gắn **test-id ổn định** vào các element có hành động trên UI FE và ghi bản đồ selector vào tech-doc §4.5.6 — làm cầu nối để QC Playwright bám selector không vỡ.
-
----
-
-## Vấn đề giải quyết
-
-Test tự động (Playwright) vỡ khi selector đổi (class/text thay đổi). `/map-testids` chuẩn hoá **test-id ổn định** cho mọi element tương tác, đảm bảo component tái dùng forward được test-id, và ghi map để QC dùng — tách concern "làm UI test được" khỏi "viết test".
-
----
-
-## Vị trí & tiền đề
-
-- **Vị trí:** Phase Tech Design / Implementation (FE), giữa code FE và QC.
-- **Chặn cứng:** chỉ FE/App (platform guard) — BE không có UI.
-
----
-
-## Input / Output
-
-**Input:** UI code FE (element có action) + catalog component tái dùng + tech-doc §4.5.
-
-**Output:** code FE được patch test-id + map §4.5.6 Test Selectors trong tech-doc.
-
----
-
-## Các bước xử lý (chi tiết)
-
-| Step | Việc |
-|------|------|
-| **0 · Platform guard** | Chỉ FE/App; else STOP |
-| **1 · Thu thập element có action** | Quét UI tìm element người dùng tương tác (nút, ô nhập, link…) |
-| **2 · Phân giải test-id ổn định** | Đặt test-id ổn định (không phụ thuộc text/class dễ đổi) cho mỗi element |
-| **3 · Đảm bảo component tái dùng forward test-id** | Component dùng lại (catalog) phải cho phép truyền test-id xuống — sửa component nếu chưa |
-| **4 · Patch usage site** (chỉ EXTEND) | Gắn test-id vào nơi dùng, chỉ thêm (không viết đè) |
-| **5 · Ghi/làm mới map §4.5.6** | Ghi bảng Test Selectors vào tech-doc để QC bám |
-| **6 · Handoff** | Bàn giao cho QC (`/qc-*`) |
-
----
-
-## Checkpoint & Gate
-
-- Không gate chặn; EXTEND-only khi patch (an toàn).
-
----
-
-## Cơ chế đặc biệt
-
-- **Test-id ổn định** — chống test vỡ do đổi visual; nguyên tắc "selector là contract QC↔FE".
-- **Forward test-id qua component tái dùng** — sửa gốc component để test-id lan xuống, không hardcode từng chỗ.
-- **Map ở §4.5.6 tech-doc** — QC đọc từ một nguồn, không tự dò.
-
----
-
-## 👓 Góc nhìn tối ưu
-
-- **Lệnh cầu nối FE→QC** — vị trí pipeline hơi mờ (giữa Tech Design & Code). Chạy sớm quá thì UI chưa xong, muộn quá thì QC phải chờ. Đáng làm rõ thời điểm tối ưu.
-- **Phụ thuộc catalog component tái dùng** — nếu component không forward được prop test-id, Step 3 phát sinh sửa lan rộng.
-- **EXTEND-only** an toàn nhưng nếu test-id cũ sai thì không tự sửa.
-- **Không bắt buộc trong golden path** — dễ bị bỏ qua, khiến QC selector giòn. Cân nhắc tích hợp vào `/generate-code --phase=ui`.
-
----
-
-## Kết nối
-
-**Trước:** [`/generate-code`](09-generate-code.md) (UI FE) · **Sau:** [`/qc-*`](15-qc-analyze.md) dùng selector đã map.
+[← /review-code](10-review-code.md) · [Explain Home](README.md) · [Next: /dev-gen-test →](12-dev-gen-test.md)
+
+# 11 · `/map-testids` — Dán test-id ổn định cho UI (FE)
+
+> **Một câu.** Gắn **test-id ổn định** vào các element có hành động trên UI FE và ghi bản đồ selector vào tech-doc §4.5.6 — làm cầu nối để QC Playwright bám selector không vỡ.
+
+---
+
+## Vấn đề giải quyết
+
+Test tự động (Playwright) vỡ khi selector đổi (class/text thay đổi). `/map-testids` chuẩn hoá **test-id ổn định** cho mọi element tương tác, đảm bảo component tái dùng forward được test-id, và ghi map để QC dùng — tách concern "làm UI test được" khỏi "viết test".
+
+---
+
+## Vị trí & tiền đề
+
+- **Vị trí:** Phase **Tech Design**, sau `/generate-tech-docs` và **TRƯỚC** `/review-tech-docs` — tức trước cả `/generate-code`. Chốt hợp đồng test-id ở đây để FE và QC đọc cùng một bản đã đóng băng rồi **chạy song song**.
+- **Hai chế độ:** mặc định (feature mới — nguồn là design-spec + BDD, **không đụng code**) · `--from-code` (brownfield — đọc/patch code đã có, chạy một lần mỗi UC cũ).
+- **Chặn cứng:** chỉ FE/App (platform guard) — BE không có UI.
+
+---
+
+## Input / Output
+
+**Input:** design-spec (Component Inventory, màn hình) + step `When` của `.feature` FE + tech-doc §4.5.1 (cây component) + catalog component tái dùng. *Chế độ `--from-code` đọc thêm UI code FE.*
+
+**Output:** map §4.5.6 Test Selectors + `@trace.testid_attr` ở header tech-doc. *Chế độ `--from-code` còn patch test-id vào code FE.*
+
+---
+
+## Các bước xử lý (chi tiết)
+
+| Step | Việc |
+|------|------|
+| **0 · Platform guard** | Chỉ FE/App; else STOP |
+| **1 · Thu thập element có action** | Quét UI tìm element người dùng tương tác (nút, ô nhập, link…) |
+| **2 · Phân giải test-id ổn định** | Đặt test-id ổn định (không phụ thuộc text/class dễ đổi) cho mỗi element |
+| **3 · Đảm bảo component tái dùng forward test-id** | Component dùng lại (catalog) phải cho phép truyền test-id xuống — sửa component nếu chưa |
+| **4 · Patch usage site** (chỉ EXTEND) | Gắn test-id vào nơi dùng, chỉ thêm (không viết đè) |
+| **5 · Ghi/làm mới map §4.5.6** | Ghi bảng Test Selectors vào tech-doc để QC bám |
+| **6 · Handoff** | Bàn giao cho QC (`/qc-*`) |
+
+---
+
+## Checkpoint & Gate
+
+- Không gate chặn; EXTEND-only khi patch (an toàn).
+
+---
+
+## Cơ chế đặc biệt
+
+- **Test-id ổn định** — chống test vỡ do đổi visual; nguyên tắc "selector là contract QC↔FE".
+- **Forward test-id qua component tái dùng** — sửa gốc component để test-id lan xuống, không hardcode từng chỗ.
+- **Map ở §4.5.6 tech-doc** — QC đọc từ một nguồn, không tự dò.
+
+---
+
+## 👓 Góc nhìn tối ưu
+
+- **Lệnh chốt hợp đồng FE↔QC** — vị trí **đã được chốt**: phase Tech Design, trước `/generate-code`. Trước đây vị trí mờ (tài liệu này từng nói 'giữa Tech Design & Code') nên lệnh hay bị bỏ qua; giờ `/generate-tech-docs` trỏ thẳng sang đây, và `/review-tech-docs` T6 không cho APPROVED nếu §4.5.6 rỗng.
+- **Phụ thuộc catalog component tái dùng** — nếu component không forward được prop test-id, Step 3 phát sinh sửa lan rộng.
+- **EXTEND-only** an toàn nhưng nếu test-id cũ sai thì không tự sửa.
+- **Đã vào golden path** — `/generate-tech-docs` → **`/map-testids`** → `/review-tech-docs` (T6 chặn nếu §4.5.6 rỗng). `lint-trace` T15/T16 canh bảng, T17/T18 canh bảng-vs-code.
+
+---
+
+## Kết nối
+
+**Trước:** [`/generate-tech-docs`](08-generate-tech-docs.md) · **Sau:** [`/review-tech-docs`](07-review-tech-docs.md), rồi rẽ hai nhánh song song — [`/generate-code`](09-generate-code.md) (FE gắn attribute) ∥ [`/qc-design-test`](17-qc-design-test.md) (QC dựng test theo cùng hợp đồng).

package/docs/plans/qc-implementation-log.md

@@ -1512,6 +1512,148 @@ xem bản mới có bắt thêm gap thật hay không.
 
 ---
 
+# ✅ B12 — Rà trạm viết kịch bản kiểm thử theo bản gốc
+
+Đi theo đúng thứ tự dây chuyền: xong trạm 1 và 2 (B11) thì tới trạm 3 — **trạm quyết định có
+test hay không có test**.
+
+## Hai điều rà ra
+
+**① Trạm này chưa hề được đụng trong cả đợt merge.** Bản đồ port ghi **21/21 file gốc ở trạng
+thái "chưa quyết"**. 11 kỹ năng đang chạy đến từ **một nguồn khác** (`lms_autotest`), không phải
+từ đội QC.
+
+| | File | Dòng |
+|---|---|---|
+| Bản gốc đội QC | 21 | **2.509** |
+| Framework | 11 | **496** *(~20%)* |
+
+**② Một lỗi im lặng, cùng lớp với `DOC_GAPS` / `DOC_GAP`:**
+
+| Ai | Nói tên file là |
+|---|---|
+| 2 kỹ năng | `TC_<FEATURE>.md` |
+| 1 kỹ năng | `TC_<FEATURE>_API.md` |
+| **4 kỹ năng** | **không nêu tên gì cả** |
+| Lệnh thiết kế · lệnh chạy · lệnh soát · module Playwright *(13 chỗ)* | `*.Test.md` |
+
+**Trạm thiết kế ghi ra thứ trạm chạy không tìm thấy.** Và không có gì báo lỗi — file vẫn nằm
+đó, trạm sau chỉ đơn giản không thấy.
+
+Framework có **phương pháp** (EP/BVA/bảng quyết định, danh sách nhóm TC); bản gốc có **chi
+tiết** (cấm từ mơ hồ, khuôn TC, từ điển hành động, bảng tra mã HTTP). Đúng khuôn đã gặp ở B1.
+
+## Bốn quyết định
+
+| # | Chốt | Nghĩa cho người dùng |
+|---|---|---|
+| **1** | **Luật ATOMIC, có cả chế độ tách tối đa** | Mỗi test case đúng **một** dòng kết quả mong đợi. Nhiều điểm kiểm → tách thành nhiều TC độc lập |
+| **2** | **Bỏ bảng trong file test case** | Toàn bộ dạng danh sách, không ký tự `\|` — kể cả mục Tổng hợp và Trace Matrix |
+| **3** | **Hai file, chia theo "có qua giao diện"** | mặc định → file giao diện (6 nhóm) · `--api` → file API (2 nhóm) · `--all` → cả hai |
+| **4** | **Lấy trọn 7 file luật chung + cả nhánh API, nhưng VIẾT LẠI 2 file mẫu** | 1.523 dòng |
+
+## Chỗ suýt tự bắn vào chân mình
+
+Nhánh API của bản gốc có 2 file **test case mẫu**. Đọc kỹ thì chúng viết **trước** luật ATOMIC
+(đội QC chốt 2026-07-09, và văn bản ghi rõ *"ĐẢO rule cũ"*):
+
+```
+MẪU GỐC (cũ hơn luật)                  ĐÃ VIẾT LẠI
+**Expected:**                           #### Expected Result
+- HTTP 201; body.id = x;                - HTTP 201 AND body.id exists
+  bản ghi có trong DB
+     ▲ ba kết cục nối bằng ";"         → TC_002: body.<field> = <giá trị>
+  mã: API-<FEATURE>-001                → TC_003: DB có bản ghi id = body.id
+     ▲ hệ mã khác                       mã: TC_<FEATURE>_NNN
+```
+
+**Lấy nguyên hai file này là dạy AI làm ngược đúng cái luật vừa chốt** — vì mẫu cụ thể luôn
+thắng luật trừu tượng. Đã viết lại cả hai, và kiểm bằng máy: **13/13 khối kết quả mong đợi có
+đúng 1 dòng**.
+
+Cũng bỏ 26 dòng là **bản nháp cũ** của chính họ: một bảng tra mã lỗi 14 dòng nằm gọn trong bảng
+95 dòng, một file chuỗi gọi 12 dòng nằm gọn trong hai file dài hơn. Lấy cả hai là có hai bảng
+tra cùng một thứ, rồi chúng lệch nhau.
+
+## Bốn thứ giờ mới có
+
+| Luật | Nó chặn điều gì |
+|---|---|
+| **Cấm 9 cụm từ mơ hồ** | *"hiển thị đúng"* · *"hoạt động bình thường"* · *"không lỗi"* → bắt viết giá trị đo được. Phép thử: **hai QC đọc có ra cùng một kết luận đỗ/trượt không?** |
+| **Khuôn TC + luật ATOMIC** | Mỗi TC một kết cục; mẫu đầy đủ; 5 bẫy khi đánh số lại hàng loạt |
+| **Cây quyết định chọn tầng** | ~12 ví dụ phân biệt: *"dropdown có placeholder"* = giao diện, *"dropdown hiện đúng N mục từ API"* = tích hợp |
+| **Từ điển hành động** | Một hành động **một** từ: Click (web) / Tap (mobile) / Enter (nhập) — cấm dùng Type, Input, Fill lẫn lộn |
+
+Thêm **kiểm trùng lặp** — thứ framework trước đây **không có gì cả**. Nó quan trọng hơn sau khi
+bật chế độ tách tối đa: nhân một TC trùng lên 5 mảnh thì thành 5 TC trùng, và không ai đếm
+được nữa. Nên kiểm trùng phải chạy **trước** khi tách.
+
+Và B11 vừa gom mọi UC vào **một thư mục** — nên **trùng chéo UC** giờ mới thực sự nhìn thấy
+được, và mới thực sự xảy ra. Hai UC của cùng tính năng rất hay dùng lại một luật nghiệp vụ;
+gặp thì trỏ trace về UC nguồn, **không viết lại**.
+
+## Chín bản của một luật → một bản
+
+Khối *"Format file TC"* trước đây **bị chép ở 9 kỹ năng** và câu chữ đã lệch nhau. Giờ một
+bản dùng chung, 9 kỹ năng trỏ về. **Cùng bệnh 5-bản mà B11 vừa chữa** — và lần này nó không
+tiết kiệm dòng, nó chỉ bỏ đi khả năng chín bản nói khác nhau.
+
+Cũng bỏ chữ **"hoặc"**: hai kỹ năng từng ghi *"file riêng **hoặc** gộp trong file feature"*.
+Chữ "hoặc" nghĩa là AI tự chọn mỗi lần một kiểu — nên hai lần chạy cùng một tính năng có thể ra
+hai cấu trúc thư mục khác nhau.
+
+## Hai lần bị máy bắt lỗi — và đó là điểm sáng
+
+**Lần 1 — self-check chặn.** Tôi dồn phần `@trace.testid_attr` sang file dùng chung, làm lệnh
+không còn nhắc tag nữa. Rule R3 đỏ ngay: *"schema khai `qc-design-test` là consumer nhưng lệnh
+KHÔNG nhắc tới nó"*. Đúng — tôi gộp quá tay. Đã trả lại ở lệnh.
+
+**Lần 2 — bộ test chặn.** `qc-scope.md` (B11) được 5 lệnh nạp, nên nó bị nướng 5 bản vào 5 file
+lệnh. Cộng thêm phần B12, tổng vượt ngưỡng: **1203 KB / ngưỡng 1200**. Framework đã có cơ chế
+cho đúng ca này (đọc-lúc-chạy thay vì nướng vào), chỉ là chưa dùng cho file đó. Chuyển xong:
+**1174 KB**.
+
+> Cả hai lỗi đều là **lỗi của tôi**, và **cả hai đều do máy bắt, không phải do tôi đọc lại**.
+> Đây chính là lập luận cho mục còn treo 2b: thứ có máy canh thì không đi lệch.
+
+## Bịt một điểm mù của chính bộ máy canh
+
+Cập nhật bản đồ port xong, self-check **xanh** — nhưng `functional/api.md` nhận nội dung port mà
+**không đóng dấu nguồn gốc** nào. Đọc lại luật thì rõ vì sao: nó so dấu với bản đồ **khi file có
+khai**. File không khai gì thì nó im lặng.
+
+Đã thêm một nhánh mới: **target đã port thì PHẢI khai** nguồn gốc, không chỉ "khai đúng nếu có
+khai". Và **thử cháy thật** cả hai góc (bỏ cả hai dòng · bỏ một dòng) — kêu đúng cả hai lần.
+
+Mất dấu nguồn gốc ở file đích nghĩa là: bản đồ biết file này port từ đâu, còn **người mở file
+thì không** — và lần đồng bộ sau, mọi thứ thành đoán.
+
+## Đã kiểm chứng
+
+| Phép kiểm | Kết quả |
+|---|---|
+| Dựng lại toàn bộ | 41/41 ✅ |
+| Bộ kiểm tra nội bộ | sạch (giờ có **17** nhánh luật) ✅ |
+| Bộ test tự động | **199/199** ✅ |
+| Tổng kích thước lệnh | 1174 KB / ngưỡng 1200 ✅ |
+| Tên file cũ còn sót | **0** |
+| Lệnh "in bảng" trong kỹ năng thiết kế | **0** |
+| Dấu vết mẫu cũ trong nhánh API | **0** |
+| Khối kết quả mong đợi đúng 1 dòng | **13/13** |
+| Entry "chưa quyết" của trạm này | **21 → 0** |
+| Target đã port có đủ dấu nguồn gốc | **23/23** |
+| File mới tới đủ ba tầng (nguồn → đóng gói → đang chạy) | **13/13/13** |
+
+## Cố ý chưa làm
+
+| Việc | Vì sao |
+|---|---|
+| **Máy kiểm cấu trúc file test case** | Vẫn là năng lực mới, và vẫn chờ kết quả phép thử của trạm 1. Nhưng B12 làm nó **rẻ hơn hẳn**: cả hai luật mới đều **đếm được** — "0 ký tự `\|`" và "1 dòng mỗi kết quả". Nếu phép thử kết luận cần máy kiểm thì làm một lượt cho cả file gap và file test case |
+| **4 file tầng test của bản gốc** *(ui · e2e · integration · nfr — 935 dòng)* | Đã ghi `skipped` **kèm lý do**, không để "chưa quyết". Framework tách tầng UI thành 3 kỹ năng theo cây quyết định thay vì một file 341 dòng; phần khuôn TC và độ chính xác **đã tách ra dùng chung**. Còn lại là phần khai kiến trúc agent — framework không có. Đối chiếu nội dung từng tầng để dành |
+| **3 trạm còn lại** | Đi theo thứ tự dây chuyền. Trạm soát là trạm kế tiếp, và nó **tiêu thụ** đúng chuẩn B12 vừa đặt ra — làm sau là đúng thứ tự |
+
+---
+
 # Tổng kết
 
 | | Quyết định ở B7 | Bằng chứng | |
@@ -1554,7 +1696,7 @@ rồi, giờ bắt nó **so** với hai tài liệu kia"*. Không nạp thêm fi
 
 # Các bước còn lại
 
-**Mười hai bước B0–B11 đã xong.** Không còn bước nào đang chờ quyết định để bắt đầu.
+**Mười ba bước B0–B12 đã xong.** Không còn bước nào đang chờ quyết định để bắt đầu.
 
 Nhưng có **hai việc chưa validate** và **bốn món nợ** — xem §Còn treo ở cuối.
 Mô tả kế hoạch gốc nằm ở [`qc-merge-plan.md`](qc-merge-plan.md).
@@ -1568,7 +1710,7 @@ Mô tả kế hoạch gốc nằm ở [`qc-merge-plan.md`](qc-merge-plan.md).
 Sau mỗi bước, toàn bộ hệ thống được dựng lại và kiểm tra tự động:
 
 - 41/41 mẫu lệnh dựng thành công
-- Bộ kiểm tra nội bộ báo sạch
+- Bộ kiểm tra nội bộ báo sạch (17 nhánh luật sau B12)
 - Nội dung mới đã lan đủ ba tầng: bản nguồn → bản đóng gói → bản đang chạy
 - **9** dấu nguồn gốc đều được kiểm chứng khớp với file gốc thật
 - Báo khói đã **thử cháy thật** cả 5 nhánh — không giao một cái chưa bao giờ kêu
@@ -1579,7 +1721,7 @@ Sau mỗi bước, toàn bộ hệ thống được dựng lại và kiểm tra
 
 | # | Câu | Mức | Ai quyết |
 |---|---|---|---|
-| **1** | Chạy thử trên một tính năng thật — **mười hai bước, chưa một lần chạy**. Sau B11 phép thử này còn quan trọng hơn: nó là cách duy nhất biết bản cấp tính năng có bắt được mâu thuẫn chéo UC, và có theo đúng template hay không. Ước lượng chi phí của tôi đã sai 3 lần, đều ước thấp | 🔴 chưa validate | bạn (cần spec thật) |
+| **1** | Chạy thử trên một tính năng thật — **mười ba bước, chưa một lần chạy**. Sau B11 phép thử này còn quan trọng hơn: nó là cách duy nhất biết bản cấp tính năng có bắt được mâu thuẫn chéo UC, và có theo đúng template hay không. Ước lượng chi phí của tôi đã sai 3 lần, đều ước thấp | 🔴 chưa validate | bạn (cần spec thật) |
 | **2** | Đưa nhật ký cho đội QC xem — họ là chủ sở hữu các kỹ năng này, và định dạng họ nhận đã đổi **hai lần** (B9 rồi B11) | 🟠 | bạn |
 | **2b** | **Máy kiểm cấu trúc file gap** — bệnh *"không theo template"* vẫn chưa có gì chặn bằng máy. Hiện chỉ có chỉ thị bằng văn xuôi, tức **cùng loại** với câu chỉ đường đã thất bại, chỉ mạnh hơn | 🟠 chưa chữa | bạn (sau khi chạy thử B11) |
 | **2c** | `Blocker` ↔ `Critical` — đổi trạm chạy test đọc `Critical` (một dòng) thay vì bắt đội QC đổi thói quen. Kết quả hôm trước cho thấy đổi từ ngữ của họ làm **tăng** khả năng lệch | 🟡 | bạn |