init git

.claude/skills/ba-traceability/GUIDE.md

@@ -0,0 +1,151 @@
+# Hướng dẫn sử dụng — `ba-traceability` (xuyên suốt)
+
+## Skill này làm gì
+
+Trả lời đúng một câu hỏi: **"có cái gì bị rơi giữa các tài liệu không?"**
+
+Nó đọc toàn bộ artifact của một project, trích mọi ID (`RQ`, `US`, `BR`, `AC`, `NFR`…), rồi
+đối chiếu chéo để tìm bốn loại lỗ hổng:
+
+| Loại lỗ hổng | Nghĩa là |
+|---|---|
+| **Yêu cầu bị bỏ quên** | Khách yêu cầu, không ai làm |
+| **Scope creep** | Team làm, không ai yêu cầu |
+| **AC không được test** | Yêu cầu không được kiểm chứng |
+| **Tham chiếu gãy** | Spec nhắc `BR-021`, tìm không ra ⇒ dev tự quyết |
+
+Nó **có quyền chặn Gate G2, G3, G4**.
+
+## 🔴 Nó không sửa tài liệu
+
+Skill này chỉ phát hiện và báo cáo, kèm chỉ dẫn skill nào cần chạy để sửa. Tự sửa sẽ che
+mất vấn đề thay vì giải quyết nó.
+
+## Khi nào gọi
+
+| Tình huống | Có nên gọi |
+|---|---|
+| Vừa chạy xong một skill giai đoạn | ✅ **Nên thành thói quen** |
+| Chuẩn bị họp duyệt gate | ✅ Bắt buộc |
+| Vừa sửa một `BR` hoặc `AC` | ✅ Để biết chỗ nào phải sửa theo |
+| Nhận bàn giao dự án từ BA khác | ✅ Cách nhanh nhất để biết tài liệu thiếu gì |
+| Sếp hỏi "đã phủ hết yêu cầu chưa" | ✅ |
+| Lần đầu chạy vào hôm trước ngày họp duyệt | 🟠 Được, nhưng phát hiện lúc đó chỉ để hoãn họp |
+
+## Cú pháp
+
+```
+/ba-traceability <PROJECT|US-id> [--gate g2|g3|g4] [--out <path>] [go]
+```
+
+| Tham số | Ý nghĩa |
+|---|---|
+| `--gate` | Chỉ chạy các phép kiểm liên quan tới một gate cụ thể |
+| `go` | Bỏ bước dừng xác nhận input |
+
+## Bạn sẽ nhận được gì
+
+File `ba-output/<PROJECT>/00-index/RTM_<PROJECT>.md` + năm phần in ra màn hình:
+
+**① Bảng coverage** — sáu phép kiểm, mỗi cái một con số
+
+```
+| Phép kiểm            | Tổng | Đã phủ | Coverage | Ngưỡng | ☐/✅ |
+| RQ → US              | 12   | 11     | 91,7%    | 100%   | 🔴  |
+| US → RQ              | 18   | 16     | 88,9%    | 100%   | 🔴  |
+| US → AC (đủ 4 nhóm)  | 18   | 12     | 66,7%    | 100%   | 🔴  |
+```
+
+**② Chi tiết từng lỗ hổng** — kèm lệnh để sửa:
+
+```
+🔴 RQ-005 chưa có US nào phủ
+   Định nghĩa tại: BRIEF_Settlement_v1.0.md §6
+   Sửa bằng: /ba-2-analysis Settlement
+```
+
+**③ Bảng nhất quán** — version lệch, ràng buộc lệch, mã lỗi lệch, trạng thái lệch
+
+**④ `OQ`/`CR` tồn đọng** — sắp theo số ngày quá hạn
+
+**⑤ Kết luận gate** — gate nào bị chặn và vì sao
+
+## Hai chiều, hai loại lỗi
+
+Đây là điểm quan trọng nhất cần hiểu về skill này:
+
+```
+chiều xuôi   RQ → US → AC → test case      bắt: BỎ SÓT
+chiều ngược  test case → AC → US → RQ      bắt: LÀM THỪA
+```
+
+Hầu hết công cụ traceability chỉ chạy chiều xuôi. Chiều ngược mới trả lời được câu hỏi
+*"cái này ai yêu cầu?"* — và scope creep là thứ làm dự án trễ mà không ai giải thích được
+vì sao.
+
+## Ví dụ hội thoại
+
+```
+Bạn:    /ba-traceability Settlement --gate g3
+
+Claude: [Bước 0]
+        Quét được:
+        | BRIEF_Settlement_v1.0.md   | 12 RQ, 3 GOAL       | ✅ Baselined |
+        | BACKLOG_Settlement_v1.0.md | 18 US               | ✅ Baselined |
+        | BR_Settlement_v1.2.md      | 24 BR               | ✅ Baselined |
+        | SRS_US011_v1.2.md          | 8 AC, 12 field      | 🟠 In Review |
+        | SRS_US012..018             | Không tìm thấy       | — |
+
+        ⚠️ Chỉ có SRS cho 1/18 US. Phép kiểm "US → AC" sẽ báo coverage rất thấp —
+        đúng thực tế, không phải lỗi quét.
+
+        Test case: chưa tìm thấy ⇒ phép kiểm 5 (AC → test case) không chạy được.
+
+        Xác nhận giúp tôi trước khi chạy.
+
+Bạn:    Đúng rồi, mới viết SRS cho US011 thôi. Chạy đi.
+
+Claude: [báo cáo]
+
+        G3: 🔴 CHẶN
+        - 17/18 US chưa có SRS
+        - US-011: thiếu AC nhóm "lỗi hệ thống" và "phân quyền"
+        - 4 TBD trong bảng field US-011 (F01 độ dài, F04 nguồn dropdown…)
+        - BR-021 tham chiếu ở SRS_US011 §1.3 nhưng không có trong BR_v1.2
+          → có thể BR bị đổi số ở v1.1
+```
+
+## Lỗi thường gặp
+
+**"Coverage 99%, làm tròn lên 100% được không?"**
+Không. Cái 1% đó là một yêu cầu thật, của một người thật, và nó sẽ lọt ra sản phẩm mà không
+ai kiểm chứng.
+
+**"BR-021 được nhắc trong SRS rồi, tính là đã phủ chứ?"**
+Không. Nhắc tới không có nghĩa là đã hiện thực hoá. Phải xem nó được áp vào field/AC nào.
+Đếm số lần xuất hiện là phép đo sai.
+
+**"Tham chiếu gãy chắc do đánh nhầm số thôi, bỏ qua."**
+Tham chiếu gãy nghĩa là dev đọc spec, thấy "theo BR-021", đi tìm không ra, rồi tự quyết.
+Đó là cách một business rule bốc hơi khỏi sản phẩm mà không ai biết.
+
+**"US-013 đã có AC rồi mà sao báo chưa phủ?"**
+Phép kiểm 3 đòi **đủ bốn nhóm**: thành công · validation · lỗi hệ thống · phân quyền. US chỉ
+có AC nhóm 1 tính là chưa phủ, không phải "phủ một phần" — vì phần thiếu chính là phần dev
+sẽ tự bịa.
+
+**"Skill tự sửa giúp luôn được không?"**
+Không, và cố ý như vậy. Nó báo cáo kèm lệnh để sửa. Tự sửa sẽ che mất vấn đề, và nguyên
+nhân gốc (đặc tả thiếu chỗ nào) không bao giờ được ghi nhận để cải thiện.
+
+**"Chỉ cần chạy trước gate là đủ."**
+Chạy sau mỗi giai đoạn thì lỗ hổng được phát hiện lúc còn rẻ. Chạy lần đầu vào hôm trước
+ngày họp duyệt thì phát hiện cũng chỉ để hoãn họp.
+
+## Liên quan
+
+- Quy ước ID: `../README.md` §4
+- Tiêu chí gate: `../ba-lifecycle/references/workflow.md` §2
+- Quan hệ phụ thuộc giữa artifact (sửa cái này thì phải sửa tiếp cái nào):
+  `../ba-lifecycle/references/artifact-map.md` §5
+- Template: `templates/rtm.md`

