init git

.claude/skills/ba-4-delivery-support/GUIDE.md

@@ -0,0 +1,185 @@
+# Hướng dẫn sử dụng — `ba-4-delivery-support` (Giai đoạn 4)
+
+## Giai đoạn này giải quyết gì
+
+Code đang chạy. Việc của BA lúc này là **giữ cho spec và sản phẩm không lệch nhau**: trả lời
+câu hỏi, xử lý thay đổi, đối chiếu test case, điều hành UAT.
+
+Đây là giai đoạn chiếm nhiều thời gian thực tế nhất nhưng ít được ghi nhận nhất — vì phần
+lớn công việc là trả lời câu hỏi, và câu trả lời không ghi lại thì mất luôn.
+
+## Bốn phần độc lập
+
+Skill chia làm bốn phần, gọi phần nào chạy phần đó:
+
+| Phần | Việc | Template |
+|---|---|---|
+| **A** | Trả lời câu hỏi làm rõ của dev/QA | `clarification-log.md` |
+| **B** | Quản lý change request | `change-request.md` |
+| **C** | Review test case của QA | `testcase-review.md` |
+| **D** | Chuẩn bị & tổng hợp UAT | `uat-plan.md` |
+
+## Cú pháp
+
+```
+/ba-4-delivery-support <US-id|PROJECT> [--part a|b|c|d] [--out <path>] [go]
+```
+
+Thường thì không cần `--part` — mô tả việc là skill tự nhận ra:
+
+```
+/ba-4-delivery-support US011 — dev hỏi field mã cửa hàng có phân biệt hoa thường không
+/ba-4-delivery-support US011 — khách muốn thêm cột ngày cập nhật vào bảng
+/ba-4-delivery-support US011 --part c — QA gửi bộ test case ở link…
+/ba-4-delivery-support Settlement --part d — UAT tuần sau
+```
+
+## Phần A — Trả lời câu hỏi dev/QA
+
+### Cách dùng
+
+Dán câu hỏi của dev vào. Skill sẽ:
+1. Phân loại câu hỏi thành 1 trong 4 loại
+2. Tìm câu trả lời trong tài liệu, trích dẫn đích danh mục nào
+3. Nếu tài liệu không có ⇒ tạo `OQ` với người phải trả lời và hạn
+4. Chỉ ra tài liệu nào cần sửa và báo cho ai
+
+### Điều quan trọng nhất
+
+**Ba trong bốn loại câu hỏi đều phải sửa tài liệu:**
+
+| Loại | Sửa tài liệu? |
+|---|---|
+| 1. Spec đã nói rõ, dev chưa đọc thấy | ❌ Không |
+| 2. Spec mơ hồ, hiểu hai cách | ✅ Bắt buộc |
+| 3. Spec không nói gì | ✅ Bắt buộc |
+| 4. Spec nói sai | ✅ Bắt buộc, qua `CR` |
+
+Trả lời cho một dev mà không sửa spec nghĩa là người tiếp theo sẽ hỏi lại đúng câu đó.
+
+Skill còn theo dõi **câu hỏi lặp lại**: cùng một câu từ ≥2 người ⇒ tài liệu có vấn đề ở chỗ
+đó, không phải người hỏi có vấn đề.
+
+## Phần B — Change Request
+
+### Việc đầu tiên: phân loại
+
+Đây là phân loại tốn kém nhất khi làm sai, và nó bị làm sai thường xuyên vì cả hai bên đều
+có động cơ: dev muốn gọi là CR, khách muốn gọi là defect.
+
+Skill áp dụng phép thử máy móc:
+
+```
+Sản phẩm có làm đúng SRS đã ký không?
+  ├── KHÔNG → DEFECT (dev sửa, không tính phí)
+  └── CÓ    → Tài liệu có nói về tình huống này không?
+               ├── CÓ  → CHANGE REQUEST
+               └── KHÔNG → SPEC GAP ← vùng xám, trách nhiệm của BA
+```
+
+**Spec gap** được xử lý thẳng thắn: ghi nhận là thiếu sót của đặc tả, đánh giá tác động như
+CR, nhưng nêu rõ nguyên nhân gốc để lần sau đặc tả kỹ chỗ đó. Không đẩy sang khách như CR
+bình thường, cũng không nhận là bug của dev.
+
+### Sáu bước, không bỏ bước
+
+Ghi nhận → **làm rõ vấn đề gốc** → đánh giá tác động → trình ≥2 phương án → PO quyết → thực thi.
+
+Bước "làm rõ vấn đề gốc" cứu được nhiều tiền nhất. Khách nói *"thêm cột X"* — hỏi *"để làm
+gì?"* — hoá ra để tìm nhanh hơn — hoá ra chỉ cần thêm bộ lọc.
+
+## Phần C — Review test case
+
+BA **không viết** test case. BA đối chiếu bốn phép:
+
+1. Mỗi `AC` → có ≥1 test case *(phát hiện AC bị bỏ sót khi test)*
+2. Mỗi test case → truy về được `AC`/`BR` *(phát hiện test thừa hoặc AC thiếu)*
+3. Mỗi `BR` → có test **ca vi phạm** *(rule chỉ test luồng đúng là chưa test)*
+4. Mỗi dòng bảng dữ liệu biên → có test case
+
+Cộng bốn nhóm hay thiếu: phân quyền (gọi thẳng API), lỗi hệ thống (giữ dữ liệu đã nhập),
+đồng thời (hai người sửa một bản ghi), dữ liệu cũ.
+
+**Độ phủ AC phải đạt 100% trước khi bắt đầu test.**
+
+## Phần D — UAT
+
+### Chuẩn bị (trước ít nhất 1 tuần)
+
+Năm việc, và mỗi việc có một chỗ hay hỏng:
+
+| Việc | Hay hỏng ở đâu |
+|---|---|
+| Kịch bản | Viết theo màn hình ⇒ người dùng không nhận ra công việc của mình |
+| Dữ liệu | Quá sạch ⇒ UAT pass, chạy thật thì lỗi |
+| Môi trường | Ngày UAT mới phát hiện chưa cấp tài khoản |
+| Người tham gia | Người đại diện pass, người dùng thật từ chối |
+| **Tiêu chí pass** | Không chốt trước ⇒ tranh cãi lúc kết luận |
+
+### Trong lúc UAT
+
+BA là **người quan sát**, không phải người hướng dẫn thao tác. Chỗ người dùng loay hoay là
+thông tin quý nhất — ghi lại trước, hướng dẫn sau.
+
+Mỗi phát hiện phân loại ngay thành ba loại: **defect** · **CR** · **hiểu nhầm cách dùng**.
+Loại thứ ba hay bị ghi nhầm thành defect; nó là tín hiệu về đào tạo hoặc thiết kế chưa rõ.
+
+## Bạn sẽ nhận được gì
+
+```
+ba-output/<PROJECT>/04-delivery/
+├── QLOG_<PROJECT>.md          ← cập nhật liên tục, không tạo file mới mỗi lần
+├── CR_<US>-<nnn>_v1.0.md      ← mỗi CR một file
+├── TCREVIEW_<US>_v1.0.md
+└── UAT_<đợt phát hành>_v1.0.md
+```
+
+Cộng bảng tương ứng phần đã chạy, và **luôn có**: danh sách tài liệu đã sửa kèm version mới,
+và ai cần được báo.
+
+## Lỗi thường gặp
+
+**"Dev hỏi qua chat, tôi trả lời qua chat, thế là xong."**
+Không xong. Ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả bạn. Mọi câu
+trả lời phải vào `QLOG`, và nếu spec mơ hồ/thiếu thì phải sửa spec.
+
+**"CR này nhỏ thôi, làm luôn cho nhanh."**
+Không có CR nhỏ, chỉ có CR chưa được đánh giá tác động. Thay đổi không ghi nhận sẽ: không
+vào test case ⇒ QA không test ⇒ lỗi lọt ra thật; không vào tài liệu ⇒ người sau đọc thấy
+khác sản phẩm; không vào ước lượng ⇒ trễ tiến độ mà không giải thích được.
+
+**"Rõ ràng là nên làm, tôi quyết luôn."**
+Vi phạm nguyên tắc "không quyết định thay PO". Kể cả khi bạn đúng, PO vẫn phải biết vì họ
+chịu trách nhiệm về scope và chi phí.
+
+**"Tôi sửa SRS rồi, dev tự đọc lại."**
+Dev đang code theo bản cũ. Sửa spec âm thầm còn tệ hơn không sửa. Danh sách "ai cần được
+báo" là phần bắt buộc của mọi lần sửa.
+
+**"Người dùng loay hoay, tôi chỉ luôn cho nhanh."**
+Bạn vừa xoá mất phát hiện quan trọng nhất của buổi UAT. Ghi lại chỗ họ loay hoay, rồi mới
+hướng dẫn.
+
+**"Defect Medium này để sau cũng được."**
+Được, nhưng phải có **ticket theo dõi và hạn**. Không có ticket thì nó biến mất và quay lại
+sau sáu tháng dưới dạng khiếu nại.
+
+## Ra khỏi giai đoạn này khi nào
+
+Đủ cả sáu:
+
+1. Kịch bản UAT mức Must pass 100%
+2. Defect Critical/High đã đóng
+3. Defect Medium/Low chấp nhận tạm đều **có ticket**
+4. Mọi `CR` đã được quyết và tài liệu đã cập nhật
+5. `QLOG` không còn câu hỏi mở chặn dev
+6. PO ký nghiệm thu theo tiêu chí đã chốt **trước** buổi UAT
+
+Rồi chạy `/ba-5-post-release <PROJECT>`.
+
+## Liên quan
+
+- Tiêu chí gate G4: `../ba-lifecycle/references/workflow.md` §2
+- Đường quay lui GĐ4 → GĐ3 / GĐ2: `../ba-lifecycle/references/workflow.md` §5
+- Template: `templates/clarification-log.md` · `templates/change-request.md` ·
+  `templates/testcase-review.md` · `templates/uat-plan.md`

