init git

.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 | ☐ |