.claude/skills/ba-traceability/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: ba-traceability
+description: Skill xuyên suốt của quy trình BA — dựng và kiểm tra ma trận truy vết yêu cầu (RTM). Dùng để phát hiện yêu cầu bị bỏ quên, user story không có nguồn gốc (scope creep), AC không được test, business rule không được kiểm chứng, và tham chiếu gãy giữa các tài liệu. Kích hoạt khi người dùng nói "kiểm tra coverage", "có sót yêu cầu nào không", "ma trận truy vết", "RTM", "traceability", "rà soát chéo tài liệu BA", "trước khi trình gate", "requirement nào chưa được test". Chạy được ở mọi giai đoạn và có quyền chặn Gate G2, G3, G4.
+---
+
+# ⊕ TRACEABILITY — Ma trận truy vết & kiểm tra coverage
+
+Skill này không thuộc giai đoạn nào. Nó chạy **sau mỗi giai đoạn** và trả lời đúng một câu
+hỏi: **"có cái gì bị rơi giữa các tài liệu không?"**
+
+Nó có **quyền chặn Gate G2, G3, G4**: coverage không đạt thì gate không pass.
+
+Output: `RTM_<PROJECT>.md` trong `ba-output/<PROJECT>/00-index/` + báo cáo coverage.
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa yêu cầu.**
+2. **Không quyết định thay PO.**
+3. **Mọi phát biểu truy vết được** — đây chính là việc của skill này.
+4. **Không ghi đè tài liệu đã qua gate.**
+
+🔴 **Nguyên tắc riêng: skill này KHÔNG sửa tài liệu nghiệp vụ.** Nó phát hiện và báo cáo.
+Sửa là việc của skill giai đoạn tương ứng. Tự sửa sẽ che mất vấn đề thay vì giải quyết nó.
+
+## Bước 0 — Chốt input rồi dừng lại
+
+**Chưa được ghi file.** Làm năm việc rồi **dừng chờ trả lời**:
+
+1. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Nó quyết định **phép kiểm nào áp dụng**
+   (Bước 2) và **ngưỡng nào bắt buộc** (Bước 5).
+2. **Tài liệu quét được** — bảng `File | Loại | Version | Status | Số ID trích được`.
+3. **Tài liệu thiếu** — loại nào không tìm thấy, và điều đó làm phép kiểm nào **không chạy
+   được** (nói rõ, đừng lặng lẽ bỏ phép kiểm đó).
+4. **Mục đích lần chạy** — dựng RTM lần đầu, cập nhật sau một giai đoạn, hay kiểm tra trước
+   khi trình gate?
+5. **Hỏi xác nhận** bốn điểm trên.
+
+Bỏ qua khi lệnh có `go`.
+
+## Thực hiện — 4 bước
+
+### Bước 1 — Trích ID từ mọi tài liệu
+
+Quét theo quy ước ID ở `../ba-lifecycle/README.md` §4:
+
+```bash
+grep -rnoE "(RQ|US|BR|AC|NFR|OQ|DEC|CR|RISK|ASM|GOAL|STK|ROLE|FLD)-[A-Za-z0-9-]+" ba-output/<PROJECT> \
+  | sort -u
+```
+
+Với mỗi ID ghi lại: **nơi định nghĩa** (tài liệu nào định nghĩa nó) và **nơi tham chiếu**
+(tài liệu nào nhắc tới nó).
+
+🔴 Phân biệt hai thứ này là điểm mấu chốt. Một ID được tham chiếu nhiều nơi nhưng **không có
+nơi định nghĩa** là tham chiếu gãy — dev đọc spec thấy "theo BR-021" rồi đi tìm không ra.
+
+### Bước 2 — Sáu phép kiểm coverage
+
+Điền `templates/rtm.md`. Chạy đủ sáu phép, mỗi phép ra một danh sách:
+
+| # | Phép kiểm | Chiều | Phát hiện | Chặn gate |
+|---|---|---|---|---|
+| 1 | Mỗi `RQ` → có ≥1 `US` | xuôi | **Yêu cầu bị bỏ quên** | G2 |
+| 2 | Mỗi `US` → truy về được `RQ` | ngược | **Scope creep** | G2 |
+| 3 | Mỗi `US` → có ≥1 `AC` mỗi nhóm bắt buộc | xuôi | Đặc tả chưa xong | G3 |
+| 4 | Mỗi `BR` → được áp dụng ở ≥1 `US`/`field` | xuôi | Rule mồ côi | G3 |
+| 5 | Mỗi `AC` → có ≥1 test case | xuôi | **AC không được kiểm chứng** | G4 |
+| 6 | Mỗi ID được tham chiếu → có nơi định nghĩa | — | **Tham chiếu gãy** | G2/G3/G4 |
+
+**Hai chiều đều quan trọng, và chúng bắt hai loại lỗi khác nhau:**
+
+```
+chiều xuôi   RQ → US → AC → test case      bắt: BỎ SÓT
+chiều ngược  test case → AC → US → RQ      bắt: LÀM THỪA
+```
+
+Chỉ chạy chiều xuôi là bỏ qua toàn bộ scope creep — thứ làm dự án trễ mà không ai giải
+thích được vì sao.
+
+**Phép kiểm 3 chặt hơn "có AC"**: mỗi `US` phải có AC ở đủ bốn nhóm (thành công · validation ·
+lỗi hệ thống · phân quyền). US chỉ có AC nhóm 1 ⇒ tính là **chưa phủ**, không phải "đã phủ
+một phần".
+
+### Điều chỉnh theo profile
+
+| Trục | Ảnh hưởng tới phép kiểm |
+|---|---|
+| `PRODUCT = ml-model` | Phép kiểm 3 **chỉ áp cho hệ thống bao quanh**. Phần dự đoán thay bằng: mỗi `GOAL` chất lượng có ≥1 metric **có ngưỡng**, và mỗi ngưỡng truy về được một chi phí nghiệp vụ |
+| `PRODUCT = data-pipeline` | Thêm phép kiểm: mỗi luồng có ≥1 quy tắc **đối soát nguồn–đích**. Thiếu ⇒ 🔴 chặn G3 |
+| `PRODUCT = batch-job` | Thêm phép kiểm: mỗi job đã trả lời **idempotency** và **thất bại giữa chừng**. Bỏ trống ⇒ 🔴 chặn G3 |
+| `PRODUCT = api-service` | Thêm phép kiểm: mỗi mã lỗi map về ≥1 endpoint, và mỗi endpoint có cột "người gọi nên làm gì" |
+| `RIGOR = light` | Phép kiểm 3 chỉ đòi nhóm 1–2; nhóm 3–4 đòi **nếu** có ghi/xoá dữ liệu hoặc >1 vai trò |
+| `RIGOR = strict` | Thêm phép kiểm: mỗi hành động ghi có dòng trong bảng lưu vết; mỗi mã lỗi có đủ bản dịch |
+
+🔴 **Phép kiểm bị bỏ vì profile phải được ghi ra trong báo cáo**, kèm lý do — đừng lặng lẽ
+tính coverage trên tập nhỏ hơn rồi báo 100%.
+
+### Bước 3 — Bốn phép kiểm nhất quán
+
+Ngoài coverage, kiểm tra tài liệu có mâu thuẫn nhau không:
+
+| # | Phép kiểm | Cách kiểm | Ví dụ lỗi bắt được |
+|---|---|---|---|
+| 1 | **Version lệch** | `SRS` khai `Source: BR_v1.0` nhưng `BR` đã lên v1.2 | SRS viết theo rule cũ |
+| 2 | **Ràng buộc lệch** | Bảng field trong `SRS` vs. bảng ràng buộc trong `API` | UI chặn 20 ký tự, API chặn 50 |
+| 3 | **Mã lỗi lệch** | Mã trong `SRS` §4.1 vs. mã trong `API` §4 | Mã lỗi không endpoint nào sinh ra |
+| 4 | **Trạng thái lệch** | Trạng thái trong `BR` vs. trạng thái dùng trong `SRS`/`RBAC` | RBAC phân quyền cho trạng thái không tồn tại |
+
+Phép 1 chạy được bằng máy: so `Source:` trong header với version thật của file được trích dẫn.
+
+### Bước 4 — `OQ` và `CR` tồn đọng
+
+```bash
+grep -rn "OQ-[0-9]" ba-output/<PROJECT> | sort -u
+grep -rn "TBD\|TODO\|???" ba-output/<PROJECT>
+```
+
+Với mỗi `OQ` mở: hỏi ai · từ ngày · chặn ID nào · quá hạn bao nhiêu ngày (>5 ngày làm việc
+⇒ 🔴). Với mỗi `CR`: trạng thái · chờ ai · bao lâu rồi.
+
+`TBD` trong bảng field hoặc bảng mã lỗi ⇒ **báo là blocker của G3**.
+
+## Báo cáo — in đúng năm phần
+
+**① Bảng coverage tổng hợp** — mở đầu bằng dòng profile và **danh sách phép kiểm đã bỏ**:
+
+```
+Profile: data-pipeline · brownfield · strict
+Phép kiểm bỏ: (không có)
+Phép kiểm thêm: đối soát nguồn–đích · lưu vết mọi hành động ghi
+```
+
+| Phép kiểm | Tổng | Đã phủ | Coverage | Ngưỡng | ☐/✅ |
+|---|---|---|---|---|---|
+| RQ → US | 12 | 11 | 91,7% | 100% | 🔴 |
+| US → RQ | 18 | 16 | 88,9% | 100% | 🔴 |
+| US → AC (đủ 4 nhóm) | 18 | 12 | 66,7% | 100% | 🔴 |
+| BR → áp dụng | 24 | 24 | 100% | 100% | ✅ |
+| AC → test case | 96 | — | — | 100% | ⏳ QA chưa viết |
+| Tham chiếu → định nghĩa | 214 | 211 | 98,6% | 100% | 🔴 |
+
+**② Danh sách chi tiết từng lỗ hổng** — mỗi dòng nêu đích danh ID, ở tài liệu nào, và
+**skill nào cần chạy để sửa**:
+
+```
+🔴 RQ-005 chưa có US nào phủ
+   Định nghĩa tại: BRIEF_Settlement_v1.0.md §6
+   Sửa bằng: /ba-2-analysis Settlement
+
+🔴 BR-021 được tham chiếu ở SRS_US011 §1.3 nhưng không tìm thấy định nghĩa
+   Có thể đã bị đổi số hoặc BR_Settlement chưa cập nhật
+   Sửa bằng: /ba-2-analysis Settlement --only br
+```
+
+**③ Bảng nhất quán** — bốn phép kiểm ở Bước 3, mỗi mâu thuẫn một dòng.
+
+**④ `OQ`/`CR` tồn đọng** — sắp theo số ngày quá hạn giảm dần.
+
+**⑤ Kết luận gate**
+
+```
+G2: 🔴 CHẶN — RQ-005 chưa phủ, US-018 và US-019 không truy về RQ
+G3: 🔴 CHẶN — 6/18 US thiếu AC nhóm lỗi hệ thống; 4 TBD trong bảng field
+G4: ⏳ Chưa đánh giá được — QA chưa nộp test case
+```
+
+Nói thẳng gate nào bị chặn và vì sao. **Không làm tròn lên.** Coverage 99% vẫn là chặn khi
+ngưỡng là 100% — cái 1% đó chính là yêu cầu sẽ lọt ra sản phẩm mà không ai kiểm chứng.
+
+## Bẫy thường gặp
+
+**Chỉ chạy chiều xuôi.** Bỏ qua toàn bộ scope creep. Chiều ngược mới trả lời được câu
+*"cái này ai yêu cầu?"*.
+
+**Coi ID xuất hiện trong tài liệu là đã được phủ.** `SRS` nhắc `BR-021` không có nghĩa là
+`BR-021` đã được hiện thực hoá — phải xem nó được áp vào field/AC nào. Đếm số lần xuất hiện
+là phép đo sai.
+
+**Bỏ qua tham chiếu gãy vì "chắc là do đánh nhầm số".** Tham chiếu gãy nghĩa là dev đọc
+spec, thấy "theo BR-021", đi tìm không ra, rồi **tự quyết**. Đó là cách một business rule
+bốc hơi khỏi sản phẩm.
+
+**Tự sửa tài liệu khi phát hiện lỗ hổng.** Vi phạm nguyên tắc riêng của skill này. Báo cáo
+và chỉ đúng skill để sửa; tự sửa sẽ che mất vấn đề, và lần sau nó lại xuất hiện.
+
+**Làm tròn coverage lên.** 99% vẫn là chặn. Cái 1% đó là một yêu cầu thật, của một người thật.
+
+**Bỏ phép kiểm vì profile rồi báo 100%.** `RIGOR = light` bỏ bớt phép kiểm là hợp lệ; **không
+ghi ra là đã bỏ** thì con số 100% trở thành nói dối. Luôn in danh sách phép kiểm đã bỏ.
+
+**Chỉ chạy trước gate.** Chạy sau mỗi giai đoạn thì lỗ hổng được phát hiện lúc còn rẻ. Chạy
+lần đầu vào hôm trước ngày họp duyệt thì phát hiện cũng chỉ để hoãn họp.