.claude/skills/ba-4-delivery-support/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: ba-4-delivery-support
+description: Giai đoạn 4 của quy trình BA — đồng hành cùng team trong lúc phát triển. Dùng để trả lời câu hỏi làm rõ của dev/QA (clarification log), quản lý change request có quy trình đánh giá tác động, review test case của QA xem có phủ đủ AC không, chuẩn bị và điều hành UAT, phân loại defect và change request. Kích hoạt khi người dùng nói "dev hỏi về spec", "trả lời câu hỏi của dev", "khách đòi thay đổi", "change request", "CR", "review test case", "chuẩn bị UAT", "kịch bản UAT", "phân loại bug hay CR", "grooming". Output vào ba-output/<PROJECT>/04-delivery/ và phải qua Gate G4 (UAT pass) trước khi go-live.
+---
+
+# GĐ4 · DELIVERY SUPPORT — Đồng hành phát triển
+
+Mục tiêu: **giữ cho spec và sản phẩm không lệch nhau trong lúc code đang chạy.**
+
+Đây là giai đoạn chiếm nhiều thời gian thực tế nhất của BA, nhưng ít được ghi nhận nhất —
+vì phần lớn công việc là trả lời câu hỏi, và câu trả lời không được ghi lại thì mất luôn.
+
+Output: `QLOG` · `CR` · `TCREVIEW` · `UAT` trong `ba-output/<PROJECT>/04-delivery/`
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa yêu cầu** — dev hỏi mà spec không nói ⇒ đi hỏi PO, không tự trả lời.
+2. **Không quyết định thay PO** — mọi CR có ảnh hưởng scope/chi phí do PO quyết.
+3. **Mọi phát biểu truy vết được** — mỗi câu trả lời trong `QLOG` phải chỉ về `BR`/`AC`/`DEC`.
+4. **Không ghi đè tài liệu đã qua gate** — SRS đã Baselined chỉ sửa qua `CR-nnn`.
+
+🔴 **Nguyên tắc riêng của giai đoạn này: mọi câu trả lời cho dev phải đi vào tài liệu.**
+Trả lời miệng hoặc qua chat rồi để đó là cách chắc chắn nhất khiến ba tháng sau không ai
+biết vì sao hệ thống hành xử như vậy — kể cả chính bạn.
+
+## Bước 0 — Chốt việc cần làm rồi dừng lại
+
+**Chưa được ghi file.** Xác định **loại việc** trước, vì bốn loại có quy trình khác hẳn nhau:
+
+| Loại việc | Dấu hiệu | Chạy phần nào |
+|---|---|---|
+| **Câu hỏi làm rõ** | Dev/QA hỏi spec nói gì | Phần A |
+| **Yêu cầu thay đổi** | Ai đó muốn khác với spec đã chốt | Phần B |
+| **Review test case** | QA gửi test case cần đối chiếu AC | Phần C |
+| **UAT** | Sắp nghiệm thu | Phần D |
+
+Rồi làm bốn việc, **dừng chờ trả lời**:
+
+1. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Nó quyết định hình dạng của UAT
+   (Phần D) và mức chặt của việc đóng defect: `PRODUCT = ml-model` ⇒ UAT là chuỗi
+   offline → shadow → thí điểm, không phải pass/fail · `RIGOR = light` ⇒ demo + checklist
+   thay UAT chính thức · `RIGOR = strict` ⇒ bằng chứng phải lưu trữ được, mọi defect kể cả
+   Low đều phải có ticket.
+2. **Input dùng được** — bảng `File | Vai trò | Version | Status`. Bắt buộc tìm `SRS` của US
+   liên quan và `QLOG` hiện có.
+3. **Phân loại sơ bộ** — với mỗi mục người dùng đưa vào, đoán loại và **nói rõ căn cứ**.
+4. **Hỏi xác nhận** phân loại — vì phân loại sai giữa *câu hỏi* và *thay đổi* là lỗi tốn kém
+   nhất ở giai đoạn này (xem §Phần B).
+
+Ví dụ phân loại thật ở nhiều domain: `examples.md`.
+
+Bỏ qua khi lệnh có `go`.
+
+---
+
+## PHẦN A — Trả lời câu hỏi làm rõ
+
+Dùng `templates/clarification-log.md`.
+
+### A1. Phân loại câu hỏi
+
+| Loại | Ai trả lời được | Thời hạn mục tiêu |
+|---|---|---|
+| **Spec đã nói rõ, người hỏi chưa đọc thấy** | BA — trích dẫn đích danh mục nào | Trong ngày |
+| **Spec nói mơ hồ, hiểu được hai cách** | BA — làm rõ và **sửa spec** | 1 ngày |
+| **Spec không nói** | PO/Tech Lead — BA đi hỏi | 2 ngày |
+| **Spec nói sai** | PO — thành `CR` | 2 ngày |
+
+🔴 **Ba loại sau đều phải sửa tài liệu.** Chỉ loại đầu tiên là trả lời xong là hết việc.
+Trả lời cho dev mà không sửa spec nghĩa là người tiếp theo đọc spec sẽ hỏi lại đúng câu đó.
+
+### A2. Trả lời
+
+Mỗi câu trả lời trong `QLOG` phải có:
+
+- **Trích dẫn nguồn** — mục nào của tài liệu nào, hoặc ai quyết định và ngày nào
+- **Câu trả lời dứt khoát** — không "có thể", không "tuỳ"
+- **Hành động kèm theo** — sửa mục nào của tài liệu nào, hay không cần sửa (ghi rõ)
+
+Không trả lời được ngay ⇒ ghi `OQ`, nêu **người phải trả lời** và **hạn**, và nói với dev
+phương án tạm để không bị chặn (kèm cảnh báo là tạm).
+
+### A3. Đóng vòng lặp
+
+Sau khi trả lời:
+
+1. Sửa tài liệu (nếu thuộc loại 2/3/4)
+2. Tăng version + ghi Change Log
+3. **Báo cho những người đã đọc bản cũ** — dev khác, QA. Sửa spec âm thầm còn tệ hơn không sửa
+4. Cập nhật `RTM` nếu AC/BR thay đổi
+
+---
+
+## PHẦN B — Quản lý Change Request
+
+Dùng `templates/change-request.md`.
+
+### B1. Phân biệt Defect và Change Request
+
+🔴 **Đây là phân loại tốn kém nhất khi làm sai**, và nó bị làm sai thường xuyên vì hai bên
+đều có động cơ: dev muốn gọi là CR (không phải lỗi của mình), khách muốn gọi là defect
+(không phải trả thêm tiền).
+
+Phép thử **duy nhất**, áp dụng máy móc:
+
+```
+Sản phẩm có làm đúng như tài liệu đã ký (SRS Baselined) không?
+  ├── KHÔNG  → DEFECT (bug). Dev sửa, không tính thêm chi phí.
+  └── CÓ     → Tài liệu có nói về tình huống này không?
+                ├── CÓ, và khách muốn khác đi  → CHANGE REQUEST
+                └── KHÔNG nói gì               → SPEC GAP → xem B2
+```
+
+**Spec gap** — tài liệu im lặng về tình huống đó — là vùng xám thật sự, và trách nhiệm
+thuộc về BA. Xử lý thẳng thắn: ghi nhận là thiếu sót của đặc tả, đánh giá tác động như một
+CR, nhưng nêu rõ nguyên nhân gốc trong `BENEFIT` ở GĐ5 để lần sau đặc tả kỹ hơn chỗ đó.
+Đừng đẩy sang khách như một CR bình thường, cũng đừng nhận là bug của dev.
+
+### B2. Quy trình xử lý CR — 6 bước, không bỏ bước
+
+| # | Bước | BA làm gì | Không được làm |
+|---|---|---|---|
+| 1 | **Ghi nhận** | Ghi nguyên văn yêu cầu, ai đề xuất, ngày | Diễn giải lại theo ý mình |
+| 2 | **Làm rõ** | Hỏi cho tới khi hiểu **vấn đề gốc**, không dừng ở giải pháp họ đề xuất | Nhận đúng câu chữ rồi đi làm |
+| 3 | **Đánh giá tác động** | Rà 6 trục như `IMPACT` ở GĐ2 + ước lượng cùng dev | Ước lượng một mình |
+| 4 | **Trình phương án** | ≥2 phương án kèm chi phí/rủi ro + **khuyến nghị của BA** | Chỉ trình một phương án |
+| 5 | **PO quyết** | Ghi `DEC-nn`: chấp nhận / hoãn / từ chối + lý do | Tự quyết vì "rõ ràng là nên làm" |
+| 6 | **Thực thi** | Sửa tài liệu, tăng version, cập nhật `RTM`, báo team | Sửa code trước, sửa tài liệu sau |
+
+🔴 **Bước 2 là bước cứu được nhiều tiền nhất.** Thứ khách yêu cầu thường là giải pháp họ
+nghĩ ra; hỏi *"để làm gì?"* cho tới khi ra vấn đề gốc, rồi mới định giá. Câu hỏi ở đây là
+câu hỏi của GĐ1, dùng lại ở GĐ4. Ba ca thật, cả ba đều ra phương án rẻ hơn: `examples.md`.
+
+### B3. CR đến vào lúc nào cũng phải qua quy trình
+
+Áp lực thường gặp: *"cái này nhỏ thôi, làm luôn đi cho nhanh"*. Trả lời: mọi thay đổi đều
+được ghi nhận, việc ghi nhận mất 5 phút. Thay đổi không ghi nhận sẽ:
+
+- Không vào test case ⇒ QA không test ⇒ lỗi lọt ra thật
+- Không vào tài liệu ⇒ người sau đọc spec thấy khác sản phẩm
+- Không vào ước lượng ⇒ trễ tiến độ mà không ai giải thích được vì sao
+
+---
+
+## PHẦN C — Review test case
+
+Dùng `templates/testcase-review.md`.
+
+BA **không viết** test case — QA viết. BA đối chiếu xem test case có phủ đúng AC không.
+
+### C1. Bốn phép đối chiếu
+
+| # | Phép đối chiếu | Phát hiện |
+|---|---|---|
+| 1 | Mỗi `AC` → có ≥1 test case | AC bị bỏ sót khi test |
+| 2 | Mỗi test case → truy về được một `AC`/`BR` | Test thừa, hoặc AC chưa viết |
+| 3 | Mỗi `BR` → có test case kiểm tra cả ca vi phạm | Rule chỉ được test ở luồng đúng |
+| 4 | Mỗi dòng **bảng dữ liệu biên** → có test case | Bug ở giá trị biên, chỗ hay lỗi nhất |
+
+### C2. Bốn nhóm hay thiếu trong test case
+
+Rà đích danh, đây là chỗ test case hay hụt:
+
+- **Phân quyền**: có test gọi thẳng API với token sai quyền không, hay chỉ test giao diện?
+- **Lỗi hệ thống**: có test timeout/5xx và kiểm tra **dữ liệu đã nhập được giữ nguyên** không?
+- **Đồng thời**: hai người sửa cùng một bản ghi thì sao?
+- **Dữ liệu cũ**: có test với bản ghi tạo trước khi có tính năng này không?
+
+### C3. Kết quả review
+
+Không sửa test case của QA. Ghi nhận xét vào `TCREVIEW` với ba mức: 🔴 thiếu phủ AC (phải
+bổ sung) · 🟠 nên bổ sung · 💬 góp ý. Rồi thống nhất với QA, không áp đặt.
+
+---
+
+## PHẦN D — UAT
+
+Dùng `templates/uat-plan.md`.
+
+🔴 **Hình dạng của UAT đổi theo `PRODUCT`.** Bảng dưới đây viết cho `screen`; ba loại khác
+nghiệm thu bằng cách khác — chi tiết ở đầu file biến thể PART 2 tương ứng:
+
+| `PRODUCT` | Nghiệm thu bằng |
+|---|---|
+| `screen` | Người dùng thao tác theo kịch bản công việc *(bảng D1 bên dưới)* |
+| `api-service` | Team tiêu thụ tích hợp thử trên sandbox, ký xác nhận hợp đồng |
+| `data-pipeline` | Chạy song song, **đối soát số liệu** với nguồn/hệ thống cũ ≥ 1 chu kỳ |
+| `batch-job` | Chạy song song với cách cũ, **thử ngắt giữa chừng rồi chạy lại** |
+| `ml-model` | offline → **shadow** → thí điểm → mở rộng; bỏ shadow là rủi ro lớn nhất |
+
+### D1. Chuẩn bị — làm trước ngày UAT ít nhất một tuần
+
+| Việc | Chi tiết | Hay hỏng ở đâu |
+|---|---|---|
+| **Kịch bản** | Theo **luồng công việc thật**, không theo màn hình | Kịch bản viết theo màn hình thì người dùng không nhận ra công việc của mình |
+| **Dữ liệu** | Dữ liệu giống thật, đủ ca biên và ca ngoại lệ | Dữ liệu quá sạch ⇒ UAT pass, thật thì lỗi |
+| **Môi trường** | Ai có tài khoản gì, quyền gì, truy cập từ đâu | Ngày UAT mới phát hiện chưa cấp tài khoản |
+| **Người tham gia** | Đúng người **sẽ dùng thật**, không phải người đại diện | Người đại diện pass, người dùng thật từ chối |
+| **Tiêu chí pass** | Thoả thuận **trước**, bằng văn bản | Không thoả thuận trước ⇒ tranh cãi lúc kết luận |
+
+🔴 **Tiêu chí pass phải chốt trước khi bắt đầu UAT.** Ví dụ: *100% kịch bản mức Must pass ·
+không còn defect Critical/High · defect Medium có kế hoạch xử lý*. Chốt sau khi đã thấy kết
+quả thì không còn là tiêu chí nữa.
+
+### D2. Trong lúc UAT
+
+BA làm **người quan sát và ghi chép**, không làm người hướng dẫn thao tác. Người dùng loay
+hoay ở đâu là thông tin quý — đừng cứu họ quá sớm, hãy ghi lại.
+
+Mỗi phát hiện ghi ngay: kịch bản nào · thao tác gì · mong đợi gì · thực tế gì · ảnh chụp ·
+**phân loại sơ bộ** (defect / CR / hiểu nhầm cách dùng).
+
+Loại thứ ba — *hiểu nhầm cách dùng* — thường bị ghi thành defect. Nó là tín hiệu về đào tạo
+hoặc về thiết kế chưa rõ, và cần được ghi riêng để xử lý ở GĐ5.
+
+### D3. Sau UAT
+
+Tổng hợp: số kịch bản pass/fail · defect theo mức · CR phát sinh · **quyết định go/no-go**.
+
+Defect được "chấp nhận tạm" phải có **ticket theo dõi và hạn xử lý**. Không có ticket thì
+nó biến mất, và quay lại sau sáu tháng dưới dạng khiếu nại của người dùng.
+
+---
+
+## Trước khi kết thúc
+
+Tuỳ phần đã chạy, in tương ứng:
+
+**Mọi lần chạy:** danh sách tài liệu đã sửa kèm version mới, và ai cần được báo.
+
+**Phần A:** bảng `QLOG` — câu hỏi mở, quá hạn (>2 ngày) đánh dấu 🔴.
+
+**Phần B:** bảng CR — trạng thái, tác động, ai đang chờ quyết. CR chờ >5 ngày ⇒ 🔴.
+
+**Phần C:** bảng phủ AC → test case, ô trống đánh dấu 🔴.
+
+**Phần D:** bảng tự chấm Gate G4 dạng ☐/✅ + kết luận go/no-go.
+
+## Bẫy thường gặp
+
+**Trả lời dev qua chat rồi thôi.** Câu trả lời không vào tài liệu là câu trả lời sẽ mất.
+Ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả bạn.
+
+**Nhận CR "nhỏ" không qua quy trình.** Không có CR nhỏ, chỉ có CR chưa được đánh giá tác
+động. Ghi nhận mất 5 phút, bỏ qua tốn hơn nhiều.
+
+**Tự quyết CR vì "rõ ràng là nên làm".** Vi phạm nguyên tắc 2. Kể cả khi bạn đúng, PO vẫn
+phải biết vì họ chịu trách nhiệm về scope và chi phí.
+
+**Sửa spec mà không báo ai.** Dev đang code theo bản cũ. Sửa âm thầm còn tệ hơn không sửa.
+
+**Cứu người dùng quá sớm trong UAT.** Chỗ họ loay hoay là dữ liệu quan trọng nhất của buổi
+UAT. Ghi lại trước, hướng dẫn sau.
+
+**UAT với dữ liệu quá sạch.** Dữ liệu thật có bản ghi thiếu trường, trùng, sai định dạng,
+tạo từ năm ngoái. Không đưa những thứ đó vào UAT thì UAT không chứng minh được gì.
+
+**Coi "không ai phản đối" là nghiệm thu.** Nghiệm thu phải có chữ ký và tiêu chí đã thoả
+thuận trước.

