improve BA skill

ba-output/e-commerce/02-analysis/BACKLOG_CartCheckout_v1.0.md

@@ -0,0 +1,534 @@
+# BACKLOG — Giỏ hàng & Checkout (e-commerce)
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | 2026-09-08 |
+| **Author** | BA (qua skill ba-2-analysis) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Profile** | screen · greenfield · standard (xem `00-index/PROFILE_e-commerce.md`) |
+| **Source** | `01-discovery/BRIEF_CartCheckout_v1.0.md` (RQ-001…RQ-004) · `PROCESS_CartCheckout_v1.0.md` v1.0 · Trả lời của người dùng cho `OQ-004` và `OQ-008` (xem `DEC-03`, `DEC-04` ở `00-index/DECISION_e-commerce.md`) |
+| **Scope** | Module Giỏ hàng & Checkout — RQ-001…RQ-004. Ưu tiên phân rã US cho màn hình Giỏ hàng (FR-05) và Checkout & tách đơn (FR-06), theo đúng chỉ định phạm vi lần chạy này. Tối đa 8 US (giới hạn theo chỉ đạo "tối đa 6–8 US"). |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | CR |
+|---|---|---|---|---|
+| 1.0 | 2026-09-08 | BA (qua skill ba-2-analysis) | Bản đầu — 8 US, 2 Epic, 3 Feature | — |
+
+---
+
+> ⚠️ **Ngoại lệ gate G1** — xem cảnh báo đầy đủ ở đầu `PROCESS_CartCheckout_v1.0.md`. Tài liệu
+> này được viết tiếp trong khi `BRIEF` module chưa qua G1 chính thức, theo xác nhận của người
+> điều phối — xem `DEC-02` ở `00-index/DECISION_e-commerce.md`. Backlog dưới đây **phải rà lại
+> phạm vi và ưu tiên** khi PO ký G1 thật.
+
+## 0. Sơ đồ Use Case — toàn cảnh cho PO
+
+```mermaid
+flowchart LR
+    GUEST(["👤 Guest"])
+    CUS(["👤 Customer"])
+
+    subgraph HT["Phạm vi RQ-001…RQ-004 — Giỏ hàng & Checkout"]
+        UC1(["US-001 Thêm sản phẩm đa seller vào giỏ"])
+        UC2(["US-002 Xem giỏ hàng nhóm theo seller"])
+        UC3(["US-003 Sửa/xoá sản phẩm trong giỏ"])
+        UC4(["US-004 Checkout & tách đơn theo seller"])
+        UC5(["US-005 Nhập địa chỉ & xem phí ship theo seller"])
+        UC6(["US-006 Checkout không cần tài khoản (Guest)"])
+        UC7(["US-007 Thanh toán COD"])
+        UC8(["US-008 Thanh toán VNPay/Momo"])
+    end
+
+    NGOAI1[["Catalog & Tìm kiếm — ngoài phạm vi"]]
+    NGOAI2[["VNPay/Momo — ngoài phạm vi (bên thứ 3)"]]
+    NGOAI3[["GHN/GHTK — ngoài phạm vi (bên thứ 3)"]]
+    NGOAI4[["Khuyến mãi & Loyalty — ngoài phạm vi (điểm tích hợp, OQ-004 đã đóng)"]]
+
+    GUEST --- UC1
+    GUEST --- UC2
+    GUEST --- UC3
+    GUEST --- UC4
+    GUEST --- UC5
+    GUEST --- UC6
+    GUEST --- UC7
+    GUEST --- UC8
+    CUS --- UC1
+    CUS --- UC2
+    CUS --- UC3
+    CUS --- UC4
+    CUS --- UC5
+    CUS --- UC7
+    CUS --- UC8
+
+    UC1 --- NGOAI1
+    UC5 --- NGOAI3
+    UC8 --- NGOAI2
+    UC4 -.-> NGOAI4
+```
+
+*`Customer` không có US-006 riêng (Guest checkout không áp dụng cho tài khoản đã có). Liên
+kết nét đứt `UC4 -.-> NGOAI4` = điểm tích hợp hiển thị kết quả coupon/điểm thưởng do module
+khác tính (đã đóng `OQ-004`, xem `DEC-03`), module này chỉ gọi API áp dụng và hiển thị.*
+
+| Actor trong sơ đồ | Vai trò trong `RBAC` | Số US |
+|---|---|---|
+| Guest | ROLE-01 | 8 |
+| Customer | ROLE-02 | 7 (không gồm US-006) |
+
+*Actor khớp `RBAC_CartCheckout_v1.0.md` §1.*
+
+## 1. Cây phân rã
+
+```mermaid
+flowchart LR
+    RQ001["RQ-001 Giỏ hàng đa seller"]
+    RQ002["RQ-002 Tách đơn theo seller"]
+    RQ003["RQ-003 Thanh toán VNPay/Momo/COD"]
+    RQ004["RQ-004 Guest checkout"]
+
+    E01["EPIC-01 Giỏ hàng & Checkout đa seller"]
+    E02["EPIC-02 Thanh toán đa kênh"]
+
+    F01["FEAT-01 Quản lý giỏ hàng đa seller"]
+    F02["FEAT-02 Checkout & tách đơn theo seller"]
+    F03["FEAT-03 Thanh toán"]
+
+    U01(["US-001"])
+    U02(["US-002"])
+    U03(["US-003"])
+    U04(["US-004"])
+    U05(["US-005"])
+    U06(["US-006"])
+    U07(["US-007"])
+    U08(["US-008"])
+
+    RQ001 --> E01
+    RQ002 --> E01
+    RQ004 --> E01
+    RQ003 --> E02
+
+    E01 --> F01
+    E01 --> F02
+    E02 --> F03
+
+    F01 --> U01
+    F01 --> U02
+    F01 --> U03
+    F02 --> U04
+    F02 --> U05
+    F02 --> U06
+    F03 --> U07
+    F03 --> U08
+```
+
+## 2. Epic
+
+| ID | Tên | Giá trị nghiệp vụ | RQ phủ | Feature | Ưu tiên |
+|---|---|---|---|---|---|
+| EPIC-01 | Giỏ hàng & Checkout đa seller | Cho phép khách mua từ nhiều seller trong một trải nghiệm thống nhất — điều kiện tiên quyết của mô hình marketplace | RQ-001, RQ-002, RQ-004 | FEAT-01, FEAT-02 | Must — ưu tiên hàng đầu theo `OQ-008` (đã đóng, xem `DEC-04`) |
+| EPIC-02 | Thanh toán đa kênh | Thu tiền qua kênh phổ biến VN mà không lưu thẻ, giảm phạm vi PCI-DSS | RQ-003 | FEAT-03 | Must, nhưng nội bộ Feature có thứ tự con: COD trước, ví điện tử có thể lùi (xem `OQ-008`/`DEC-04` và §8) |
+
+## 3. Feature
+
+| ID | Tên | Epic | Mô tả một câu | US | MoSCoW |
+|---|---|---|---|---|---|
+| FEAT-01 | Quản lý giỏ hàng đa seller | EPIC-01 | Customer/Guest thêm, xem, sửa, xoá sản phẩm từ nhiều seller trong một giỏ hàng | US-001, US-002, US-003 | Must |
+| FEAT-02 | Checkout & tách đơn theo seller | EPIC-01 | Customer/Guest xác nhận đặt hàng; hệ thống thu địa chỉ, tính phí ship, tách đơn theo seller, hỗ trợ cả Guest | US-004, US-005, US-006 | Must |
+| FEAT-03 | Thanh toán | EPIC-02 | Customer/Guest thanh toán qua COD hoặc VNPay/Momo | US-007, US-008 | Must (US-007) — US-008 Must nhưng có thể triển khai sau theo `DEC-04` |
+
+## 4. User Story
+
+> Mẫu — **cả ba vế bắt buộc**: *Là `<vai trò cụ thể>`, tôi muốn `<hành động>`, để `<giá trị
+> nghiệp vụ>`.*
+
+### US-001 — Thêm sản phẩm từ nhiều seller vào giỏ hàng
+
+| | |
+|---|---|
+| **Feature** | FEAT-01 |
+| **RQ** | RQ-001 |
+| **MoSCoW** | Must |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | Không — US nền tảng đầu tiên |
+| **BR áp dụng** | *(chưa có BR ràng buộc số lượng seller/sản phẩm tối đa trong giỏ — xem `OQ` mới nếu phát sinh ở GĐ3)* |
+| **Ước lượng sơ bộ** | M |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn thêm sản phẩm từ nhiều seller khác nhau vào cùng một giỏ
+> hàng, để tôi có thể mua sắm từ nhiều gian hàng mà không phải đặt hàng riêng lẻ với từng
+> seller.
+
+**Phạm vi:**
+- Trong: thêm `CartItem` từ bất kỳ seller nào vào `Cart` hiện có của khách (theo `customer_id`
+  hoặc `session_id` nếu Guest)
+- Ngoài: kiểm tra tồn kho thời điểm checkout (thuộc US-004), tính giá sau khuyến mãi (thuộc
+  module Khuyến mãi/Loyalty theo `OQ-004`/`DEC-03`)
+
+**Điều kiện nghiệm thu mức thô:**
+- Thêm được sản phẩm của seller A rồi seller B vào cùng một giỏ mà không bị lỗi/mất dữ liệu
+  của seller A
+- Giỏ hàng của Guest được giữ lại theo phiên (thời hạn cụ thể — GĐ3 xác nhận, tham khảo SAD
+  §5.3.1 đề xuất 7 ngày cho Guest, cần Tech Lead xác nhận có áp dụng đúng con số này không)
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | — |
+
+### US-002 — Xem giỏ hàng nhóm theo seller
+
+| | |
+|---|---|
+| **Feature** | FEAT-01 |
+| **RQ** | RQ-001 |
+| **MoSCoW** | Must |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | US-001 (phải có sản phẩm trong giỏ trước) |
+| **BR áp dụng** | *(chưa có — mục hiển thị thuần tuý)* |
+| **Ước lượng sơ bộ** | M |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn xem giỏ hàng của mình được **nhóm hiển thị theo từng
+> seller** kèm tổng tiền từng nhóm, để tôi biết rõ mình đang mua gì của ai trước khi quyết định
+> đặt hàng.
+
+**Phạm vi:**
+- Trong: hiển thị màn hình Giỏ hàng (FR-05, ưu tiên của lần chạy này) nhóm `CartItem` theo
+  `seller_id`, tổng tiền từng nhóm, tổng tiền toàn giỏ
+- Ngoài: phí vận chuyển (chưa biết tới lúc checkout — thuộc US-005), áp dụng coupon/điểm
+  thưởng (module khác, `OQ-004`/`DEC-03`)
+
+**Điều kiện nghiệm thu mức thô:**
+- Giỏ hàng có sản phẩm của 3 seller hiển thị đúng 3 nhóm, mỗi nhóm đúng tổng tiền của nhóm đó
+- Giỏ hàng rỗng hiển thị trạng thái rỗng rõ ràng (text cụ thể — GĐ3, W5)
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | — |
+
+### US-003 — Sửa số lượng / xoá sản phẩm trong giỏ hàng
+
+| | |
+|---|---|
+| **Feature** | FEAT-01 |
+| **RQ** | RQ-001 |
+| **MoSCoW** | Must |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | US-001 |
+| **BR áp dụng** | *(chưa có — ràng buộc số lượng tối thiểu/tối đa mỗi dòng chưa được chốt, xem GĐ3)* |
+| **Ước lượng sơ bộ** | S |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn cập nhật số lượng hoặc xoá sản phẩm khỏi giỏ hàng, để tôi
+> kiểm soát đúng những gì mình sẽ mua trước khi checkout.
+
+**Phạm vi:**
+- Trong: sửa `quantity`, xoá `CartItem` khỏi `Cart`
+- Ngoài: cảnh báo hết hàng theo thời gian thực (thuộc US-004 tại thời điểm checkout, không
+  phải tại thời điểm xem/sửa giỏ — trừ khi PO quyết khác, xem `OQ-009`)
+
+**Điều kiện nghiệm thu mức thô:**
+- Sửa số lượng thành 0 ⇒ hành vi (xoá luôn hay chặn) — **chưa chốt, cần OQ ở GĐ3**
+- Xoá hết sản phẩm của một seller ⇒ nhóm hiển thị theo seller đó biến mất (US-002)
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ⚠️ | ✅ | ✅ | E: hành vi khi sửa số lượng về 0 chưa rõ — cần làm rõ ở GĐ3 (AC) |
+
+### US-004 — Checkout & tự động tách đơn theo seller
+
+| | |
+|---|---|
+| **Feature** | FEAT-02 |
+| **RQ** | RQ-002 |
+| **MoSCoW** | Must |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | US-001, US-002, US-005 (cần địa chỉ + phí ship trước khi xác nhận cuối) |
+| **BR áp dụng** | BR-CART-01 (tách đơn theo seller), BR-CART-02 (giữ tồn kho — chống oversell) |
+| **Ước lượng sơ bộ** | L |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn xác nhận đặt hàng và để hệ thống **tự động tách giỏ hàng đa
+> seller thành các đơn con riêng theo từng seller**, để mỗi seller nhận và xử lý đúng phần đơn
+> của mình mà không thấy dữ liệu của seller khác.
+
+**Phạm vi:**
+- Trong: kiểm tra tồn kho, tạo `Order` (cha) + nhiều `OrderSeller` (con) + `OrderItem`
+- Ngoài: xử lý đơn sau khi tạo (đóng gói, giao hàng — FR-19/FR-26, ngoài phạm vi module)
+
+**Điều kiện nghiệm thu mức thô:**
+- Giỏ hàng có N seller ⇒ tạo đúng N `OrderSeller` con **(giả định `ASM-03` chưa xác minh —
+  `OQ-011`, phải xác nhận trước khi coi AC này là chốt ở GĐ3)**
+- Không đủ tồn kho một sản phẩm bất kỳ ⇒ chặn tạo đơn, báo lỗi, giữ nguyên giỏ hàng
+  (BR-CART-02)
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ | E: phụ thuộc `OQ-009` (giá/tồn kho thay đổi) và `OQ-011` (ASM-03 tách N seller); S: đây là US lõi phức tạp nhất, có thể cần tách thêm ở GĐ3 theo luồng thành công/luồng lỗi (W4); T: điều kiện biên "đủ tồn kho" cần dữ liệu test cụ thể ở GĐ3 |
+
+### US-005 — Nhập địa chỉ & xem phí vận chuyển ước tính theo từng seller
+
+| | |
+|---|---|
+| **Feature** | FEAT-02 |
+| **RQ** | RQ-002, RQ-001 (đóng góp làm rõ chi phí giỏ đa seller — `RISK-04`) |
+| **MoSCoW** | Must |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | US-002 |
+| **BR áp dụng** | *(chưa có BR tính phí ship cụ thể — thuộc tích hợp GHN/GHTK, `ASM-02` chưa xác minh)* |
+| **Ước lượng sơ bộ** | L |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn nhập/chọn địa chỉ giao hàng và xem phí vận chuyển ước tính
+> theo từng đơn con seller **trước khi** xác nhận đặt hàng, để tôi biết chính xác tổng số tiền
+> phải trả và không bị bất ngờ ở bước cuối (giải quyết điểm đau `P3`/`RISK-04` ở `PROCESS` B3).
+
+**Phạm vi:**
+- Trong: thu thập địa chỉ giao hàng, gọi tích hợp GHN/GHTK để ước tính phí/thời gian giao theo
+  từng seller
+- Ngoài: tạo vận đơn thật (chỉ xảy ra sau khi đơn đã `confirmed`, thuộc FR-26)
+
+**Điều kiện nghiệm thu mức thô:**
+- Địa chỉ ngoài vùng phục vụ của GHN/GHTK cho một seller cụ thể ⇒ hành vi hiển thị — **chưa
+  chốt, cần OQ ở GĐ3**
+- Nếu `ASM-02` sai (API không khả dụng thời gian thực) ⇒ phương án dự phòng (ước tính tĩnh)
+  — **chưa chốt, chặn bởi xác minh ASM-02 ở GĐ1/RISK**
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ⚠️ | ✅ | ⚠️ | E/T: phụ thuộc kết quả xác minh `ASM-02` (GHN/GHTK) — chưa có, ảnh hưởng trực tiếp cách viết AC ở GĐ3 |
+
+### US-006 — Checkout không cần tạo tài khoản (Guest)
+
+| | |
+|---|---|
+| **Feature** | FEAT-02 |
+| **RQ** | RQ-004 |
+| **MoSCoW** | Must |
+| **Vai trò** | Guest |
+| **Phụ thuộc** | US-004, US-005 |
+| **BR áp dụng** | BR-CART-07 (điều kiện tối thiểu cho Guest checkout) |
+| **Ước lượng sơ bộ** | M |
+
+**Story:**
+> Là Guest (khách vãng lai), tôi muốn hoàn tất checkout mà không cần tạo tài khoản trước, để
+> tôi không phải dừng lại đăng ký tài khoản khi chỉ muốn mua một lần.
+
+**Phạm vi:**
+- Trong: cho phép hoàn tất toàn bộ luồng US-001…US-005, US-007/US-008 mà không yêu cầu đăng
+  nhập/đăng ký
+- Ngoài: chuyển đổi giỏ hàng Guest thành tài khoản Customer sau khi mua (nếu có — thuộc FR-01,
+  ngoài phạm vi module này)
+
+**Điều kiện nghiệm thu mức thô:**
+- Guest hoàn tất được toàn bộ luồng checkout mà không bị chặn bởi bước "đăng nhập bắt buộc"
+- Guest phải cung cấp tối thiểu thông tin liên hệ nào (họ tên, SĐT, email?) — **chưa chốt, xem
+  `BR-CART-07`, cần GĐ3 xác nhận danh sách field bắt buộc**
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ⚠️ | ✅ | ✅ | E: danh sách field bắt buộc tối thiểu cho Guest chưa chốt — xem `BR-CART-07`, để GĐ3 làm bảng field |
+
+### US-007 — Thanh toán khi nhận hàng (COD)
+
+| | |
+|---|---|
+| **Feature** | FEAT-03 |
+| **RQ** | RQ-003 |
+| **MoSCoW** | Must |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | US-004 |
+| **BR áp dụng** | BR-CART-03 (giới hạn giá trị đơn COD — **chưa chốt, `OQ-006`**), BR-CART-04 |
+| **Ước lượng sơ bộ** | M |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn thanh toán đơn hàng bằng hình thức thanh toán khi nhận hàng
+> (COD), để tôi hoàn tất mua sắm mà không cần thanh toán trước qua kênh điện tử.
+
+*Ưu tiên triển khai trước US-008 theo xác nhận của PO ở `OQ-008` — xem `DEC-04` và §8.*
+
+**Phạm vi:**
+- Trong: chọn COD làm phương thức thanh toán, tạo `Payment` gắn với `Order`
+- Ngoài: thu tiền thật lúc giao hàng (thuộc vận hành giao nhận, FR-26)
+
+**Điều kiện nghiệm thu mức thô:**
+- Chọn COD ⇒ đơn được tạo mà không cần chuyển hướng ra ngoài hệ thống
+- Đơn giá trị vượt ngưỡng (nếu PO chốt `BR-CART-03`) ⇒ hành vi chặn/cảnh báo — **chưa chốt,
+  `OQ-006`**
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ⚠️ | ✅ | ⚠️ | E/T: phụ thuộc `OQ-006` (giới hạn COD) và `OQ-013` (Payment.status COD ghi nhận thế nào) — chưa có câu trả lời, AC ở GĐ3 chưa viết được đầy đủ nếu hai OQ này còn mở |
+
+### US-008 — Thanh toán qua VNPay/Momo
+
+| | |
+|---|---|
+| **Feature** | FEAT-03 |
+| **RQ** | RQ-003 |
+| **MoSCoW** | Must (theo `BRIEF`), nhưng **có thể lùi triển khai sau US-007** theo `OQ-008`/`DEC-04` |
+| **Vai trò** | Customer, Guest |
+| **Phụ thuộc** | US-004 |
+| **BR áp dụng** | BR-CART-04, BR-CART-05 (không lưu thẻ), BR-CART-06 (xác thực webhook — phụ thuộc `ASM-01`) |
+| **Ước lượng sơ bộ** | XL |
+
+**Story:**
+> Là Customer hoặc Guest, tôi muốn thanh toán đơn hàng qua VNPay hoặc Momo mà không phải
+> nhập/lưu thông tin thẻ trên hệ thống sàn, để tôi dùng đúng ví điện tử quen thuộc mà không lộ
+> thông tin thẻ cho sàn.
+
+**Phạm vi:**
+- Trong: khởi tạo giao dịch, chuyển hướng cổng thanh toán, nhận xác nhận qua webhook
+- Ngoài: hoàn tiền qua VNPay/Momo (thuộc FR-25 đổi trả/tranh chấp, ngoài phạm vi module này),
+  cơ chế đối soát bù đầy đủ (thuộc thiết kế chi tiết Payment Service ở GĐ3)
+
+**Điều kiện nghiệm thu mức thô:**
+- Thanh toán thành công ⇒ webhook cập nhật `Payment.status = success`, `OrderSeller.status`
+  chuyển sang `confirmed`
+- Webhook không tới đúng hạn ⇒ hành vi hiển thị cho khách — **chưa chốt, phụ thuộc `ASM-01`/
+  `OQ-010` và cơ chế đối soát bù (ngoài phạm vi US module này, xem `PROCESS` B9)**
+
+**INVEST:**
+
+| I | N | V | E | S | T | Ghi chú nếu không đạt |
+|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ | E/S/T: đây là US phụ thuộc nhiều nhất vào xác nhận bên ngoài (`ASM-01`, sandbox VNPay/Momo) — nếu tới GĐ3 vẫn chưa xác minh được, đề xuất tách nhỏ US-008 theo từng cổng thanh toán (VNPay riêng, Momo riêng) để không chặn nhau |
+
+---
+
+## 5. Bảng tổng hợp US
+
+| ID | Tên | Feature | RQ | MoSCoW | Ước lượng | Phụ thuộc | INVEST | Trạng thái |
+|---|---|---|---|---|---|---|---|---|
+| US-001 | Thêm sản phẩm đa seller vào giỏ | FEAT-01 | RQ-001 | Must | M | — | ✅ | Draft |
+| US-002 | Xem giỏ hàng nhóm theo seller | FEAT-01 | RQ-001 | Must | M | US-001 | ✅ | Draft |
+| US-003 | Sửa/xoá sản phẩm trong giỏ | FEAT-01 | RQ-001 | Must | S | US-001 | ⚠️ | Draft |
+| US-004 | Checkout & tách đơn theo seller | FEAT-02 | RQ-002 | Must | L | US-001, US-002, US-005 | ⚠️ | Draft |
+| US-005 | Địa chỉ & phí ship theo seller | FEAT-02 | RQ-002, RQ-001 | Must | L | US-002 | ⚠️ | Draft |
+| US-006 | Checkout không cần tài khoản (Guest) | FEAT-02 | RQ-004 | Must | M | US-004, US-005 | ⚠️ | Draft |
+| US-007 | Thanh toán COD | FEAT-03 | RQ-003 | Must | M | US-004 | ⚠️ | Draft |
+| US-008 | Thanh toán VNPay/Momo | FEAT-03 | RQ-003 | Must | XL | US-004 | ⚠️ | Draft |
+
+## 6. Đối chiếu ngược RQ → US *(bảng bắt buộc)*
+
+| RQ | Phát biểu ngắn | MoSCoW | US phủ | Trạng thái |
+|---|---|---|---|---|
+| RQ-001 | Giỏ hàng đa seller, một lần checkout | Must | US-001, US-002, US-003, US-005 | ✅ Đã phủ |
+| RQ-002 | Tự động tách đơn theo seller | Must | US-004, US-005 | ✅ Đã phủ |
+| RQ-003 | Thanh toán VNPay/Momo/COD, không lưu thẻ | Must | US-007, US-008 | ✅ Đã phủ |
+| RQ-004 | Guest checkout không cần tài khoản | Must | US-006 | ✅ Đã phủ |
+
+**Kết luận:** 4/4 `RQ` của module này đã được phủ bởi ≥1 `US` — không có `RQ` bị bỏ quên.
+
+## 7. US không truy về RQ nào *(nghi ngờ scope creep)*
+
+| US | Từ đâu ra | Đề xuất | PO quyết |
+|---|---|---|---|
+| *(không có)* | — | — | — |
+
+**Kết luận:** cả 8 US đều truy về được một `RQ` cụ thể — không phát hiện scope creep trong
+lần phân rã này.
+
+## 8. Đề xuất thứ tự thực hiện
+
+*BA đề xuất theo trả lời của PO ở `OQ-008` (xem `DEC-04`): giữ RQ-001/RQ-002 (giỏ hàng đa
+seller, tách đơn) trước; RQ-003 phần ví điện tử (VNPay/Momo) có thể lùi sau COD nếu thiếu
+thời gian. **PO chốt thứ tự cuối cùng.***
+
+| Đợt | US | Lý do xếp trước | Kết quả demo được |
+|---|---|---|---|
+| 1 | US-001, US-002, US-003 | Nền tảng giỏ hàng — mọi US sau đều phụ thuộc | Thêm/xem/sửa giỏ hàng đa seller |
+| 2 | US-004, US-005, US-006 | Lõi giao dịch — tách đơn theo seller (RQ-002, ưu tiên theo `OQ-008`), gồm cả luồng Guest | Checkout hoàn tất, tạo được `Order`/`OrderSeller`, hỗ trợ cả Guest và Customer |
+| 3 | US-007 | COD không phụ thuộc tích hợp bên thứ ba phức tạp (VNPay/Momo) — làm trước theo `DEC-04` | Đặt hàng thanh toán COD đầu-cuối |
+| 4 | US-008 | Phụ thuộc xác minh `ASM-01` + sandbox VNPay/Momo (`RISK` §3 phụ thuộc bên ngoài) — có thể lùi theo `DEC-04` nếu ASM-01 chưa xác minh kịp | Đặt hàng thanh toán qua ví điện tử đầu-cuối |
+
+## 9. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn US nào |
+|---|---|---|---|---|
+| OQ-006 | *(đã mở từ GĐ1)* Giới hạn giá trị đơn COD là gì? | PO, Kế toán đối soát | 2026-09-08 | US-007 |
+| OQ-009 | Giá/tồn kho thay đổi giữa lúc thêm giỏ và checkout — tự động cập nhật hay chặn xác nhận lại? | PO + Tech Lead | 2026-09-08 | US-003, US-004 |
+| OQ-010 | Xác nhận khả thi `ASM-01` (webhook VNPay/Momo) | Tech Lead | 2026-09-08 | US-008 |
+| OQ-011 | Xác nhận `ASM-03` — giỏ N seller luôn tách đúng N đơn, không gộp | PO | 2026-09-08 | US-004 |
+| OQ-013 | Với COD, `Payment.status` ghi "success" ngay khi xác nhận đơn hay giữ "pending" tới khi thực thu tiền? | Kế toán đối soát, PO | 2026-09-08 | US-007 |
+
+## 10. Ngoài phạm vi
+
+- Ước lượng story point chính thức → team dev ở buổi grooming
+- Thiết kế màn hình, field spec chi tiết → GĐ3 `SRS`
+- Áp dụng coupon/điểm thưởng (FR-13/FR-14) → module Khuyến mãi & Loyalty (điểm tích hợp đã
+  xác nhận qua `OQ-004`/`DEC-03`)
+- Xử lý đơn sau khi tạo (đóng gói, giao hàng, đổi trả, khiếu nại) → module Quản lý đơn hàng
+- Cơ chế đối soát bù thanh toán → thiết kế chi tiết Payment Service ở GĐ3, không phải US của
+  module này
+
+---
+
+## 11. Tự chấm Gate G2 *(chấm ở mức RIGOR = standard — áp đúng checklist `workflow.md` §2, không bớt/thêm)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | `PROCESS` có AS-IS và TO-BE, mỗi bước ghi ai làm, input/output, điều kiện rẽ nhánh | ✅ (có lưu ý) | AS-IS rút gọn đúng theo `greenfield` (A3–A5 thay vì A1/A2/A6, giải thích rõ lý do ở `PROCESS` §0); TO-BE (B1–B6) đầy đủ |
+| 2 | `BACKLOG` phân rã tới `US-nnn`, mỗi US có value statement và ước lượng sơ bộ | ✅ | 8 US, đủ ba vế Là/muốn/để, có ước lượng S/M/L/XL |
+| 3 | Mỗi `RQ-nnn` của G1 map được về ≥1 `US-nnn` | ✅ | 4/4 RQ đã phủ — xem §6 |
+| 4 | `BR-nnn` đã chốt, không mâu thuẫn nhau | ☐ | `BR_CartCheckout_v1.0.md` đã liệt kê đủ rule nhưng **3 rule quan trọng chưa chốt được giá trị** (BR-CART-03 giới hạn COD, BR-CART-01 phụ thuộc xác minh ASM-03, BR-CART-06 phụ thuộc xác minh ASM-01) — đây là khoảng trống thật, đã ghi `OQ`, không tự chốt thay PO/Tech Lead |
+| 5 | `RBAC` có ma trận vai trò × hành động; hành động phê duyệt/chốt sổ có bảng SoD | ✅ (có lưu ý) | Ma trận Guest/Customer đầy đủ; **không có hành động phê duyệt nội bộ nào trong phạm vi RQ-001…004** (tách đơn/thanh toán do hệ thống tự động, không có bước người duyệt) — đã ghi rõ lý do thay vì bỏ trống bảng SoD, xem `RBAC` §3 |
+| 6 | `IMPACT` nêu module/dữ liệu/tích hợp bị ảnh hưởng và cách xử lý dữ liệu cũ | ✅ (rút gọn theo greenfield) | Theo `PROFILE` §"Hệ quả đã áp dụng": `IMPACT` rút gọn chỉ trọng tâm trục tích hợp (1.5); các trục khác ghi N/A kèm lý do (greenfield, module đầu tiên, không dữ liệu cũ) |
+| 7 | Tech Lead xác nhận khả thi kỹ thuật và nêu ràng buộc | ☐ | **Chưa có** — không có Tech Lead thật tham gia lần chạy này (đúng như cảnh báo G1 chưa ký); các giả định kỹ thuật (`ASM-01`, `ASM-02`, `ASM-06`) vẫn ở trạng thái "chưa xác minh" |
+| 8 | `ba-traceability` báo coverage RQ→US ≥ 100% | ☐ | Chưa chạy `ba-traceability` trong lần này — khuyến nghị chạy trước khi trình G2, theo đúng nhắc nhở cuối `SKILL.md` |
+
+**Kết luận tự chấm:** G2 **chưa đủ điều kiện ký chính thức** — 4/8 tiêu chí còn ☐, chủ yếu vì
+thiếu xác nhận thật từ Tech Lead (đúng hệ quả của việc G1 cũng chưa ký thật, xem ngoại lệ gate
+ở đầu tài liệu) và chưa chạy `ba-traceability`. Đây là kết quả *tự chấm*, không phải kết luận
+gate — PO + Tech Lead phải xem lại trước khi ký.
+
+## 12. Quy tắc viết W1–W13
+
+| W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | W11 | W12 | W13 |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| ✅ | ✅ (có lưu ý) | N/A (chưa có field/con số cụ thể — thuộc GĐ3) | N/A (GĐ2 chưa viết AC Given/When/Then chi tiết) | N/A (chưa có text hiển thị — GĐ3) | ✅ (xem `BR` §3) | N/A (chưa có bảng field — GĐ3) | ✅ | ✅ | ✅ | N/A (chưa có wireframe ở GĐ2) | ✅ | ✅ |
+
+Ghi chú W2: quét `nhanh|mượt|thân thiện|v\.v|phù hợp|tương ứng|nên |có thể ` trên 5 file GĐ2
+(`PROCESS`, `BACKLOG`, `BR`, `RBAC`, `IMPACT`) — 27 dòng khớp trước khi soát, đã rà từng dòng:
+- Hai dòng ban đầu dùng "nhanh" trong vế **để** của US-006/US-008 đã được **sửa lại** (không
+  còn "mua nhanh"/"thanh toán nhanh") để không mô tả giá trị bằng tính từ mơ hồ — thay bằng mô
+  tả hành vi cụ thể hơn (không phải dừng lại đăng ký; dùng đúng ví điện tử quen thuộc mà không
+  lộ thông tin thẻ). Grep lại sau khi sửa: 0 kết quả cho riêng từ khoá `nhanh` trong toàn bộ
+  5 file.
+- Các dòng còn lại (25 dòng) đều thuộc hai nhóm: (a) trích dẫn/diễn giải rủi ro theo đúng công
+  thức chuẩn của `RISK` GĐ1 ("có thể xảy ra…"), hoặc (b) mô tả điều mà PO **có thể** cân nhắc
+  như một tuỳ chọn thương mại/kỹ thuật chưa chốt (VD trợ giá phí ship ở `PROCESS` B3, thứ tự
+  triển khai US-008 "có thể lùi" theo `DEC-04`) — đây là ngôn ngữ mô tả **tuỳ chọn có nguồn**
+  (`RISK`, `DEC-04`), không phải một phát biểu `RQ`/`AC` né tránh quyết định bằng từ mơ hồ.
+- Không có dòng nào dùng các từ này để thay thế cho một con số/quyết định còn thiếu — mọi chỗ
+  thiếu số đều có `OQ` riêng (xem §9, §13). Đã quét `TBD|TODO|\?\?\?` — 0 kết quả ngoài chính
+  dòng giải thích quy tắc này.
+
+## 13. OQ mở tổng hợp của lần chạy GĐ2 này
+
+| ID | Câu hỏi | Hỏi ai | Chặn gì | Nguồn |
+|---|---|---|---|---|
+| OQ-006 | *(GĐ1, nhắc lại)* Giới hạn giá trị đơn COD | PO, Kế toán đối soát | BR-CART-03, US-007 | `RISK_CartCheckout_v1.0.md` |
+| OQ-009 | Giá/tồn kho đổi giữa thêm giỏ và checkout — tự động cập nhật hay chặn? | PO + Tech Lead | US-003, US-004 | `PROCESS` A5 (E2) |
+| OQ-010 | Xác nhận khả thi `ASM-01` (webhook VNPay/Momo) | Tech Lead | BR-CART-06, US-008 | `PROCESS` A3 (P2) |
+| OQ-011 | Xác nhận `ASM-03` — luôn tách đúng N đơn theo N seller | PO | BR-CART-01, US-004 | `RISK_CartCheckout_v1.0.md` ASM-03 |
+| OQ-012 | Guest có giới hạn giá trị đơn hoặc cần OTP xác thực cho đơn giá trị cao? | PO, Bảo mật | RBAC §4, RISK-01 phương án (b) | `RBAC_CartCheckout_v1.0.md` |
+| OQ-013 | Payment.status của COD ghi "success" ngay hay giữ "pending" tới khi thực thu? | Kế toán đối soát, PO | US-007, `BR_CartCheckout` §3 |  `BR_CartCheckout_v1.0.md` |
+
+*Đã đồng bộ vào `00-index/OQ_e-commerce.md` — xem sổ toàn dự án để theo dõi trạng thái đóng/mở.*