.claude/skills/ba-traceability/templates/rtm.md

@@ -0,0 +1,142 @@
+# RTM — Requirements Traceability Matrix — <PROJECT>
+
+| | |
+|---|---|
+| **Cập nhật** | YYYY-MM-DD |
+| **Chạy bởi** | skill `ba-traceability` |
+| **Tài liệu đã quét** | *(liệt kê kèm version)* |
+| **Tài liệu thiếu** | *(và phép kiểm nào không chạy được vì thiếu nó)* |
+
+---
+
+## 1. Bảng coverage tổng hợp
+
+| # | Phép kiểm | Chiều | Tổng | Đã phủ | Coverage | Ngưỡng | ☐/✅ | Chặn gate |
+|---|---|---|---|---|---|---|---|---|
+| 1 | RQ → US | xuôi | | | | 100% | | G2 |
+| 2 | US → RQ | ngược | | | | 100% | | G2 |
+| 3 | US → AC (**đủ 4 nhóm**) | xuôi | | | | 100% | | G3 |
+| 4 | BR → áp dụng ở US/field | xuôi | | | | 100% | | G3 |
+| 5 | AC → test case | xuôi | | | | 100% | | G4 |
+| 6 | Tham chiếu → định nghĩa | — | | | | 100% | | mọi gate |
+
+**Không làm tròn lên.** Coverage 99% vẫn là chặn khi ngưỡng là 100% — cái 1% đó là một yêu
+cầu thật, của một người thật.
+
+---
+
+## 2. Ma trận chính
+
+*Một dòng cho mỗi mắt xích. Ô trống = lỗ hổng.*
+
+| RQ | MoSCoW | US | BR | AC | Field | Mã lỗi | Test case | Kết quả test | CR |
+|---|---|---|---|---|---|---|---|---|---|
+| RQ-001 | Must | US-001 | BR-003 | AC-01, AC-05 | F01, F02 | E-STL-0001 | TC-001..004 | ✅ | — |
+| RQ-005 | Should | 🔴 — | | | | | | | |
+
+---
+
+## 3. Chi tiết từng lỗ hổng
+
+*Mỗi dòng nêu đích danh ID, nơi định nghĩa, và **skill nào cần chạy để sửa**.*
+
+### 3.1 🔴 RQ chưa có US nào phủ *(yêu cầu bị bỏ quên — chặn G2)*
+
+| RQ | MoSCoW | Định nghĩa tại | Vì sao chưa phủ | Sửa bằng |
+|---|---|---|---|---|
+| RQ-005 | Should | `BRIEF_…_v1.0.md` §6 | *(bị bỏ sót? đã hoãn nhưng chưa ghi DEC?)* | `/ba-2-analysis <P>` |
+
+### 3.2 🔴 US không truy về RQ nào *(scope creep — chặn G2)*
+
+| US | Định nghĩa tại | Từ đâu ra | PO quyết | Sửa bằng |
+|---|---|---|---|---|
+| US-018 | `BACKLOG_…_v1.0.md` | | Giữ / Bỏ / Hoãn | `/ba-2-analysis <P>` |
+
+### 3.3 🔴 US thiếu AC *(chặn G3)*
+
+*Đủ 4 nhóm mới tính là phủ. Chỉ có nhóm 1 ⇒ **chưa phủ**, không phải "phủ một phần".*
+
+| US | Thành công | Validation | Lỗi hệ thống | Phân quyền | Sửa bằng |
+|---|---|---|---|---|---|
+| US-013 | ✅ AC-20 | ✅ AC-21 | 🔴 — | 🔴 — | `/ba-3-specification US013` |
+
+### 3.4 🟠 BR mồ côi *(không được áp dụng ở đâu)*
+
+| BR | Định nghĩa tại | Vì sao mồ côi | Sửa bằng |
+|---|---|---|---|
+| BR-030 | `BR_…_v1.0.md` | *(rule của phase sau? hay SRS quên áp?)* | `/ba-3-specification <US>` |
+
+### 3.5 🔴 AC không có test case *(chặn G4)*
+
+| AC | US | Nhóm | Sửa bằng |
+|---|---|---|---|
+| AC-09 | US-011 | Lỗi hệ thống | `/ba-4-delivery-support US011 --part c` |
+
+### 3.6 🔴 Tham chiếu gãy
+
+*ID được nhắc tới nhưng **không có nơi định nghĩa**.*
+
+| ID được tham chiếu | Nhắc ở đâu | Có thể là | Sửa bằng |
+|---|---|---|---|
+| BR-021 | `SRS_US011_v1.2` §1.3 | Đổi số? `BR` chưa cập nhật? | `/ba-2-analysis <P> --only br` |
+
+🔴 Tham chiếu gãy nghĩa là dev đọc spec, thấy "theo BR-021", đi tìm không ra, rồi **tự
+quyết**. Đó là cách một business rule bốc hơi khỏi sản phẩm.
+
+---
+
+## 4. Kiểm tra nhất quán
+
+| # | Phép kiểm | Phát hiện | Mức | Xử lý |
+|---|---|---|---|---|
+| 1 | **Version lệch** — `Source:` trích version cũ | `SRS_US011` khai `BR_v1.0`, thực tế `BR` đã v1.2 | 🔴 | Rà lại SRS theo BR mới |
+| 2 | **Ràng buộc lệch** — field vs. API | F01 max 20 ký tự (SRS) vs. 50 (API) | 🔴 | |
+| 3 | **Mã lỗi lệch** — SRS vs. API | `E-STL-0007` không endpoint nào sinh ra | 🟠 | |
+| 4 | **Trạng thái lệch** — BR vs. SRS/RBAC | RBAC phân quyền cho trạng thái `LOCKED` không có trong BR | 🔴 | |
+
+---
+
+## 5. Open Question & Change Request tồn đọng
+
+*Sắp theo số ngày quá hạn giảm dần.*
+
+| ID | Nội dung | Hỏi ai | Từ ngày | Số ngày | Chặn ID nào | Mức |
+|---|---|---|---|---|---|---|
+| OQ-014 | | | | 9 | AC-05, F03 | 🔴 quá hạn |
+
+| CR | Tóm tắt | Chờ ai quyết | Từ ngày | Số ngày | Mức |
+|---|---|---|---|---|---|
+
+**`TBD` / `TODO` còn lại:**
+
+| Tài liệu | Mục | Nội dung | Chặn gate |
+|---|---|---|---|
+| `SRS_US011` | §2.3.3 F01 | Độ dài chưa chốt | 🔴 G3 |
+
+---
+
+## 6. Kết luận gate
+
+```
+G1: ✅ / 🔴 CHẶN — <lý do>
+G2: ✅ / 🔴 CHẶN — <lý do>
+G3: ✅ / 🔴 CHẶN — <lý do>
+G4: ✅ / ⏳ Chưa đánh giá được — <thiếu gì>
+G5: —
+```
+
+| Gate | Trạng thái | Blocker | Chạy gì để gỡ |
+|---|---|---|---|
+| G2 | 🔴 | RQ-005 chưa phủ · US-018, US-019 scope creep | `/ba-2-analysis <P>` |
+| G3 | 🔴 | 6/18 US thiếu AC nhóm lỗi · 4 TBD trong bảng field | `/ba-3-specification <US...>` |
+
+---
+
+## 7. Lịch sử chạy
+
+| Ngày | Coverage RQ→US | US→AC | AC→TC | Số blocker | Ghi chú |
+|---|---|---|---|---|---|
+| | | | | | |
+
+*Chạy sau **mỗi giai đoạn**, không chỉ trước gate. Lỗ hổng phát hiện sớm thì rẻ; phát hiện
+hôm trước ngày họp duyệt thì chỉ để hoãn họp.*