.claude/skills/ba-4-delivery-support/examples.md

@@ -0,0 +1,98 @@
+# Ví dụ minh hoạ — `ba-4-delivery-support`
+
+Tách khỏi `SKILL.md` để quy trình không lẫn ví dụ của một ngành cụ thể.
+
+---
+
+## Phần A · Bốn loại câu hỏi — phân loại rồi mới trả lời
+
+| Dev/QA hỏi | Loại | Trả lời thế nào | Sửa tài liệu? |
+|---|---|---|---|
+| "Mã cửa hàng có phân biệt hoa thường không?" | 1 — spec đã nói | Trích `SRS_US011 §2.3.3 F01`: `^[A-Z0-9-]+$`, tự chuyển hoa khi nhập | ❌ |
+| "AC-05 nói 'không cho lưu' — là chặn nút hay báo lỗi sau khi bấm?" | 2 — mơ hồ | Chốt: validate khi rời field, chặn nút khi form không hợp lệ | ✅ SRS v1.1 |
+| "Bệnh nhân huỷ lịch trước 2 tiếng thì có hoàn phí không?" | 3 — spec không nói | Đi hỏi PO → `OQ-018` | ✅ sau khi có trả lời |
+| "Spec nói giữ slot 10 phút nhưng nghiệp vụ bảo 5 phút" | 4 — spec sai | → `CR-004` | ✅ qua CR |
+
+🔴 Ba loại sau đều phải sửa tài liệu. Trả lời cho một dev mà không sửa spec nghĩa là người
+tiếp theo sẽ hỏi lại đúng câu đó.
+
+### Một mục `QLOG` đủ tiêu chuẩn
+
+```
+Q-014 | 2026-09-03 | Dev A | Loại 2
+Hỏi:      "AC-05 nói 'không cho lưu' — chặn nút hay báo lỗi sau khi bấm?"
+Trả lời:  Validate khi rời field (blur). Nút Lưu disable khi còn field lỗi.
+          Bấm Lưu khi hợp lệ mà server từ chối ⇒ hiện lỗi, GIỮ NGUYÊN dữ liệu đã nhập.
+Nguồn:    Chốt với PO (chị Lan) 2026-09-03 → DEC-07
+Hành động: ☐ SRS_US011 v1.0→v1.1 §2.3.4  ☐ Cập nhật RTM  ☐ Báo Dev B, QA
+```
+
+Ba phần bắt buộc: **trích dẫn nguồn** · **câu trả lời dứt khoát** · **hành động kèm theo**.
+
+---
+
+## Phần B · Phép thử Defect / CR / Spec gap
+
+Áp dụng **máy móc**, không theo cảm tính — cả hai bên đều có động cơ phân loại lệch.
+
+| Tình huống | SRS nói gì | Kết luận | Ai chịu |
+|---|---|---|---|
+| Lưu thất bại thì form bị xoá trắng | `AC-09` nói rõ "giữ nguyên dữ liệu đã nhập" | **Defect** | Dev sửa, không tính phí |
+| Khách muốn thêm cột "ngày cập nhật" vào bảng | §2.3.2 liệt kê 6 cột, không có cột này | **Change Request** | PO quyết |
+| Hai người cùng sửa một bản ghi, người sau ghi đè người trước | 🔴 SRS **không nói gì** về đồng thời | **Spec gap** | BA — thiếu sót đặc tả |
+| Job chạy lại tạo bút toán trùng | SRS không nói về idempotency | **Spec gap** | BA |
+
+**Spec gap xử lý thẳng thắn:** ghi nhận là thiếu sót của đặc tả, đánh giá tác động như một
+CR, nhưng nêu rõ nguyên nhân gốc trong `BENEFIT` ở GĐ5. Đừng đẩy sang khách như CR bình
+thường, cũng đừng nhận là bug của dev.
+
+Hai dòng cuối bảng là **cùng một lỗ hổng đặc tả** (không nghĩ tới đồng thời / chạy lại) ở hai
+loại sản phẩm khác nhau — đó là kiểu bài học đáng ghi vào GĐ5.
+
+---
+
+## Phần B · Bước "làm rõ vấn đề gốc" cứu tiền
+
+| Khách yêu cầu | Hỏi "để làm gì?" | Vấn đề gốc | Phương án rẻ hơn |
+|---|---|---|---|
+| "Thêm cột ngày cập nhật vào bảng" | Để tìm bản ghi mới sửa gần đây | Không lọc được theo thời gian | Thêm **bộ lọc** ngày, không thêm cột |
+| "Cho xuất toàn bộ hồ sơ ra Excel" | Để gửi bác sĩ xem trước ca khám | Bác sĩ không truy cập được hệ thống lúc đi buồng | Cấp quyền xem trên mobile — và tránh được rủi ro lộ hồ sơ |
+| "Chạy job đối soát mỗi giờ" | Vì sợ phát hiện lỗi muộn | Không có cảnh báo khi job đêm thất bại | Thêm **cảnh báo**, giữ nguyên lịch chạy đêm |
+
+Cả ba: giải pháp đúng khác thứ khách yêu cầu, và rẻ hơn nhiều.
+
+---
+
+## Phần C · Bốn nhóm test case hay thiếu
+
+| Nhóm | Câu hỏi kiểm tra | Ví dụ phát hiện thật |
+|---|---|---|
+| Phân quyền | Có test **gọi thẳng API** với token sai quyền không? | QA chỉ test ẩn nút trên UI; gọi thẳng API vẫn tạo được bản ghi |
+| Lỗi hệ thống | Có test timeout và kiểm tra **dữ liệu đã nhập được giữ nguyên**? | Không ai test, và form xoá trắng lọt tới UAT |
+| Đồng thời | Hai người sửa cùng bản ghi? Bản ghi bị xoá khi mình đang mở? | Không có test nào, và đây là spec gap phổ biến nhất |
+| Dữ liệu cũ | Có test với bản ghi tạo **trước** khi có tính năng này? | Bản ghi cũ thiếu trường mới ⇒ màn hình chi tiết lỗi |
+
+---
+
+## Phần D · Kịch bản UAT viết theo công việc, không theo màn hình
+
+| ❌ Theo màn hình | ✅ Theo công việc |
+|---|---|
+| "S1: Kiểm tra màn hình danh sách chênh lệch" | "S1: Đối soát doanh thu ngày hôm qua của 3 cửa hàng khu vực Hà Nội" |
+| "S2: Kiểm tra form đặt lịch" | "S2: Bệnh nhân gọi điện xin đổi lịch khám sang buổi chiều cùng ngày" |
+
+Kịch bản viết theo màn hình thì người dùng không nhận ra công việc của mình trong đó, và họ
+sẽ thao tác theo hướng dẫn thay vì theo thói quen thật — làm mất giá trị của buổi UAT.
+
+---
+
+## Phần D · Ba loại phát hiện — loại thứ ba hay bị ghi nhầm
+
+| Phát hiện tại UAT | Phân loại đúng | Xử lý |
+|---|---|---|
+| Bấm Lưu, mất kết nối, form trắng | **Defect** | Dev sửa |
+| "Tôi muốn thấy cả tên cửa hàng, không chỉ mã" | **Change Request** | Phiếu CR, PO quyết |
+| Người dùng tìm nút Lưu mất ~20 giây, cuối cùng phải hỏi | **Hiểu nhầm cách dùng** | → đào tạo **hoặc** xem lại vị trí nút |
+
+Loại thứ ba thường bị ghi thành defect. Nó là tín hiệu quý về đào tạo hoặc thiết kế chưa rõ —
+ghi riêng, và nó trở thành nguồn nội dung tốt nhất cho `MANUAL` ở GĐ5.

