improve BA skill

ba-output/e-commerce/01-discovery/BRIEF_CartCheckout_v1.0.md

@@ -0,0 +1,278 @@
+# BRIEF — Module Giỏ hàng & Checkout (e-commerce)
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | 2026-09-08 |
+| **Author** | BA (qua skill ba-1-discovery) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Profile** | screen · greenfield · standard (xem `00-index/PROFILE_e-commerce.md`) |
+| **Source** | `e-commerce/docs/00-project-brief.md` · `e-commerce/docs/sections/01-tong-quan.md` · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` (FR-05, FR-06, FR-07, NFR-01, NFR-03, NFR-05) · `e-commerce/docs/sections/07-giao-dien.md` (SCR-04…SCR-07, chỉ dùng làm bối cảnh) · `STAKEHOLDER_CartCheckout_v1.0.md` · `ELICITATION_CartCheckout_2026-09-08.md` · `RISK_CartCheckout_v1.0.md` |
+| **Scope** | Module Giỏ hàng & Checkout — FR-05 (Giỏ hàng đa seller), FR-06 (Checkout & tách đơn theo seller), FR-07 (Thanh toán VNPay/Momo/COD) — dự án e-commerce (marketplace). **Không** bao gồm toàn sàn. |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | CR |
+|---|---|---|---|---|
+| 1.0 | 2026-09-08 | BA (qua skill ba-1-discovery) | Bản đầu | — |
+
+---
+
+## 1. Tóm tắt cho người quyết định
+
+Sàn marketplace đa seller sắp xây (dự án e-commerce) cần một luồng giỏ hàng–checkout–thanh
+toán xử lý đúng đặc thù đa người bán: một khách mua từ nhiều seller trong một lần thanh toán,
+hệ thống tự tách thành các đơn con theo seller, thanh toán qua VNPay/Momo/COD. Đây là luồng
+giao dịch lõi — không có nó, sàn không ghi nhận được doanh thu và seller không nhận được đơn.
+Tài liệu này chốt phạm vi, mục tiêu đo được và bốn yêu cầu mức nghiệp vụ (`RQ-001`…`RQ-004`)
+cho module này; còn nhiều `OQ` cần PO/Tech Lead trả lời trước khi ký G1 chính thức (tên thật
+stakeholder, KPI baseline, chính sách giới hạn COD).
+
+---
+
+## 2. Bối cảnh
+
+Dự án e-commerce là **greenfield** — chưa có hệ thống nào đang chạy để thay thế (xem
+`00-index/PROFILE_e-commerce.md`). Vì vậy không có "cách làm thủ công hiện tại" của chính sàn
+này để mô tả; bối cảnh dưới đây là **quyết định mô hình kinh doanh đã chốt**, không phải số đo
+vận hành thật.
+
+| Thông tin hiện trạng | Giá trị | Nguồn |
+|---|---|---|
+| Số giao dịch/ngày (dự kiến khi vận hành) | Chưa vận hành — quy mô mục tiêu "lớn": hàng trăm nghìn SKU, hàng trăm nghìn–hàng triệu user đăng ký, cao điểm hàng nghìn–chục nghìn concurrent user mùa flash sale | `00-project-brief.md` mục 3 |
+| Số người thao tác checkout đồng thời | N/A — chưa vận hành | — |
+| Thời gian xử lý trung bình | N/A — chưa vận hành; mục tiêu latency đề xuất ở NFR-01 (< 2s catalog/search, < 3s checkout) là **giả định mặc định đã chốt trong brief**, chưa phải SLA hợp đồng thật | `sections/02-phan-tich-yeu-cau.md` NFR-01, ghi chú cuối §2.2 |
+| Tỷ lệ sai sót hiện tại | N/A — chưa vận hành, không có hệ thống cũ | — |
+
+## 3. Phát biểu bài toán
+
+> **Vấn đề:** Sàn marketplace đa seller đã cam kết mô hình "khách mua từ nhiều seller trong một
+> trải nghiệm thống nhất" (mục tiêu dự án, `sections/01-tong-quan.md` §1.1) nhưng **chưa có**
+> luồng giỏ hàng–checkout–thanh toán nào xử lý được việc: (1) gộp sản phẩm nhiều seller vào một
+> giỏ, (2) tách thành đơn con đúng theo từng seller khi khách xác nhận mua, (3) thu tiền qua
+> nhiều kênh thanh toán phổ biến tại Việt Nam (VNPay, Momo, COD) mà không lưu thông tin thẻ.
+> Thiếu luồng này, sàn không thể ra mắt MVP, seller không có cách nào nhận đơn hàng, và không
+> có dữ liệu giao dịch để tính hoa hồng/payout ở các module khác.
+
+❌ Không viết giải pháp ở đây — mục này giữ đúng quy tắc, không nêu tên màn hình/nút cụ thể.
+
+**Bằng chứng của vấn đề:**
+
+| # | Bằng chứng | Nguồn | Loại |
+|---|---|---|---|
+| 1 | Mô hình kinh doanh đã xác nhận là marketplace đa seller (không phải single-vendor) — kéo theo yêu cầu bắt buộc về giỏ hàng/checkout đa seller | `00-project-brief.md` vòng 1, câu hỏi 1 | Sự thật (quyết định đã chốt) |
+| 2 | FR-05 (Giỏ hàng đa người bán), FR-06 (Checkout & tách đơn theo seller), FR-07 (Thanh toán) đều được xếp **Must** trong bảng yêu cầu đã duyệt | `sections/02-phan-tich-yeu-cau.md` §2.1 | Sự thật |
+| 3 | Guest (khách vãng lai) được xác nhận cho phép checkout không cần tài khoản | `sections/01-tong-quan.md` §1.2 | Sự thật |
+
+**Điều gì xảy ra nếu không làm gì cả?** Sàn không ra mắt được MVP marketplace — toàn bộ các
+module phụ thuộc (quản lý đơn hàng, hoa hồng, payout, đánh giá sau mua) đều cần dữ liệu đơn
+hàng sinh ra từ checkout. Đây là điều kiện tiên quyết (blocker), không phải một cải tiến.
+
+## 4. Mục tiêu kinh doanh & KPI
+
+🔴 **Cả hai GOAL dưới đây chưa có baseline số thật** vì dự án greenfield (chưa vận hành). Theo
+quy tắc, không bỏ trống — ghi `OQ` kèm đề xuất cách đo baseline.
+
+| ID | Mục tiêu | Baseline hiện tại | Mục tiêu | Cách đo | Ai đo | Tần suất |
+|---|---|---|---|---|---|---|
+| GOAL-01 | Giảm tỷ lệ bỏ giỏ hàng ở bước checkout đối với giỏ hàng có ≥2 seller (rủi ro cao hơn giỏ 1 seller do phí ship gộp — xem `RISK-04`) | ❓ Chưa có — dự án chưa vận hành (`OQ-007`). Đề xuất cách đo: theo dõi tỷ lệ hoàn tất checkout trong 4–6 tuần đầu soft-launch, tách riêng theo số seller trong giỏ | PO xác nhận sau khi có số đo soft-launch, đề xuất ban đầu ≤ tỷ lệ bỏ giỏ của giỏ 1 seller + 10 điểm phần trăm | (số phiên checkout hoàn tất) / (số phiên bắt đầu checkout), theo nhóm số seller trong giỏ | BA + PO, hàng tuần trong 6 tuần đầu | Hàng tuần (giai đoạn đầu) |
+| GOAL-02 | Tỷ lệ thanh toán thành công trên tổng số phiên checkout đã chọn phương thức thanh toán | ❓ Chưa có — chưa vận hành (`OQ-007`). Đề xuất đo baseline bằng dữ liệu 4 tuần đầu sau go-live, tách riêng theo kênh VNPay/Momo/COD | PO xác nhận; đề xuất tham khảo ngành ≥ 90% cho ví điện tử, COD không tính "thất bại" theo nghĩa kỹ thuật mà theo tỷ lệ hoàn/từ chối nhận hàng (liên quan `RISK-01`) | (số giao dịch thanh toán thành công) / (số giao dịch đã khởi tạo), theo kênh | BA + Kế toán đối soát (STK-04), hàng tuần | Hàng tuần (giai đoạn đầu), sau đó hàng tháng |
+
+## 5. Phạm vi
+
+### 5.1 Trong phạm vi
+
+| # | Hạng mục | Vì sao cần | RQ liên quan |
+|---|---|---|---|
+| 1 | Giỏ hàng chứa sản phẩm từ nhiều seller khác nhau, nhóm hiển thị theo seller | Điều kiện tiên quyết của mô hình marketplace đa seller | RQ-001 |
+| 2 | Checkout: thu thập địa chỉ giao hàng, tự động tách giỏ hàng thành các đơn con theo từng seller | Mỗi seller cần xử lý đơn độc lập, không lẫn với seller khác | RQ-002 |
+| 3 | Thanh toán qua VNPay, Momo hoặc COD, không lưu thông tin thẻ trên hệ thống sàn | Đối tác thanh toán đã xác nhận; giảm phạm vi PCI-DSS (NFR-05) | RQ-003 |
+| 4 | Guest checkout — mua hàng không cần tạo tài khoản trước | Đã xác nhận trong `sections/01-tong-quan.md` §1.2 | RQ-004 |
+
+### 5.2 Ngoài phạm vi *(quan trọng hơn mục 5.1)*
+
+| # | Hạng mục | Lý do loại | Xử lý ở đâu / khi nào |
+|---|---|---|---|
+| 1 | Áp mã khuyến mãi/coupon (FR-13) | Được giao ở một module khác (Khuyến mãi), dù xuất hiện trên cùng màn hình checkout theo bối cảnh UI ở `sections/07-giao-dien.md` SCR-05 | Module Khuyến mãi & Loyalty — cần PO xác nhận điểm nối, xem `OQ-004` |
+| 2 | Dùng điểm thưởng loyalty khi checkout (FR-14) | Tương tự trên | Module Loyalty — `OQ-004` |
+| 3 | Theo dõi/xử lý đơn hàng sau khi đã tạo (huỷ, đổi trả, khiếu nại — FR-08, FR-09, FR-25) | Là vòng đời đơn hàng sau checkout, không phải hành vi tạo đơn | GĐ1/GĐ2 của module Quản lý đơn hàng, chạy riêng |
+| 4 | Xử lý tồn kho, đóng gói, cập nhật vận chuyển sau khi đơn được tạo (FR-26) | Thuộc vận hành kho, không phải luồng giỏ hàng/checkout | Module Vận hành đơn hàng, chạy riêng |
+| 5 | KYC, cấu hình hoa hồng, payout cho seller (FR-17, FR-21, FR-22) | Không liên quan trực tiếp tới hành vi giỏ hàng/checkout của khách mua | Module Quản trị Seller & Tài chính, chạy riêng |
+| 6 | Danh mục & tìm kiếm sản phẩm (FR-04) | Là bước trước giỏ hàng, đã có màn hình riêng (SCR-01…SCR-03) | Module Catalog & Tìm kiếm, chạy riêng |
+| 7 | Nội dung/mẫu thông báo email/SMS xác nhận đơn hàng (FR-12) | Module này chỉ **kích hoạt** sự kiện gửi thông báo, không thiết kế nội dung/kênh gửi | Module Thông báo, chạy riêng — GĐ3 chỉ ghi rõ sự kiện trigger |
+
+### 5.3 Ranh giới hệ thống
+
+```mermaid
+flowchart LR
+    GUEST(["👤 Guest"])
+    CUS(["👤 Customer"])
+
+    subgraph PHAMVI["Trong phạm vi — Module Giỏ hàng & Checkout"]
+        CART["Giỏ hàng đa seller (FR-05)"]
+        CHK["Checkout & tách đơn theo seller (FR-06)"]
+        PAY["Thanh toán VNPay/Momo/COD (FR-07)"]
+    end
+
+    CATALOG[["Catalog & Tìm kiếm (FR-04) — ngoài phạm vi"]]
+    PROMO[["Khuyến mãi & Loyalty (FR-13/14) — ngoài phạm vi"]]
+    ORDER[["Quản lý đơn hàng sau checkout (FR-08/09) — ngoài phạm vi"]]
+    SELLERBIZ[["KYC / Hoa hồng / Payout seller (FR-17/21/22) — ngoài phạm vi"]]
+    NOTI[["Thông báo email/SMS (FR-12) — ngoài phạm vi"]]
+    VNPAY[["VNPay"]]
+    MOMO[["Momo"]]
+    GHN[["GHN"]]
+    GHTK[["GHTK"]]
+
+    GUEST --> CART
+    CUS --> CART
+    CATALOG --> CART
+    CART --> CHK
+    PROMO -.-> CHK
+    CHK --> GHN
+    CHK --> GHTK
+    CHK --> PAY
+    PAY <--> VNPAY
+    PAY <--> MOMO
+    CHK --> ORDER
+    CHK --> SELLERBIZ
+    CHK --> NOTI
+```
+
+*Khung đôi `[[ ]]` = ngoài phạm vi module này (có thể trong phạm vi dự án e-commerce nói
+chung, chạy ở module khác). Mũi tên hai chiều = trao đổi dữ liệu hai chiều với hệ thống ngoài.*
+
+| Hệ thống | Trong/Ngoài phạm vi | Dữ liệu trao đổi | Chiều | Đầu mối |
+|---|---|---|---|---|
+| VNPay | Ngoài — tích hợp | Yêu cầu thanh toán, xác nhận kết quả (webhook — `ASM-01` chưa xác minh) | Hai chiều | Chưa xác định |
+| Momo | Ngoài — tích hợp | Tương tự VNPay | Hai chiều | Chưa xác định |
+| GHN | Ngoài — tích hợp | Địa chỉ giao hàng → phí ship/thời gian giao ước tính (`ASM-02` chưa xác minh) | Hai chiều | Chưa xác định |
+| GHTK | Ngoài — tích hợp | Tương tự GHN | Hai chiều | Chưa xác định |
+| Catalog & Tìm kiếm | Ngoài phạm vi module, trong phạm vi dự án | Sản phẩm, giá, tồn kho → giỏ hàng | Một chiều vào giỏ hàng | STK-06 (Tech Lead) |
+| Khuyến mãi & Loyalty | Ngoài phạm vi module — điểm nối cần xác nhận (`OQ-004`) | Mã coupon/điểm thưởng → giảm giá áp vào checkout | Một chiều vào checkout | STK-01 (PO sàn) |
+| Quản lý đơn hàng sau checkout | Ngoài phạm vi module, trong phạm vi dự án | Đơn con đã tạo → module quản lý đơn hàng | Một chiều ra khỏi module | STK-05 (Trưởng vận hành) |
+| KYC/Hoa hồng/Payout seller | Ngoài phạm vi module | Dữ liệu giao dịch đã thanh toán → tính hoa hồng/payout | Một chiều ra khỏi module | STK-04 (Kế toán đối soát) |
+| Thông báo email/SMS | Ngoài phạm vi module | Sự kiện "đơn đã tạo/thanh toán thành công" → trigger gửi | Một chiều ra khỏi module | Chưa xác định |
+
+## 6. Yêu cầu mức nghiệp vụ
+
+| ID | Phát biểu yêu cầu | Nguồn (STK + ngày) | MoSCoW | GOAL | Giải pháp khách gợi ý |
+|---|---|---|---|---|---|
+| RQ-001 | Customer/Guest phải mua được sản phẩm từ nhiều seller khác nhau trong một giỏ hàng và hoàn tất bằng một lần checkout, thay vì phải đặt hàng riêng lẻ với từng seller trên các trang/luồng khác nhau. | STK-01 (PO sàn), qua `00-project-brief.md` vòng 1 (2026, vòng 1 không ghi ngày cụ thể) | Must | GOAL-01 | "Giỏ hàng đa seller" |
+| RQ-002 | Hệ thống phải tự động tách một giỏ hàng đa seller thành các đơn con riêng theo từng seller ngay khi Customer/Guest xác nhận đặt hàng, để mỗi seller xử lý đơn của mình độc lập mà không thấy dữ liệu của seller khác. | STK-01 (PO sàn), STK-03 (Seller đại diện — chưa phỏng vấn trực tiếp), qua `00-project-brief.md` mục 2 & `sections/02-phan-tich-yeu-cau.md` FR-06 | Must | GOAL-01 | "tách đơn theo seller" |
+| RQ-003 | Customer/Guest phải thanh toán được bằng VNPay, Momo hoặc COD mà hệ thống sàn không lưu trữ thông tin thẻ thanh toán, để giảm phạm vi tuân thủ PCI-DSS. | STK-01 (PO sàn), STK-06 (Tech Lead — chưa xác nhận khả thi), qua `00-project-brief.md` vòng 1 & `sections/02-phan-tich-yeu-cau.md` NFR-05 | Must | GOAL-02 | "Thanh toán (VNPay/Momo + COD)" |
+| RQ-004 | Guest (khách vãng lai) phải checkout hoàn tất được mà không cần tạo tài khoản trước, để không mất khách hàng tiềm năng ở bước bắt buộc đăng ký. | STK-01 (PO sàn), qua `sections/01-tong-quan.md` §1.2 | Must | GOAL-01 | "guest checkout" |
+
+🔴 **Kiểm tra phân bổ MoSCoW:** cả 4/4 RQ đều Must = 100% > ngưỡng 60%. Theo quy tắc, đây là
+dấu hiệu "chưa phân loại thật" và cần hỏi PO câu "nếu chỉ kịp một nửa module này thì cắt cái
+nào". Trong trường hợp này, mức Must khớp với xếp hạng đã có sẵn ở `FR-05/06/07` trong tài
+liệu phân tích yêu cầu đã duyệt (`sections/02-phan-tich-yeu-cau.md`), với lý do hợp lý là cả 4
+RQ đều thuộc luồng giao dịch lõi không thể MVP thiếu. Tuy vậy, **BA chưa tự ý coi đây là đã
+chốt** — ghi `OQ-008` để PO xác nhận lại đúng theo quy trình BA-1, không suy diễn thay PO.
+
+| MoSCoW | Nghĩa chính xác |
+|---|---|
+| **Must** | Không có thì bản phát hành này vô nghĩa |
+| **Should** | Quan trọng, nhưng thiếu vẫn dùng được, có cách làm thủ công tạm |
+| **Could** | Có thì tốt, cắt đầu tiên khi thiếu thời gian |
+| **Won't (this time)** | Đã bàn và thống nhất **không** làm lần này |
+
+## 7. Ràng buộc
+
+| Loại | Nội dung | Nguồn | Ảnh hưởng |
+|---|---|---|---|
+| Thời gian | Ngân sách/thời gian dự án chưa xác định chính thức; giả định lộ trình MVP tiêu chuẩn ~9–12 tháng cho toàn sàn | `00-project-brief.md` mục 5, giả định #7 | Có thể cần cắt phạm vi module nếu timeline thực tế ngắn hơn |
+| Ngân sách / nguồn lực | Chưa xác định | `00-project-brief.md` mục 6 | — |
+| Công nghệ | Triển khai trên AWS; không ràng buộc tech stack cụ thể cho module này | `sections/01-tong-quan.md` §1.5 | Kiến trúc chi tiết thuộc GĐ2/Tech Lead |
+| Pháp lý / tuân thủ | NĐ52/85 (thông báo website TMĐT), NĐ13/2023 (bảo vệ dữ liệu cá nhân — địa chỉ/SĐT trong đơn hàng), PCI-DSS phạm vi giảm (không lưu thẻ) | `sections/01-tong-quan.md` §1.5, NFR-05 | Cần đại diện Pháp chế xác nhận (chưa có — `OQ-003`); ảnh hưởng RQ-003, RISK-03 |
+| Tổ chức / quy trình | Không có hệ thống cũ, không có seller/khách hàng thật để tham chiếu quy trình — mọi giả định phải xác minh trước GĐ2/GĐ3 | `00-project-brief.md` mục 3, mục 6 | Số lượng `ASM` cao hơn bình thường cho một dự án brownfield |
+
+## 8. Giả định và rủi ro
+
+*Chi tiết đầy đủ ở `RISK_CartCheckout_v1.0.md`. Tóm tắt các mục ảnh hưởng trực tiếp tới phạm
+vi module này:*
+
+| ID | Nội dung | Nếu sai thì sao |
+|---|---|---|
+| ASM-01 | VNPay/Momo hỗ trợ webhook xác nhận thanh toán gần thời gian thực | Phải đổi cơ chế xác nhận đơn hàng ở GĐ3, ảnh hưởng NFR-01 |
+| ASM-02 | GHN/GHTK cung cấp API tính phí ship/kiểm tra vùng phục vụ tại checkout | Không hiển thị được phí/thời gian giao theo seller lúc checkout |
+| ASM-05 | COD không giới hạn giá trị đơn ở MVP | Thiếu một business rule quan trọng, có thể lộ ở UAT dưới dạng rủi ro tài chính |
+| RISK-01 | Bùng đơn COD một phần khi giỏ đa seller bị tách nhiều đơn con | Tổn thất phí vận chuyển hoàn hàng cho seller, tranh chấp seller–sàn |
+| RISK-02 | Webhook thanh toán trễ/lỗi khiến đơn kẹt "Chờ thanh toán" dù đã thu tiền | Khiếu nại CSKH, sai lệch đối soát |
+| RISK-03 | Chưa có đại diện Pháp chế/Bảo mật rà soát việc chia sẻ PII cho seller | Rủi ro vi phạm NĐ13/2023 khi go-live |
+
+## 9. Tiêu chí thành công của giai đoạn
+
+- [ ] PO sàn xác nhận đúng phát biểu bài toán ở mục 3 (không phải giải pháp)
+- [ ] PO sàn chốt lại KPI/baseline ở mục 4 (dù chỉ là cam kết đo baseline trong X tuần đầu, không cần số thật ngay)
+- [ ] PO sàn xác nhận điểm nối với module Khuyến mãi/Loyalty (`OQ-004`) và ranh giới ngoài phạm vi ở mục 5.2
+- [ ] Tech Lead xác nhận sơ bộ tính khả thi của ASM-01, ASM-02 (không cần xác minh đầy đủ ở G1, nhưng phải biết là rủi ro)
+- [ ] RISK-01 (bùng COD) có người chịu trách nhiệm thật và hướng xử lý (chọn 1 trong 2 phương án BA đề xuất, hoặc phương án khác)
+- [ ] Có người đại diện Pháp chế/Bảo mật được chỉ định (`OQ-003`), dù việc rà soát chi tiết có thể làm ở GĐ2
+
+## 10. Open Questions
+
+*Tổng hợp từ mọi artifact của lần chạy này. Sổ toàn dự án: `00-index/OQ_e-commerce.md`.*
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Phương án BA đề xuất |
+|---|---|---|---|---|---|
+| OQ-001 | Tên thật + đầu mối liên lạc của STK-01…STK-06 là gì? | Điều phối dự án / PO | 2026-09-08 | Ký G1 thật | Dùng vai trò tạm để chạy tiếp; phải có tên thật trước khi coi G1 là ký hợp lệ |
+| OQ-002 | Mức Quan tâm × Ảnh hưởng ở `STAKEHOLDER` mục 2 là đánh giá của BA — từng STK có đồng ý không? | STK-01…STK-06 | 2026-09-08 | Chiến lược tiếp cận | Giữ nguyên đánh giá ban đầu, điều chỉnh khi có phản hồi |
+| OQ-003 | Ai là đại diện Pháp chế/Bảo mật cho dự án? Cần xác nhận phạm vi lưu/chia sẻ PII khi tách đơn theo seller. | PO sàn | 2026-09-08 | RISK-03, RQ-003 | Đề nghị PO chỉ định trước khi kết thúc GĐ2 |
+| OQ-004 | Áp coupon (FR-13) và dùng điểm thưởng (FR-14) trong màn hình checkout có thuộc phạm vi module này không, hay là điểm tích hợp với module khác? | PO sàn | 2026-09-08 | Phạm vi mục 5.1/5.2, thiết kế màn hình checkout ở GĐ3 | Đề xuất: coi là điểm tích hợp (module Khuyến mãi/Loyalty sở hữu logic, module này chỉ hiển thị kết quả) — PO quyết |
+| OQ-005 | Cần tổ chức phỏng vấn thật với Khách hàng đại diện (STK-02) và Seller đại diện (STK-03) — ai làm đầu mối sắp xếp? | Điều phối dự án / PO sàn | 2026-09-08 | Chất lượng RQ, phát hiện ngoại lệ thực tế | Đề nghị lên lịch trong tuần đầu GĐ2 |
+| OQ-006 | Chính sách giới hạn giá trị đơn COD (nếu có) là gì? | PO sàn, Kế toán đối soát | 2026-09-08 | ASM-05, RISK-01, `BR` ở GĐ2 | BA đề xuất 2 phương án ở RISK-01, PO chọn |
+| OQ-007 | Baseline thật cho GOAL-01 (tỷ lệ bỏ giỏ hàng) và GOAL-02 (tỷ lệ thanh toán thành công) là bao nhiêu? | PO sàn | 2026-09-08 | Đo lường hiệu quả ở GĐ5 | Đo trong 4–6 tuần đầu soft-launch theo cách đề xuất ở mục 4 |
+| OQ-008 | Xác nhận lại: cả 4 RQ của module này đều Must — nếu chỉ kịp một nửa thời gian, PO sẽ cắt cái nào? | PO sàn | 2026-09-08 | Ưu tiên hoá ở GĐ2 (`BACKLOG`) | Đề xuất giữ nguyên cả 4 vì đều thuộc luồng giao dịch lõi, nhưng đây là đề xuất — PO quyết |
+
+## 11. Ngoài phạm vi tài liệu này
+
+- Thiết kế màn hình chi tiết (field, validation, message lỗi) → GĐ3, `SRS`
+- Quy trình AS-IS/TO-BE chi tiết từng bước, business rule đầy đủ (VD công thức tính phí ship gộp) → GĐ2, `PROCESS`/`BR`
+- Ước lượng công sức, lịch trình → PM
+- Thiết kế API/kiến trúc tích hợp VNPay/Momo/GHN/GHTK → GĐ2/GĐ3, Tech Lead
+- Nội dung/mẫu email/SMS thông báo đơn hàng → module Thông báo (FR-12), ngoài phạm vi module này
+
+---
+
+## Tự chấm
+
+**Gate G1** *(chấm ở mức RIGOR = standard — áp đúng checklist §2 của `workflow.md`, không bớt/thêm)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | BRIEF có bối cảnh, phát biểu bài toán, phạm vi in/out, GOAL kèm KPI | ✅ | Có đủ; GOAL chưa có baseline số thật (greenfield) nhưng đã ghi `OQ-007` + đề xuất cách đo, đúng quy tắc "không bỏ trống" |
+| 2 | STAKEHOLDER đủ 4 nhóm, có tên thật | ☐ | Đủ 4 nhóm (Quyết định/Sử dụng/Bị ảnh hưởng/Cung cấp thông tin) nhưng **chưa có tên thật** cho bất kỳ ai — chỉ có vai trò, chờ `OQ-001`. Thiếu hẳn đại diện Pháp chế/Bảo mật (`OQ-003`) |
+| 3 | ELICITATION có ≥1 buổi với nhóm quyết định và nhóm sử dụng | ☐ | Có bản tổng hợp có nguồn (từ brief 3 vòng), nhưng **không phải buổi làm việc trực tiếp** với STK-02 (Sử dụng) riêng cho module này — xem `ELICITATION` mục 0 và `OQ-005` |
+| 4 | RQ có MoSCoW, truy về được stakeholder cụ thể | ✅ (có lưu ý) | 4/4 RQ có MoSCoW + nguồn, nhưng nguồn là brief cấp dự án (qua STK-01) chứ chưa phải phỏng vấn riêng module; 100% Must đã ghi nhận và tạo `OQ-008` theo đúng quy tắc thay vì tự quyết |
+| 5 | RISK/ASM đã ghi, rủi ro mức cao có người chịu trách nhiệm | ☐ | Đã ghi đủ 6 ASM + 4 RISK (3 mức 🔴); nhưng người chịu trách nhiệm mới là **vai trò**, chưa có tên thật (`OQ-001`), và RISK-03 chưa có người chịu trách nhiệm nào (chưa có đại diện Pháp chế) |
+| 6 | KPI có baseline | ☐ | Cả 2 GOAL đều baseline = ❓ (đúng vì greenfield), đã đề xuất cách đo — chưa phải "có" baseline thật |
+
+**Kết luận tự chấm:** G1 **chưa đủ điều kiện ký chính thức** theo đúng nghĩa checklist —
+3/6 tiêu chí còn ☐ do thiếu tên thật stakeholder, thiếu buổi làm việc trực tiếp, và KPI chưa
+có baseline số. Đây là kết quả **đúng như thiết kế của GĐ1 chạy chế độ `go` không phỏng vấn
+thật**: sản phẩm là một bộ khung đầy đủ cấu trúc + danh sách việc cụ thể cần làm trước khi PO
+ký thật. Không tự đánh ✅ cho có.
+
+**Quy tắc viết W1–W13**
+
+| W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | W11 | W12 | W13 |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| ✅ | ✅ | ✅ | N/A (GĐ1 chưa có luồng lỗi màn hình) | N/A (GĐ1 chưa có text hiển thị) | N/A (GĐ1 chưa có trạng thái thực thể) | N/A (GĐ1 chưa có field/nút) | ✅ | ✅ | ✅ | ✅ | N/A (GĐ1 không có hình wireframe) | ✅ | ✅ |
+
+Ghi chú W2: đã quét cụm từ mơ hồ (`nhanh|mượt|thân thiện|v\.v|phù hợp|tương ứng|nên |có thể `)
+trên toàn bộ 4 file GĐ1 — **~15 dòng khớp**, không phải 0. Đã soát lại từng dòng:
+- Phần lớn nằm trong **mô tả rủi ro** (`RISK_CartCheckout_v1.0.md` RISK-01…04), dùng đúng công
+  thức bắt buộc của template rủi ro *"có thể xảy ra <sự kiện>, dẫn tới <hậu quả đo được>"* —
+  đây là cú pháp chuẩn của `risk-register.md`, không phải một phát biểu yêu cầu/NFR mơ hồ.
+- Một số nằm trong **giả định `ASM`** đang chờ xác minh (VD "đồng bộ đủ nhanh" ở `ASM-06`) —
+  đây là hạn chế thật, chưa xác minh xong nên chưa thể quy về con số cụ thể; đã gắn `ASM-06`
+  và lịch xác minh trước GĐ3, không để trôi thành spec chính thức còn mơ hồ.
+- Một số nằm trong **trích dẫn/diễn giải nguồn** (F1 ở `ELICITATION`, ghi chú phạm vi ở
+  `BRIEF` §5.3, §9) — mô tả khả năng/phạm vi bằng ngôn ngữ tự nhiên, không phải NFR/AC cần đo
+  được ở GĐ1.
+Không có dòng nào trong 4 file dùng các từ này để **né việc quyết định** trong một phát biểu
+`RQ`/`GOAL` chính thức (mọi `RQ`/`GOAL` đều dùng "phải" và có phép đo). Đã quét
+`TBD|TODO|\?\?\?` — 0 kết quả là placeholder chưa xử lý thật (chỉ có 1 dòng tự nhắc tới chuỗi
+`TBD|TODO` trong chính câu giải thích quy tắc này); mọi chỗ chưa rõ đều dùng `OQ-nnn`.

ba-output/e-commerce/01-discovery/ELICITATION_CartCheckout_2026-09-08.md

@@ -0,0 +1,123 @@
+# ELICITATION — Module Giỏ hàng & Checkout — 2026-09-08
+
+| | |
+|---|---|
+| **Buổi** | Tổng hợp — không phải phỏng vấn trực tiếp (xem mục 0) |
+| **Ngày giờ** | Không ghi trong nguồn theo mốc ngày/giờ cụ thể — nguồn ghi theo "vòng 1" và "vòng 3" của `docs/00-project-brief.md`; ngày tổng hợp lại: 2026-09-08 |
+| **Hình thức** | Phân tích tài liệu đã chốt (không phải phỏng vấn 1-1/workshop/quan sát trực tiếp) |
+| **Người tham gia** | Không có — nguồn là biên bản Q&A giữa điều phối dự án và "người dùng" (đóng vai PO) đã chốt qua 3 vòng, ghi trong `docs/00-project-brief.md` §4 |
+| **Người ghi** | BA (qua skill ba-1-discovery) |
+| **Đã gửi xác nhận** | ☐ Chưa — chưa có đầu mối thật để gửi (xem `OQ-001` ở `STAKEHOLDER_CartCheckout_v1.0.md`) |
+
+---
+
+## 0. Ghi chú bắt buộc đọc trước
+
+Theo chỉ đạo của người duyệt: *"Không cần chạy phỏng vấn thật: ELICITATION ghi lại 3 vòng Q&A
+trong brief như biên bản có nguồn."* File này **không phải** biên bản một buổi phỏng vấn/khảo
+sát/workshop thật với STK-01…STK-06 của module Giỏ hàng & Checkout. Nó là bản trích lọc và
+diễn giải lại các câu hỏi/trả lời **liên quan tới FR-05, FR-06, FR-07** đã có sẵn trong
+`e-commerce/docs/00-project-brief.md` (văn bản đã qua 3 vòng Q&A ở cấp toàn dự án, không phải
+riêng module này).
+
+Hệ quả:
+
+- **Năm câu hỏi bắt buộc** của `ba-1-discovery` (Bước 3) — *"cho tôi xem một ca thật"*, *"chỗ
+  nào hay sai nhất"*, *"trường hợp ngoại lệ nào"*, *"nếu chỉ làm được một thứ"*, *"làm sao biết
+  thành công"* — **chưa được hỏi nguyên văn** cho module này, vì nguồn là văn bản tổng hợp, không
+  phải hội thoại trực tiếp. Đây là khoảng trống thật, không che giấu — xem mục 5 (Open Questions).
+- **Không có bước "đọc lại tóm tắt cho người tham gia xác nhận tại chỗ"** vì không có buổi họp
+  thật diễn ra.
+- Mọi phát biểu dưới đây **vẫn có nguồn truy vết được** (trích dẫn tới `00-project-brief.md`),
+  đáp ứng nguyên tắc "không bịa yêu cầu", nhưng **độ tin cậy thấp hơn** một buổi phỏng vấn thật
+  với đúng vai trò sử dụng/bị ảnh hưởng của module (STK-02…STK-05) — vì brief được chốt ở tầm
+  toàn dự án, chưa đào sâu riêng luồng giỏ hàng/checkout/thanh toán.
+
+## 1. Mục tiêu
+
+- Trích ra các Q&A trong `docs/00-project-brief.md` liên quan tới: giỏ hàng đa seller (FR-05),
+  checkout & tách đơn theo seller (FR-06), thanh toán VNPay/Momo/COD (FR-07).
+
+## 2. Nội dung
+
+### 2.1 Sự thật thu được *(đã chốt qua Q&A, coi là quyết định của PO)*
+
+| # | Nội dung | Nguồn xác minh |
+|---|---|---|
+| F1 | Mô hình là marketplace đa người bán (multi-vendor B2C/B2B2C); Guest có thể checkout không cần tài khoản | `00-project-brief.md` vòng 1, câu hỏi 1; `sections/01-tong-quan.md` §1.2 |
+| F2 | MVP xác nhận có "Giỏ hàng & checkout (hỗ trợ giỏ hàng đa seller trong 1 đơn)" và "Thanh toán (VNPay/Momo + COD)" | `00-project-brief.md` vòng 1, câu hỏi 2 |
+| F3 | Quản lý đơn hàng bao gồm "tách đơn theo seller" — một giỏ hàng đa seller được tách thành các đơn con | `00-project-brief.md` mục 2 "Bộ tính năng MVP chuẩn"; `sections/02-phan-tich-yeu-cau.md` FR-06 |
+| F4 | Nền tảng client MVP là web responsive (không phải app di động) | `00-project-brief.md` vòng 1, câu hỏi 4 |
+| F5 | Đối tác thanh toán/vận chuyển mặc định: VNPay, Momo, COD / GHN, GHTK | `00-project-brief.md` vòng 1, câu hỏi 4 |
+| F6 | FR-05, FR-06, FR-07 đều được xếp **Must** trong bảng yêu cầu chức năng đã duyệt | `sections/02-phan-tich-yeu-cau.md` §2.1 |
+| F7 | Không có hệ thống cũ (ERP/kho/CRM) cần tích hợp hoặc migrate cho luồng giỏ hàng/checkout — dự án hoàn toàn mới | `00-project-brief.md` vòng 3, câu hỏi 4; mục 3 |
+
+### 2.2 Ý kiến / mong muốn *(chưa phải yêu cầu đã chốt ở mức chi tiết module)*
+
+| # | Nội dung | Người nêu | Mức thiết tha |
+|---|---|---|---|
+| O1 | Mã khuyến mãi/coupon và điểm thưởng loyalty có thể áp dụng ngay trong bước checkout (không phải một bước tách riêng) | Suy ra từ mô tả UI ở `sections/07-giao-dien.md` SCR-05 — **chỉ là bối cảnh UI, chưa phải yêu cầu đã chốt cho module này** (FR-13/FR-14 nằm ngoài phạm vi FR-05/06/07 được giao) | Trung bình — cần PO xác nhận có thuộc phạm vi module Giỏ hàng & Checkout hay là điểm nối với module Khuyến mãi/Loyalty |
+| O2 | Kỳ vọng phí vận chuyển/thời gian giao hiển thị riêng theo từng đơn con seller trước khi thanh toán | Suy ra từ `sections/07-giao-dien.md` SCR-05 (bối cảnh UI) | Trung bình — chưa có RQ chính thức, xem `OQ-004` |
+
+### 2.3 Giả định phát hiện *(người nói tin là đúng nhưng chưa ai xác nhận riêng cho module này)*
+
+| # | Giả định | Cách xác minh | → ASM |
+|---|---|---|---|
+| A1 | VNPay/Momo hỗ trợ webhook xác nhận thanh toán gần thời gian thực | Đọc tài liệu tích hợp VNPay/Momo, gọi thử sandbox | ASM-01 |
+| A2 | GHN/GHTK cung cấp API tính phí vận chuyển & kiểm tra vùng phục vụ theo địa chỉ ngay tại bước checkout | Đọc tài liệu API GHN/GHTK, xác nhận với Trưởng vận hành (STK-05) | ASM-02 |
+| A3 | COD không có giới hạn giá trị đơn hàng tối đa ở MVP | Hỏi PO sàn (STK-01) và Kế toán đối soát (STK-04) | ASM-05 |
+| A4 | Giá/tồn kho hiển thị trong giỏ hàng được đồng bộ đủ nhanh với catalog để phát hiện thay đổi giữa lúc thêm giỏ và lúc checkout | Xác nhận kiến trúc dữ liệu catalog ở GĐ2 với Tech Lead (STK-06) | ASM-06 |
+
+### 2.4 Trích nguyên văn
+
+> "Giữ toàn bộ MVP đề xuất VÀ bổ sung ngay từ MVP: (1) loyalty/điểm thưởng; (2) đa ngôn ngữ và
+> đa tiền tệ." — trả lời vòng 1, câu hỏi 2, `00-project-brief.md`
+
+> "Payout hàng tuần qua chuyển khoản ngân hàng, có kỳ giữ tiền (hold) sau giao hàng thành công
+> (dùng mặc định 3-7 ngày)." — trả lời vòng 3, câu hỏi 1, `00-project-brief.md` *(không thuộc
+> phạm vi module này nhưng cho biết chính sách đổi trả có thể ảnh hưởng tới thời điểm "giao hàng
+> thành công" mà module Order/Payment cần ghi nhận — liên quan gián tiếp tới FR-07)*
+
+## 3. Mâu thuẫn với thông tin trước đó
+
+Không phát hiện mâu thuẫn giữa các vòng Q&A trong brief liên quan tới FR-05/06/07 — cả 3 vòng
+đều nhất quán về việc giữ nguyên các tính năng này ở mức Must, không có vòng nào đề xuất bỏ hoặc
+thay đổi.
+
+| # | Buổi này nói | Buổi/nguồn trước nói | Trạng thái |
+|---|---|---|---|
+| — | *(không có)* | | — |
+
+## 4. Yêu cầu chưng cất được
+
+Chi tiết đầy đủ (nguồn, MoSCoW, liên kết GOAL) nằm ở `BRIEF_CartCheckout_v1.0.md` §6. Tóm tắt
+liên kết:
+
+| → RQ | Phát biểu | MoSCoW đề xuất | Giải pháp khách gợi ý |
+|---|---|---|---|
+| RQ-001 | Customer/Guest mua được từ nhiều seller trong một giỏ hàng | Must | "Giỏ hàng đa seller" (F2) |
+| RQ-002 | Hệ thống tự tách đơn theo seller khi checkout | Must | "tách đơn theo seller" (F3) |
+| RQ-003 | Thanh toán qua nhiều kênh (VNPay/Momo/COD), không lưu thẻ trên hệ thống sàn | Must | "Thanh toán (VNPay/Momo + COD)" (F2) |
+| RQ-004 | Guest checkout không cần tạo tài khoản trước | Must | "checkout không cần đăng nhập" (F1) |
+
+## 5. Open Questions phát sinh
+
+| ID | Câu hỏi | Hỏi ai | Hạn đề xuất |
+|---|---|---|---|
+| OQ-004 | Việc áp coupon (FR-13) và dùng điểm thưởng (FR-14) ngay trong màn hình checkout có thuộc phạm vi module Giỏ hàng & Checkout hay là điểm tích hợp với module Khuyến mãi/Loyalty (xử lý ở GĐ2 module khác)? | PO sàn (STK-01) | Trước khi bắt đầu GĐ2 của module này |
+| OQ-005 | Cần tổ chức tối thiểu 1 buổi phỏng vấn/workshop thật với STK-02 (Khách hàng đại diện) và STK-03 (Seller đại diện) để hỏi 5 câu bắt buộc của Bước 3 (ca thật, điểm hay sai, ngoại lệ, ưu tiên số 1, định nghĩa thành công) — hiện chưa có buổi nào. Ai sẽ làm đầu mối sắp xếp? | Điều phối dự án / PO sàn | Trước khi ký G1 chính thức (khuyến nghị, xem mục 0) |
+| OQ-006 | Chính sách giới hạn giá trị đơn COD (nếu có) là gì, để giảm rủi ro bùng hàng khi một giỏ hàng đa seller bị tách thành nhiều đơn COD độc lập? | PO sàn (STK-01), Kế toán đối soát (STK-04) | Trước GĐ2 (ảnh hưởng BR) |
+
+## 6. Việc cần làm tiếp
+
+| # | Việc | Ai | Hạn |
+|---|---|---|---|
+| 1 | Xác nhận tên thật + đầu mối liên lạc của STK-01…STK-06 | Điều phối dự án | Trước ký G1 |
+| 2 | Tổ chức phỏng vấn thật với Khách hàng đại diện và Seller đại diện cho module này | BA | Trước GĐ2 |
+| 3 | Xác nhận với Tech Lead về ASM-01, ASM-02, ASM-06 | BA | Trước GĐ2 |
+
+## 7. Tóm tắt đã đọc lại cho người tham gia xác nhận tại chỗ
+
+- [ ] Đã đọc lại tóm tắt cuối buổi — **N/A, không có buổi họp trực tiếp (xem mục 0)**
+- [ ] Đã gửi biên bản trong vòng 24h — **N/A**
+- [ ] Đã nhận phản hồi xác nhận — **N/A, chờ đầu mối thật (`OQ-001`)**

ba-output/e-commerce/01-discovery/RISK_CartCheckout_v1.0.md

@@ -0,0 +1,100 @@
+# RISK — Sổ rủi ro & giả định — Module Giỏ hàng & Checkout (e-commerce)
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | 2026-09-08 |
+| **Author** | BA (qua skill ba-1-discovery) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Profile** | screen · greenfield · standard |
+| **Source** | `e-commerce/docs/00-project-brief.md` · `e-commerce/docs/sections/01-tong-quan.md` · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` · `e-commerce/docs/sections/07-giao-dien.md` (bối cảnh UI SCR-04…07) · `ELICITATION_CartCheckout_2026-09-08.md` |
+| **Scope** | Module Giỏ hàng & Checkout (FR-05, FR-06, FR-07) — dự án e-commerce |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | CR |
+|---|---|---|---|---|
+| 1.0 | 2026-09-08 | BA (qua skill ba-1-discovery) | Bản đầu | — |
+
+---
+
+## 1. Giả định (`ASM-nn`)
+
+| ID | Giả định | Ai/cái gì làm nó đúng | Cách xác minh | Hạn xác minh | Hệ quả nếu sai | Trạng thái |
+|---|---|---|---|---|---|---|
+| ASM-01 | VNPay/Momo hỗ trợ webhook xác nhận thanh toán gần thời gian thực (không phải chỉ polling chậm) | Cổng thanh toán bên thứ ba | Đọc tài liệu tích hợp VNPay/Momo, gọi thử sandbox | Trước GĐ2 kết thúc (trước khi chốt `PROCESS`/`BR` thanh toán) | SCR-07 (xác nhận đơn) phải đổi từ "chờ webhook" sang polling định kỳ, tăng độ trễ cảm nhận, ảnh hưởng NFR-01 | ☐ Chưa xác minh |
+| ASM-02 | GHN/GHTK cung cấp API tính phí vận chuyển & kiểm tra vùng phục vụ theo địa chỉ tại thời điểm checkout | Đơn vị vận chuyển bên thứ ba | Đọc tài liệu API GHN/GHTK; xác nhận với Trưởng vận hành (STK-05) | Trước GĐ2 kết thúc | Không hiển thị được phí/thời gian giao theo từng seller lúc checkout → phải chuyển sang ước tính tĩnh hoặc tính sau, ảnh hưởng trải nghiệm và RQ liên quan tách đơn | ☐ Chưa xác minh |
+| ASM-03 | Giỏ hàng có N seller sẽ luôn tách thành đúng N đơn con — không có trường hợp gộp 2 seller vào 1 đơn con | FR-06 đã mô tả rõ cơ chế này ở mức khái niệm | Xác nhận lại với PO sàn (STK-01) khi làm `BR` ở GĐ2 — chưa có ngoại lệ nào được nêu | Trước khi chốt `BR` ở GĐ2 | Nếu có ngoại lệ (VD gộp đơn cùng kho vận), toàn bộ luồng tách đơn và tính phí ship phải thiết kế lại | ☐ Chưa xác minh |
+| ASM-04 | Seller (STK-03) sẽ nhận được thông báo về đơn con mới ngay sau khi checkout thành công, dù việc gửi thông báo thuộc FR-12/FR-19 (ngoài phạm vi module này) | Phụ thuộc module Quản lý đơn hàng (seller) và Thông báo — chưa xác nhận SLA bàn giao dữ liệu giữa hai module | Xác nhận điểm nối dữ liệu (event/queue) với Tech Lead (STK-06) ở GĐ2 | Trước khi chốt `IMPACT` ở GĐ2 | Seller không biết có đơn mới kịp thời → chậm xử lý, ảnh hưởng SLA giao hàng | ☐ Chưa xác minh |
+| ASM-05 | COD không có giới hạn giá trị đơn hàng tối đa ở MVP (không có business rule chặn) | Suy ra từ việc brief không đề cập giới hạn COD | Hỏi PO sàn (STK-01) và Kế toán đối soát (STK-04) — xem `OQ-006` | Trước khi chốt `BR` thanh toán ở GĐ2 | Nếu sai (cần giới hạn) → thiếu một business rule quan trọng, phát hiện muộn có thể lộ ở UAT hoặc sau go-live dưới dạng rủi ro tài chính thật (RISK-01) | ☐ Chưa xác minh |
+| ASM-06 | Giá/tồn kho hiển thị trong giỏ hàng đủ đồng bộ với catalog để phát hiện thay đổi giữa lúc thêm giỏ và lúc checkout (không có cache trễ đáng kể) | Kiến trúc dữ liệu catalog (chưa thiết kế — thuộc GĐ2/GĐ3) | Xác nhận với Tech Lead (STK-06) khi có kiến trúc sơ bộ | Trước GĐ3 (SRS) | Nếu cache trễ, khách có thể thanh toán với giá/tồn kho sai → tranh chấp, phải bổ sung cơ chế khoá giá/tồn kho tạm thời (reservation) | ☐ Chưa xác minh |
+
+**Bốn chỗ giả định hay ẩn nấp — đã rà theo checklist chuẩn:**
+
+| Chỗ | Giả định điển hình trong module này | Trạng thái rà soát |
+|---|---|---|
+| **Dữ liệu** | ASM-06 (đồng bộ giá/tồn kho) | Đã ghi, chưa xác minh |
+| **Tích hợp** | ASM-01 (webhook VNPay/Momo), ASM-02 (API GHN/GHTK) | Đã ghi, chưa xác minh |
+| **Con người** | ASM-04 (seller được thông báo kịp thời) | Đã ghi, chưa xác minh |
+| **Pháp lý** | Không có ASM riêng cho PII ở đây — xem `RISK-03` (chưa có đại diện Pháp chế để hỏi, `OQ-003` ở `STAKEHOLDER_CartCheckout_v1.0.md`) | Chưa có người trả lời được |
+
+🔴 ASM-05 có hệ quả nếu sai ở mức **Cao** (rủi ro tài chính thật) → đã nâng thành `RISK-01`
+bên dưới và cần xác minh **ngay trong GĐ1/đầu GĐ2**, không để tới UAT.
+
+## 2. Rủi ro (`RISK-nn`)
+
+| ID | Mô tả rủi ro | Loại | Khả năng | Tác động | Mức | Người chịu trách nhiệm | Phương án ứng phó | Dấu hiệu sớm | Trạng thái |
+|---|---|---|---|---|---|---|---|---|---|
+| RISK-01 | Vì một giỏ hàng đa seller được tách thành nhiều đơn con COD độc lập (FR-06) và MVP theo giả định (`ASM-05`) chưa có giới hạn giá trị/số lượng đơn COD, có thể xảy ra tình trạng khách nhận một phần đơn (VD chỉ nhận đơn của seller A, từ chối đơn seller B), dẫn tới seller B chịu phí vận chuyển hoàn hàng và phát sinh tranh chấp seller–sàn hàng loạt khi quy mô giao dịch lớn (brief xác nhận quy mô "lớn", hàng trăm nghìn user). | Nghiệp vụ / Tài chính | Cao | Cao | 🔴 | STK-01 (PO sàn) — *chưa có tên thật, `OQ-001`* | BA đề xuất 2 phương án cho PO chọn: (a) giới hạn giá trị tối đa cho đơn COD đa seller; (b) yêu cầu xác thực OTP/đặt cọc cho đơn giá trị cao. **Đây là đề xuất, PO phải chọn (W8)** | Tỷ lệ đơn con bị từ chối một phần tăng bất thường theo dữ liệu vận hành sau go-live | Mở |
+| RISK-02 | Vì VNPay/Momo là bên thứ ba và cơ chế xác nhận qua webhook chưa được xác minh (`ASM-01`), có thể xảy ra tình trạng khách đã bị trừ tiền nhưng hệ thống không nhận được xác nhận trong thời gian chờ ở màn hình xác nhận đơn hàng (SCR-07, bối cảnh UI), dẫn tới đơn hàng kẹt ở trạng thái "Chờ thanh toán" dù tiền đã được cổng thanh toán ghi nhận, gây khiếu nại CSKH và tranh chấp đối soát với STK-04. | Tích hợp | Trung bình | Cao | 🔴 | STK-06 (Tech Lead) + STK-01 (PO sàn) | BA đề xuất: có cơ chế đối soát bù (reconciliation job) định kỳ đối chiếu trạng thái giao dịch với cổng thanh toán, không chỉ dựa vào webhook một lần. **Cần Tech Lead xác nhận khả thi** | Số lượng đơn "Chờ thanh toán" quá 15 phút tăng bất thường | Mở |
+| RISK-03 | Vì dự án chưa có đại diện Pháp chế/Bảo mật được chỉ định (xem `STAKEHOLDER_CartCheckout_v1.0.md` mục 3), có thể xảy ra việc module Giỏ hàng & Checkout thu thập/chia sẻ dữ liệu địa chỉ giao hàng và số điện thoại người nhận cho từng seller (khi tách đơn) mà chưa được rà soát theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân, dẫn tới rủi ro vi phạm quy định khi go-live. | Tuân thủ | Trung bình | Cao | 🔴 | *(Chưa có người — `OQ-003`)* | BA đề xuất: PO chỉ định người phụ trách pháp chế/bảo mật trước khi kết thúc GĐ2; BA chuẩn bị danh sách trường dữ liệu PII được chia sẻ cho seller để người đó rà soát | Chưa có ai được hỏi về việc này tính tới thời điểm chốt G1 | Mở |
+| RISK-04 | Vì checkout phải tính phí vận chuyển riêng cho từng đơn con theo seller (FR-06, tích hợp GHN/GHTK — `ASM-02`), tổng phí vận chuyển của một giỏ hàng nhiều seller có thể cao hơn đáng kể so với mua từ một seller duy nhất, dẫn tới khách bỏ giỏ hàng ở bước checkout (ảnh hưởng trực tiếp tới GOAL-01/GOAL-02 ở `BRIEF`). | Nghiệp vụ | Trung bình | Trung bình | 🟠 | STK-01 (PO sàn) | BA đề xuất PO cân nhắc chính sách trợ giá/miễn phí ship theo ngưỡng đơn hàng — **đề xuất, PO quyết, chưa phải chốt** | Tỷ lệ bỏ giỏ hàng ở bước checkout cao hơn ở bước giỏ hàng, đặc biệt với giỏ có ≥2 seller | Mở |
+
+**Ma trận mức:**
+
+| Tác động ↓ · Khả năng → | Thấp | Trung bình | Cao |
+|---|---|---|---|
+| **Cao** | 🟠 | 🔴 RISK-02, RISK-03 | 🔴 RISK-01 |
+| **Trung bình** | 🟢 | 🟠 RISK-04 | 🔴 |
+| **Thấp** | 🟢 | 🟢 | 🟠 |
+
+🔴 RISK-01, RISK-02, RISK-03 phải có phương án ứng phó và người chịu trách nhiệm **thật** (không
+phải placeholder vai trò) trước khi qua G2 — báo PM.
+
+**Loại rủi ro — đã rà đủ 6 loại:**
+
+| Loại | Rà cho module này |
+|---|---|
+| Nghiệp vụ | RISK-01, RISK-04 |
+| Dữ liệu | Chưa phát hiện rủi ro riêng — theo dõi qua `ASM-06` |
+| Tích hợp | RISK-02 |
+| Con người | Chưa phát hiện rủi ro riêng cho module này — theo dõi qua `ASM-04` |
+| Tuân thủ | RISK-03 |
+| Tổ chức | Chưa phát hiện — vì chưa có buổi làm việc thật để lộ mâu thuẫn (xem `STAKEHOLDER` mục 6) |
+
+## 3. Phụ thuộc bên ngoài
+
+| # | Phụ thuộc vào | Bên nào | Cần trước ngày | Nếu trễ thì sao | Đầu mối | Trạng thái |
+|---|---|---|---|---|---|---|
+| 1 | Tài liệu API + tài khoản sandbox VNPay | VNPay | Trước khi bắt đầu GĐ3 (SRS thanh toán) | Không xác minh được ASM-01, chặn thiết kế luồng xác nhận thanh toán | Chưa xác định | Mở |
+| 2 | Tài liệu API + tài khoản sandbox Momo | Momo | Trước khi bắt đầu GĐ3 | Tương tự trên | Chưa xác định | Mở |
+| 3 | Tài liệu API + tài khoản tích hợp GHN | GHN | Trước khi bắt đầu GĐ3 (SRS checkout, tính phí ship) | Không xác minh được ASM-02, phải dùng ước tính tĩnh tạm thời | Chưa xác định | Mở |
+| 4 | Tài liệu API + tài khoản tích hợp GHTK | GHTK | Trước khi bắt đầu GĐ3 | Tương tự trên | Chưa xác định | Mở |
+
+## 4. Rủi ro đã đóng
+
+*Chưa có — dự án mới bắt đầu GĐ1.*
+
+| ID | Rủi ro | Ngày đóng | Kết cục | Bài học |
+|---|---|---|---|---|
+
+## 5. Lịch rà soát
+
+| Mốc | Việc |
+|---|---|
+| Trước khi ký G1 | Rà lại RISK-01, RISK-02, RISK-03 với người chịu trách nhiệm thật (không phải vai trò placeholder) |
+| GĐ2 bắt đầu | ASM-03, ASM-04, ASM-05 phải chuyển sang "đã xác minh" trước khi chốt `BR` |
+| GĐ3 bắt đầu | ASM-01, ASM-02, ASM-06 phải chuyển sang "đã xác minh" hoặc thành `RISK` chính thức |
+| GĐ4 UAT | Rà lại RISK-01 (COD) và RISK-02 (webhook) — đây là lúc chúng dễ hiện hình nhất |
+| GĐ5 | Chuyển bài học vào `BENEFIT` |

