@educa-corp/sdd-framework 0.9.0 → 0.9.2

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

@@ -0,0 +1,1446 @@
+# Nhật ký triển khai — đưa dây chuyền QC vào framework
+
+> **Viết cho người đọc không cần biết code.** Mỗi bước ghi: giải quyết vấn đề gì, đổi cái gì,
+> và trước/sau khác nhau ra sao.
+>
+> Hai tài liệu đi kèm: [`qc-merge-plan.md`](qc-merge-plan.md) — gộp cái gì và ba quyết định
+> đang treo · [`qc-sync-command.md`](qc-sync-command.md) — về sau QC sửa skill thì đưa vào thế nào.
+
+---
+
+## Bối cảnh trong ba câu
+
+Đội QC có một dây chuyền kiểm thử bằng AI chạy riêng bên ngoài framework, đã tích luỹ nhiều
+kinh nghiệm thực chiến. Framework cũng có phần QC của mình, nhưng nó được sao chép từ một
+**nhánh cũ** của đội QC và trong lúc sao chép đã **rút gọn mất** phần chi tiết nhất.
+
+Việc đang làm: đưa bản đầy đủ về, và dựng cách để lần sau QC cải tiến thì mang sang được
+mà không phải làm tay.
+
+---
+
+## Tổng quan các bước
+
+| Bước | Tên | Trạng thái | Cần ai quyết? |
+|---|---|---|---|
+| **B0** | Làm cho hai bản so sánh được với nhau | ✅ xong | không |
+| **B1** | Lấy lại phần kinh nghiệm đã bị rút gọn mất | ✅ xong | không |
+| **B2** | Đóng dấu nguồn gốc cho từng file | ✅ xong | không |
+| **B3** | Hỏi ít hơn, đúng hơn, đủ thông tin hơn | ✅ xong | không |
+| **B4** | Sửa ba lỗi + lắp báo khói | ✅ xong | không |
+| **B5** | Trạm QC đọc thêm tài liệu kỹ thuật | ✅ xong | đã chốt: **A** |
+| **B6** | Bổ sung cách tính rủi ro cho trạm lập kế hoạch | ✅ xong | đã chốt: **a** |
+| **B7** | Chốt hình dạng kết quả đầu ra | ✅ xong | `1B` · lăng kính *(`2A` bị B9 thay · **D5 tắt sai → B10 sửa**)* |
+| **B8** | Bật lăng kính QC ở bước soát PRD | ✅ xong | đã chốt |
+| **B9** | Bỏ chế độ `--standard`, gộp vào mặc định | ✅ xong | đã chốt |
+| **B10** | Bật lại "đối chiếu chéo", thu hẹp còn 2 cặp | ✅ xong | **sửa quyết định sai ở B7** |
+
+---
+
+## ⚠️ Một chỗ rất dễ hiểu nhầm — đọc trước
+
+**Không có tài liệu nào của đội QC bị xoá hay sửa.**
+
+Suốt quá trình này, repo của đội QC **chỉ được ĐỌC**. Bản sao đóng băng nằm trong
+`upstream/qc-base/` và còn **nguyên vẹn 82 file**.
+
+Khi nhật ký ghi một kỹ năng là **"cố ý chưa lấy"**, nó có nghĩa:
+
+| Nghĩa là | KHÔNG có nghĩa là |
+|---|---|
+| Kỹ năng đó **chưa được đưa vào** framework | ❌ bị xoá khỏi repo đội QC |
+| Đã có **quyết định và lý do ghi lại** cho việc chưa đưa vào | ❌ bị đánh giá là vô dụng |
+| Vẫn nằm nguyên trong bản sao — **lấy lúc nào cũng được** | ❌ mất đi |
+
+Ngược lại với "bỏ": trước đây những kỹ năng này **vô hình** — không ai biết chúng tồn tại hay
+tại sao framework không có. Giờ mỗi cái có một dòng ghi rõ tình trạng và lý do.
+
+---
+
+## 📁 Từ vựng — bốn loại tài liệu, và tên thật của chúng
+
+Nhật ký này gọi tài liệu bằng tên tiếng Việt cho dễ đọc. Nhưng **hai trong bốn cái tên nghe rất
+giống nhau** trong khi chúng là hai tài liệu hoàn toàn khác — nên tra bảng này khi thấy mơ hồ.
+
+```
+specs/{lĩnh vực}/{tên-tính-năng}/
+├── {MÃ}-{tên-tính-năng}.md                 ①  PRD
+├── design-spec/
+│   └── {MÃ}-design-spec-web-….md           ②  "bản thiết kế"
+├── bdd/
+│   └── web/{UC}.feature                    ③  "kịch bản test"
+└── tech-docs/
+    └── {MÃ}-tech-design.md                 ④  "tài liệu kỹ thuật"
+```
+
+| # | Nhật ký gọi là | Tên thật | Ai viết | Bên trong có gì |
+|---|---|---|---|---|
+| ① | **PRD** | `{MÃ}-{tên}.md` | PO | yêu cầu nghiệp vụ · tiêu chí chấp nhận · luật nghiệp vụ |
+| ② | **bản thiết kế** | `design-spec/` | **Designer** | màn hình · thành phần giao diện · **trạng thái màn** (đang tải / lỗi / rỗng) · điều hướng · **link Figma** |
+| ③ | **kịch bản test** | `bdd/{nền}/*.feature` | sinh từ PRD | Gherkin — Cho trước / Khi / Thì |
+| ④ | **tài liệu kỹ thuật** | `tech-docs/…-tech-design.md` | **Kiến trúc sư** | mô hình dữ liệu · **hợp đồng hệ thống** (nhận gì, trả gì) · **danh sách mã lỗi** · luồng tuần tự · điểm nối với hệ thống khác |
+
+> ⚠️ **② và ④ là HAI tài liệu khác nhau, đừng nhầm.**
+>
+> **② bản thiết kế** = *Designer vẽ gì* — người dùng nhìn thấy gì trên màn hình.
+> **④ tài liệu kỹ thuật** = *hệ thống làm gì* — backend nhận vào gì, trả ra gì, lỗi có mấy loại.
+>
+> Cả hai tên tiếng Việt đều nghe như "kỹ thuật", nhưng một cái là **giao diện**, một cái là
+> **hệ thống**. Chỗ phân biệt này quan trọng nhất ở §Kiểm chứng 31 câu hỏi (cuối nhật ký): lỗ
+> tìm ra nằm ở **② bản thiết kế**, không phải ④.
+
+---
+
+# ✅ B0 — Làm cho hai bản so sánh được với nhau
+
+## Vấn đề
+
+Hai tài liệu **trông giống hệt nhau** với mắt người, nhưng máy báo *"toàn bộ 149 dòng đều khác"*.
+
+Nguyên nhân: Windows và Mac/Linux đánh dấu **kết thúc dòng** bằng ký tự khác nhau. Con người
+không thấy, máy thì thấy từng dòng một đều lệch.
+
+Hậu quả: không thể trả lời câu hỏi cơ bản nhất — *"đội QC vừa sửa gì?"* Mọi phép so sánh
+đều là nhiễu.
+
+> Giống như hai bản Word nội dung y hệt nhau, nhưng một bản đặt font khác — công cụ so sánh
+> tô đỏ **toàn bộ** trang, và bạn không tìm ra chỗ nào thực sự đổi.
+
+## Đã đổi gì
+
+Chuẩn hoá 81 trên 82 file của bản sao đội QC về cùng một quy ước.
+
+## Trước / sau
+
+| File | Máy báo "khác" trước B0 | Thực tế khác |
+|---|---|---|
+| Trích xuất luật nghiệp vụ | 149 dòng | **49** |
+| Bóc tách yêu cầu | 119 | **19** |
+| Phân tích luồng dữ liệu | 125 | **15** |
+| Sinh tiêu chí chấp nhận | 117 | **13** |
+
+## Vì sao phải làm đầu tiên
+
+Mọi bước sau đều dựa trên việc so sánh hai bản. Không làm B0 thì B1 mù, và công cụ đồng bộ
+sau này cũng vô dụng.
+
+---
+
+# ✅ B1 — Lấy lại phần kinh nghiệm đã bị rút gọn mất
+
+## Vấn đề
+
+Khi framework sao chép kỹ năng của đội QC trước đây, nó giữ lại **phần tóm tắt** và bỏ đi
+**phần checklist**. Mà checklist chính là chỗ chứa kinh nghiệm: *"đây là những thứ chúng ta
+hay quên kiểm"*.
+
+Bản framework chỉ còn câu chung chung: *"quét tìm điều kiện, ràng buộc field, giới hạn…"*
+
+## Đã lấy lại được gì
+
+### Checklist ràng buộc ô nhập liệu
+
+Với **mọi** ô nhập, kiểm đủ 4 mục:
+
+- Độ dài tối thiểu / tối đa — PRD có nêu không? Không nêu → ghi thành câu hỏi cho PO
+- Ký tự nào được phép — chữ, số, **tiếng Việt có dấu**, ký tự đặc biệt, khoảng trắng?
+- Có cắt khoảng trắng đầu/cuối không?
+- Định dạng riêng — email, số điện thoại, ngày tháng?
+
+Kèm một luật quan trọng:
+
+> ⚠️ **Ô "không bắt buộc nhập" VẪN phải kiểm đủ 4 mục.**
+> "Không bắt buộc" **không** đồng nghĩa "không có ràng buộc". Đây là chỗ hay bị bỏ sót nhất.
+
+### Checklist "hay bị bỏ sót khi đọc PRD"
+
+| | Kiểm gì | Bug điển hình nếu bỏ qua |
+|---|---|---|
+| **a** | Bảng phân luồng phải đọc **cả hai chiều** — "đủ điều kiện thì bỏ qua" *và* "thiếu thì vào" | Chỉ test nhánh thuận, nhánh nghịch ra production mới lộ |
+| **b** | Liệt kê **hết** biến thể (Google/Facebook, Lớp 1–6…) và hỏi: biến thể nào hành vi khác? | Test 1 biến thể, 5 cái kia không ai đụng |
+| **c** | Liệt kê **mọi** sự kiện thống kê được nhắc tới; có trường nhạy cảm (SĐT) **không được** lọt vào không? | Lộ dữ liệu cá nhân qua log thống kê |
+| **d** | Spec có nói "KHÔNG ghi", "KHÔNG hiển thị", "chỉ đọc" → mỗi câu là một phép kiểm riêng | Không ai test điều-không-được-xảy-ra |
+| **e** | Spec viết "chuẩn hoá theo AC3", "giống màn Z" → phải mở AC3 / màn Z ra đọc | Kế thừa nửa vời, hai màn hành vi lệch nhau |
+| **f** | Một tiêu chí viết "(1)…; (2)…; (3)…" → đếm ra, mỗi ý một phép kiểm | Đọc thành một ý, test một ý, sót hai |
+
+## Trước / sau
+
+| | Trước | Sau |
+|---|---|---|
+| Kỹ năng "trích xuất luật nghiệp vụ" | 59 dòng | **91 dòng** |
+| Checklist ô nhập liệu | không có | 4 mục + luật ô tuỳ chọn |
+| Checklist hay-bỏ-sót | không có | 6 nhóm (a–f) |
+
+## Giá trị với PO
+
+Mỗi dòng checklist tương ứng **một loại bug**. Hỏi ở lúc viết PRD thì mất 2 phút; không hỏi
+thì nó thành bug ở lúc test, hoặc tệ hơn — thành tranh cãi *"spec đâu có nói"* giữa dev và QC.
+
+## Hai chỗ cố ý **không** lấy theo bản đội QC
+
+| Chỗ | Bản đội QC | Quyết định |
+|---|---|---|
+| Câu kết phần kết quả | có lỗi lặp — viết "ghi vào file X" hai lần trong một câu | giữ bản framework (đã sạch) |
+| Đường dẫn thư mục | trỏ vào thư mục riêng của dự án đội QC | giữ bản framework (đã chỉnh cho đúng cấu trúc chung) |
+
+Hai chỗ này phải được ghi nhớ là **"khác có chủ ý"** — nếu không, mỗi lần đồng bộ sau này
+sẽ lôi lại đúng lỗi lặp kia.
+
+## Hai file còn lại: không mất gì
+
+"Phân tích luồng dữ liệu" và "sinh tiêu chí chấp nhận" chỉ khác cách diễn đạt.
+Riêng "sinh tiêu chí chấp nhận" thì **bản framework tốt hơn** — nó có thêm phần nối tiêu chí
+về đúng kịch bản kiểm thử tương ứng, thứ bản đội QC không có.
+
+---
+
+# ✅ B2 — Đóng dấu nguồn gốc cho từng file
+
+## Vấn đề
+
+> Bạn nhận một bản hợp đồng mẫu từ phòng pháp chế, sửa vài điều cho hợp với dự án của mình.
+> Sáu tháng sau pháp chế gửi bản mẫu **mới**.
+>
+> Nếu lúc sửa bạn **không ghi lại** *"tôi sửa từ bản v3"*, thì bây giờ bạn không phân biệt được:
+> chỗ nào là **pháp chế vừa đổi**, chỗ nào là **bạn cố ý sửa**. Ghép hai bản lại thành ra đoán.
+
+Đây đúng tình trạng của framework: mỗi file chỉ ghi *"lấy từ đội QC"* — một cái tên, **không có
+phiên bản**. Và cái tên đó còn **ghi sai** tên kho tài liệu.
+
+## Đã đổi gì
+
+Mỗi file được đóng dấu ba thông tin: **lấy từ kho nào · lấy từ file nào · lấy từ phiên bản nào**
+(bằng một mã kiểm tra duy nhất cho từng phiên bản).
+
+Kết quả:
+
+- **5 file** đóng dấu đầy đủ — đã kiểm chứng tự động là mã khớp với file gốc thật
+- **30 file** sửa lại tên kho cho đúng, **chưa đóng dấu được** (lý do bên dưới)
+
+## Phát hiện: 30 trên 35 file **không tìm được bản gốc**
+
+Kiểm tra đối chiếu cho thấy:
+
+| Nhóm kỹ năng của framework | Số file | Tìm được bản gốc tương ứng |
+|---|---|---|
+| Phân tích yêu cầu | 5 | **5/5** ✅ |
+| Thiết kế test case | 11 | **0/11** |
+| Soát test case & script | 10 | không rõ — tên và cách chia đều khác |
+| Chạy test & báo cáo | 8 | **0/8** — đội QC chỉ có 2 file cho phần này, framework chia thành 8 |
+
+Nguyên nhân: framework sao chép từ một **nhánh cũ** của đội QC. Sau đó đội QC đã gộp nhiều
+kỹ năng nhỏ thành kỹ năng lớn với tên khác. Nên bản gốc của 30 file kia **không còn tồn tại**
+dưới dạng có thể đối chiếu.
+
+**Hệ quả cần biết trước:** về sau đội QC cải tiến phần thiết kế test case hay phần chạy test,
+sẽ **không có đường tự động** mang sang framework — vì 1 file bên họ ứng với 11 file bên mình.
+Ba hướng xử lý (chưa cần quyết bây giờ):
+
+1. Chấp nhận 30 file đó **do framework tự sở hữu**, không đồng bộ ngược nữa
+2. Gộp lại theo cách chia của đội QC — đổi kiến trúc bốn trạm
+3. Ghép tay, công cụ chỉ báo *"bên kia vừa đổi, tự xem"*, không tự ghép
+
+## Phát hiện thứ hai: phần "lập kế hoạch test" cũng bị cắt
+
+Cùng bệnh với B1, nhưng nặng hơn: **158 → 120 dòng**. Phần bị mất:
+
+- **Phủ theo nhóm người dùng** — bảng liệt kê từng nhóm (theo vai trò / trạng thái / phân khúc),
+  mỗi nhóm thấy màn hình và luồng khác nhau, **kể cả nhóm "không đủ điều kiện"**
+- **Ma trận đa nền** — luồng quan trọng nhất × từng cặp nền/thiết bị, ghi rõ hành vi
+  chỉ có ở một nền (vuốt về chỉ có ở app, bàn phím chỉ có ở web)
+- **Ba chỉ số nghiệm thu có công thức đo được** — phủ chức năng 100% · phủ đa nền · phủ giá trị biên 100%
+- Bảng ước lượng số test case, kèm giải thích chênh lệch giữa "tối thiểu theo yêu cầu" và "thực tế cần"
+- Luật: *lỗi hạ tầng (mất mạng, quá hạn) thì kiểm **điều người dùng nhìn thấy**, không kiểm số lần thử lại*
+- Ghi chú hiệu chỉnh: *tính năng đơn giản, một nền, một nhóm người dùng thì ghi "không áp dụng" —
+  đừng tick cho đủ ô*
+
+**Chưa lấy lại**, vì ba lý do: nó thuộc trạm 2 chứ không phải trạm 1 · phần mất có chứa đường dẫn
+nên phải chỉnh chứ không dán thẳng được · và nó tham chiếu tới cách chia UI/API/E2E — chính là
+câu B5 đang chờ quyết.
+
+---
+
+# ✅ B3 — Hỏi ít hơn, đúng hơn, đủ thông tin hơn
+
+## Vấn đề
+
+Khi AI đọc PRD rồi báo *"chỗ này chưa rõ, PO xác nhận giúp"*, có **hai bệnh** — và bệnh thứ hai
+tốn của PO nhiều hơn.
+
+**Bệnh 1 — sót.** Chạy lần 1 ra 8 chỗ. Sửa xong chạy lại ra 6 chỗ *mới*. Lần 3 ra 4 chỗ nữa.
+PO tưởng đã chốt PRD, sang viết kịch bản test hoặc code mới lòi tiếp → làm lại.
+
+**Bệnh 2 — bịa.** Báo 22 chỗ "thiếu", nhưng phần lớn thực ra là: PRD **đã nói rồi** ở mục khác
+hoặc ở tài liệu sản phẩm gốc · AI **tự nghĩ ra một yêu cầu** rồi than PRD không mô tả nó ·
+hoặc là chuyện **QC tự quyết được**, không cần hỏi PO.
+
+Bệnh 2 tệ hơn vì nó **ăn mòn lòng tin**: PO đọc 22 câu, thấy 15 câu vô nghĩa, lần sau nhận
+danh sách thì lướt. Lúc đó cả những câu **thật** cũng chết theo.
+
+> Đội QC viết thẳng điều này trong tài liệu của họ:
+> *"5 gap thật tốt hơn 22 gap với 20 gap ảo."*
+
+**Nguyên nhân gốc:** quy trình soát của framework chỉ có **một chiều lực**. Nó quét rộng, rồi
+lặp một vòng phê bình hỏi *"còn thiếu gì nữa?"* cho tới khi không ra thêm. Cả hai đều đẩy
+**độ phủ** lên. **Không có bước nào hỏi ngược lại: "cái vừa tìm ra có thật không?"**
+
+## Đã đổi gì
+
+### 1 · Thêm bước thẩm định độc lập — thứ framework hoàn toàn chưa có
+
+Một bước dùng chung mới: sau khi có danh sách, nó **mở lại tài liệu gốc** và bắt từng mục tự
+chứng minh. Sáu phép kiểm:
+
+| | Kiểm gì | Loại ra cái gì |
+|---|---|---|
+| **T1** | Đoạn trích dẫn có thật trong tài liệu không, có đúng nghĩa không? | trích dẫn bịa hoặc chép sai nghĩa |
+| **T2** | Hành vi bị bảo là "thiếu" — spec **có thật sự yêu cầu** nó không? | tự nghĩ ra yêu cầu rồi than spec không tả |
+| **T3** | Câu hỏi này đã được trả lời ở tài liệu khác chưa? | cái spec đã trả lời rồi |
+| **T3b** | Hai chỗ bị bảo "mâu thuẫn" — có cùng một giai đoạn không? | hai giai đoạn khác nhau của cùng luồng, không mâu thuẫn |
+| **T4** | Rule đã có ở tài liệu sản phẩm gốc chưa? | đòi tài liệu con lặp lại tài liệu cha |
+| **T5** | Đây có thật là chuyện nghiệp vụ không? | lệch version · làm-kỹ-test · chuyện Dev/Design tự quyết |
+| **T6** | Có trùng root cause với mục khác không? | đếm hai lần một vấn đề |
+
+Kèm hai luật cứng:
+
+> **Cấm dùng chính phần trích dẫn trong danh sách làm bằng chứng.** Bắt buộc mở file gốc đọc lại.
+> Đây là **toàn bộ lý do** bước này tồn tại — bỏ qua nó thì nó chỉ là một vòng phê bình nữa.
+
+> **Không xoá mục nào.** Cái bị loại thì **đóng lại kèm lý do**, giữ lại để kiểm chứng.
+> Xoá thì không ai kiểm được là loại đúng hay loại nhầm.
+
+### 2 · Hiệu chỉnh mức độ — chống thổi phồng
+
+T1–T6 quyết định một mục **còn hay bỏ**. Nhưng còn một bệnh nữa: mục hợp lệ nhưng **bị gán mức
+quá cao**. Một danh sách toàn 🔴 Critical thì **không xếp được ưu tiên** — tức cột mức độ mất
+sạch giá trị.
+
+Thêm năm nhóm được hạ mức tự động, đều là *"không phải lỗ hổng của tính năng đang xét"*: lệch
+pha với tài liệu gốc · spec con đã rõ chỉ nền domain lệch · nguồn tự đánh dấu là giả định ·
+nhánh phòng vệ không thể chạm tới · thiếu tài liệu kỹ thuật ở tính năng xây mới (chặn tự-động-hoá,
+không phải khuyết tật nghiệp vụ).
+
+### 3 · Ba câu hỏi lọc — trong đó có một câu bảo vệ thời gian của PO
+
+Mỗi mục phải vượt cả ba mới được giữ:
+
+| | Câu hỏi |
+|---|---|
+| **Q1** | Chỗ này đã được spec ở thiết kế / tài liệu sản phẩm / tài liệu kỹ thuật chưa? |
+| **Q2** | Chỗ này có thuộc phạm vi spec đang xét không? |
+| **Q3** | **Người thực thi tự quyết được không, hay bắt buộc cần PO/BA chốt?** |
+
+> **Q3 là câu bảo vệ thời gian của PO.** Mọi thứ QC hoặc dev tự quyết được mà vẫn đẩy lên PO
+> đều là chi phí thuần — và tệ hơn, nó làm loãng những câu thật.
+
+### 4 · Năm góc nhìn quét song song, thay vì một lượt đọc
+
+| Góc | Soi gì |
+|---|---|
+| Luật nghiệp vụ | điều kiện thiếu nhánh, ngưỡng chưa chốt số |
+| Xử lý lỗi | quá hạn thì sao, thử lại mấy lần, hết lần thì đi đâu |
+| Giao diện | màn thiếu trạng thái đang tải / rỗng / lỗi; chữ trên nút có nhất quán không |
+| Dữ liệu & cấu hình | có đủ dữ liệu để tự kiểm chứng kết quả tính không |
+| Đối chiếu chéo tài liệu | PRD nói A, thiết kế nói B — và **thiếu hay thừa** |
+
+Riêng góc cuối có một luật đáng chú ý: phải phân biệt **THIẾU** (thiết kế bỏ sót thứ PRD yêu cầu)
+với **THỪA** (thiết kế **tự thêm** thứ PRD không định nghĩa). Hai hướng xử lý ngược nhau —
+THIẾU thì bổ sung vào thiết kế; THỪA thì PO chốt giữ hay gỡ. Gọi nhầm hướng là đặt sai đề bài.
+
+### 5 · Bảng câu hỏi đầy đủ hơn *(mới, chưa bật)*
+
+Bảng 10 cột của đội QC được đưa vào, đặt **cạnh** bảng 9 cột hiện hành. Hai điểm hơn:
+
+| | Bảng 9 cột hiện dùng | Bảng 10 cột mới |
+|---|---|---|
+| **Giao cho đội nào** | ❌ không có cột | ✅ Dev / PO / BA / Design / Kiến trúc / Dữ liệu |
+| **Nội dung câu hỏi** | một ô tự do — hay chỉ ghi *"AC3 mơ hồ"* | ✅ bắt buộc đủ bốn mục: **Bối cảnh** → **Vấn đề** → **Tại sao quan trọng** → **Gợi ý** |
+
+*"Tại sao quan trọng"* cho phép PO **xếp ưu tiên** — biết bỏ qua thì hỏng gì.
+*"Gợi ý"* cho phép PO **trả lời nhanh** — duyệt hoặc sửa, thay vì nghĩ lại từ đầu.
+
+Bảng mới **chưa được bật**; nó chờ quyết định về hình dạng đầu ra (B7).
+
+## Trước / sau, dưới góc nhìn PO
+
+| | Trước | Sau |
+|---|---|---|
+| Bước thẩm định | **không có** | 6 phép kiểm + 3 câu lọc + hiệu chỉnh mức |
+| Câu bị loại | không tồn tại khái niệm này | đóng kèm lý do — kiểm chứng được |
+| Báo cáo | *"Gaps: 22 (5 blocker)"* | thêm dòng: *"22 gap thô → 7 còn mở (❌ 9 bịa/đã-trả-lời · ⚠️ 4 không phải nghiệp vụ · 🔁 2 trùng)"* |
+| Chạy lại lần 2 | lòi thêm câu mới | vòng phê bình lặp tới khi hai lượt liền không ra gì mới |
+
+## Một quyết định port đáng ghi lại
+
+Bản gốc của đội QC **tự cài lại toàn bộ cơ chế quét song song** bằng tay — một bộ điều phối
+kiểm kê tài liệu, gọi 5 luồng, rồi gom kết quả.
+
+Framework **đã có sẵn đúng cơ chế đó**, và bản của framework còn hơn ở hai điểm: có vòng phê
+bình lặp tới khi cạn, và có giới hạn số luồng chạy đồng thời khi tài liệu quá lớn.
+
+→ Chỉ port **phần nội dung** (5 góc nhìn), bỏ phần điều phối. Nuôi hai bản cài đặt của cùng
+một thứ thì chúng sẽ trôi khỏi nhau. Quyết định này được ghi vào chính file đó
+(`port_completeness: partial`) để lần đồng bộ sau không hiểu nhầm phần thiếu là *"ta cố ý xoá"*.
+
+## Cái B3 **không** đổi
+
+- Không đổi quy trình PO — vẫn là nhận danh sách, trả lời, duyệt
+- Không đổi PRD, kịch bản test, hay tài liệu nào đang có
+- Bảng 10 cột và 5 góc nhìn **chưa bật** — chờ quyết định B7
+- Bước thẩm định **tắt mặc định** ở quy trình soát PRD; chỉ **bật sẵn** ở bước phân tích QC,
+  nơi nó không đổi hình dạng đầu ra, chỉ đổi chất lượng
+
+## Phần thưởng chưa dùng tới
+
+Bước thẩm định đặt ở **tầng dùng chung**, không gắn chết vào QC. Nghĩa là quy trình soát PRD
+(ba góc nhìn Dev / Kiến trúc / PO) **bật được ngay bằng một tham số** — vì nó cũng đang mắc
+đúng bệnh bịa, cũng chỉ có vòng "tìm thêm" mà không có vòng "kiểm lại".
+
+Chưa bật, để tránh đổi hành vi một lệnh đang chạy ổn. Nhưng đường đã sẵn.
+
+---
+
+# ✅ B4 — Sửa ba lỗi + lắp báo khói
+
+## Ba lỗi lẻ
+
+### 1 · Kiểm nhầm bản
+
+Một tính năng thường chạy trên **ba nền**: web, app, hệ thống. Mỗi nền có **kịch bản test riêng**,
+và ba bản đó **duyệt độc lập** — bản web có thể đã duyệt trong khi bản app còn nháp.
+
+Lệnh phân tích đang làm theo thứ tự: **kiểm "đã duyệt chưa"** → rồi mới **hỏi "nền nào"**.
+Tức nó kiểm trước khi biết đang kiểm bản nào.
+
+> Giống như ký duyệt bản hợp đồng tiếng Anh, rồi mới hỏi *"à mà mình đang triển khai bản tiếng
+> Việt hay tiếng Anh nhỉ?"*
+
+**Hậu quả:** báo "đã duyệt" trong khi bản đang dùng còn nháp — QC làm cả buổi trên tài liệu chưa
+chốt. Hoặc ngược lại, chặn oan một bản đã duyệt rồi.
+
+**Đã sửa:** đổi chỗ hai bước, hỏi nền trước. Và bổ sung một bước suy luận: nếu tính năng chỉ có
+**một** nền thì tự nhận ra, không hỏi.
+
+### 2 · Sách hướng dẫn ghi ngược với thực tế
+
+Tài liệu mô tả lệnh ghi *"không có bước dừng hỏi"*. Thực tế **có** — lệnh này ghi file ra nên nó
+dừng xin xác nhận, đúng thiết kế.
+
+**Vì sao lọt được:** framework có cơ chế tự động canh *"mỗi lệnh phải khai rõ mình có dừng hỏi
+không"*. Nhưng nó chỉ canh **file lệnh**, **không canh** tài liệu mô tả lệnh. Hai chỗ cùng nói về
+một hành vi mà không ai bắt chúng phải đồng ý với nhau.
+
+**Đã sửa:** lệnh khai rõ mức chặn, tài liệu sửa cho khớp.
+
+### 3 · Chạy tự động thì bị treo
+
+Framework hứa một đường chạy **không cần người ngồi canh**. Nhưng lệnh phân tích có **ba chỗ dừng
+hỏi**, mà công tắc *"chạy tự động, đừng hỏi tôi"* chỉ tắt được **một**:
+
+| Chỗ dừng hỏi | Trước | Sau |
+|---|---|---|
+| Xác nhận trước khi chạy | ✅ tắt được | ✅ |
+| *"Kịch bản chưa duyệt, vẫn chạy chứ?"* | ❌ treo | ✅ tự tiếp — **nhưng vẫn in cảnh báo** |
+| *"Đang làm cho nền nào?"* | ❌ treo | ✅ tự suy; không suy được thì **dừng với lỗi rõ ràng** |
+
+Đặt chạy lúc 11 giờ đêm, 11 giờ 1 phút nó dừng hỏi, không ai trả lời, treo tới sáng.
+
+Hai chi tiết cố ý trong bản sửa:
+
+- Chỗ thứ hai **vẫn in cảnh báo** dù không chặn. *Không chặn ≠ không báo* — người đọc log sau này
+  vẫn cần thấy QC đã chạy trên tài liệu chưa chốt.
+- Chỗ thứ ba **không đoán bừa**. Đoán sai nền là ghi kết quả vào sai thư mục **và** ghi trạng thái
+  kiểm thử vào sai sổ — hỏng im lặng. Thà dừng và nói rõ phải nêu nền.
+
+---
+
+## Việc thứ tư — lắp báo khói
+
+Ba việc trên là lỗi lẻ. Việc này **chống tái phát**, và nó không phải phòng xa: **đã cháy hai lần**
+ngay trong lúc làm.
+
+### Đám cháy 1 — 35 file biến mất mà mọi đèn đều xanh
+
+| Lớp kiểm tra | Báo gì | Vì sao không bắt |
+|---|---|---|
+| Bộ kiểm tra tự động | ✅ sạch | canh chuyện khác, không canh *"file có tồn tại không"* |
+| Bộ đóng gói | ✅ 41/41 | không có file thì đóng gói cái rỗng — vẫn thành công |
+| Chạy thử tại chỗ | ✅ vẫn chạy | bản chạy thử **không tự dọn** file cũ, nên chúng vẫn nằm đó |
+
+Và bộ cài đặt sẽ **chủ động xoá** 35 file đó ở máy người dùng khi họ nâng cấp — đúng luật, đúng
+thiết kế, và im lặng hoàn toàn.
+
+> Ba lớp che nhau. Bên trong nhà thấy bình thường; chỉ người ngoài mới bị.
+
+### Đám cháy 2 — mã nguồn gốc bịa
+
+Lúc viết một file mới ở bước trước, cần ghi vào đó **mã nhận dạng phiên bản gốc** mà nó được sao
+chép từ. Mã đó bị **gõ đại** thay vì tính.
+
+Tự phát hiện và sửa. Nhưng nếu lọt, dãy số bịa nằm đó **vĩnh viễn** và mọi lần đồng bộ sau đều lấy
+nó làm gốc so sánh — tức mọi lần đồng bộ về sau đều là đoán.
+
+> Đây đúng loại việc con người **không thể** làm đáng tin bằng sự cẩn thận.
+
+### Báo khói kiểm bốn thứ
+
+| | Kiểm | Bắt được |
+|---|---|---|
+| **a** | Mọi tài liệu của đội QC phải có mặt trong bảng theo dõi | Kỹ năng **bị bỏ quên trong im lặng**. Ghi *"cố ý không lấy"* là hợp lệ — **vắng mặt** thì không |
+| **b** | Mọi mã nguồn gốc phải **khớp file thật**, ở cả bảng lẫn trong file | Đám cháy 2 |
+| **c** | Mọi đích trong bảng phải tồn tại | Bảng lỗi thời sau khi đổi tên file |
+| **d** | **Lệnh trỏ vào kỹ năng nào thì kỹ năng đó phải có thật** | Đám cháy 1 |
+
+### Đã thử cháy thật để chắc báo khói kêu
+
+Một cái báo khói chưa bao giờ kêu thì không ai biết nó có hoạt động không. Cả bốn nhánh được thử
+bằng cách **cố tình tái tạo hai đám cháy**:
+
+| Thử | Kết quả |
+|---|---|
+| Xoá thư mục kỹ năng *(tái tạo đám cháy 1)* | 🔴 **9 lỗi** — nhánh (d) và (c) cùng nổ |
+| Đổi một mã nguồn gốc thành số bịa *(tái tạo đám cháy 2)* | 🔴 **2 lỗi** — bắt cả ở bảng lẫn ở file, và chỉ ra hai chỗ nói khác nhau |
+| Thêm một file vào tài liệu đội QC mà không khai vào bảng | 🔴 bắt đúng tên file bị bỏ quên |
+
+Khôi phục xong, tất cả về xanh.
+
+---
+
+## Bảng theo dõi — thứ có giá trị lâu hơn cả bốn việc trên
+
+Ba nhánh **a·b·c** cần một thứ: **bảng theo dõi 82 dòng** — mỗi tài liệu của đội QC một dòng, ghi
+rõ *đã lấy / sẽ lấy / **cố ý chưa lấy** / chưa quyết*.
+
+| Trạng thái | Số dòng | Nghĩa |
+|---|---:|---|
+| `ported` — đã lấy | **8** | có mã nguồn gốc, đồng bộ ngược được |
+| `skipped` — **cố ý chưa lấy** | **1** | tài liệu đội QC khai đã bỏ nhánh Excel thủ công, file còn sót |
+| `undecided` — **chưa quyết** | **73** | ← đây là danh sách việc thật |
+
+> **73 việc chưa quyết hiện ra rõ ràng.** Trước đó chúng vô hình — và cảm giác là "chỉ còn vài
+> việc nữa". Bảng này cũng là chỗ **ghi quyết định** cho các bước còn lại: mỗi lần chốt một câu là
+> một dòng đổi trạng thái, thay vì quyết định tản mát trong hội thoại rồi quên.
+
+Một loại ghi chú nữa được đưa vào bảng: **"lấy một phần có chủ ý"**. Ví dụ ở bước trước, năm góc
+nhìn quét gap được lấy nhưng phần điều phối thì không (framework đã có sẵn). Không đánh dấu thì
+lần đồng bộ sau sẽ hiểu phần thiếu là *"ta cố ý xoá nội dung"* và giữ nguyên trạng thiếu.
+
+## Cái B4 **không** đổi
+
+- Không đổi quy trình PO
+- Không đổi kết quả đầu ra của bất kỳ lệnh nào
+- 73 dòng `chưa quyết` **không chặn gì** — chúng chỉ là danh sách hiện ra
+
+---
+
+# ✅ B5 — Trạm QC đọc thêm tài liệu kỹ thuật
+
+**Quyết định: phương án A** — không nhận cách chia UI/API/E2E của đội QC.
+
+## Vấn đề
+
+Khi phân tích một tính năng, đội QC đọc **hai loại tài liệu**:
+
+1. **Tài liệu nghiệp vụ** — PRD, kịch bản test, bản thiết kế giao diện *(trạm QC đang đọc rồi)*
+2. **Tài liệu kỹ thuật** — hệ thống nhận vào gì, trả ra gì, dữ liệu lưu ra sao *(trạm QC **chưa** đọc)*
+
+Vì sao phải đọc loại 2? Vì có những lỗi **chỉ lộ ra khi so hai loại với nhau** — đọc riêng bên
+nào cũng thấy hợp lý.
+
+> **Ví dụ:** PRD viết *"người dùng chọn lớp **1 đến 6**"*. Tài liệu kỹ thuật ghi hệ thống chấp
+> nhận **lớp 1 đến 9**.
+>
+> Vênh. QC hỏi PO: *lớp 7–9 là gì — PRD thiếu, hay hệ thống làm dư?*
+>
+> Không ai đọc cả hai thì không ai thấy. Lỗi này thường ra tận lúc chạy thật.
+
+## Câu hỏi ban đầu — và vì sao nó sai
+
+Đội QC có **11 công cụ** để đọc loại tài liệu thứ hai. Câu hỏi tưởng là: *"có lấy 11 công cụ đó
+không?"*
+
+Nhưng kiểm rồi thì framework **đã có sẵn** một tài liệu kỹ thuật hợp nhất, viết ra ở bước ngay
+trước QC, gộp đủ: hệ thống nhận gì trả gì · dữ liệu lưu ra sao · lỗi xử lý thế nào · luồng chạy
+qua đâu · điểm nối với hệ thống khác.
+
+> Đội QC phải xây 11 công cụ vì ở dự án của họ, tài liệu kỹ thuật **nằm rải rác ba chỗ**, mỗi
+> chỗ một định dạng.
+>
+> Giống như: đội thẩm định quen đọc **ba tập hồ sơ gốc** vì công ty cũ không có bản tóm tắt.
+> Còn ở đây **đã có sẵn** bản tổng hợp do kỹ sư trưởng viết, gộp cả ba, luôn cập nhật.
+
+**Đối chiếu 11 công cụ với thứ framework đã có:**
+
+| Công cụ của đội QC | Framework đã có ở đâu | Trạm QC **đã đọc** chưa |
+|---|---|---|
+| Đọc đặc tả màn hình | bản thiết kế giao diện | ✅ đã đọc |
+| Chụp thiết kế Figma | bản thiết kế giao diện | ✅ đã đọc |
+| Đọc đặc tả tính năng | PRD + tài liệu sản phẩm gốc | ✅ đã đọc |
+| Đọc hợp đồng hệ thống | **tài liệu kỹ thuật** | ❌ chưa |
+| Đọc sơ đồ dữ liệu | **tài liệu kỹ thuật** | ❌ chưa |
+| Rút thiết kế kỹ thuật | **tài liệu kỹ thuật** | ❌ chưa |
+| Nối giao diện ↔ hệ thống | **tài liệu kỹ thuật** | ❌ chưa |
+| Vẽ đường đi luồng | **tài liệu kỹ thuật** | ❌ chưa |
+| Đối chiếu chéo ba nguồn | *(chính là việc đối chiếu ở trên)* | — |
+| Lập kế hoạch test hệ thống | thuộc **trạm 2**, không phải trạm 1 | — |
+| Điều phối ba làn | engine quét song song đã có *(B3)* | — |
+
+**Ba công cụ đầu đã được phủ** bởi tài liệu trạm QC đang đọc rồi.
+**Năm công cụ giữa** được phủ bởi **một** tài liệu mà trạm QC chưa đọc.
+
+→ Câu hỏi rút gọn còn: **"trạm QC có nên đọc thêm bản tổng hợp đã có sẵn không?"**
+Không phải *"port 11 công cụ"*, mà là **sửa vài dòng trong một lệnh**.
+
+## Đã đổi gì
+
+Thêm một bước vào trạm phân tích: đọc tài liệu kỹ thuật và **đối chiếu sáu mục** với PRD/kịch bản
+test — mỗi chỗ vênh là một câu hỏi loại *"hai tài liệu nói khác nhau"*:
+
+| Đối chiếu gì |
+|---|
+| Thực thể / trường dữ liệu PRD nhắc tới có khớp không |
+| **Tập giá trị hợp lệ** · ràng buộc trường · **danh sách mã lỗi** — PRD nêu bao nhiêu nhánh lỗi, hệ thống định nghĩa bao nhiêu |
+| Màn hình / thành phần giao diện có mặt đủ không |
+| Thứ tự bước và nhánh rẽ có khớp kịch bản test không |
+| Việc phụ PRD nêu (gửi thông báo, gọi hệ thống khác) có được định nghĩa không |
+| Trường hợp biên PRD nêu có đường xử lý không — và ngược lại |
+
+**Không có tài liệu kỹ thuật → cảnh báo, không chặn.** Dự án có thể chưa dựng nó. Nhưng phải nói
+rõ hậu quả: *"lệch giữa yêu cầu nghiệp vụ và hệ thống sẽ không được phát hiện ở trạm này"* — thay
+vì im lặng bỏ qua rồi để người đọc tưởng đã kiểm.
+
+## Chuyện thứ hai — hai sổ ghi "chỗ chưa chốt"
+
+Tài liệu kỹ thuật **đã có sẵn một sổ** ghi những chỗ chưa chốt, do người viết nó ghi. Sổ đó có
+người chịu trách nhiệm, có mức độ, **và có cổng chặn** — còn chỗ chưa chốt nghiêm trọng thì
+không được sinh code.
+
+Nên khi trạm QC bắt đầu đọc tài liệu kỹ thuật, nó gặp **một sổ khác đã tồn tại**.
+
+**Cách xử lý đã chốt: QC ĐỌC sổ đó, KHÔNG GHI vào.**
+
+| Thấy gì trong sổ kỹ thuật | QC làm gì |
+|---|---|
+| Mục chưa chốt, **đội backend tự quyết** | ghi nhận *"đang chờ"* — **không** hỏi PO |
+| Mục chưa chốt, **cần đội khác** | ghi nhận *"đang chờ"* — **không** hỏi PO |
+| Mục ghi rõ là **PRD/kịch bản test sai hoặc thiếu** | **đúng là việc của PO** → vẫn ghi thành câu hỏi, và trỏ ngược về mục gốc để không đếm hai lần |
+
+> **Vì sao không ghi vào.** Một mục đã nằm trong sổ kỹ thuật nghĩa là **đã có người đang lo**.
+> Mở lại nó thành câu hỏi QC là gửi PO một câu hỏi không phải việc của PO — và tạo hai sổ cùng
+> theo dõi một chuyện, rồi chúng lệch nhau.
+
+Đây thực ra là **câu hỏi lọc Q1** đã lắp ở bước trước (*"chỗ này đã được trả lời ở tài liệu khác
+chưa?"*), chỉ mở rộng phạm vi *"tài liệu khác"* thêm một nguồn.
+
+## Điểm yếu đã biết — ghi lại để sau này không quên
+
+Tài liệu kỹ thuật của framework **do AI viết ra từ PRD**. Nên đối chiếu chỉ bắt được *"PRD lệch
+tài liệu kỹ thuật"* — **không** bắt được *"PRD lệch hệ thống thật đang chạy"*.
+
+Điều này chỉ quan trọng với **dự án đã có hệ thống chạy sẵn từ trước**. Với dự án làm mới theo
+framework thì code sinh **ra từ** tài liệu kỹ thuật, nên nó chính là nguồn.
+
+→ Đường nâng cấp đã ghi sẵn: gặp dự án cũ cần soi hệ thống thật thì lấy đúng **2–3** công cụ cần,
+không phải lấy hết 11.
+
+## Bảng theo dõi sau B5
+
+| | Trước | Sau |
+|---|---:|---:|
+| đã lấy | 8 | 8 |
+| **cố ý chưa lấy, có lý do** | 1 | **11** |
+| chưa quyết | 73 | **63** |
+
+Mười công cụ chuyển từ *chưa quyết* sang *cố ý chưa lấy* — **mỗi cái ghi rõ lý do và ghi rõ framework
+đã có gì thay thế**. Quyết định B5 cũng được ghi thành một mục riêng trong bảng: câu hỏi, câu trả
+lời, ba lý do, và điểm yếu đã biết.
+
+> Đây là lần đầu bảng theo dõi làm đúng việc nó sinh ra để làm: **giữ quyết định ở chỗ máy đọc
+> được**, thay vì để nó tan trong hội thoại.
+
+## Cái B5 **không** đổi
+
+- Không đổi quy trình PO
+- Không đổi tài liệu nào đang có
+- Không thêm bước dừng hỏi nào
+- Dự án chưa có tài liệu kỹ thuật vẫn chạy bình thường — chỉ mất phần đối chiếu, và được báo rõ
+
+---
+
+# ✅ B6 — Bổ sung cách tính rủi ro cho trạm lập kế hoạch
+
+**Quyết định: chỉ làm (a)** — bổ sung cách tính rủi ro. Hai việc kia để dành.
+
+## Vấn đề tôi tưởng — và hoá ra không phải
+
+Còn ba kỹ năng của đội QC mà tôi xếp là *"đúng vai nhưng đứng sai trạm"*, nghe như ba tranh chấp
+cần phân xử. Đọc kỹ thì **hai cái tự trả lời, và cái thứ ba tôi báo sai**.
+
+### 1 · Phân tích rủi ro — nó tự nói ra đích đến
+
+Câu cuối của chính kỹ năng đó ghi: *"Bổ sung vào **`TEST_PLAN.md`**"* — mà đó là sản phẩm của
+**trạm 2**, không phải trạm 1. Nó tự chỉ về trạm 2. Không có gì để tranh chấp.
+
+### 2 · Đo độ phủ — nó tự nói ra không chạy được ở trạm 1
+
+Phần *"khi nào KHÔNG dùng"* của chính nó ghi: *"chưa có test case nào → độ phủ sẽ = 0%, **không
+có ý nghĩa**"*.
+
+Trạm 1 là trạm **đầu tiên** — lúc đó chưa có test case nào. **Nó không thể chạy ở đó.**
+Tôi xếp nhầm ngay từ đầu.
+
+### 3 · Kịch bản thăm dò — không trùng lặp, tôi báo sai
+
+Tôi nói *"trùng vai, khác trạm, phải chọn một"*. Sai. Cùng một kỹ thuật, **hai mục đích khác hẳn**:
+
+| | Framework — trạm 3 | Đội QC — trạm 1 |
+|---|---|---|
+| Dùng khi | *trước khi bắt đầu buổi thăm dò* | *spec mơ hồ / thiếu / **không có*** |
+| Để làm gì | **thiết kế** test kiểu thăm dò | **học** xem yêu cầu là gì, khi tài liệu không đủ |
+| Ví dụ | tính năng mới rủi ro cao | tiếp quản hệ thống cũ, không ai viết tài liệu |
+
+> Giống dùng đèn pin: một bên **soi kỹ một góc đã biết**, một bên vì **mất điện cả nhà**.
+
+Đội QC dùng nó làm **phương án dự phòng khi không có tài liệu**. Framework không có phương án đó —
+trạm 1 hiện giả định luôn có PRD và kịch bản test.
+
+→ Không phải chọn một. Là câu hỏi *"framework có cần phương án dự phòng không?"* — và câu trả lời
+là **chưa**: trạm 1 của framework đứng **sau** cả chuỗi PRD → kịch bản test → tài liệu kỹ thuật →
+code. Đến lúc QC vào việc thì tài liệu **phải có**; nếu không có thì vấn đề nằm ở chỗ khác, không
+phải ở QC.
+
+## Việc thật sự phải làm
+
+Chỉ một: **framework có khung bảng rủi ro nhưng không có cách điền.**
+
+| | Framework hiện có | Đội QC có |
+|---|---|---|
+| Bảng rủi ro | 4 cột trống, một dòng gợi ý *"rút từ gap chặn + logic phức tạp"* | **cách chấm**: khả năng xảy ra × mức thiệt hại → P0–P3 |
+| Nguồn rủi ro | không liệt kê | **7 nguồn cụ thể** |
+| Rủi ro dùng làm gì | không nói | quyết định **độ sâu** test từng vùng |
+
+## Đã bổ sung gì
+
+### Bảy nguồn rủi ro — quét từng cái, không bỏ nguồn nào
+
+logic phức tạp · **tiền / thanh toán** · dữ liệu nhạy cảm · tích hợp nhiều phần · code mới hoặc
+sửa nhiều · **lịch sử lỗi cao** · ảnh hưởng nhiều người dùng
+
+> Nguồn *"lịch sử lỗi cao"* là nguồn duy nhất **tra được bằng dữ liệu thật** — framework có sổ bug.
+> Nên luật viết vào là: **mở ra đếm, đừng đoán "vùng này chắc ổn"**.
+
+### Chấm hai chiều rồi mới nhân
+
+| Khả năng \ Thiệt hại | Cao | Trung bình | Thấp |
+|---|:---:|:---:|:---:|
+| **Cao** | **P0** | **P1** | P2 |
+| **Trung bình** | **P1** | P2 | P3 |
+| **Thấp** | P2 | P3 | P3 |
+
+> **Vì sao tách hai chiều thay vì chấm thẳng ra P0/P1.** Hai chiều tách nhau là chỗ tranh luận
+> trở nên **cụ thể**: *"cái này thiệt hại cao nhưng khả năng thấp"* là một câu **nói được và cãi
+> được**. Còn *"cái này P1"* thì không cãi được — chỉ tin hoặc không tin.
+
+### Mức rủi ro quyết định **độ sâu** test
+
+Đây là chỗ bảng rủi ro trả lại giá trị. Không có bước này thì nó chỉ là bảng trang trí.
+
+| Mức | Test sâu tới đâu | Tự động hoá |
+|---|---|---|
+| **P0** | nhiều kỹ thuật cùng lúc | ✅ ưu tiên, cả hồi quy |
+| **P1** | hai kỹ thuật trở lên, đủ nhánh chính + nhánh lỗi | ✅ nếu ổn định |
+| **P2** | một kỹ thuật, luồng thuận + một nhánh lỗi tiêu biểu | tuỳ |
+| **P3** | danh sách kiểm tay | ❌ |
+
+Và hai luật đi kèm:
+
+- **Thứ tự chạy:** rủi ro cao **và** phụ thuộc thấp làm trước — không phải *"P0 làm hết rồi mới tới P1"*.
+  Một P0 đang bị chặn thì không chạy được; làm P1 sẵn sàng trước là đúng.
+- **Rủi ro P0 không có cách giảm thiểu = chưa đủ điều kiện bắt đầu.** Ghi ra một rủi ro rồi không
+  nói làm gì với nó là ghi cho có.
+
+## Một quyết định kỹ thuật nhỏ, nhưng đáng ghi
+
+Nội dung này lẽ ra trộn thẳng vào kỹ năng lập kế hoạch đã có. **Nhưng không làm vậy** — vì kỹ năng
+đó đã được **đóng dấu nguồn gốc** trỏ về một file của đội QC, còn phần rủi ro đến từ **file khác**.
+
+Trộn vào là file có **hai nguồn gốc**, mà cơ chế đóng dấu chỉ chịu được một → báo khói lắp ở bước
+trước sẽ mất tác dụng với chính file đó.
+
+→ Tách thành file riêng, đóng dấu sạch. Hai file nạp cùng lúc.
+
+> Đây là lần đầu **cơ chế đóng dấu ảnh hưởng ngược lại cách tổ chức file** — và theo hướng đúng:
+> nó ép một file = một nguồn, thay vì để nội dung trộn lẫn rồi không ai truy được về đâu.
+
+Cũng ghi `lấy một phần có chủ ý`: bản gốc có 5 phần, chỉ lấy 2. Ba phần kia trạm 1 đã làm rồi
+(bóc tách yêu cầu · tìm gap · tiêu chí chấp nhận).
+
+## Bảng theo dõi sau B6
+
+| | Trước | Sau |
+|---|---:|---:|
+| đã lấy | 8 | **9** |
+| cố ý chưa lấy, có lý do | 11 | **13** |
+| chưa quyết | 63 | **60** |
+
+## Cái B6 **không** đổi
+
+- Không đổi quy trình PO
+- Không đổi tài liệu nào đang có — chỉ thêm cột vào một bảng vốn đã có
+- Không thêm bước dừng hỏi nào
+
+---
+
+# ✅ B7 — Chốt hình dạng kết quả đầu ra
+
+**Quyết định: 1B · 2A · 3 lăng kính · núm tự-chọn-theo-kích-thước · in dòng bước tiếp.**
+
+## Hai phần tự giải quyết trước khi bàn
+
+| | Kết quả | Vì sao không còn gì để cân |
+|---|---|---|
+| Bản phân tích yêu cầu | **giữ** | B5 vừa đổ thêm nội dung vào chính file này — danh sách *"đang chờ chốt"* từ sổ ẩn số kỹ thuật. Nó không còn chỉ là bản phân tích, mà là chỗ trạm 2 và 3 biết **cái gì đang bị chặn và bởi ai** |
+| Kế hoạch test | **vẫn ở trạm 2** | B6 vừa làm trạm 2 dày lên (cách tính rủi ro, bảy nguồn). Gộp ngược vào trạm 1 bây giờ là một trạm ôm hai việc không liên quan |
+
+## 1 · Hai bản file gap, **một** nguồn dữ liệu
+
+```
+{qc_dir}/{UC-ID}/{nền}/DOC_GAPS.md         ← bản người đọc
+{refinement_dir}/{UC-ID}-qa-findings.yaml  ← bảng điều khiển đọc được
+```
+
+Sinh bản người đọc trước rồi **render** sang bản máy đọc — không phân tích lại lần hai.
+
+PO giờ xem gap của QC **trong cùng bảng điều khiển** đã quen dùng cho việc soát PRD, thay vì phải mở đúng file trong đúng thư mục.
+
+### Hai rào bắt buộc
+
+**Không có nút "chấp nhận rồi tự sửa".** Bảng điều khiển có nút đó, và với gap của việc soát PRD thì đúng — nó chạy ở **thời điểm PRD**, sửa lúc đó là sửa đúng chỗ.
+
+Gap của trạm QC phát hiện **sau khi code đã xong**. Tự sửa PRD ở thời điểm đó là **sửa sau lưng cả dây chuyền**: kịch bản test sinh từ PRD cũ, code sinh từ kịch bản đó, sổ kết quả kiểm thử neo vào kịch bản đó. Đổi PRD mà không đi lại đường ấy thì mọi thứ phía sau **nói dối**.
+
+→ File này để **PO đọc và quyết**, không phải để máy tự áp. Đường sửa vẫn là kênh báo lỗi và đề xuất kịch bản đã có.
+
+**File riêng, không ghi chung.** Ghi chung với file soát PRD sẽ phá cơ chế mà nó dùng để phân biệt *"PRD đổi do chính tôi"* với *"có người lạ sửa"* — và nó sẽ **mãi mãi** tưởng có người sửa sau lưng, mỗi lần chạy đều quét lại toàn bộ kèm cảnh báo giả.
+
+## 2 · Chế độ `--standard` chỉ trả bảng 10 cột
+
+> ⚠️ **Quyết định này bị B9 thay thế.** `--standard` đã bị bỏ hẳn — khuôn 10 cột trở thành
+> **mặc định**. Giữ phần dưới để thấy đường suy nghĩ: chính việc viết ra bảng so sánh này làm
+> lộ ra rằng mọi ô ở cột `--standard` đều **nên** là mặc định. Xem B9.
+
+| | Mặc định | `--standard` |
+|---|---|---|
+| Bảng gap | 9 cột | **10 cột** — thêm *giao cho đội*; ô câu hỏi bắt buộc đủ **bối cảnh → vấn đề → tại sao quan trọng → gợi ý** |
+| Bản cho bảng điều khiển | ✅ | ❌ |
+| Liệt kê tài liệu đã đọc | không bắt buộc | **bắt buộc** |
+| Kèm kế hoạch test | ❌ | ❌ — việc của trạm 2 |
+
+**Bản phân tích yêu cầu vẫn ghi ra** kể cả ở chế độ này. Đội QC coi nó là giấy nháp, nhưng trạm 2 và 3 **đọc nó**.
+
+## 3 · Ba lăng kính bật, hai tắt
+
+| Lăng kính | | Vì sao |
+|---|:---:|---|
+| Dữ liệu & cấu hình | ✅ | **không gì phủ** — thêm nhiều giá trị nhất |
+| Xử lý lỗi | ✅ | không kỹ năng nào chuyên về *"hết số lần thử lại thì đi đâu"* |
+| Giao diện | ✅ | bản thiết kế có trạng thái màn, nhưng **không ai đối chiếu chữ trên nút** giữa các tài liệu |
+| Luật nghiệp vụ | ⏸️ | B1 vừa thu hồi 2 checklist chuyên sâu — trùng |
+| Đối chiếu chéo tài liệu | ⏸️ | B5 làm spec ↔ kỹ thuật; lệnh soát PRD làm PRD ↔ kịch bản test — trùng |
+
+> ⚠️ **Quyết định tắt "đối chiếu chéo" là SAI — đã sửa ở B10.** Lăng kính đó phủ **bốn** cặp tài
+> liệu, không phải hai; **2/4 đang hở**. Lý do *"trùng"* ghi ở đây đúng một nửa.
+> Xem §Kiểm chứng 31 câu hỏi và **B10**.
+
+Bật cả 5 tốn ~5–6 lần; bật 3 còn ~3 lần. **Hai cái tắt là hai cái trùng nhiều nhất**, nên cắt chúng mất ít độ phủ nhất.
+
+## 4 · Núm "tự chọn theo kích thước"
+
+Việc soát PRD **luôn** chia mịn tới từng use case. Trạm QC thì **không** — nó chọn theo kích thước.
+
+> **Vì sao khác nhau.** Ở tầng PRD, gap bỏ sót **đi tiếp im lặng** tới tận lúc chạy thật. Ở trạm QC, gap bỏ sót còn **bốn lớp chặn phía sau**: trạm 3 bật ngược khi không viết nổi giá trị mong đợi · trạm 4 soát độ phủ · trạm 5 phân loại lỗi thật vs script sai.
+>
+> Ép mịn ở đây tốn gấp ~3 lần cho tính năng nhỏ, để đổi lấy một lưới an toàn **đã có ba lớp khác**.
+
+## 5 · In dòng bước tiếp
+
+Đo được ở repo đội QC: **13/14 lần** một lần chạy ra **cả** file gap **và** kế hoạch test. Ở framework đó là **hai lệnh**.
+
+Người quen dây cũ sẽ dừng lại và tưởng đã xong. Dòng `Next` là chỗ duy nhất nói cho họ biết còn một bước.
+
+## Một quyết định thiết kế đáng ghi
+
+Gap đến từ **hai nguồn**, và chúng bổ sung nhau:
+
+| Nguồn | Trả lời câu | Gap là |
+|---|---|---|
+| 4 kỹ năng phân tích | *"yêu cầu là gì?"* | sản phẩm phụ |
+| 3 lăng kính | *"còn thiếu gì?"* | mục tiêu chính |
+
+Nên bước thẩm định chạy **một lần, sau khi gộp** — không phải mỗi nguồn một lần.
+
+> Lý do: phép kiểm chống trùng lặp là *"hai gap cùng gốc thì gộp lại"*, và nó chỉ chạy được khi **thấy toàn bộ** tập. Thẩm định hai tập rời thì trùng lặp chéo nguồn lọt lưới, và PO nhận **hai câu hỏi giống nhau**.
+
+## Hai mâu thuẫn tôi tự tạo ra rồi sửa
+
+Trong lúc viết tôi tạo ra đúng lớp lỗi cả việc này đang chữa — **hai chỗ nói khác nhau về cùng một chuyện**:
+
+1. Bảng ghi *"lăng kính luật nghiệp vụ: tắt"*, nhưng ngay dưới nó vẫn dán nhãn *"(luôn chạy)"*
+2. Cuối file khai *"engine tự thẩm định"*, trong khi trạm QC lại tự thẩm định sau khi gộp
+
+Sửa cả hai. Chỗ thứ hai thay bằng bảng **nói rõ hai cách gọi** thay vì khẳng định một cách — vì cả hai cách đều đúng, tuỳ lệnh gọi có bao nhiêu nguồn gap.
+
+## Ước lượng chi phí — và ba lỗi của tôi
+
+Đo được từ **14 lần chạy thật** ở repo đội QC:
+
+| | |
+|---|---|
+| Gap mỗi lần | trung vị **12**, dải **2–28** |
+| Cấu hình 4 nguồn *(giống framework)* | trung bình **9,4** gap |
+| Ra cả kế hoạch test | **13/14** lần |
+| Đầu ra mỗi lần | file gap ~21.700 B + kế hoạch test ~21.400 B |
+
+**Phát hiện ngược trực giác:** đọc **ít** tài liệu → tìm ra **nhiều** gap hơn.
+
+```
+Chỉ PRD        → 14,0 gap
+Đủ 4 nguồn     →  9,4 gap
+```
+
+Không phải vì đọc nhiều thì lười tìm, mà vì **tài liệu bổ sung TRẢ LỜI bớt câu hỏi**. PRD viết *"hiển thị thông báo lỗi phù hợp"* → đọc riêng PRD là gap; có kịch bản test ghi rõ nội dung thông báo → hết gap.
+
+Điều này **ủng hộ B5**: đọc thêm tài liệu kỹ thuật không chỉ **bắt thêm** lệch nghiệp vụ ↔ kỹ thuật, mà còn **loại bớt** câu hỏi thừa gửi PO. Lúc quyết B5 tôi chỉ lập luận vế đầu.
+
+**Ba lỗi trong ước lượng của tôi**, đều cùng hướng ước thấp:
+
+| # | Lỗi |
+|---|---|
+| 1 | Kích thước tài liệu nguồn — **bịa**, và vẫn chưa đo được (submodule spec chưa checkout) |
+| 2 | Số gap giả định 10 → thật là 9,4 ở cấu hình framework |
+| 3 | Chỉ tính đầu ra là file gap — quên kế hoạch test, thiếu ~80% ở khâu đó |
+
+**Tỉ lệ giữa hai lựa chọn:** sinh thêm bản file gap ~**3%** của phần đội thêm; bật lăng kính ~**97%**. Chọn định dạng file gần như miễn phí; **số lăng kính là toàn bộ câu chuyện.**
+
+---
+
+# ✅ B8 — Bật lăng kính QC ở bước soát PRD
+
+**Ý này của bạn, không phải của tôi** — và nó làm tổng thể tốt hơn bản B7 vừa xong.
+
+## Câu hỏi
+
+*"Bật lăng kính QC ở bước soát PRD, dùng đúng nội dung vừa xây, rồi trạm QC chỉ ra file gap — có tối ưu hơn không?"*
+
+Trong ý đó có **ba việc**. Kiểm rồi thì **chỉ một nên làm** — nhưng làm nó thì đúng là tốt hơn.
+
+## Việc nên làm: bật lăng kính QC ở bước soát PRD ✅
+
+Framework đã có sẵn một lăng kính QC ở bước soát PRD, **viết xong rồi tắt đi**, kèm công thức bật lại 5 bước.
+
+Điểm mấu chốt khi đọc kỹ: lăng kính đó **không phải "tìm mọi gap"**. Nó hỏi đúng **hai câu về hình thức**:
+
+> *"Tiêu chí chấp nhận này có nêu kết quả **quan sát / kiểm chứng được** không?"*
+> *"Tiêu chí chấp nhận có lặp lại nội dung của luật nghiệp vụ không?"*
+
+Và nó **tự cấm** hỏi câu thứ ba: *"KHÔNG hỏi 'tiêu chí đủ chi tiết chưa' — câu đó kéo cơ chế kỹ thuật vào tiêu chí nghiệm thu"*.
+
+Cả hai câu nó hỏi đều **trả lời được từ PRD một mình**. Không cần bản thiết kế, không cần kịch bản test, không cần tài liệu kỹ thuật.
+
+| | |
+|---|---|
+| **Rẻ** | Bước soát PRD **đã** chạy quét song song với 3 lăng kính. Thêm cái thứ tư = cộng vào một lần chạy đã có |
+| **An toàn** | Chạy ở thời điểm PRD → nút *"chấp nhận rồi tự sửa PRD"* là **đúng**, vì phía sau chưa có gì để lỗi thời. Đây chính là thứ B7 phải tắt |
+| **Sẵn sàng** | Công thức bật lại đã viết trong file từ trước |
+
+## Hai việc KHÔNG làm — và lý do
+
+### Không chuyển 3 lăng kính của trạm QC lên đây ❌
+
+Không phải vì không nên, mà vì **không chạy được**. Thứ tự dây chuyền:
+
+```
+Discovery → [PRD ◀ bước soát] → Bản thiết kế → Kịch bản test → Tài liệu kỹ thuật → Code → QC
+```
+
+Ở thời điểm soát PRD, **chỉ có PRD**:
+
+| Lăng kính | Cần đọc | Có ở thời điểm PRD? |
+|---|---|---|
+| Xử lý lỗi | nhánh lỗi nghiệp vụ — phần lớn ở PRD | ✅ phần lớn |
+| Giao diện | **bản thiết kế** | ❌ chưa tồn tại |
+| Dữ liệu & cấu hình | bảng tính điểm ở PRD; **cờ tính năng + môi trường ở tài liệu kỹ thuật** | ⚠️ nửa |
+| Đối chiếu nghiệp vụ ↔ kỹ thuật *(B5)* | **tài liệu kỹ thuật** | ❌ chưa tồn tại |
+
+Và có vấn đề sâu hơn cả việc thiếu file:
+
+> Ở thời điểm PRD **không thể phân biệt** *"PRD thiếu X"* với *"PRD cố ý để X cho bản thiết kế"*.
+>
+> Câu hỏi lọc quan trọng nhất của bước thẩm định là *"chỗ này đã được trả lời ở tài liệu khác chưa?"* — mà ở đây **không có tài liệu khác để tra**. Bộ lọc mất tác dụng.
+
+Số liệu 14 lần chạy thật xác nhận:
+
+```
+Chỉ đọc PRD     → 14,0 gap trung bình
+Đọc đủ 4 nguồn  →  9,4 gap trung bình
+```
+
+Khoảng **5 gap chênh lệch** phần lớn là câu hỏi mà tài liệu sau **trả lời hộ**. Đưa lăng kính nội dung lên thời điểm PRD là **cố tình sinh ra 5 gap đó rồi gửi PO**.
+
+Đây chính là lý do lăng kính gốc **tự bó hẹp vào câu hỏi hình thức**. Người viết nó đã nhìn ra chuyện này từ trước.
+
+### Không bỏ bản file cho bảng điều khiển ở trạm QC ❌
+
+Có một lớp gap **chỉ tồn tại ở thời điểm QC**: kịch bản test nói khác PRD · tài liệu kỹ thuật nói khác PRD *(ca "lớp 1–6 vs 1–9")* · không có dữ liệu để tự kiểm chứng kết quả tính · ẩn số thiết kế đang chờ chốt.
+
+Không cái nào tồn tại được ở thời điểm PRD. Bỏ bản đó là đẩy chúng về lại một file trong thư mục — đúng vấn đề mà B7 vừa giải.
+
+## Cái thật sự tốt hơn: **lọc hai tầng**
+
+Không phải thay thế, mà là **tầng rẻ chạy trước, tầng đắt chạy sau trên đầu vào đã sạch hơn**:
+
+```
+Thời điểm PRD   lăng kính QC (hình thức)   →  tiêu chí nào không kiểm chứng được
+                                              → sửa NGAY, chưa có gì phía sau để lỗi thời
+
+Thời điểm QC    3 lăng kính + đối chiếu    →  gap CHỈ có ở đây
+                                              và ÍT HƠN, vì tầng trên đã dọn
+```
+
+| | Chỉ có B7 | Thêm B8 |
+|---|---|---|
+| Tiêu chí không kiểm chứng được | phát hiện ở **thời điểm QC** → gửi PO → PO sửa PRD → kịch bản test lỗi thời → sinh lại | phát hiện ở **thời điểm PRD** → sửa luôn → chưa có gì phía sau |
+| Số gap ở trạm QC | như cũ | **ít hơn** |
+| Chi phí thẩm định ở QC | tỉ lệ số gap | **giảm theo** |
+| PO nhận gì | gap ở hai thời điểm, lẫn loại | **loại hình thức sớm, loại nội dung muộn** — mỗi loại đúng lúc sửa được |
+
+## Chi phí — con số này chắc hơn các con số trước
+
+Lần này suy được từ **công thức trong engine**, không phải giả định về kích thước tài liệu.
+
+Bước soát PRD chạy ba giai đoạn, chỉ **một** phụ thuộc số lăng kính:
+
+| Giai đoạn | Tăng khi thêm lăng kính? |
+|---|---|
+| Quét song song | ✅ tổng lượt đọc = *lăng kính × phạm vi* → **+33%** |
+| Vòng phê bình | ❌ **0%** — mỗi lượt là **một** luồng đọc toàn bộ, không liên quan số lăng kính |
+| Gộp & khử trùng | tăng chút |
+
+**Và số luồng KHÔNG tăng.** Engine chặn ở 12 luồng, chia nhóm để vừa:
+
+```
+3 lăng kính  →  4 nhóm  →  3 × 4 = 12 luồng
+4 lăng kính  →  3 nhóm  →  4 × 3 = 12 luồng   ← Y HỆT
+```
+
+Nên chi phí cố định mỗi luồng **không tăng chút nào**; chỉ khối lượng đọc tài liệu tăng.
+
+**Hệ quả ngược trực giác: PRD càng lớn thì % tăng càng NHỎ.**
+
+| PRD | 3 lăng kính | 4 lăng kính | Tăng |
+|---|---|---|---|
+| ≤ 2 use case | 9 luồng | **12 luồng** | ~**+33%** — chưa chạm chặn |
+| ≥ 4 use case | 12 luồng *(đã chặn)* | 12 luồng *(đã chặn)* | ~**+13%** — chỉ đọc tăng |
+
+Ba điều làm nhẹ thêm:
+
+1. **Bước soát PRD chỉ đọc MỘT tài liệu** (PRD), so với trạm QC đọc **bốn**. Cùng phần trăm nhưng cơ số nhỏ hơn nhiều.
+2. **Chỉ lần chạy đầu là toàn bộ** — nó có chế độ chỉ quét phần đã đổi cho các lần sau.
+3. **Có tiết kiệm ở phía đối diện** — trạm QC gặp ít gap loại đó hơn. *(Không đo được, nên không tính vào.)*
+
+> So sánh cái đáng so: cùng một việc, làm ở bước soát PRD tốn **+13–33% của một lần chạy nhỏ**; để ở trạm QC thì nó là **+300% của một lần chạy lớn**.
+
+## Đã đổi gì
+
+Áp đúng công thức 5 bước có sẵn trong file:
+
+1. Đưa lăng kính QC ra khỏi khối bị vô hiệu, đặt **đầu** danh sách
+2. Đổi *3 lăng kính / cả ba* → *4 lăng kính / cả bốn* ở 4 chỗ + file engine dùng chung
+3. Thêm `QA` vào danh sách giá trị hợp lệ + bảng tổng hợp
+4. Thêm `QA` vào ghi chú *"phán đoán DEV/SA/PO"*
+5. Dựng lại
+
+Thêm hai thứ không có trong công thức:
+
+- **Khối ghi rõ phạm vi lăng kính** — hình thức, KHÔNG phải nội dung — kèm lý do và số liệu. Để người sau **không nới nó ra** mà tưởng đang làm tốt hơn.
+- **Công thức TẮT LẠI**, đối xứng với công thức bật. Bản gốc chỉ có một chiều.
+
+## Một lỗi tôi bắt được nhờ B4
+
+Sau khi sửa lệnh, `docs/explain/03-refine-prd.md` vẫn ghi *"3 lăng kính"* ở **5 chỗ**.
+
+Đây **đúng lớp lỗi tôi vừa sửa ở B4** — tài liệu mô tả nói ngược với lệnh, và không cơ chế nào canh chuyện đó. Sửa cả 5 chỗ, thêm dòng giải thích phạm vi.
+
+> Lần này tôi tự đi kiểm vì B4 đã dạy phải kiểm. Nhưng nó cho thấy **báo khói vẫn còn một lỗ**: nó canh *"lệnh trỏ vào kỹ năng có tồn tại"*, **không** canh *"tài liệu mô tả có khớp lệnh"*. Đáng thêm, nhưng khó — vì so văn xuôi với văn xuôi.
+
+---
+
+# ✅ B9 — Bỏ chế độ `--standard`, gộp cái tốt vào mặc định
+
+**Câu hỏi của bạn:** *"Nếu đã ghi 2 file, thì `--standard` để làm gì nữa?"*
+
+Đi kiểm thì đúng — nó **gần như không còn lý do tồn tại**.
+
+## Ba dữ kiện đã đo
+
+**1 · Không có công cụ nào đọc file gap.** Grep toàn bộ repo đội QC: file gap xuất hiện đúng
+**một** lần, và là một **dòng chú thích** trong file test (*"xem DOC_GAP"*). Không script, không
+parser, không CI. File gap là **để người đọc**.
+
+**2 · Cột thứ 10 không được bước sau dùng.** Cột *"Giao cho đội"* — khác biệt chính giữa hai
+khuôn — **không** được bước thiết kế test, bước soát, hay bước tổng hợp đọc. Nó là thông tin cho
+**người**, không phải khoá liên kết giữa các bước.
+
+**3 · Khác biệt còn lại là thẩm mỹ, không phải chức năng.**
+
+## Đối chiếu từng khác biệt
+
+| Khác biệt | Là lý do cần một chế độ riêng? |
+|---|---|
+| Cột *Giao cho đội* | ❌ **nên có ở mặc định** — framework thiếu nó là thiếu |
+| Câu hỏi 4 phần *(bối cảnh → vấn đề → tại sao quan trọng → gợi ý)* | ❌ **nên có ở mặc định** — B3 đã ghi *"framework thiếu hai thứ PO cần"* |
+| Section *tài liệu đã đọc* | ❌ **nên có ở mặc định** — đây là căn cứ độ phủ |
+| Cách đánh số gap | ❌ đổi thẳng được |
+| Từ `Blocker` vs `Critical` | ⚠️ **cái duy nhất nối vào bước sau** |
+| Không ghi bản cho bảng điều khiển | ❓ ai lại muốn **ít** thông tin hơn? |
+
+Chỉ **một** dòng thật sự vướng: `/qc-run-test` đọc `🔴 Blocker` để đặt *"scenario này đang chờ PO"*
+vào sổ kết quả.
+
+## Đã đổi gì
+
+**Bỏ hẳn `--standard`.** Mặc định giờ là khuôn 10 cột của đội QC:
+
+```
+{qc_dir}/{UC-ID}/{nền}/
+├── REQUIREMENT_ANALYSIS.md      handoff nội bộ cho trạm 2 và 3
+└── DOC_GAP.md                   10 cột + section "tài liệu đã đọc"
+{refinement_dir}/
+└── {UC-ID}-qa-findings.yaml     bản cho bảng điều khiển
+```
+
+**Hợp nhất hai template thành một.** Bản 9 cột đã xoá.
+
+**Giữ từ `Blocker`** thay vì `Critical` — đây là chỗ **cố ý khác upstream**, và lý do được ghi
+ngay trong template: đổi từ là đứt liên kết với sổ kết quả. Ba mức còn lại giữ nguyên upstream.
+
+**Đổi tên file: `DOC_GAPS.md` → `DOC_GAP.md`** — 33 file trong nguồn.
+
+> **Vì sao không dùng `DOC_GAP_{UC-ID}.md` như đội QC.** Họ dùng hai kiểu: 10 file có hậu tố UC,
+> 4 file không. Nhưng **cả 10 file có hậu tố đều nằm trong thư mục vốn đã mang UC** — tức chính
+> họ cũng lặp. Framework đặt file trong `{qc_dir}/{UC-ID}/{nền}/`, nên thêm hậu tố là lặp UC-ID
+> **hai lần** trong đường dẫn. Chọn `DOC_GAP.md`: khớp từ vựng đội QC (bỏ chữ `S`), và cũng là
+> một trong hai kiểu họ dùng thật.
+
+## Bốn lý do bỏ chế độ riêng
+
+**1 · Không nuôi một bản kém hơn làm mặc định.** Bản 9 cột thiếu đúng hai thứ PO cần. Giữ nó làm
+mặc định rồi để bản tốt sau một cờ là **để người không biết có cờ đó nhận bản kém**.
+
+**2 · Hai template = hai chỗ phải bảo trì.** Đội QC cải tiến bảng của họ thì ta phải đồng bộ
+**hai** bản, và chúng sẽ lệch. Đúng bệnh cả việc này đang chữa.
+
+**3 · Chế độ mà khác biệt duy nhất là "ghi ít file hơn" thì không phải chế độ.** Nó là một cờ
+`--no-findings`, và chẳng ai cần cờ đó.
+
+**4 · Kỳ vọng ban đầu vẫn được đáp — tốt hơn.** Yêu cầu gốc là *"`--standard` trả về đúng kết quả
+gốc đội QC"*. Giờ **mặc định** đã là khuôn của họ → họ nhận đúng thứ họ quen mà **không cần gõ
+cờ nào**.
+
+## Một cái bẫy bắt được ngay tại chỗ
+
+Sau khi xoá hai template cũ và dựng lại, `core/` sạch — nhưng bản chạy thử tại chỗ **vẫn còn cả
+hai file cũ**.
+
+Đây **đúng cơ chế đã gây sự cố 35 file** ở B4: bản chạy thử là bản copy-đè, **không tự dọn**. Nên
+nó thấy sạch trong khi bản phát hành mới là bản đúng — và lần này ngược lại: bản phát hành đúng,
+bản chạy thử còn rác.
+
+Dọn tay. Ba tầng giờ khớp: **7 file mỗi tầng**.
+
+> Báo khói lắp ở B4 **không bắt được cái này** — nó canh *"lệnh trỏ vào kỹ năng có tồn tại"*,
+> không canh *"bản chạy thử có file lạ không có ở bản nguồn"*. Đáng thêm một nhánh nữa.
+
+## Và một lỗi thứ hai — đã bít bằng nhánh báo khói mới
+
+Script đổi tên hàng loạt `DOC_GAPS → DOC_GAP` quét **cả phần khai nguồn gốc** ở đầu file, nên nó
+sửa luôn dòng *"lấy từ file nào của đội QC"* thành một tên **không tồn tại** ở bản gốc.
+
+Báo khói **vẫn báo xanh**. Vì nhánh kiểm mã nguồn gốc chỉ so **mã**, mà mã thì vẫn khớp — đường
+dẫn sai không làm mã sai. Chỉ lộ ra khi tôi kiểm tay.
+
+> Mất đường dẫn nguồn gốc là **mất nửa mốc so sánh**: biết *"mã nào"* mà không biết *"của file nào"*.
+> Lần đồng bộ sau sẽ so với một file không có thật.
+
+**Đã thêm nhánh mới:** đường dẫn nguồn gốc khai trong file phải **khớp bảng theo dõi** *và* phải
+**tồn tại thật** ở bản gốc. Thử lại đúng ca vừa lọt → báo khói kêu, **cả hai góc**.
+
+Đây là nhánh thứ năm. Bốn nhánh trước sinh ra từ hai sự cố ở B4; nhánh này sinh ra từ một sự cố
+ở B9. **Cứ mỗi lần lọt một lỗi mới, báo khói dày thêm một tầng** — và lần nào cũng là loại lỗi
+*im lặng*, không phải loại báo ầm ĩ.
+
+## Cái B9 **không** đổi
+
+- Không đổi quy trình PO — PO nhận **nhiều** thông tin hơn, không ít hơn
+- Không đổi từ `Blocker` nên sổ kết quả và các bước sau không bị đụng
+- Không đổi số file đầu ra
+
+---
+
+# ✅ B10 — Bật lại "đối chiếu chéo", thu hẹp còn hai cặp
+
+**Sửa quyết định sai ở B7.** Bảng kiểm chứng 31 câu hỏi (ngay dưới) là thứ chứng minh nó sai.
+
+## Đã bật gì
+
+Lăng kính *"đối chiếu chéo tài liệu"* phủ **bốn cặp**. Giờ chạy **hai**:
+
+| Cặp | | Vì sao |
+|---|---|---|
+| `PRD ↔ design-spec/` | ✅ **SO** | **không ai đối chiếu nội dung.** Lệnh sinh kịch bản test chỉ kiểm *số phiên bản* — cùng phiên bản mà nội dung lệch thì lọt |
+| `bdd/ ↔ design-spec/` | ✅ **SO** | không ai |
+| `PRD ↔ bdd/` | ❌ bỏ | lệnh soát tài liệu đã làm |
+| `PRD·bdd/ ↔ tech-docs/` | ❌ bỏ | B5 đã làm |
+
+**Cả hai cặp bật đều dính `design-spec/`** — thứ **Designer vẽ**. Đây là artifact **duy nhất**
+trong bộ tài liệu tính năng mà không ai đối chiếu nội dung với nó.
+
+> ⚠️ Đừng lẫn `design-spec/` với `tech-docs/`. Cái đầu là **giao diện người dùng thấy**; cái sau
+> là **hợp đồng hệ thống** — và `tech-docs/` đã được B5 phủ. Hai tên tiếng Việt nghe gần giống
+> nhau, đọc nhầm là hiểu ngược kết luận. Xem §Từ vựng đầu nhật ký.
+
+## Bốn hướng lệch — và vì sao phải phân biệt
+
+| Hướng | Nghĩa | Ai xử lý |
+|---|---|---|
+| **THIẾU** | PRD có màn/trạng thái/hành vi mà Designer **không vẽ** | Designer bổ sung |
+| **THỪA** | Designer **tự thêm** màn/nút mà PRD không định nghĩa | **PO chốt**: giữ (rồi định nghĩa hệ quả vào PRD) hay gỡ |
+| **MÂU THUẪN** | cùng hành vi/giá trị/chữ nhưng hai tài liệu nói khác | PO + Designer |
+| **LỆCH-REF** | bản thiết kế trích số yêu cầu đã đổi nghĩa | PO |
+
+> **THIẾU và THỪA xử lý ngược nhau**, nên gọi nhầm hướng là **đặt sai đề bài cho cả hai người**:
+> một bên tưởng phải vẽ thêm, một bên đáng lẽ phải quyết giữ hay gỡ.
+
+## Với cặp kịch bản test ↔ bản thiết kế — soi gì
+
+- Kịch bản đi qua một **trạng thái màn** mà bản thiết kế không có (đang tải / lỗi / rỗng)?
+- Kịch bản tác động lên một **thành phần giao diện** không có trong danh sách thành phần?
+- Bản thiết kế mô tả một **đường điều hướng** mà không kịch bản nào đi qua?
+
+## Chi phí — rẻ hơn ước lượng ban đầu
+
+Hai lý do:
+
+1. **Chỉ so 2 cặp**, không phải 4 — nửa khối lượng của một lăng kính đầy đủ.
+2. **Trạm QC đã đọc bản thiết kế từ trước** — nó nằm trong danh sách nguồn từ đầu. Nên đây không
+   phải *"đọc thêm tài liệu"*, mà là *"đã đọc rồi, giờ bắt nó **so** thay vì chỉ **đọc**"*.
+   Không nạp thêm file nào.
+
+Cấu hình hiện tại: 3 lăng kính đầy đủ + 1 thu hẹp ≈ **~3,5 lần** so với không bật lăng kính nào.
+
+## Chốt lại: 4/5 lăng kính đang bật
+
+| Lăng kính | | Bằng chứng |
+|---|---|---|
+| Xử lý lỗi | ✅ | 4/6 câu không ai hỏi |
+| Giao diện | ✅ | 1/8 phủ tốt, 3 hở hẳn |
+| Dữ liệu & cấu hình | ✅ | **6/6 câu không ai hỏi** |
+| Đối chiếu chéo | ✅ thu hẹp | 2/4 cặp đang hở |
+| **Luật nghiệp vụ** | ⏸️ **duy nhất tắt** | 4/5 câu đã có chỗ hỏi, **và hỏi cụ thể hơn** |
+
+## Đã ghi chống tái phát
+
+Cả hai file — lệnh và định nghĩa lăng kính — đều mang một dòng ghi **vì sao `D5` từng bị tắt** và
+kết luận rằng lý do đó **đúng một nửa**, kèm câu:
+
+> *"Đừng tắt lại `D5` mà không đọc bảng kiểm chứng 31 câu hỏi."*
+
+Vì lỗi ban đầu không phải lỗi kiến thức mà là **lỗi phương pháp**: suy từ ấn tượng thay vì đếm
+danh sách. Người sau đọc thấy *"nghe trùng"* rất dễ tắt lại đúng như tôi đã làm.
+
+---
+
+# 🔍 Kiểm chứng — 31 câu hỏi của 5 lăng kính, từng câu một
+
+> **Vì sao có phần này.** Quyết định bật/tắt lăng kính ở B7 dựa trên **ấn tượng**
+> (*"cái này nghe trùng"*), không phải trên danh sách. Phần này làm lại tử tế: đọc **đủ 31 câu
+> hỏi** của 5 lăng kính, đối chiếu từng câu với chỗ khác trong framework, và ghi bằng chứng.
+>
+> **Kết quả: 4/5 quyết định đúng, 1 SAI.** Chi tiết ở cuối.
+
+## Cách đọc bảng
+
+| Ký hiệu | Nghĩa |
+|---|---|
+| ✅ **phủ tốt** / **phủ hơn** | chỗ khác đã hỏi, và hỏi **cụ thể hơn** |
+| 🟡 **một phần** | có chạm tới, nhưng không hỏi đúng câu đó |
+| 🔴 **hở** | **không ai hỏi câu này** |
+
+---
+
+## D1 · Luật nghiệp vụ — ⏸️ tắt
+
+| Câu hỏi lăng kính đặt ra | Chỗ khác đã hỏi gì | |
+|---|---|---|
+| Điều kiện đủ chưa? Thiếu nhánh nào? | `business-rules` — *"bảng phân luồng đọc **cả hai chiều**; bảng N loại tài khoản × M màn → duyệt **từng ô**"* | ✅ phủ hơn |
+| Ngưỡng chốt số chưa? | `business-rules` + `spec-breakdown` — *"mọi ô nhập, **kể cả ô không bắt buộc**: min/max · ký tự cho phép · trim · định dạng"* | ✅ phủ hơn |
+| Trường hợp biên chưa xử lý? | `business-rules` *(tiêu chí có sub-case → đếm ra)* + `spec-breakdown` *(trạng thái, luồng phụ)* | 🟡 một phần — biên **đầu vào** có, biên **nghiệp vụ** chung chung |
+| Rule mâu thuẫn giữa tài liệu? | `business-rules` §Kết quả — *"rule mâu thuẫn/không rõ → ghi thành câu hỏi"* | ✅ phủ |
+| Chỗ buộc phải giả định? | `business-rules` + `spec-breakdown` §F — *"điều suy ra được vs điều cần xác nhận"* | ✅ phủ |
+
+**4/5 phủ tốt hoặc tốt hơn → tắt là đúng.**
+
+---
+
+## D2 · Xử lý lỗi — ✅ bật
+
+| Câu hỏi lăng kính đặt ra | Chỗ khác đã hỏi gì | |
+|---|---|---|
+| Quá hạn → hành vi là gì? | `data-flow` chỉ **liệt kê** "timeout" là một *loại* điểm thất bại, **không hỏi hành vi** | 🔴 hở |
+| Số lần thử lại? Khoảng cách? | — | 🔴 hở |
+| Hết số lần thử → đi đâu? | — | 🔴 hở |
+| Hàng đợi lỗi: ai xử lý? có cảnh báo? | `data-flow` có nhắc hàng đợi, **không hỏi ai xử lý lỗi** | 🔴 hở |
+| Từng loại lỗi: màn nào hiện, làm gì tiếp? | tài liệu kỹ thuật §8 **có bảng** — nhưng đó là **đầu ra của người viết tài liệu**, không phải câu hỏi QC đặt ra | 🟡 một phần |
+| Khôi phục: thử lại được? bị chặn? | — | 🔴 hở |
+
+**4/6 hoàn toàn không ai hỏi → bật là đúng.**
+
+---
+
+## D3 · Giao diện — ✅ bật
+
+| Câu hỏi lăng kính đặt ra | Chỗ khác đã hỏi gì | |
+|---|---|---|
+| Trạng thái màn thiếu gì? | bản thiết kế **bắt buộc** có `default / loading / error`, thêm `empty` nếu màn có thể rỗng | ✅ phủ tốt |
+| Chữ & nhãn nhất quán **giữa các tài liệu**? | — | 🔴 hở |
+| Điều hướng đủ mọi đường chưa? | bản thiết kế §Hành động & Điều hướng — **mô tả**, không kiểm đủ | 🟡 một phần |
+| Thông báo lỗi có **nội dung cụ thể** chưa? | `review-context` R7 đòi giá trị cụ thể — nhưng cho **kịch bản test**, không cho nội dung thông báo | 🟡 một phần |
+| Trạng thái biên: rỗng, kết quả 0? | bản thiết kế có `empty` state | 🟡 một phần |
+| UI đã gỡ ở PRD nhưng còn trong thiết kế? | — | 🔴 hở |
+| Đa nền nhất quán? | bản thiết kế mô tả **riêng từng nền**, không đối chiếu chúng với nhau | 🟡 một phần |
+| Tài nguyên hiển thị đã xác định? | — | 🔴 hở |
+
+**1/8 phủ tốt, 3 hở hẳn → bật là đúng.**
+
+---
+
+## D4 · Dữ liệu & cấu hình — ✅ bật
+
+| Câu hỏi lăng kính đặt ra | Chỗ khác đã hỏi gì | |
+|---|---|---|
+| Đủ dữ liệu để **tự kiểm chứng kết quả tính**? | — | 🔴 hở |
+| Dữ liệu mẫu đủ dựng môi trường test? | — | 🔴 hở |
+| Cấu hình đổi **giữa lúc đang chạy** → hành vi? | — | 🔴 hở |
+| Phụ thuộc môi trường đã spec? | `data-flow` liệt kê chặng, **không hỏi môi trường test** | 🔴 hở |
+| Dựng dữ liệu phụ thuộc thứ chưa có? | — | 🔴 hở |
+| Cờ tính năng ảnh hưởng gì? Giá trị mặc định? | — | 🔴 hở |
+
+**6/6 không ai hỏi → đây là lăng kính đáng giá nhất trong cả năm.**
+
+---
+
+## D5 · Đối chiếu chéo tài liệu — ⏸️ tắt ← **quyết định SAI**
+
+Lăng kính này phủ **bốn cặp** tài liệu, không phải hai.
+
+*(Tra §Từ vựng đầu nhật ký nếu quên — ② **bản thiết kế** `design-spec/` là Designer vẽ gì;
+④ **tài liệu kỹ thuật** `tech-docs/` là hệ thống nhận/trả gì. Hai file khác nhau.)*
+
+| Cặp tài liệu | Tên thật | Chỗ khác đã làm gì | |
+|---|---|---|---|
+| ① PRD ↔ ③ kịch bản test | `PRD` ↔ `bdd/` | `review-context` — yêu cầu nào chưa có kịch bản | ✅ phủ |
+| ①③ ↔ ④ tài liệu kỹ thuật | `PRD·bdd/` ↔ `tech-docs/` | trạm QC §Đối chiếu *(thêm ở B5)* — 6 mục | ✅ phủ |
+| ① PRD ↔ ② **bản thiết kế** | `PRD` ↔ **`design-spec/`** | lệnh sinh kịch bản test chỉ so **số phiên bản** *("thiết kế dựng từ PRD v2, PRD giờ v3")*. **Cùng phiên bản mà nội dung lệch thì không ai thấy** | 🔴 hở nội dung |
+| ③ **kịch bản test** ↔ ② **bản thiết kế** | `bdd/` ↔ **`design-spec/`** | — | 🔴 hở hẳn |
+
+**2/4 hở — và cả hai cặp hở đều dính ② `design-spec/`, tức phần Designer vẽ.**
+
+> ④ `tech-docs/` **không liên quan** tới lỗ này — B5 đã phủ nó. Đây là chỗ dễ nhầm nhất, vì hai
+> cái tên tiếng Việt nghe gần giống nhau.
+
+### Lỗ đó cụ thể là gì
+
+Cả hai ca đều nằm ở **② `design-spec/`** — thứ Designer vẽ:
+
+| Ca | Hướng | Xử lý |
+|---|---|---|
+| Designer vẽ nút *"Bỏ qua ngay"* mà PRD **không định nghĩa** | **THỪA** *(thiết kế > PRD)* | PO chốt: giữ (rồi định nghĩa hệ quả vào PRD) hay gỡ đi |
+| PRD có màn *"chờ 5 giây"* mà Designer **không vẽ** | **THIẾU** *(thiết kế < PRD)* | bổ sung vào bản thiết kế |
+| Kịch bản test đi qua một trạng thái màn mà bản thiết kế **không có** | **THIẾU** | bổ sung, hoặc sửa kịch bản |
+
+**Hai hướng xử lý ngược nhau** — gọi nhầm hướng là đặt sai đề bài cho cả PO lẫn Designer.
+Lăng kính này phân biệt được. Hiện **không ai làm**.
+
+---
+
+# Tổng kết
+
+| | Quyết định ở B7 | Bằng chứng | |
+|---|---|---|---|
+| **D1** Luật nghiệp vụ | tắt | 4/5 phủ tốt hơn | ✅ đúng |
+| **D2** Xử lý lỗi | bật | 4/6 không ai hỏi | ✅ đúng |
+| **D3** Giao diện | bật | 3/8 hở hẳn | ✅ đúng |
+| **D4** Dữ liệu & cấu hình | bật | **6/6 không ai hỏi** | ✅ đúng nhất |
+| **D5** Đối chiếu chéo | tắt | **2/4 hở** | ❌ **SAI** |
+
+## Vì sao sai ở D5
+
+Tôi thấy **hai cặp đầu** đã có người làm nên kết luận *"trùng nhiều"* — mà **không đếm hết**
+lăng kính này phủ **bốn** cặp.
+
+Đó là suy từ ấn tượng, không phải từ danh sách. **Đúng loại lỗi cả việc này đang chữa: khẳng
+định không có bằng chứng đằng sau.** Và nó lọt vì không có bảng nào như bảng trên — bảng này
+đáng lẽ phải làm **trước** khi quyết, không phải sau.
+
+## Sửa — ĐÃ LÀM ở B10
+
+**Bật lại D5, thu hẹp còn đúng hai cặp đang hở:**
+
+```
+CHỈ đối chiếu:   PRD           ↔  design-spec/     ← ① ↔ ②
+                 bdd/*.feature ↔  design-spec/     ← ③ ↔ ②
+
+BỎ (đã có người làm):
+                 PRD           ↔  bdd/             ← review-context
+                 PRD · bdd/    ↔  tech-docs/       ← B5
+```
+
+Thu hẹp thế thì nó **không làm lại việc đã có**, chỉ bịt đúng chỗ hở.
+
+**Rẻ hơn ước lượng ban đầu** (~+15–20%, có thể ít hơn): trạm QC **đã đọc `design-spec/` rồi** —
+nó nằm trong danh sách nguồn từ đầu. Nên đây không phải *"đọc thêm tài liệu"*, mà là *"đã đọc
+rồi, giờ bắt nó **so** với hai tài liệu kia"*. Không nạp thêm file nào.
+
+---
+
+# Các bước còn lại
+
+**Chín bước B0–B9 đã xong.** Không còn bước nào đang chờ quyết định để bắt đầu.
+
+Nhưng có **một quyết định sai đã phát hiện** và **hai 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).
+
+> **Nhật ký này chỉ ghi bước đã hoàn thành** — mỗi bước xong mới nạp vào đây, không viết trước.
+
+---
+
+## Những gì đã kiểm chứng sau mỗi bước
+
+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
+- 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
+
+---
+
+## Còn treo
+
+| # | Câu | Mức | Ai quyết |
+|---|---|---|---|
+| **1** | Chạy thử trên một tính năng thật — **chín bước, chưa một lần chạy**. Ướ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 | 🟠 | bạn |
+| 3 | 30 file không có bản gốc — framework tự sở hữu, gộp lại, hay ghép tay? | 🟡 nợ | bạn |
+| 4 | Có lấy lại 38 dòng đã mất của phần "lập kế hoạch test" không? | 🟡 nợ | bạn |