.claude/skills/ba-4-delivery-support/templates/change-request.md

@@ -0,0 +1,179 @@
+# CR — Change Request — `CR-nnn`
+
+| | |
+|---|---|
+| **ID** | CR-001 |
+| **Ngày nhận** | YYYY-MM-DD |
+| **Người đề xuất** | |
+| **Kênh** | |
+| **Ưu tiên đề xuất** | Khẩn / Cao / Trung bình / Thấp |
+| **Trạng thái** | 🟡 Đang đánh giá / 🟠 Chờ PO quyết / ✅ Chấp nhận / ⏸ Hoãn / ❌ Từ chối |
+| **Author** | <BA> (skill ba-4-delivery-support) |
+| **Liên quan** | US-011 · SRS_US011 v1.2 · AC-05 |
+
+---
+
+## 0. Phân loại — làm trước mọi thứ khác
+
+> 🔴 Đây là phân loại tốn kém nhất khi làm sai. Áp dụng phép thử **máy móc**, không theo cảm tính.
+
+```mermaid
+flowchart TD
+    Q1{"Sản phẩm có làm đúng<br/>tài liệu đã ký (SRS Baselined)?"}
+    Q2{"Tài liệu có nói về<br/>tình huống này không?"}
+    D(["DEFECT<br/>Dev sửa, không tính thêm chi phí<br/>→ Đóng phiếu này"])
+    CR(["CHANGE REQUEST<br/>PO quyết<br/>→ Tiếp tục §1"])
+    GAP(["SPEC GAP<br/>Thiếu sót đặc tả, trách nhiệm BA<br/>→ Tiếp tục, xem §0.1"])
+
+    Q1 -->|KHÔNG| D
+    Q1 -->|CÓ| Q2
+    Q2 -->|"CÓ, khách muốn khác đi"| CR
+    Q2 -->|"KHÔNG nói gì"| GAP
+```
+
+| | |
+|---|---|
+| **Kết luận** | Defect / Change Request / **Spec gap** |
+| **Căn cứ** | *(trích đích danh mục tài liệu — không viết "theo tôi nghĩ")* |
+
+### 0.1 Nếu là Spec gap
+
+Tài liệu im lặng về tình huống này ⇒ **thiếu sót của đặc tả, trách nhiệm thuộc BA**.
+
+| | |
+|---|---|
+| Vì sao đặc tả bỏ sót | |
+| Lẽ ra phải nằm ở mục nào | |
+| Đưa vào bài học GĐ5 | ☐ |
+
+Xử lý tiếp như một CR (đánh giá tác động, PO quyết), nhưng **nói rõ nguyên nhân gốc** —
+đừng đẩy sang khách như CR bình thường, cũng đừng nhận là bug của dev.
+
+---
+
+## 1. Yêu cầu — nguyên văn
+
+> "…"
+
+*Chép nguyên văn. Diễn giải lại theo ý mình là cách làm mất thông tin ngay từ bước đầu.*
+
+## 2. Làm rõ — vấn đề gốc là gì
+
+> 🔴 **Bước cứu được nhiều tiền nhất.** Khách nói "thêm cột X vào bảng" → hỏi *"để làm gì?"*
+> → hoá ra để tìm nhanh hơn → hoá ra chỉ cần thêm bộ lọc, rẻ hơn nhiều.
+
+| Câu hỏi | Trả lời |
+|---|---|
+| Việc này giải quyết vấn đề gì? | |
+| Hiện tại không có nó thì xử lý thế nào? | |
+| Bao lâu gặp một lần? Ai gặp? | |
+| Nếu để sau bản phát hành này thì sao? | |
+| Có cách nào khác đạt cùng kết quả không? | |
+
+**Vấn đề gốc:**
+> *(phát biểu lại bằng ngôn ngữ vấn đề, không phải ngôn ngữ giải pháp)*
+
+## 3. Đánh giá tác động
+
+*Rà đủ 6 trục như `IMPACT` ở GĐ2.*
+
+| Trục | Tác động | Mức |
+|---|---|---|
+| Màn hình/chức năng | | 🔴/🟠/🟢 |
+| Dữ liệu | | |
+| Business rule | | |
+| Phân quyền | | |
+| Tích hợp | | |
+| Báo cáo/đối soát | | |
+
+**Tài liệu phải sửa:**
+
+| Tài liệu | Mục | Version hiện tại → mới |
+|---|---|---|
+| SRS_US011 | §2.3.3, §4.1 | v1.2 → v1.3 |
+| AC_US011 | AC-05, AC-09 | |
+| RTM | | |
+
+**Ảnh hưởng tới việc đã làm:**
+
+| | |
+|---|---|
+| Code đã viết phải sửa | |
+| Test case phải viết lại | |
+| Đã UAT rồi thì phải test lại phần nào | |
+
+**Ước lượng** *(làm cùng dev, không ước lượng một mình)*:
+
+| Hạng mục | Công sức | Ai ước lượng |
+|---|---|---|
+| Phân tích + sửa tài liệu | | BA |
+| Phát triển | | Dev |
+| Kiểm thử | | QA |
+| **Tổng** | | |
+
+**Ảnh hưởng tiến độ:** …
+
+## 4. Phương án
+
+> 🔴 **Luôn trình ≥2 phương án.** Một phương án không phải là lựa chọn, đó là thông báo.
+
+| # | Phương án | Công sức | Rủi ro | Đáp ứng vấn đề gốc |
+|---|---|---|---|---|
+| A | Làm đúng như đề xuất | | | Hoàn toàn |
+| B | Giải pháp thay thế rẻ hơn | | | Một phần — thiếu … |
+| C | Hoãn sang phase sau | 0 | Người dùng phải làm tay tới … | Không |
+
+**Khuyến nghị của BA:** Phương án … vì …
+
+*(Khuyến nghị, không phải quyết định — nguyên tắc 2.)*
+
+## 5. Quyết định của PO
+
+| | |
+|---|---|
+| **Người quyết** | |
+| **Ngày** | |
+| **Quyết định** | ✅ Chấp nhận PA… / ⏸ Hoãn tới… / ❌ Từ chối |
+| **Lý do** | |
+| **Ghi vào** | `DEC-nn` trong `00-index/` |
+| **Ảnh hưởng tiến độ được chấp nhận** | |
+| **Chi phí được chấp nhận** | |
+
+## 6. Thực thi
+
+> Thứ tự bắt buộc: **sửa tài liệu trước, code sau.** Ngược lại thì tài liệu không bao giờ đuổi kịp.
+
+| # | Việc | Ai | Hạn | Trạng thái |
+|---|---|---|---|---|
+| 1 | Sửa SRS + tăng version + Change Log | BA | | ☐ |
+| 2 | Cập nhật RTM | BA | | ☐ |
+| 3 | **Báo cho team** (dev, QA, ai đã đọc bản cũ) | BA | | ☐ |
+| 4 | Sửa code | Dev | | ☐ |
+| 5 | Cập nhật test case | QA | | ☐ |
+| 6 | Test lại phạm vi hồi quy | QA | | ☐ |
+
+## 7. Đóng phiếu
+
+| | |
+|---|---|
+| Ngày đóng | |
+| Đã verify | ☐ |
+| Người xác nhận | |
+
+---
+
+# Sổ tổng hợp CR
+
+| ID | Ngày | Người đề xuất | Tóm tắt | Loại | Công sức | Trạng thái | Quyết định | Ngày quyết |
+|---|---|---|---|---|---|---|---|---|
+| CR-001 | | | | CR | 3d | ✅ | PA-B | |
+
+**Thống kê:**
+
+| Chỉ số | Giá trị | Ý nghĩa nếu cao |
+|---|---|---|
+| Tổng CR | | |
+| Trong đó **Spec gap** | | 🔴 Đặc tả GĐ3 chưa kỹ — rà lại checklist G3 |
+| Trong đó bị phân loại nhầm ban đầu | | Cần thống nhất lại phép thử §0 với team |
+| Tổng công sức phát sinh | | So với ước lượng ban đầu |
+| CR chờ quyết > 5 ngày | | 🔴 Đang chặn team |