ba-output/e-commerce/01-discovery/STAKEHOLDER_CartCheckout_v1.0.md

@@ -0,0 +1,148 @@
+# STAKEHOLDER — Module Giỏ hàng & Checkout (e-commerce)
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | 2026-09-08 |
+| **Author** | BA (qua skill ba-1-discovery) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Profile** | screen · greenfield · standard (xem `00-index/PROFILE_e-commerce.md`) |
+| **Source** | `e-commerce/docs/00-project-brief.md` · `e-commerce/docs/sections/01-tong-quan.md` §1.2 · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` · Ghi chú vai trò từ người duyệt (prompt khởi tạo, 2026-09-08) |
+| **Scope** | Module Giỏ hàng & Checkout (FR-05, FR-06, FR-07) — dự án e-commerce |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | CR |
+|---|---|---|---|---|
+| 1.0 | 2026-09-08 | BA (qua skill ba-1-discovery) | Bản đầu | — |
+
+---
+
+## 0. Ghi chú về nguồn — đọc trước khi dùng
+
+🔴 Stakeholder thật **chưa có tên**. Theo ghi chú từ người duyệt, dùng **vai trò** thay tên
+thật: PO sàn, Trưởng vận hành, Kế toán đối soát, Seller đại diện, Khách hàng đại diện, Tech
+Lead. Mọi ô "Tên" dưới đây ghi placeholder theo vai trò và có `OQ` đòi tên thật + đầu mối
+liên lạc — **chưa liên hệ được thì chưa nên coi G1 là đã ký thật**, kể cả khi PO ký thay bằng
+vai trò.
+
+Mức quan tâm/ảnh hưởng ở bảng dưới là **đánh giá ban đầu của BA** dựa trên vai trò nghiệp vụ
+mô tả trong brief, **chưa được chính chủ tự chấm** — xem `OQ-002`.
+
+---
+
+## 1. Danh sách stakeholder
+
+| ID | Tên | Vai trò / Bộ phận | Nhóm | Quan tâm | Ảnh hưởng | Chiến lược | Kênh | Người thay thế |
+|---|---|---|---|---|---|---|---|---|
+| STK-01 | *(chưa có tên thật — OQ-001)* | PO sàn (Product Owner marketplace) | Quyết định | Cao | Cao | Quản lý sát | Chưa xác định | Chưa xác định |
+| STK-02 | *(chưa có tên thật — OQ-001)* | Khách hàng đại diện (đại diện Guest + Customer, người thao tác giỏ hàng/checkout/thanh toán) | Sử dụng | Cao | Thấp | Giữ thông tin | Chưa xác định | Chưa xác định |
+| STK-03 | *(chưa có tên thật — OQ-001)* | Seller đại diện (Vendor — đơn con của họ được tạo ra từ checkout) | Bị ảnh hưởng | Cao | Trung bình | Giữ thông tin | Chưa xác định | Chưa xác định |
+| STK-04 | *(chưa có tên thật — OQ-001)* | Kế toán đối soát (đối soát doanh thu theo VNPay/Momo/COD, theo seller) | Bị ảnh hưởng | Thấp | Cao | Giữ hài lòng | Chưa xác định | Chưa xác định |
+| STK-05 | *(chưa có tên thật — OQ-001)* | Trưởng vận hành (Ops/Warehouse — nhận đơn con sau checkout, phối hợp GHN/GHTK) | Cung cấp thông tin | Trung bình | Trung bình | Giữ thông tin | Chưa xác định | Chưa xác định |
+| STK-06 | *(chưa có tên thật — OQ-001)* | Tech Lead (khả thi tích hợp VNPay/Momo/GHN/GHTK, ràng buộc kiến trúc) | Cung cấp thông tin | Cao | Cao | Quản lý sát | Chưa xác định | Chưa xác định |
+
+**Nhóm** — bốn nhóm, thiếu nhóm nào cũng là lỗ hổng:
+
+| Nhóm | Câu hỏi nhận diện | Rủi ro nếu bỏ sót |
+|---|---|---|
+| Quyết định | Ai ký duyệt? Ai cắt được scope? | Làm xong bị bác |
+| Sử dụng | Ai ngồi trước màn hình mỗi ngày? | Đúng spec nhưng không ai dùng |
+| Bị ảnh hưởng | Quy trình của ai thay đổi? Ai mất/được việc? | Kháng cự lúc go-live |
+| Cung cấp thông tin | Ai biết nghiệp vụ hiện tại? Ai giữ dữ liệu? | Hiểu sai AS-IS |
+
+🔴 **Nhóm còn thiếu — Pháp chế/Bảo mật.** Module này xử lý PII (địa chỉ giao hàng, số điện
+thoại) và dữ liệu thanh toán (dù không lưu số thẻ). Danh sách vai trò do người duyệt cung cấp
+**không có** đại diện Pháp chế/Bảo mật. Đây đúng là một trong ba nhóm SKILL cảnh báo hay bị bỏ
+sót nhất → `OQ-003`. Chưa có người này ký thì rủi ro tuân thủ (RISK-03) chưa ai chịu trách
+nhiệm chính thức.
+
+## 2. Ma trận Quan tâm × Ảnh hưởng
+
+```mermaid
+quadrantChart
+    title Stakeholder — Quan tâm × Ảnh hưởng (module Giỏ hàng & Checkout)
+    x-axis "Quan tâm thấp" --> "Quan tâm cao"
+    y-axis "Ảnh hưởng thấp" --> "Ảnh hưởng cao"
+    quadrant-1 "QUẢN LÝ SÁT"
+    quadrant-2 "GIỮ HÀI LÒNG"
+    quadrant-3 "THEO DÕI"
+    quadrant-4 "GIỮ THÔNG TIN"
+    "STK-01 PO sàn": [0.90, 0.90]
+    "STK-02 KH đại diện": [0.80, 0.25]
+    "STK-03 Seller đại diện": [0.75, 0.50]
+    "STK-04 Kế toán đối soát": [0.20, 0.85]
+    "STK-05 Trưởng vận hành": [0.50, 0.45]
+    "STK-06 Tech Lead": [0.75, 0.85]
+```
+
+*Toạ độ 0–1, đánh giá sơ bộ của BA — cần từng người tự xác nhận lại, xem `OQ-002`.*
+
+| Ô | Chiến lược | STK trong ô |
+|---|---|---|
+| **Quản lý sát** *(quan tâm cao, ảnh hưởng cao)* | Đồng hành, duyệt từng gate | STK-01, STK-06 |
+| **Giữ hài lòng** *(quan tâm thấp, ảnh hưởng cao)* | Hỏi từng điểm một, không chấp nhận im lặng | STK-04 |
+| **Giữ thông tin** *(quan tâm cao, ảnh hưởng thấp/TB)* | Hỏi ý kiến, demo sớm | STK-02, STK-03, STK-05 |
+| **Theo dõi** *(cả hai thấp)* | Thông báo khi cần | — |
+
+🔴 **STK-04 (Kế toán đối soát) nằm ở ô nguy hiểm nhất** — ảnh hưởng cao (họ phát hiện lỗi số
+liệu payout/đối soát muộn nhất, và phủ quyết muộn nhất) nhưng quan tâm thấp (hiếm khi được
+mời họp sản phẩm). Không được coi im lặng là đồng ý.
+
+## 3. Ba nhóm hay bị bỏ sót — rà đích danh
+
+| Nhóm | Có mặt trong danh sách vai trò của người duyệt? | Câu phải hỏi |
+|---|---|---|
+| Vận hành / CS | ✅ STK-05 Trưởng vận hành | "Khi Customer khiếu nại một đơn con bị chậm ngay sau checkout, ai nhận đầu tiên?" |
+| Kế toán / đối soát | ✅ STK-04 Kế toán đối soát | "Số liệu doanh thu theo VNPay/Momo/COD, theo seller, ai đối chiếu và đối chiếu với cái gì?" |
+| Pháp chế / bảo mật | ❌ **Không có trong danh sách** — `OQ-003` | "Dữ liệu địa chỉ + số điện thoại người nhận trong Order có phải PII cần xin phép lưu trữ/chia sẻ cho seller không?" |
+
+## 4. RACI theo hạng mục quyết định (thu hẹp cho module này)
+
+| Hạng mục | R (làm) | A (chịu trách nhiệm cuối) | C (hỏi ý kiến) | I (thông báo) |
+|---|---|---|---|---|
+| Chốt phạm vi module Giỏ hàng & Checkout | BA | STK-01 (PO sàn) | STK-06 (Tech Lead) | Team |
+| Chốt quy tắc tách đơn theo seller (FR-06) | BA | STK-01 | STK-03, STK-05 | STK-04 |
+| Chốt danh sách phương thức thanh toán & xử lý lỗi thanh toán (FR-07) | BA | STK-01 | STK-06, STK-04 | STK-02 |
+| Chốt giới hạn/điều kiện áp dụng COD (RISK-01) | BA | STK-01 | STK-04, STK-05 | STK-03 |
+| Xác nhận yêu cầu tuân thủ PII/thanh toán | BA | *(chưa xác định — `OQ-003`)* | STK-01, STK-06 | Team |
+| Duyệt UAT module | QA | STK-01 | BA | Team |
+
+**Mỗi hàng chỉ có đúng một chữ A.** Hàng "Xác nhận yêu cầu tuân thủ PII/thanh toán" chưa có A
+vì chưa có đại diện Pháp chế — đây chính là lỗ hổng nêu ở mục 3.
+
+## 5. Kế hoạch tiếp cận
+
+🔴 Toàn bộ nội dung trong `BRIEF`/`ELICITATION` của lần chạy này lấy từ `docs/00-project-brief.md`
+(biên bản 3 vòng Q&A đã chốt ở cấp toàn dự án, không riêng module Giỏ hàng & Checkout) — **chưa
+có buổi làm việc trực tiếp nào với 6 vai trò dưới đây riêng cho module này.** Bảng dưới là kế
+hoạch đề xuất, chưa thực hiện.
+
+| STK | Cần lấy thông tin gì | Kỹ thuật | Dự kiến | Trạng thái |
+|---|---|---|---|---|
+| STK-01 (PO sàn) | Xác nhận tên thật, KPI/baseline conversion & tỷ lệ thanh toán thành công, ngưỡng Must/Should thật của module | Phỏng vấn 1-1 | Trước khi ký G1 | ☐ Chưa thực hiện |
+| STK-02 (KH đại diện) | Kỳ vọng thực tế khi mua từ nhiều seller (mức chấp nhận phí ship gộp, thời gian chờ) | Phỏng vấn/khảo sát | Trước GĐ2 | ☐ Chưa thực hiện |
+| STK-03 (Seller đại diện) | Kỳ vọng về tốc độ nhận đơn con, rủi ro bùng COD ảnh hưởng seller thế nào | Phỏng vấn 1-1 | Trước GĐ2 | ☐ Chưa thực hiện |
+| STK-04 (Kế toán đối soát) | Cách đối soát hiện tại (nếu công ty đã có luồng thu khác), yêu cầu dữ liệu tối thiểu từ Order/Payment | Phỏng vấn 1-1 | Trước GĐ2 (BR) | ☐ Chưa thực hiện |
+| STK-05 (Trưởng vận hành) | Ràng buộc thực tế của GHN/GHTK (vùng phục vụ, SLA báo phí), quy trình nhận đơn con | Phỏng vấn 1-1 hoặc workshop | Trước GĐ2 | ☐ Chưa thực hiện |
+| STK-06 (Tech Lead) | Khả thi webhook VNPay/Momo, ràng buộc kiến trúc tách đơn | Phỏng vấn 1-1 | Trước G2 | ☐ Chưa thực hiện |
+| *(Pháp chế/Bảo mật — chưa có người)* | Phạm vi PII được phép lưu/chia sẻ cho seller, thời hạn lưu | Chưa xác định người | Trước G2/G3 | ☐ Chưa xác định |
+
+## 6. Mâu thuẫn giữa các bên
+
+Chưa phát hiện mâu thuẫn trực tiếp nào giữa các vai trò cho module này, **vì chưa có buổi làm
+việc riêng với từng vai trò** (xem mục 5). Đây không phải "không có mâu thuẫn" mà là "chưa đủ
+dữ liệu để phát hiện mâu thuẫn" — ghi nhận như một giới hạn của lần chạy này, không tự suy diễn.
+
+| # | Bên A muốn | Bên B muốn | Vì sao mâu thuẫn | Trạng thái |
+|---|---|---|---|---|
+| — | *(chưa phát hiện — xem ghi chú trên)* | | | — |
+
+## 7. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|
+| OQ-001 | Tên thật + đầu mối liên lạc của 6 vai trò STK-01…STK-06 là gì? | Điều phối dự án / PO | 2026-09-08 | Ký G1 thật (hiện chỉ có vai trò, chưa có người ký thật) |
+| OQ-002 | Mức Quan tâm × Ảnh hưởng ở mục 2 là đánh giá của BA — từng STK có đồng ý không? | STK-01…STK-06 | 2026-09-08 | Chiến lược tiếp cận ở mục 5 |
+| OQ-003 | Ai là đại diện Pháp chế/Bảo mật cho dự án e-commerce? Module Giỏ hàng & Checkout cần họ xác nhận phạm vi lưu/chia sẻ PII (địa chỉ, SĐT) cho seller khi tách đơn. | PO sàn (STK-01) | 2026-09-08 | RACI mục 4 (hàng tuân thủ PII), RISK-03 |