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

# 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ở.*