.claude/skills/ba-4-delivery-support/templates/clarification-log.md

@@ -0,0 +1,101 @@
+# QLOG — Clarification Log — <PROJECT / US-id>
+
+| | |
+|---|---|
+| **Version** | *(cập nhật liên tục, tăng 0.1 mỗi lần thêm mục)* |
+| **Cập nhật** | YYYY-MM-DD |
+| **Author** | <BA> (skill ba-4-delivery-support) |
+| **Scope** | |
+
+> 🔴 **Mọi câu trả lời cho dev/QA phải nằm ở đây.** Trả lời miệng hoặc qua chat rồi để đó
+> là cách chắc chắn nhất khiến ba tháng sau không ai biết vì sao hệ thống hành xử như vậy.
+
+---
+
+## 1. Bảng theo dõi
+
+| ID | Ngày hỏi | Người hỏi | Câu hỏi (tóm tắt) | Loại | Người trả lời | Ngày trả lời | Tài liệu đã sửa | Trạng thái |
+|---|---|---|---|---|---|---|---|---|
+| Q-001 | | Dev A | | 2 | BA | | SRS v1.1 §2.3.3 | ✅ Đã đóng |
+| Q-002 | | QA B | | 3 | PO | — | — | 🔴 Quá hạn 4 ngày |
+
+**Bốn loại câu hỏi:**
+
+| Loại | Mô tả | Ai trả lời được | Hạn mục tiêu | Có phải sửa tài liệu |
+|---|---|---|---|---|
+| 1 | Spec đã nói rõ, người hỏi chưa đọc thấy | BA — trích dẫn đích danh | Trong ngày | ❌ Không |
+| 2 | Spec nói mơ hồ, hiểu được hai cách | BA — làm rõ | 1 ngày | ✅ **Bắt buộc** |
+| 3 | Spec không nói gì | PO / Tech Lead | 2 ngày | ✅ **Bắt buộc** |
+| 4 | Spec nói sai | PO → thành `CR` | 2 ngày | ✅ **Bắt buộc, qua CR** |
+
+🔴 Ba loại sau đều phải sửa tài liệu. Trả lời cho một dev mà không sửa spec nghĩa là người
+tiếp theo sẽ hỏi lại đúng câu đó.
+
+---
+
+## 2. Chi tiết
+
+### Q-001
+
+| | |
+|---|---|
+| **Ngày hỏi** | |
+| **Người hỏi** | |
+| **Kênh** | Chat / Họp / PR comment |
+| **Liên quan** | US-011 · SCR-03 · F04 · AC-05 |
+| **Loại** | 2 — spec mơ hồ |
+| **Chặn gì** | Dev đang chờ để code màn hình form |
+
+**Câu hỏi (nguyên văn):**
+> "…"
+
+**Câu trả lời:**
+> *(dứt khoát — không "có thể", không "tuỳ")*
+
+**Nguồn của câu trả lời:**
+
+| | |
+|---|---|
+| Trích dẫn | `SRS_US011_v1.0.md` §2.3.3, dòng F04 |
+| Hoặc: ai quyết định | STK-01, ngày… → `DEC-nn` |
+
+**Hành động kèm theo:**
+
+| # | Việc | Tài liệu | Version | Trạng thái |
+|---|---|---|---|---|
+| 1 | Làm rõ mô tả F04 | `SRS_US011` | v1.0 → v1.1 | ☐ |
+| 2 | Cập nhật RTM | `RTM_…` | | ☐ |
+| 3 | Báo cho Dev B và QA (đang dùng bản cũ) | — | | ☐ |
+
+**Nếu chưa trả lời được:**
+
+| | |
+|---|---|
+| Đã tạo | `OQ-0nn` |
+| Người phải trả lời | |
+| Hạn | |
+| **Phương án tạm cho dev** | *(kèm cảnh báo rõ: đây là tạm, có thể phải sửa lại)* |
+
+---
+
+## 3. Câu hỏi lặp lại
+
+*Cùng một câu hỏi từ ≥2 người ⇒ tài liệu có vấn đề ở chỗ đó, không phải người hỏi có vấn đề.*
+
+| Câu hỏi | Số lần được hỏi | Mục tài liệu liên quan | Đã sửa để không ai hỏi nữa |
+|---|---|---|---|
+| | | | ☐ |
+
+Đây là nguồn cải tiến chất lượng đặc tả tốt nhất — ghi lại và mang vào bài học ở GĐ5.
+
+## 4. Thống kê
+
+| Chỉ số | Giá trị | Ý nghĩa |
+|---|---|---|
+| Tổng câu hỏi | | |
+| Loại 1 (spec đã nói rõ) | | Cao ⇒ tài liệu khó tra cứu, cần mục lục/chỉ mục tốt hơn |
+| Loại 2 (mơ hồ) | | Cao ⇒ vi phạm quy tắc W2, cần viết chặt hơn |
+| Loại 3 (không nói) | | Cao ⇒ đặc tả thiếu phạm vi, rà lại checklist G3 |
+| Loại 4 (sai) | | Cao ⇒ GĐ2 hiểu sai nghiệp vụ |
+| Thời gian trả lời trung bình | | |
+| Đang quá hạn | | 🔴 nếu > 0 |

.claude/skills/ba-4-delivery-support/templates/testcase-review.md

@@ -0,0 +1,115 @@
+# TCREVIEW — Biên bản review test case — <US-id>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Người review** | <BA> |
+| **Người viết test case** | <QA> |
+| **Tài liệu đối chiếu** | `SRS_US011_v1.2` · `AC_US011_v1.1` · `BR_…_v1.0` |
+| **Bộ test case** | *(đường dẫn/công cụ)* |
+
+> BA **không viết** test case — QA viết. BA đối chiếu xem test case có phủ đúng AC không.
+> Kết quả review là **nhận xét để thống nhất**, không phải lệnh sửa.
+
+---
+
+## 1. Bốn phép đối chiếu
+
+### 1.1 Mỗi AC → có ≥1 test case
+
+| AC | Nhóm | Test case phủ | ☐/🔴 | Ghi chú |
+|---|---|---|---|---|
+| AC-01 | Thành công | TC-001, TC-002 | ✅ | |
+| AC-09 | Lỗi hệ thống | — | 🔴 | Chưa có TC nào cho timeout |
+
+**AC không có test case ⇒ 🔴 bắt buộc bổ sung.** Đây là AC sẽ không được kiểm chứng.
+
+### 1.2 Mỗi test case → truy về được một AC/BR
+
+| Test case | Truy về | ☐/🟠 | Ghi chú |
+|---|---|---|---|
+| TC-015 | — | 🟠 | Không map về AC nào — test thừa, hay AC còn thiếu? |
+
+Test case không truy về được ⇒ **một trong hai**: QA test thừa, hoặc BA viết thiếu AC.
+Cả hai đều là phát hiện có giá trị.
+
+### 1.3 Mỗi BR → có test ca vi phạm
+
+| BR | Test luồng đúng | Test **ca vi phạm** | ☐/🔴 |
+|---|---|---|---|
+| BR-021 | TC-003 | TC-004 | ✅ |
+| BR-022 | TC-007 | — | 🔴 |
+
+Rule chỉ được test ở luồng đúng là rule chưa được test.
+
+### 1.4 Mỗi dòng bảng dữ liệu biên → có test case
+
+| Field | Dưới ngưỡng | Ngưỡng dưới | Ngưỡng trên | Trên ngưỡng | Rỗng | Ký tự đặc biệt | Khoảng trắng |
+|---|---|---|---|---|---|---|---|
+| F01 | TC-010 | TC-011 | TC-012 | TC-013 | TC-014 | 🔴 — | 🔴 — |
+
+Giá trị biên là chỗ lỗi hay xảy ra nhất. Ô trống ở đây là rủi ro thật.
+
+---
+
+## 2. Bốn nhóm hay thiếu — rà đích danh
+
+| Nhóm | Câu hỏi kiểm tra | Có test | Ghi chú |
+|---|---|---|---|
+| **Phân quyền** | Có test **gọi thẳng API** với token sai quyền không, hay chỉ test giao diện? | ☐ | Chặn ở UI là trải nghiệm, chặn ở BE mới là bảo mật |
+| **Lỗi hệ thống** | Có test timeout/5xx và kiểm tra **dữ liệu đã nhập được giữ nguyên** không? | ☐ | |
+| **Đồng thời** | Hai người sửa cùng một bản ghi thì sao? Bản ghi bị xoá khi mình đang mở? | ☐ | |
+| **Dữ liệu cũ** | Có test với bản ghi tạo **trước khi** có tính năng này không? | ☐ | Bản ghi cũ thiếu trường mới |
+
+---
+
+## 3. Nhận xét
+
+*Ba mức. Không sửa test case của QA — ghi nhận xét rồi thống nhất.*
+
+| # | Mức | Test case / AC | Nhận xét | QA phản hồi | Thống nhất |
+|---|---|---|---|---|---|
+| 1 | 🔴 Thiếu phủ AC | AC-09 | Chưa có TC cho timeout khi lưu | | ☐ |
+| 2 | 🟠 Nên bổ sung | TC-012 | Nên thêm ca chuỗi có dấu tiếng Việt | | ☐ |
+| 3 | 💬 Góp ý | TC-005 | Dữ liệu mẫu nên giống dữ liệu thật hơn | | ☐ |
+
+| Mức | Nghĩa | Bắt buộc xử lý |
+|---|---|---|
+| 🔴 | Có AC/BR không được kiểm chứng | ✅ Phải bổ sung trước khi test |
+| 🟠 | Rủi ro sót lỗi, không chặn | Thoả thuận với QA |
+| 💬 | Góp ý chất lượng | Tuỳ QA |
+
+---
+
+## 4. Phát hiện ngược — lỗi của tài liệu BA
+
+*Review test case là dịp phát hiện lỗi của chính SRS. Ghi ra, đừng im lặng sửa.*
+
+| # | QA phát hiện | Loại | Xử lý |
+|---|---|---|---|
+| 1 | AC-05 hiểu được hai cách | Spec mơ hồ | → `Q-0nn`, sửa SRS v1.3 |
+| 2 | Không có AC cho ca … | Spec thiếu | → `OQ-0nn` hỏi PO |
+
+---
+
+## 5. Kết luận
+
+| | |
+|---|---|
+| **Số AC** | |
+| **Số AC được phủ** | … / … (…%) |
+| **Số test case** | |
+| **Số test case không truy vết được** | |
+| **Số phát hiện 🔴** | |
+| **Kết luận** | ✅ Đủ để bắt đầu test / 🔴 Cần bổ sung trước |
+
+**Độ phủ AC phải đạt 100% trước khi bắt đầu test.** Dưới 100% nghĩa là có yêu cầu sẽ không
+được kiểm chứng, và không ai biết là cái nào cho tới khi người dùng phát hiện.
+
+## 6. Xác nhận
+
+| Vai trò | Người | Ngày | Xác nhận |
+|---|---|---|---|
+| QA | | | ☐ Đã tiếp nhận nhận xét, thống nhất xử lý 🔴 |
+| BA | | | ☐ Đã sửa các lỗi tài liệu phát hiện ở §4 |

.claude/skills/ba-4-delivery-support/templates/uat-plan.md

@@ -0,0 +1,187 @@
+# UAT — Kế hoạch & kết quả — <PROJECT / Đợt phát hành>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <BA> (skill ba-4-delivery-support) |
+| **Status** | 🟡 Kế hoạch / 🟠 Đang chạy / ✅ Hoàn thành |
+| **Approved by** | PO: — |
+| **Phạm vi** | US-011, US-012, US-013 |
+
+---
+
+# PHẦN A — KẾ HOẠCH *(hoàn thành trước ngày UAT ít nhất 1 tuần)*
+
+## A1. Tiêu chí pass — chốt TRƯỚC khi bắt đầu
+
+> 🔴 Chốt sau khi đã thấy kết quả thì không còn là tiêu chí. Mục này phải có chữ ký của PO
+> **trước** buổi UAT đầu tiên.
+
+| # | Tiêu chí | Ngưỡng |
+|---|---|---|
+| 1 | Kịch bản mức Must pass | 100% |
+| 2 | Kịch bản mức Should pass | ≥ 90% |
+| 3 | Defect Critical/High còn mở | 0 |
+| 4 | Defect Medium còn mở | Có kế hoạch xử lý + ticket |
+| 5 | | |
+
+| | |
+|---|---|
+| **PO xác nhận tiêu chí** | ☐ — ngày… |
+
+## A2. Người tham gia
+
+| Vai trò | Tên | Là người dùng thật? | Kịch bản phụ trách | Đã có tài khoản |
+|---|---|---|---|---|
+| | | ✅/❌ | S1, S2 | ☐ |
+
+🔴 **Phải là người sẽ dùng thật, không phải người đại diện.** Người đại diện pass rồi người
+dùng thật từ chối là kịch bản hỏng dự án ở phút chót.
+
+## A3. Môi trường
+
+| | |
+|---|---|
+| Môi trường | |
+| Đường dẫn | |
+| Phiên bản triển khai | |
+| Truy cập từ đâu (VPN? máy nội bộ?) | |
+| Hệ thống ngoài: thật hay giả lập | |
+| Ai hỗ trợ kỹ thuật tại chỗ | |
+
+**Tài khoản:**
+
+| Tài khoản | Vai trò | Phạm vi dữ liệu | Đã cấp | Đã đăng nhập thử |
+|---|---|---|---|---|
+| | | | ☐ | ☐ |
+
+*Chưa đăng nhập thử trước ngày UAT là lý do phổ biến khiến buổi UAT mất một tiếng đầu.*
+
+## A4. Dữ liệu chuẩn bị
+
+| Loại dữ liệu | Số lượng | Đặc điểm | Đã chuẩn bị |
+|---|---|---|---|
+| Bản ghi bình thường | | | ☐ |
+| **Bản ghi ở giá trị biên** | | Dài nhất, ngắn nhất, số lớn nhất | ☐ |
+| **Bản ghi ca ngoại lệ** | | Theo bảng A5 của `PROCESS` | ☐ |
+| **Bản ghi cũ** | | Tạo trước khi có tính năng này, thiếu trường mới | ☐ |
+| **Dữ liệu bẩn** | | Thiếu trường, sai định dạng, trùng | ☐ |
+
+🔴 **Dữ liệu quá sạch ⇒ UAT pass, chạy thật thì lỗi.** Dữ liệu thật luôn có bản ghi thiếu
+trường, trùng, sai định dạng, tạo từ nhiều năm trước. Không đưa chúng vào UAT thì UAT không
+chứng minh được gì.
+
+## A5. Kịch bản
+
+> Viết theo **luồng công việc thật**, không theo màn hình. Kịch bản viết theo màn hình thì
+> người dùng không nhận ra công việc của mình trong đó.
+
+### S1 — <Tên công việc theo cách người dùng gọi>
+
+| | |
+|---|---|
+| **Mức** | Must / Should / Could |
+| **Vai trò thực hiện** | |
+| **AC liên quan** | AC-01, AC-03 |
+| **Dữ liệu cần** | |
+| **Thời gian dự kiến** | |
+
+| # | Bước | Người dùng làm gì | Kết quả mong đợi |
+|---|---|---|---|
+| 1 | | | |
+| 2 | | | |
+
+**Coi là pass khi:** …
+
+---
+
+# PHẦN B — KẾT QUẢ
+
+## B1. Tổng hợp kịch bản
+
+| Kịch bản | Mức | Người chạy | Ngày | Kết quả | Phát hiện |
+|---|---|---|---|---|---|
+| S1 | Must | | | ✅ Pass / ❌ Fail / ⏭ Chưa chạy | P-001 |
+
+| | |
+|---|---|
+| **Must**: pass … / … (…%) | |
+| **Should**: pass … / … (…%) | |
+
+## B2. Phát hiện
+
+| ID | Kịch bản | Bước | Mong đợi | Thực tế | Ảnh | **Phân loại** | Mức | Trạng thái |
+|---|---|---|---|---|---|---|---|---|
+| P-001 | S1 | 3 | | | | Defect | High | Mở |
+| P-002 | S2 | 1 | | | | **Hiểu nhầm cách dùng** | — | → đào tạo |
+
+**Ba loại phát hiện — phân loại đúng ngay tại chỗ:**
+
+| Loại | Nghĩa | Xử lý |
+|---|---|---|
+| **Defect** | Sản phẩm không đúng SRS đã ký | Dev sửa |
+| **Change Request** | Sản phẩm đúng SRS, khách muốn khác | → phiếu `CR-nnn` |
+| **Hiểu nhầm cách dùng** | Sản phẩm đúng, người dùng không tìm ra/hiểu sai | → đào tạo **hoặc** cải thiện thiết kế |
+
+🔴 Loại thứ ba thường bị ghi nhầm thành defect. Nó là tín hiệu quý về đào tạo hoặc về thiết
+kế chưa rõ — ghi riêng và xử lý ở GĐ5, đừng để lẫn vào danh sách bug.
+
+**Mức defect:**
+
+| Mức | Định nghĩa |
+|---|---|
+| Critical | Chặn hoàn toàn nghiệp vụ, hoặc sai lệch dữ liệu/tiền |
+| High | Nghiệp vụ chính không hoàn thành được, có cách vòng nhưng tốn kém |
+| Medium | Gây bất tiện, có cách vòng chấp nhận được |
+| Low | Thẩm mỹ, chính tả, không ảnh hưởng nghiệp vụ |
+
+## B3. Quan sát trong lúc UAT
+
+*BA là **người quan sát và ghi chép**, không phải người hướng dẫn thao tác. Chỗ người dùng
+loay hoay là thông tin quý nhất của buổi UAT — đừng cứu họ quá sớm.*
+
+| # | Quan sát | Ở đâu | Ý nghĩa | Đề xuất |
+|---|---|---|---|---|
+| 1 | Người dùng tìm nút Lưu mất ~20 giây | SCR-03 | Vị trí nút không theo thói quen | Xem lại bố cục |
+
+## B4. Defect chấp nhận tạm
+
+| ID | Mức | Vì sao chấp nhận | **Ticket theo dõi** | Hạn xử lý | Ai chịu trách nhiệm |
+|---|---|---|---|---|---|
+| | | | 🔴 **bắt buộc có** | | |
+
+🔴 Defect "chấp nhận tạm" mà **không có ticket** sẽ biến mất, và quay lại sau sáu tháng dưới
+dạng khiếu nại của người dùng. Không có ticket ⇒ không được chấp nhận tạm.
+
+## B5. Change Request phát sinh
+
+| CR | Tóm tắt | Quyết định | Ảnh hưởng phát hành này |
+|---|---|---|---|
+
+## B6. Kết luận Go / No-go
+
+| Tiêu chí (từ A1) | Ngưỡng | Thực tế | ☐/✅ |
+|---|---|---|---|
+| Kịch bản Must pass | 100% | | |
+| Defect Critical/High mở | 0 | | |
+
+| | |
+|---|---|
+| **Kết luận** | ✅ GO / 🔴 NO-GO / 🟠 GO có điều kiện |
+| **Điều kiện kèm theo** | |
+| **Người quyết** | PO — |
+| **Ngày** | |
+| **Chữ ký nghiệm thu** | |
+
+*"Không ai phản đối" không phải nghiệm thu. Nghiệm thu cần chữ ký và tiêu chí đã thoả thuận
+trước ở §A1.*
+
+## B7. Bàn giao sang GĐ5
+
+| # | Việc | Ai | Trạng thái |
+|---|---|---|---|
+| 1 | Danh sách defect còn mở + ticket | BA | ☐ |
+| 2 | Danh sách "hiểu nhầm cách dùng" → nội dung đào tạo | BA | ☐ |
+| 3 | Baseline KPI trước go-live *(để GĐ5 so sánh)* | BA | ☐ |
+| 4 | Chốt ngày đo hiệu quả | BA + PO | ☐ |