save

sa-output/e-commerce/01-context/ARISK_e-commerce_v1.0.md

@@ -0,0 +1,234 @@
+# ARISK — Architecture Risk Register & POC Plan — e-commerce
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | 2026-09-12 |
+| **Author** | SA (skill sa-1-context, chế độ `go`, hoạt động `cost-risk`) |
+| **Status** | 🟡 Draft *(duyệt từng phần — xem `Approved by`; chấp nhận 10 rủi ro `ARISK-01…10` (mức, chủ, biện pháp) và 2 kế hoạch `POC-01`/`POC-02` với tiêu chí PASS/FAIL viết trước ở §6; POC **chưa chạy** — phải xong trước `ADR` message backbone GĐ2; đây **chưa phải** AG1 toàn phần, Tech Lead/PM chưa ký thật, `OQ-004` còn mở; xem "Tự chấm" §①)* |
+| **Approved by** | PO (uỷ quyền, chế độ chạy thử): **Điều phối dự án** — duyệt **từng phần** bản v1.0 · 2026-09-12: chấp nhận 10 rủi ro `ARISK-01…10`, chủ sở hữu và biện pháp hạ rủi ro tương ứng (§3), và kế hoạch `POC-01` (throughput SQS/EventBridge) + `POC-02` (RDS gộp tải) với tiêu chí PASS/FAIL viết trước (§6). **POC chưa chạy** — bắt buộc chạy xong trước khi chốt `ADR` message backbone GĐ2. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-10`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở. `Confidence` giữ 🔴; Status **giữ** 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện. · Tech Lead: — *(chưa ký)* · PM: — *(chưa ký)* |
+| **Source** | `01-context/CTX_e-commerce_v1.0.md` (v1.2 trong header) §3, §4.2, §4.4, §5 `ASM-01…06` · `01-context/OPT_e-commerce_v1.0.md` §1, §4, §5, §8 `ASM-07…09` · `01-context/TCO_e-commerce_v1.0.md` §2, §8 `ASM-10…15` · `ba-output/e-commerce/01-discovery/RISK_CartCheckout_v1.0.md` `RISK-01…04`, `ASM-01…06` (BA — tham chiếu ID, không copy) |
+| **Scope** | Toàn sàn e-commerce (marketplace đa seller), trọng tâm rủi ro kiến trúc gắn với phương án đã chọn tạm thời **P2** (`DEC-06`) và các rủi ro độc lập với lựa chọn kiến trúc nội bộ (đối tác bên ngoài, pháp lý, ngân sách, năng lực team) |
+| **Confidence** | 🔴 Giả định chưa xác minh — kế thừa nguyên nhân của `CTX`/`OPT`/`TCO` (BA chưa ký G1, AG1 GĐ1 SA chưa từng chạy, ngoại lệ gate `DEC-01/03/04/05/07` tiếp tục ở `DEC-08`). Riêng mức độ (XS/TĐ) của từng `ARISK` là đánh giá kỹ thuật của SA dựa trên nguồn hiện có — sẽ điều chỉnh khi có xác nhận thật từ Tech Lead/PM/Security |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR/DEC |
+|---|---|---|---|---|
+| 1.0 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `cost-risk`) | Bản đầu — Bước 5 (phần `ARISK`) của `sa-1-context`. Lập sổ 10 rủi ro kiến trúc (`ARISK-01…10`), kế thừa ứng viên từ `CTX §4.2/§4.4`, `OPT ASM-07/08/09`, `TCO ASM-14`, và tham chiếu `RISK-01…04`/`ASM-01…06` của BA bằng ID (không copy nội dung). Lập 2 kế hoạch POC bắt buộc (`POC-01` SQS/EventBridge throughput, `POC-02` RDS gộp tải) có tiêu chí pass/fail suy từ `DRV-04`, phải chạy xong **trước khi** chốt `ADR` message backbone ở GĐ2 (theo cam kết `OQ-012`/`DEC-06`). Tiếp tục ngoại lệ gate `DEC-01/03/04/05/07`, ghi thêm `DEC-08`. `Confidence` 🔴 toàn tài liệu. | `DEC-08` |
+| 1.0 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **từng phần** bản v1.0: chấp nhận 10 rủi ro `ARISK-01…10`, chủ và biện pháp (§3), và kế hoạch `POC-01`/`POC-02` với tiêu chí PASS/FAIL viết trước (§6). Không đổi nội dung chuyên môn. **POC chưa chạy** — phải chạy xong trước `ADR` message backbone GĐ2. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-10`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở, Tech Lead/PM **chưa ký**. `Confidence` giữ 🔴. Status **giữ** 🟡 Draft — AG1 toàn phần chưa đủ điều kiện (xem "Tự chấm" §①). | `DEC-10` |
+
+> Sổ này **sống suốt dự án**, không đóng ở AG1. Mỗi rủi ro chỉ đóng khi có bằng chứng (kết quả
+> POC, xác nhận hợp đồng, xác nhận bằng văn bản), không đóng vì hết hạn.
+
+---
+
+## 0. Ghi chú Preflight & ngoại lệ gate — tiếp nối `CTX`/`OPT`/`TCO`
+
+> **DEC-08 (SA)** — Tiếp tục chạy `sa-1-context` Bước 5 (phần `ARISK`) cho e-commerce trong khi
+> BA vẫn chưa qua G1 và AG1 vẫn chưa từng chạy — tiếp nối `DEC-01/03/04/05/07`. Người dùng tái
+> khẳng định muốn tiếp tục.
+> **Quyết định:** Tiếp tục, lập sổ `ARISK` và kế hoạch POC với `Confidence 🔴` cho mức độ đánh giá
+> (xác suất/tác động), cho tới khi Tech Lead/PM xác nhận lại từng dòng.
+> **Người quyết:** Điều phối dự án (đại diện PO, dự án chạy thử).
+> **Radar (ước lượng):** ~3–4 — cùng lý lẽ như `DEC-07`.
+> **Hệ quả nếu không chấp nhận ngoại lệ:** GĐ1 SA không đủ 4 artifact (`CTX`/`OPT`/`TCO`/`ARISK`)
+> để audit AG1 theo đúng yêu cầu "sau lượt này GĐ1 đủ 4 artifact" của ghi chú người duyệt.
+
+---
+
+## 1. Tóm tắt
+
+| Mức | Số lượng | Đã có biện pháp cụ thể | Quá hạn |
+|---|---|---|---|
+| 🔴 Cao | 6 (`ARISK-01,02,03,05,06,07`) | 5/6 (trừ `ARISK-07` — chờ `OQ-005`) | 0 (sổ mới lập) |
+| 🟠 Trung bình | 3 (`ARISK-04,08,09`) | 3/3 | 0 |
+| 🟡 Thấp | 1 (`ARISK-10`) | 1/1 | 0 |
+
+**Ba rủi ro cần chú ý nhất tuần này:** `ARISK-01` (throughput SQS/EventBridge — chặn `ADR` message
+backbone GĐ2 theo `OQ-012`), `ARISK-02` (RDS gộp tải — chặn `DAT` GĐ2), `ARISK-06` (residency
+NĐ13/2023 — chặn `DAT`/`INF` GĐ2, người phủ quyết muộn nhất theo `GUIDE.md`).
+
+## 2. Cách chấm mức
+
+| | Tác động thấp | Tác động vừa | Tác động lớn *(lệch tiến độ >4 tuần, vượt ngân sách, không đáp ứng `DRV` Must)* |
+|---|---|---|---|
+| **Xác suất cao** | 🟠 | 🔴 | 🔴 |
+| **Xác suất vừa** | 🟡 | 🟠 | 🔴 |
+| **Xác suất thấp** | 🟡 | 🟡 | 🟠 |
+
+## 3. Sổ rủi ro
+
+| ID | Rủi ro | Nguồn | XS | TĐ | Mức | Biện pháp hạ rủi ro | Chủ | Hạn | Trạng thái |
+|---|---|---|---|---|---|---|---|---|---|
+| `ARISK-01` | SQS/EventBridge (P2, thay Kafka/MSK) chưa được đo throughput thật cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải đỉnh flash sale — nếu không đủ, luồng đặt hàng nghẽn đúng lúc doanh thu cao nhất | Hiệu năng — kế thừa `ASM-07` (`OPT §8`) | Vừa | Lớn | 🔴 | `POC-01` (§6) — đo throughput thật trước khi chốt `ADR` message backbone GĐ2 | Tech Lead | Trước `ADR` message backbone GĐ2 (`OQ-012`) | Mở |
+| `ARISK-02` | 1 cụm RDS PostgreSQL chính (schema-per-module, P2) chưa đo tải ghi/đọc gộp cho toàn bộ module ngoại trừ Payment — nếu quá tải, mọi module (Catalog/Cart/Seller/Commission…) cùng bị ảnh hưởng vì chung 1 instance | Hiệu năng — kế thừa `ASM-08` (`OPT §8`) | Vừa | Lớn | 🔴 | `POC-02` (§6) — load test trước khi chốt `DAT` GĐ2 | Tech Lead/DBA | Trước `DAT` GĐ2 | Mở |
+| `ARISK-03` | VNPay/Momo chưa có sandbox/hợp đồng thật; xác nhận thanh toán qua webhook chưa xác minh khả thi gần thời gian thực — đơn hàng có thể kẹt "chờ thanh toán" dù tiền đã thu | Phụ thuộc ngoài — kế thừa `CTX §4.2`, `RISK-02` (BA), `ASM-01` (BA) | Vừa | Lớn | 🔴 | Đàm phán sandbox VNPay/Momo sớm (trước GĐ2 `ICD`); thiết kế job đối soát bù (reconciliation) — đã có trong `SAD.md §3.4`, kế thừa nguyên trạng, xác minh lại khi có sandbox thật | Tech Lead (đàm phán) + PO (ưu tiên lịch) | Trước GĐ2 kết thúc (`ICD`) | Mở |
+| `ARISK-04` | GHN/GHTK chưa có sandbox/hợp đồng thật; cơ chế fallback chéo (GHN→GHTK) chưa kiểm chứng hoạt động đúng giữa hai API khác nhau | Phụ thuộc ngoài — kế thừa `CTX §4.2`, phần liên quan `RISK-04` (BA), `ASM-02` (BA) | Vừa | Vừa | 🟠 | Xin tài liệu API + sandbox trước GĐ2 `ICD`; viết integration test riêng cho luồng fallback (đã định hướng ở `docs/sections/09-van-hanh-kiem-thu.md` §9.1.2 "trọng tâm rủi ro cao") | Tech Lead | Trước GĐ2 `ICD` | Mở |
+| `ARISK-05` | Đội thi công thật chưa xác nhận kinh nghiệm production với Kafka/MSK/OpenSearch/EKS (`OQ-010`) — ảnh hưởng trực tiếp nếu `POC-01` fail và phải bổ sung Kafka/MSK cho hot-path (kiến trúc lai theo `OPT §1`) | Con người — kế thừa `CTX §4.4` | Cao | Vừa | 🔴 | Tech Lead xác nhận năng lực đội thật (`OQ-010`); nếu thiếu kinh nghiệm — thuê chuyên gia tư vấn ngắn hạn cho riêng giai đoạn triển khai Kafka/MSK nếu `POC-01` fail (không phải "sẽ theo dõi") | Tech Lead | Trước khi chốt `ADR` message backbone GĐ2 | Mở |
+| `ARISK-06` | Chia sẻ PII (địa chỉ, SĐT người nhận) cho seller khi tách đơn chưa được rà soát theo NĐ13/2023; residency dữ liệu (`ap-southeast-1`) chưa được đại diện Pháp chế xác nhận | Tuân thủ — kế thừa `CTX ASM-04`, `RISK-03` (BA), `OQ-007` | Vừa | Lớn | 🔴 | PO chỉ định đại diện Pháp chế/Bảo mật (`OQ-007`); SA chuẩn bị danh sách trường PII chia sẻ cho seller để người đó rà soát trước khi chốt `DAT`/`INF` GĐ2 | PO (chỉ định người) → Legal/Security (rà soát) | Trước GĐ2 (`DAT`/`INF`), chậm nhất trước go-live | Mở |
+| `ARISK-07` | Ngân sách vận hành 3 năm thật (`TCO` §1: 11,2–19,1 tỷ VND tuỳ phương án/kịch bản) chưa được PO/tài chính xác nhận có đủ khả năng chi trả hay không — con số duy nhất PO từng thấy (~3,76 tỷ) chỉ là chi phí xây dựng | Chi phí — kế thừa `CON-01`, `OQ-005`, `TCO §1` | Cao | Lớn | 🔴 | Trình `TCO` đầy đủ (đã lập) cho PO/tài chính; nếu ngân sách thật thấp hơn nhiều, loại bớt cấu phần hạ tầng nặng (đã có phương án P2 rẻ hơn P1 làm phương án dự phòng "cắt giảm") | PO/tài chính | Trước khi ký AG1 | Mở *(biện pháp = trình số liệu; chưa có xác nhận ngân sách nên chưa "đã hạ")* |
+| `ARISK-08` | Đội vận hành (Ops/SRE) sau go-live chưa xác nhận nội bộ hay thuê ngoài, quy mô bao nhiêu người (`OQ-008`) — ảnh hưởng cả khả năng đạt `DRV-05` (99.9% uptime) lẫn chi phí `TCO` (`ASM-14`, dòng nhạy cảm nhất) | Con người — kế thừa `CON-05/08` | Vừa | Vừa | 🟠 | PM/SRE xác nhận số người thật trước GĐ2 (`OQ-008`); tạm dùng giả định 2 FTE (`ASM-14`) làm mốc thiết kế `INF`/on-call ban đầu, sẽ điều chỉnh khi có số thật | PM/SRE | Trước khi chốt `INF` GĐ2 | Mở |
+| `ARISK-09` | Cảnh báo tự động `estimate.computed.json.crosscheck`: effort WBS (42,48 MM) lệch 54,47% so với UCP (27,5 MM), vượt ngưỡng 25% — dấu hiệu ước lượng effort xây dựng chưa ổn định, có thể ảnh hưởng cả tiến độ lẫn `TCO` §6 | Chi phí/ước lượng | Vừa | Vừa | 🟠 | Nhà thầu/PM giải thích chênh lệch tại mục C1 hồ sơ thầu (đã có lý giải sơ bộ: mật độ hạng mục kỹ thuật xuyên suốt cao hơn UCP phản ánh được); Tech Lead xác nhận lại effort WBS-03/05/06 (3 hạng mục XL/high risk) độc lập trước khi ký hợp đồng | PM/Tech Lead | Trước khi chốt hợp đồng thi công | Mở |
+| `ARISK-10` | Email/SMS Provider và ngân hàng đối tác payout chưa chốt cụ thể (`SAD.md §3.4` tự ghi "chưa chốt") — ảnh hưởng cả `ICD` GĐ2 lẫn `TCO §4` (`OQ-016`) | Phụ thuộc ngoài | Thấp | Vừa | 🟡 | PO/PM chọn nhà cung cấp cụ thể trước GĐ2 `ICD`; không chặn Bước 4/5 của GĐ1 vì đây không phải luồng giao dịch lõi (`DRV-01`) | PM | Trước GĐ2 `ICD` | Mở |
+
+**Trạng thái:** Mở · Đang hạ · Đã đóng (kèm bằng chứng) · Đã chấp nhận (kèm ai chấp nhận)
+
+## 4. Rà sáu nguồn rủi ro *(checklist)*
+
+| Nguồn | Câu hỏi | Trả lời | Sinh `ARISK` nào |
+|---|---|---|---|
+| Công nghệ mới | Có ai trong team từng chạy production cái này chưa? | Chưa xác nhận cho Kafka/MSK/OpenSearch/EKS (`OQ-010`); SQS/EventBridge/ECS Fargate là công nghệ managed phổ biến hơn, rủi ro thấp hơn nhưng chưa đo throughput trong ngữ cảnh này | `ARISK-01`, `ARISK-05` |
+| Phụ thuộc bên ngoài | Bên kia có SLA không? Ta có phương án khi họ hỏng/đổi/ngừng? | VNPay/Momo/GHN/GHTK: chưa sandbox/hợp đồng thật, chưa có SLA xác nhận; Email/SMS/ngân hàng: chưa chọn nhà cung cấp | `ARISK-03`, `ARISK-04`, `ARISK-10` |
+| Dữ liệu | Migration có rollback được không? Dữ liệu bẩn tới mức nào? | Không áp dụng — greenfield (`CTX §4.1`), không có dữ liệu cũ để migrate | *(không sinh ARISK — ghi nhận N/A trong "Ngoài phạm vi")* |
+| Hiệu năng | Con số throughput/latency lấy từ bài đo hay từ suy đoán? | Suy đoán/giả định (`ASM-07/08` của `OPT`) — chưa có bài đo thật | `ARISK-01`, `ARISK-02` |
+| Con người | Người duy nhất biết hệ thống cũ có còn ở công ty không? | Không áp dụng (greenfield, không có hệ thống cũ); nhưng đội vận hành/thi công thật chưa xác nhận | `ARISK-05`, `ARISK-08` |
+| Chi phí | Khoản nào tăng phi tuyến theo tải? | Egress CDN và RDS scale-up (§3 `TCO`) tăng theo tải nhưng đã mô hình hoá 2 kịch bản; ngân sách 3 năm thật chưa xác nhận đủ hay không | `ARISK-07`, `ARISK-09` |
+
+## 5. Rủi ro đã chấp nhận
+
+*Chưa có rủi ro nào được chính thức chấp nhận (cần người có thẩm quyền ký) ở lượt chạy này.*
+`ARISK-06` (residency NĐ13/2023) là ứng viên gần nhất nếu Legal/Security sau này xác nhận
+`ap-southeast-1` đủ đáp ứng — khi đó chuyển dòng này xuống bảng dưới kèm chữ ký thật, không tự
+đóng bằng đánh giá của SA (`D10`).
+
+| ID | Rủi ro | Vì sao chấp nhận | Ai ký · ngày | Dấu hiệu cảnh báo sớm | Kế hoạch dự phòng |
+|---|---|---|---|---|---|
+| *(trống)* | | | | | |
+
+## 6. Kế hoạch POC
+
+*`ARISK-01`/`ARISK-02` là rủi ro 🔴 chưa chứng minh được — bắt buộc POC theo `decision-radar.md
+§6` (quyết định "kiểu kiến trúc tổng thể"/"đồng bộ hay bất đồng bộ" đạt radar ≥ 8 ở `DEC-06`
+cần POC trước khi `ADR` GĐ2 chuyển `Accepted`). Tiêu chí pass/fail viết **trước** khi làm.*
+
+### POC-01 — Throughput SQS/EventBridge cho luồng đặt hàng
+
+| | |
+|---|---|
+| **Hạ rủi ro** | `ARISK-01` |
+| **Câu hỏi cần trả lời** | SQS FIFO (per-seller message group) + EventBridge có xử lý được ≥ 100 message/giây bền vững (payload ~2KB, giống `OrderPlaced`/`PaymentConfirmed`) mà không mất message và độ trễ chấp nhận được không? |
+| **Tiêu chí PASS** | Thông lượng sustained **≥ 100 msg/s** trong 30 phút liên tục; **p99 độ trễ publish→consume ≤ 2 giây**; **0 message mất**; EventBridge fan-out tới ≥ 5 consumer rule không lag quá 5 giây. *(Cơ sở con số: `DRV-04` đỉnh ~15.000 đơn/giờ × ~5 event/đơn ≈ 21 event/giây trung bình; thiết kế biên an toàn ×5 cho burst ⇒ ngưỡng 100 msg/s)* |
+| **Tiêu chí FAIL** | Thông lượng sustained < 100 msg/s, hoặc p99 > 2 giây, hoặc có message mất, hoặc lag > 5 giây kéo dài > 5 phút liên tục |
+| **Phạm vi** | Chỉ đo throughput/latency/độ tin cậy message — **không** đo chi phí (đã có ở `TCO`), **không** đo tích hợp với Payment Service thật (dùng giả lập payload) |
+| **Thời lượng tối đa** | 5 ngày làm việc — dừng khi hết thời lượng dù chưa xong, báo cáo kết quả dở dang |
+| **Ai làm** | Tech Lead + 1 DevOps |
+| **Môi trường** | AWS `ap-southeast-1` (SQS FIFO + EventBridge thật, không giả lập), payload JSON ~2KB theo schema `OrderPlaced` dự kiến, load generator k6/artillery |
+
+**Kết quả** *(điền sau khi chạy)*
+
+| | |
+|---|---|
+| **Ngày chạy** | *(chưa chạy — theo `OQ-012`, POC phải xong trước `ADR` message backbone GĐ2)* |
+| **Kết quả đo** | — |
+| **PASS / FAIL** | — |
+| **Điều bất ngờ phát hiện được** | — |
+| **Quyết định rút ra** | ⟶ sẽ tham chiếu `ADR` message backbone GĐ2 (`sa-2-architecture`) |
+
+### POC-02 — RDS PostgreSQL gộp chịu tải ghi/đọc kết hợp (P2)
+
+| | |
+|---|---|
+| **Hạ rủi ro** | `ARISK-02` |
+| **Câu hỏi cần trả lời** | 1 cụm RDS chính (giả định `db.r6g.xlarge` Multi-AZ, `TCO §3.2`) có đáp ứng đủ tải ghi (checkout) + đọc (catalog) gộp cho các module ngoài Payment ở tải đỉnh flash sale không? |
+| **Tiêu chí PASS** | Đồng thời ~15.000 đơn/giờ (ghi) + ~150.000 truy vấn catalog/giờ (đọc, ước ×10 tải ghi) trong 30 phút liên tục: **p95 write latency (checkout) ≤ 300ms**, **p95 read latency (catalog) ≤ 200ms** (khớp `NFR-01` của `docs/sections/09` §9.1.4), **CPU RDS < 75%**, **connection pool không bị exhaust** |
+| **Tiêu chí FAIL** | Vượt một trong các ngưỡng trên, hoặc xuất hiện lỗi connection/timeout do exhaust pool |
+| **Phạm vi** | Chỉ đo tải DB gộp — **không** đo chịu lỗi/failover (đã có kịch bản chaos riêng ở `docs/sections/09` §9.1.4 NFR-03, thuộc GĐ3) |
+| **Thời lượng tối đa** | 5 ngày làm việc |
+| **Ai làm** | Tech Lead/DBA |
+| **Môi trường** | Staging cấu hình instance class thật (`db.r6g.xlarge` Multi-AZ), dataset synthetic quy mô tương đương Năm 1 (`TCO §2` kịch bản A: ~50GB, 300.000 SKU) |
+
+**Kết quả** *(điền sau khi chạy)*
+
+| | |
+|---|---|
+| **Ngày chạy** | *(chưa chạy — cần trước khi chốt `DAT` GĐ2)* |
+| **Kết quả đo** | — |
+| **PASS / FAIL** | — |
+| **Điều bất ngờ phát hiện được** | — |
+| **Quyết định rút ra** | ⟶ sẽ tham chiếu `DAT`/`ADR` liên quan ở GĐ2 |
+
+🔴 **POC fail vẫn phải ghi lại đầy đủ** — nếu `POC-01` fail: bổ sung Kafka/MSK riêng cho hot-path
+đặt hàng (kiến trúc lai, theo điều kiện đã nêu ở `OPT §1`), **không** chuyển hẳn sang P1. Nếu
+`POC-02` fail: tách read replica/DB riêng cho Catalog/Search sớm hơn dự kiến, cập nhật `TCO`
+(chi phí hạ tầng P2 tăng, tiệm cận P1 cho phần đó — đã cảnh báo ở `TCO §3.3` cuối).
+
+## 7. Rủi ro đã đóng
+
+| ID | Rủi ro | Đóng ngày | Bằng chứng |
+|---|---|---|---|
+| *(chưa có — sổ mới lập)* | | | |
+
+## 8. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|
+| `OQ-013` | Xác nhận đơn giá AWS `ap-southeast-1` ước tính ở `TCO §3.1` (`ASM-11`) bằng AWS Pricing Calculator thật hoặc báo giá đại lý AWS tại VN — chênh lệch bao nhiêu so với ước tính? | Tech Lead/DevOps + tài chính | 2026-09-12 | Độ tin cậy `TCO` toàn bộ; ngân sách hạ tầng `INF` GĐ2 phải khớp (`D9`) |
+| `OQ-014` | Biểu phí giao dịch VNPay/Momo thật (theo % hay phí cố định) và GMV (tổng giá trị giao dịch) dự kiến năm 1 là bao nhiêu, để tính `NL-03` trong `TCO`? | PO/tài chính + đàm phán với VNPay/Momo | 2026-09-12 | `TCO §4` (hiện chưa tính được khoản này) |
+| `OQ-015` | Biểu phí API GHN/GHTK theo hợp đồng thật là bao nhiêu (`NL-05`)? | PM (đàm phán hợp đồng vận chuyển) | 2026-09-12 | `TCO §4`, `ARISK-04` |
+| `OQ-016` | Nhà cung cấp Email/SMS cụ thể (SES/SNS hay SendGrid/Twilio hay nhà cung cấp nội địa) là gì, biểu phí bao nhiêu (`NL-04`)? | PM/Tech Lead | 2026-09-12 | `TCO §4`, `ARISK-10`, `ICD` GĐ2 |
+| `OQ-017` | Báo giá pentest ứng dụng hàng năm + ASV scan hàng quý (phạm vi PCI-DSS SAQ A) từ nhà cung cấp thật là bao nhiêu (`NL-07`)? | PO/Security (khi có người) | 2026-09-12 | `TCO §4` |
+
+**Nhắc:** cùng với `OQ-005/006/007/008/010/011/012` (còn mở, xem `00-index/OQ_e-commerce.md`),
+năm câu hỏi mới ở trên hoàn thiện bức tranh input còn thiếu cho `TCO`/`ARISK`. Sau lượt này, GĐ1
+SA đã đủ 4 artifact (`CTX`/`OPT`/`TCO`/`ARISK`) để **audit AG1** — nhưng tự chấm cho thấy AG1
+**vẫn chưa đủ điều kiện ký chính thức** (xem Tự chấm ở cuối mỗi artifact); cần PO + Tech Lead xử
+lý các `OQ` chặn trước khi ký.
+
+---
+
+## Tự chấm
+
+### ① Bảng tự chấm Gate AG1 *(`workflow.md §2`, cập nhật cuối cùng của GĐ1)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | `CTX` có `DRV-nn` | ✅ | `CTX §2` |
+| 2 | `CTX` có `CON-nn` | ✅ *(với lưu ý)* | `CTX §3` |
+| 3 | `CTX` mô tả hiện trạng as-is | ✅ *(với lưu ý)* | `CTX §4` |
+| 4 | `OPT` có ≥2 phương án, chấm điểm, nêu phương án bị loại | ✅ | `OPT §4`/§5 |
+| 5 | `TCO` có chi phí 3 năm, ≥2 kịch bản tải | ✅ | `TCO_e-commerce_v1.0.md` toàn bộ |
+| 6 | `ARISK` có rủi ro cao kèm chủ + biện pháp | ✅ | §3 — `ARISK-01,02,03,05,06,07` mức 🔴, mỗi cái có chủ + biện pháp cụ thể (POC, đàm phán sandbox, chỉ định người rà soát pháp lý) — không có biện pháp "sẽ theo dõi" |
+| 7 | Rủi ro cao chưa chứng minh được có kế hoạch POC | ✅ | §6 — `POC-01` (SQS/EventBridge), `POC-02` (RDS gộp tải), mỗi cái có tiêu chí PASS/FAIL viết trước khi làm, thời lượng tối đa, ai làm, môi trường |
+
+**Kết luận tự chấm AG1 (toàn GĐ1):** **7/7 tiêu chí đủ về cấu trúc** — GĐ1 SA hoàn tất đủ 4
+artifact bắt buộc (`CTX`, `OPT`, `TCO`, `ARISK`) theo đúng `artifact-map.md`. **Vẫn chưa đủ điều
+kiện để PO + Tech Lead ký AG1 chính thức** vì: (a) BA chưa ký G1 thật cho `BRIEF_CartCheckout`
+(`OQ-001` còn mở); (b) nhiều con số nền (`CON-01/02/05`, đơn giá AWS, đội vận hành) vẫn ở mức
+🔴 giả định/tham khảo, chưa được PO/PM/Tech Lead xác nhận bằng số thật; (c) hai `POC` bắt buộc
+(`POC-01`, `POC-02`) **chưa chạy** — chỉ mới có kế hoạch. Khuyến nghị trình tự trước khi ký:
+(1) PO/PM trả lời `OQ-005` (ngân sách) và `OQ-008` (đội vận hành) bằng số thật; (2) Tech Lead trả
+lời `OQ-010` (năng lực team); (3) chạy `POC-01`/`POC-02`, cập nhật kết quả vào `ARISK §6`; (4) khi
+đó AG1 mới có đủ bằng chứng để ký thay vì "trông hợp lý" (đúng tinh thần `workflow.md §2`: *"Gate
+kiến trúc khác gate BA ở một điểm: không ký được bằng trông hợp lý"*).
+
+### ② Checklist D1–D12 *(`design-rules.md`)*
+
+| # | Mục | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| D1 | Một ADR một quyết định | N/A | Không có `ADR` trong tài liệu này |
+| D2 | Không NFR định tính | N/A | Không chứa `QAS` |
+| D3 | Nêu phương án bị loại + lý do | N/A | Không áp dụng cho sổ rủi ro (đã có ở `OPT §5`) |
+| D4 | Sơ đồ khai báo mức + legend | N/A | Không có sơ đồ mới |
+| D5 | Interface có chủ/contract | N/A | Chưa tới `ICD` |
+| D6 | Phụ thuộc ngoài process có timeout/retry | 🟡 Một phần | §3 `ARISK-03/04` kế thừa nguyên trạng timeout/retry đề xuất từ `SAD.md §3.4` (VNPay/Momo 10s, GHN/GHTK 8s) — chưa kiểm chứng sandbox thật, ghi rõ trạng thái |
+| D7 | Một chủ sở hữu dữ liệu | N/A | Chưa tới `DAT` |
+| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` |
+| D9 | Con số hạ tầng quy ra tiền + nguồn | N/A | Đã xử lý ở `TCO`; `ARISK` không lặp lại con số |
+| D10 | Không quyết định thay người có thẩm quyền | ✅ | Mọi rủi ro cần quyết định của PO/Security (ngân sách, chấp nhận rủi ro residency) đều ghi ở dạng `ARISK` + `OQ` kèm biện pháp đề xuất, không tự chấp nhận thay (§5 "Rủi ro đã chấp nhận" còn trống — đúng, vì chưa ai ký) |
+| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ *(tham chiếu)* | Không tạo `ASM` mới riêng — tham chiếu `ASM-04/07/08` (`CTX`/`OPT`) và `ASM-10…15` (`TCO`) theo đúng nguyên tắc "không copy, chỉ tham chiếu ID" (`artifact-map.md §7`); mục dữ liệu/migration ghi rõ N/A ở §4 (greenfield) |
+| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ☐ | *(Thiếu — sổ rủi ro dạng bảng, không có sơ đồ, nên không bắt buộc câu này; ghi nhận để nhất quán với các artifact khác nếu cần)* |
+
+### ③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì
+
+Xem bảng đầy đủ §8 (`OQ-013…017`, mới) cộng sổ `00-index/OQ_e-commerce.md` (`OQ-001, 003, 004,
+005, 006, 007, 008, 010, 012` còn mở). Hai câu chặn trực tiếp việc chạy `POC`: **`OQ-010`**
+(năng lực team — ảnh hưởng quyết định có cần `POC-01` hay không nếu team đã có kinh nghiệm) và
+**`OQ-012`** (đã đóng có điều kiện — POC phải chạy trước `ADR` message backbone GĐ2, xem `DEC-06`).
+
+**Nhắc cuối GĐ1:** AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header `OPT`, xem
+`workflow.md §2`) trước khi chạy `/sa-2-architecture`. Bốn điều kiện ra khỏi GĐ1 theo `GUIDE.md`:
+(1) bảng tự chấm AG1 toàn ✅ *(đạt về cấu trúc, chưa đạt về nội dung đã xác nhận)*; (2) PO **và**
+Tech Lead điền `Approved by` thật vào `OPT` *(chưa — vẫn là ký thay theo ngoại lệ)*; (3) mọi
+`ARISK` mức cao có chủ + biện pháp cụ thể *(đạt)*; (4) `POC-01`/`POC-02` đã **chạy xong**, kết quả
+ghi vào `ARISK` *(chưa — mới có kế hoạch)*. Còn thiếu (2) và (4) trước khi coi AG1 là qua thật.

sa-output/e-commerce/01-context/CTX_e-commerce_v1.0.md

@@ -0,0 +1,356 @@
+# CTX — Solution Context & Drivers — e-commerce
+
+| | |
+|---|---|
+| **Version** | 1.2 |
+| **Date** | 2026-09-12 |
+| **Author** | SA (skill sa-1-context, chế độ `go`, hoạt động `as-is`) |
+| **Status** | 🟡 Draft *(duyệt tạm/từng phần — xem `Approved by`; §2 Driver và §3 Ràng buộc/§5 Giả định đã duyệt tạm ở v1.0/v1.1; **§4 Hiện trạng (AS-IS) vừa bổ sung ở v1.2** theo ghi chú người duyệt — chưa được PO/Tech Lead ký riêng, sẽ ký cùng đợt AG1 toàn phần; Bước 4–5 (`OPT`/`TCO`/`ARISK`) vẫn chưa làm; AG1 toàn phần **chưa** đủ điều kiện, xem "Tự chấm" §① bên dưới, 3/7 tiêu chí ✅)* |
+| **Approved by** | PO (uỷ quyền, chế độ chạy thử): **Điều phối dự án** — duyệt **§2 Driver (`DRV-01`…`DRV-09`)** của bản v1.0 · 2026-09-12; và duyệt **§3 Ràng buộc (`CON-01`…`CON-09`) + §5 Giả định (`ASM-01`…`ASM-06`)** của bản v1.1 · 2026-09-12, cùng cách và cùng ngoại lệ như đã áp dụng cho §2. Ký thay PO theo mô hình ngoại lệ `DEC-01` (SA) / `DEC-01` (BA); **không phải chữ ký PO thật** — `OQ-004` giữ mở cho tới khi PO sàn thật xác nhận lại. `Confidence` của `CTX` giữ 🔴 cho tới khi BA ký G1 thật (không đổi bởi phê duyệt này — phê duyệt không phải bằng chứng nguồn mới, đặc biệt vì phần lớn `CON` neo theo hồ sơ thầu Draft chưa hợp đồng). Duyệt này vẫn là duyệt **từng phần**, không phải AG1 toàn phần. · Tech Lead: — *(chưa ký)* · **§4 Hiện trạng (AS-IS, v1.2) chưa được ai duyệt** — chờ cùng đợt duyệt AG1 toàn phần với Bước 4–5 |
+| **Source** | `ba-output/e-commerce/01-discovery/BRIEF_CartCheckout_v1.0.md` (Draft) · `ba-output/e-commerce/01-discovery/STAKEHOLDER_CartCheckout_v1.0.md` · `ba-output/e-commerce/01-discovery/RISK_CartCheckout_v1.0.md` · `ba-output/e-commerce/02-analysis/PROCESS_CartCheckout_v1.0.md` §0 (khẳng định greenfield, AS-IS rút gọn) · `ba-output/e-commerce/02-analysis/IMPACT_CartCheckout_v1.0.md` · `ba-output/e-commerce/00-index/PROFILE_e-commerce.md` (LIFECYCLE=greenfield) · `e-commerce/docs/SAD.md` v0.2 (§0–§3, §5.3.6, §8, §9.5.2) · `e-commerce/docs/00-project-brief.md` (v3) · `e-commerce/docs/sections/01-tong-quan.md` · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` · `e-commerce/docs/sections/03-kien-truc.md` §3.3–§3.4 (môi trường, tích hợp bên thứ ba) · `e-commerce/docs/sections/09-van-hanh-kiem-thu.md` §9.5.2 (RTO/RPO kế thừa) · `e-commerce/bid/bid-config.md` (Draft — hồ sơ thầu, chưa hợp đồng) · `e-commerce/bid/30-implementation-plan.md` (Draft) · `e-commerce/bid/estimate.computed.json` (Draft, `priceComplete: false`) |
+| **Scope** | Toàn sàn e-commerce (marketplace đa seller) theo `SAD.md` v0.2. Trọng tâm chi tiết nhất: module **Giỏ hàng & Checkout** (FR-05/06/07, US-002/003, RQ-001…004) — nguồn driver có Confidence cao nhất. Các module khác của sàn (Catalog, Seller/KYC, Commission & Payout, Loyalty, Notification…) suy driver từ `SAD.md`/`docs/sections/01,02` — chưa qua BRIEF/RISK cấp module riêng, Confidence thấp hơn. **Phạm vi hoạt động của lượt chạy này (v1.2): Bước 3 — Hiện trạng (AS-IS), §4**, tiếp nối Bước 1 (Driver, v1.0) và Bước 2 (Ràng buộc, v1.1) đã làm trước đó. Phương án (`OPT`)/Chi phí (`TCO`)/Rủi ro kiến trúc (`ARISK`) **vẫn chưa** thực hiện — xem §6 "Ngoài phạm vi". |
+| **Confidence** | 🔴 Giả định chưa xác minh — *(bắt buộc theo ghi chú điều phối: BA chưa ký G1 chính thức cho `BRIEF_CartCheckout` — Draft, `OQ-001`/`OQ-007` (BA) còn mở; đồng thời AG1 (gate của chính GĐ1 SA) chưa từng chạy cho dự án này. Mọi `DRV` suy ra từ nguồn Draft giữ mức 🔴 cho tới khi BA ký G1 thật. §3/§5 (v1.1) dùng nhiều số liệu từ hồ sơ thầu `e-commerce/bid/` — đây là ƯỚC LƯỢNG DỰ THẦU (Draft, `priceComplete: false`, chưa PO ký hợp đồng), KHÔNG phải ràng buộc cứng đã duyệt. §4 (v1.2, mới) có phần **khẳng định greenfield** đủ tin cậy 🟢 (nguồn `PROFILE_e-commerce.md` đã PO chốt 2026-09-08) nhưng phần **tài sản thiết kế `SAD.md`/hồ sơ thầu dùng làm điểm khởi đầu OPT** và **trạng thái đối tác tích hợp** vẫn 🔴 (chưa sandbox/hợp đồng thật với bất kỳ đối tác nào — kế thừa `CON-04`). Header giữ mức thấp nhất toàn tài liệu: 🔴, cho tới khi PO/PM/Tech Lead xác nhận bằng số/tài liệu thật.)* |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR/DEC |
+|---|---|---|---|---|
+| 1.0 | 2026-09-12 | SA (qua skill sa-1-context) | Bản đầu — chỉ hoạt động **Driver** (Bước 1/5 của `sa-1-context`), theo yêu cầu phạm vi hẹp của lượt chạy này. Ràng buộc/Hiện trạng/Giả định/`OPT`/`TCO`/`ARISK` để lượt sau. Chạy dưới ngoại lệ gate (BA chưa ký G1, AG1 của chính GĐ1 SA cũng chưa có tiền lệ) theo yêu cầu điều phối viên. | `DEC-01` (SA) |
+| 1.0 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **tạm/từng phần** §2 Driver (`DRV-01`…`DRV-09`) của bản v1.0. Không đổi nội dung chuyên môn. Ký thay PO theo ngoại lệ `DEC-01`; `OQ-004` (tính hợp lệ của ngoại lệ ký thay) **giữ mở**. `Confidence` giữ 🔴 (không nâng lên do phê duyệt này — phê duyệt không phải là bằng chứng mới về nguồn driver). Tech Lead **chưa ký** — theo "Tự chấm AG1" trong tài liệu, gate AG1 toàn phần (đủ 7 tiêu chí, cần cả PO + Tech Lead) **chưa đạt**; đây chỉ là ghi nhận đồng thuận tạm thời trên phần Driver để cho phép các bước sau của `sa-1-context` (Ràng buộc/Hiện trạng/Giả định/`OPT`/`TCO`/`ARISK`) tiếp tục dưới ngoại lệ đã có. Đồng thời, người dùng chốt hướng trả lời `OQ-002` (Bước 2 — ràng buộc Con người): dùng giả định "team MVP chuẩn" ở `Confidence` 🔴, ghi tại `DEC-02` (SA) và đóng `OQ-002` trong sổ `00-index/OQ_e-commerce.md` (giả định thật `ASM-nn` sẽ được lập khi `CON` Bước 2 chạy, tham chiếu `DEC-02`). | `DEC-01`, `DEC-02` (SA) |
+| 1.1 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `constraints`) | Bổ sung §3 Ràng buộc — đủ 6 nhóm (`CON-01` Tiền; `CON-02` Thời gian; `CON-03`/`CON-04` Công nghệ; `CON-05` Con người; `CON-06`/`CON-07` Pháp lý; `CON-08`/`CON-09` Tổ chức/Vận hành) và §5 Giả định (`ASM-01`…`ASM-06`), theo ghi chú người duyệt. Ngân sách/deadline tham khảo `e-commerce/bid/` (hồ sơ thầu ước lượng, **không phải hợp đồng** — nêu rõ độ tin cậy thấp, không coi là ràng buộc cứng khi chưa có PO xác nhận). Pháp lý bổ sung chi tiết PCI-DSS (SAQ A, không lưu thẻ), NĐ13/2023 (residency/retention/quyền xoá dữ liệu, theo `SAD.md` §5.3.6/§8.2.4), hoá đơn điện tử (đã xác nhận hoãn phase 2, không phải khoảng trống). Tiếp tục ngoại lệ gate `DEC-01` (BA chưa qua G1) — người dùng tái khẳng định muốn tiếp tục, ghi nhận thêm tại `DEC-03` (SA); `Confidence` giữ 🔴 toàn bộ tài liệu. Thêm `OQ-005`…`OQ-009` (ngân sách, deadline, đại diện Pháp chế cho residency, đội vận hành sau go-live, có neo theo `SAD.md`/hồ sơ thầu cho Bước 4 hay không) vào §7 và sổ `00-index/OQ_e-commerce.md`. Không sửa §2 Driver đã duyệt từng phần. | `DEC-01`, `DEC-03` (SA) |
+| 1.1 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **từng phần** §3 Ràng buộc (`CON-01`…`CON-09`) và §5 Giả định (`ASM-01`…`ASM-06`) của bản v1.1 — cùng cách ký thay PO theo ngoại lệ `DEC-01` (SA) đã dùng cho §2 Driver ở v1.0, **không phải chữ ký PO thật**. Không đổi nội dung chuyên môn. `OQ-004` (tính hợp lệ của ngoại lệ ký thay) giữ **mở**; Tech Lead **chưa ký**. `Confidence` giữ 🔴 (không nâng — phê duyệt không phải bằng chứng nguồn mới, và phần lớn `CON` vẫn neo theo hồ sơ thầu Draft/`priceComplete:false`, chưa PO xác nhận số thật). Status **giữ** 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện baseline (2/7 tiêu chí ✅, xem "Tự chấm" §①); §4 Hiện trạng và Bước 4–5 (`OPT`/`TCO`/`ARISK`) vẫn để lượt sau. | `DEC-01` (SA) |
+| 1.2 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `as-is`) | Bổ sung §4 Hiện trạng (AS-IS) theo ghi chú người duyệt — bốn phần: (a) khẳng định greenfield + hệ quả (không dữ liệu migrate, không baseline tải/KPI thật); (b) hệ sinh thái bên ngoài phải tích hợp và trạng thái từng đối tác (VNPay, Momo, GHN, GHTK, Email/SMS, hoá đơn điện tử — hoãn phase 2); (c) tài sản thiết kế đã có (`SAD.md` v0.2 approved + hồ sơ thầu) — ghi rõ đây là **thiết kế đề xuất chưa thi công**, dùng làm điểm khởi đầu cho một phương án `OPT` theo trả lời `OQ-009`; (d) kỹ năng/tài sản tổ chức đã biết (AWS bắt buộc `CON-03`, team giả định `DEC-02`). Đóng `OQ-009` (chấp nhận `SAD.md` làm điểm khởi đầu tham khảo cho Bước 4, không phải phương án đã thắng sẵn) — ghi `DEC-04` (SA); `OQ-005`/`OQ-006` **giữ mở**, bổ sung ghi chú "câu trả lời tạm" (dùng số hồ sơ thầu làm mốc tham khảo, chưa PO xác nhận số thật) tại §7 và sổ `00-index/OQ_e-commerce.md`. Không sửa §2 Driver, §3 Ràng buộc, §5 Giả định đã duyệt từng phần trước đó. Tiếp tục ngoại lệ gate `DEC-01`/`DEC-03` (BA chưa qua G1, AG1 chưa từng chạy) — người dùng tái khẳng định muốn tiếp tục; `Confidence` giữ 🔴 cho phần lớn nội dung mới, riêng khẳng định greenfield (a) đạt 🟢 vì có nguồn `PROFILE_e-commerce.md` đã PO chốt. | `DEC-04` (SA) |
+
+> Sơ đồ thắng về **quan hệ và luồng** (không có sơ đồ trong phần Driver của lượt chạy này).
+> Bảng/văn bản thắng về **ràng buộc và con số**. Mâu thuẫn ngoài hai loại này là lỗi tài liệu.
+
+---
+
+## 0. Ghi chú Preflight & ngoại lệ gate — bắt buộc đọc trước
+
+Đây là **GĐ1 đầu tiên của bộ SA** cho dự án e-commerce — không có gate SA nào trước nó
+(`sa-lifecycle/workflow.md §4` chỉ yêu cầu điều kiện *ngoài bộ*: BA đã qua **G1** với `BRIEF`,
+`GOAL`, `RQ`). Điều kiện đó **chưa đạt**:
+
+- `BRIEF_CartCheckout_v1.0.md` — Status `🟡 Draft`, tự chấm G1 = **chưa đủ điều kiện ký chính
+  thức** (3/6 tiêu chí ☐: tên thật stakeholder `OQ-001`, buổi làm việc trực tiếp `OQ-005`,
+  baseline KPI thật `OQ-007`).
+- Không có `BRIEF`/`RISK`/`STAKEHOLDER` cấp module cho các phần còn lại của sàn (Catalog,
+  Seller/KYC, Commission & Payout, Loyalty, Notification…) — driver các phần này chỉ suy được
+  từ `SAD.md` (đã "approved" ở cấp tài liệu BA nội bộ riêng, không đi qua pipeline `ba-*` module
+  hoá theo đúng quy trình).
+
+**Người dùng (vai điều phối dự án chạy thử) đã được cảnh báo và khẳng định lại muốn tiếp tục**,
+tham chiếu mô hình ngoại lệ đã dùng ở bộ BA (`DEC-02..07`, dự án e-commerce là dự án chạy thử,
+không có Designer, PO ký thay). Quyết định ngoại lệ này được ghi tại `DEC-01` (SA) —
+xem sổ `00-index/DEC_e-commerce.md` (sẽ đồng bộ khi chạy `/sa-lifecycle`).
+
+> **DEC-01 (SA)** — Chạy `sa-1-context` (hoạt động Driver) cho dự án e-commerce trong khi BA
+> chưa ký G1 chính thức và bản thân GĐ1 SA chưa có gate trước nó để chờ.
+> **Quyết định:** Tiếp tục, gắn `Confidence 🔴` cho toàn bộ `DRV` cho tới khi BA ký G1 thật.
+> **Người quyết:** Điều phối dự án (đại diện PO, theo ghi chú vận hành dự án chạy thử).
+> **Radar (ước lượng):** chi phí đảo ngược thấp (viết lại phần Driver mất < 1 tuần nếu BA đổi
+> phát biểu bài toán) · bán kính ảnh hưởng toàn bộ GĐ1 SA (một dự án) · không chạm trực tiếp một
+> `QAS` cụ thể (chưa có `QAS` vì đây là GĐ1) · không ràng buộc dài hạn (là ngoại lệ tạm thời,
+> không phải quyết định kiến trúc) · đã có tiền lệ ở bộ BA, ít tranh cãi. Tổng ước ~4 → **ghi
+> `DEC-nn`, không cần `ADR`** theo `decision-radar.md §1–§2`.
+> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng toàn bộ GĐ1 SA cho tới khi BA ký G1 thật (cần
+> tối thiểu: tên thật stakeholder, 1 buổi elicitation trực tiếp, baseline KPI đo được) — ước
+> chậm tiến độ chạy thử ít nhất bằng thời gian BA hoàn tất các mục đó (không có con số cụ thể vì
+> đây là dự án chạy thử không có lịch thật).
+
+---
+
+## 1. Tóm tắt cho người quyết định
+
+Sàn marketplace đa seller (e-commerce) cần kiến trúc chịu được quy mô "lớn" (hàng trăm nghìn
+SKU, hàng trăm nghìn–hàng triệu user, đỉnh hàng nghìn–chục nghìn concurrent user mùa flash sale)
+trong khi vẫn giữ đúng luồng giao dịch lõi (giỏ hàng đa seller → tách đơn → thanh toán) không
+mất tiền, không mất dữ liệu, và tách bạch dòng tiền giữa khách–sàn–seller. Áp lực lớn nhất
+không nằm ở tính năng mà ở: (1) luồng giao dịch lõi là blocker của toàn bộ MVP, (2) đỉnh tải
+flash sale, (3) tuân thủ pháp lý (PCI-DSS, NĐ13/2023) khi xử lý tiền và PII của hai loại chủ
+thể (khách hàng và seller). Tài liệu này **chỉ chốt phần Driver** (`DRV-nn`) của GĐ1; Ràng buộc,
+hiện trạng, phương án, chi phí và rủi ro sẽ chạy ở các lượt kế tiếp — xem `Ngoài phạm vi`.
+
+---
+
+## 2. Driver — `DRV-nn`
+
+*Áp lực kinh doanh ép ra kiến trúc, không phải tính năng. Ưu tiên nguồn: `BRIEF_CartCheckout`
+(GOAL-01/02, RQ-001…004) cho module Giỏ hàng & Checkout; `SAD.md` v0.2 §1–§2 (FR-01…27,
+NFR-01…08) cho các module còn lại của sàn — Confidence thấp hơn vì chưa qua BRIEF module hoá.*
+
+| ID | Áp lực (định lượng) | Nguồn | Ai xác nhận · ngày | Thuộc tính chất lượng bị ép | Ưu tiên |
+|---|---|---|---|---|---|
+| `DRV-01` | Chưa có luồng giỏ hàng–checkout–thanh toán đa seller hoạt động ⇒ sàn **không thể ra mắt MVP**: 0 giao dịch ghi nhận được, seller không nhận được đơn, mọi module phụ thuộc (quản lý đơn hàng, hoa hồng, payout, đánh giá) bị **chặn hoàn toàn** — đây là blocker, không phải cải tiến. | `BRIEF_CartCheckout` §3 "Điều gì xảy ra nếu không làm gì cả" · §5.1 RQ-001…004 (Must) | STK-01 (PO sàn) qua `00-project-brief.md` vòng 1 — **chưa có tên thật**, `OQ-001` (BA) còn mở | Tính đúng đắn giao dịch · tính nhất quán dữ liệu qua nhiều seller · thông lượng | Must |
+| `DRV-02` | Giỏ hàng ≥2 seller có nguy cơ tỷ lệ bỏ giỏ ở bước checkout cao hơn giỏ 1 seller (phí ship tính riêng theo từng seller, `RISK-04` mức 🟠). `GOAL-01` đề xuất ngưỡng chấp nhận ≤ (tỷ lệ bỏ giỏ 1 seller) + 10 điểm phần trăm — **baseline thật chưa có** (greenfield, `OQ-007` BA còn mở). | `BRIEF_CartCheckout` §4 GOAL-01 · `RISK_CartCheckout` RISK-04 | STK-01 (PO sàn) — đề xuất đo baseline 4–6 tuần đầu soft-launch, **chưa xác nhận số thật** | Độ trễ hiển thị phí ship theo seller · trải nghiệm nhất quán khi tách đơn | Must (gắn RQ-001/002 Must) |
+| `DRV-03` | Thanh toán phải chấp nhận VNPay/Momo/COD **không lưu thông tin thẻ** để giảm phạm vi tuân thủ PCI-DSS — nếu tự lưu/xử lý thẻ, phạm vi kiểm toán PCI-DSS đầy đủ (thay vì rút gọn qua bên thứ ba) kéo theo chi phí tuân thủ và rủi ro pháp lý cao hơn đáng kể (con số tuân thủ cụ thể chưa có — cần Legal, xem `OQ` mới ở §7). | `BRIEF_CartCheckout` §5.1 RQ-003 · `docs/sections/01-tong-quan.md` §1.5 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-05 | 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 | Bảo mật/tuân thủ (ranh giới phạm vi PCI-DSS) | Must |
+| `DRV-04` | Quy mô mục tiêu "lớn": hàng trăm nghìn SKU trở lên, hàng trăm nghìn–hàng triệu user đăng ký, đỉnh **hàng nghìn–chục nghìn concurrent user** mùa flash sale. Không scale-out ngay từ đầu ⇒ hệ thống có nguy cơ sập đúng lúc doanh thu cao nhất trong năm (flash sale). | `00-project-brief.md` mục 3 (Q&A vòng 1) · `docs/sections/02-phan-tich-yeu-cau.md` NFR-02 | STK-01 (PO sàn) qua vòng 1 brief — **chưa có tên thật, chưa có số đo thật** (dự án chưa vận hành, đây là mục tiêu quy mô đã "chốt" ở mức mô tả định tính "lớn", không phải SLA hợp đồng) | Khả năng mở rộng (scale-out) · thông lượng · độ trễ dưới tải đỉnh | Must |
+| `DRV-05` | Uptime mục tiêu 99.9% cho dịch vụ giao dịch lõi (catalog, checkout, thanh toán) vì doanh thu phụ thuộc trực tiếp; escalation 24/7 cho sự cố nghiêm trọng. 99.9%/tháng ⇒ ngân sách lỗi ≈ 43 phút/tháng — vượt ngân sách này ở đúng dịch vụ giao dịch nghĩa là mất doanh thu trực tiếp trong khung giờ đó. | `docs/sections/02-phan-tich-yeu-cau.md` NFR-03, NFR-08 · `00-project-brief.md` mục 5 giả định #6 | STK-01 (PO sàn) — 🔴 **đây là "giả định mặc định đã chốt trong brief", CHƯA phải SLA hợp đồng thật** (ghi rõ trong `docs/sections/02-phan-tich-yeu-cau.md` cuối §2.2) | Sẵn sàng (availability) · khả năng phục hồi | Must |
+| `DRV-06` | Dòng tiền phải minh bạch giữa 3 bên (khách–sàn–seller): hoa hồng tính theo ngành hàng (cấu hình được), payout hàng tuần qua chuyển khoản có kỳ giữ tiền (hold) 3–7 ngày sau giao hàng thành công. Sai lệch đối soát phát sinh từ tầng giao dịch (checkout/payment) sẽ lan sang toàn bộ hệ thống payout/commission — ở quy mô "lớn" (hàng trăm nghìn giao dịch), một lỗi hệ thống nhỏ nhân lên thành tranh chấp tài chính hàng loạt. | `docs/sections/01-tong-quan.md` §1.1 · `00-project-brief.md` mục 2 & mục 5 (giả định #3) · `docs/sections/02-phan-tich-yeu-cau.md` FR-17/FR-21/FR-22 | STK-01 (PO sàn), STK-04 (Kế toán đối soát — vai trò, chưa tên thật) | Tính nhất quán dữ liệu tài chính · khả năng kiểm toán (audit) · ranh giới sở hữu dữ liệu | Must |
+| `DRV-07` | Chia sẻ PII (địa chỉ giao hàng, số điện thoại người nhận) cho từng seller khi tách đơn theo seller **chưa được rà soát** theo Nghị định 13/2023 vì dự án chưa có đại diện Pháp chế/Bảo mật được chỉ định. Rủi ro tương ứng đã được BA ghi nhận mức **Cao/Trung bình** (`RISK-03`). | `RISK_CartCheckout_v1.0.md` RISK-03 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-04, NFR-05 | *(Chưa có người — `OQ-003` BA còn mở)* | Bảo mật/quyền riêng tư · phân loại dữ liệu nhạy cảm | Must |
+| `DRV-08` | Xác nhận thanh toán qua webhook VNPay/Momo (bên thứ ba) **chưa được xác minh khả thi gần thời gian thực** (`ASM-01`, chưa xác minh). Nếu webhook trễ/lỗi, đơn hàng kẹt "chờ thanh toán" dù tiền đã thu ⇒ khiếu nại CSKH + sai lệch đối soát (`RISK-02`, tác động Cao, khả năng Trung bình). | `RISK_CartCheckout_v1.0.md` RISK-02, ASM-01 · `IMPACT_CartCheckout_v1.0.md` §1.5 | STK-06 (Tech Lead) + STK-01 (PO sàn) — chưa xác nhận khả thi thật (cần đọc tài liệu/gọi sandbox VNPay/Momo) | Tính nhất quán (eventual) · khả năng đối soát bù · quan sát được (observability) | Must |
+| `DRV-09` | Đa ngôn ngữ 5 thứ tiếng (VI mặc định/EN/ZH/KO/JA) để mở rộng tệp khách hàng mục tiêu ra ngoài thị trường Việt Nam thuần tuý — Should, không chặn MVP nếu thiếu, nhưng thiếu thì giới hạn khả năng tiếp cận thị trường theo đúng mô hình kinh doanh đã chốt (marketplace quy mô lớn). | `docs/sections/01-tong-quan.md` §1.1 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-06 | STK-01 (PO sàn) qua vòng 3 brief — chưa tên thật | Khả năng bảo trì (kiến trúc i18n/l10n tách nội dung khỏi code) | Should |
+
+**Ghi chú Confidence theo dòng:** `DRV-01, 02, 03, 07, 08` có nguồn trực tiếp từ `BRIEF/RISK/
+IMPACT` cấp module Giỏ hàng & Checkout (dù bản thân các tài liệu đó còn Draft) — Confidence
+🔴 hiện tại chỉ vì BA chưa ký G1, **không phải vì thiếu nguồn**. `DRV-04, 05, 06, 09` chỉ có
+nguồn từ `SAD.md`/`docs/sections` (chưa qua BRIEF/RISK module hoá riêng cho các phần đó của sàn)
+— Confidence 🔴 vì **cả hai lý do**: chưa qua G1 và chưa có phân tích module hoá cấp BA. Ghi rõ
+để người ký AG1 sau này biết mức độ rủi ro khác nhau giữa các dòng.
+
+### 2.1 Định hướng khách gợi ý *(tham khảo, KHÔNG phải driver)*
+
+| Khách/tài liệu nói | Đây là giải pháp cho vấn đề gì | Đã hỏi ngược chưa | `DRV` thật rút ra được |
+|---|---|---|---|
+| "Kiến trúc cần cache (Redis), CDN, message queue (Kafka/RabbitMQ), scale-out ngang ngay từ đầu" (`00-project-brief.md` mục 2 "NFR tiêu biểu"; lặp lại ở NFR-02) | Giải pháp cho vấn đề chịu tải đỉnh mùa flash sale — nhưng câu này tự nó không định lượng được tải đỉnh | ☐ Chưa hỏi trực tiếp PO/Tech Lead; suy luận qua con số ở NFR-02 ("hàng nghìn–chục nghìn concurrent user") | `DRV-04` — công nghệ cụ thể (Redis/Kafka/RabbitMQ) là đề xuất, **không phải ràng buộc bắt buộc**; việc chọn công nghệ nào thuộc Bước 4 (Phương án) của GĐ1, chưa làm ở lượt này |
+| "Kiến trúc module hoá để các nhóm (catalog, order, seller, payment) phát triển độc lập" (NFR-07) | Giải pháp cho vấn đề đội ngũ chờ nhau khi release (Conway) — nhưng **số đội/số người CHƯA có** | ☐ Chưa hỏi — đây là câu hỏi thuộc nhóm ràng buộc "Con người" (Bước 2, ngoài phạm vi lượt chạy này) | Chưa rút ra được driver cụ thể — ghi `OQ-002` (SA) ở §7 |
+| "Tech stack không bắt buộc, kiến trúc sư tự đề xuất theo best practice cho quy mô lớn; cloud = AWS" (`00-project-brief.md` mục 2 & 5) | Đây là **ràng buộc** (`CON`), không phải driver — AWS đã được xác nhận là bắt buộc (cứng) | N/A — không phải driver | Sẽ thành `CON-nn` (nhóm Công nghệ) khi chạy Bước 2 — ngoài phạm vi lượt này |
+
+---
+
+## 3. Ràng buộc — `CON-nn`
+
+*Thứ KHÔNG thương lượng được — sở thích không phải ràng buộc. Rà đủ sáu nhóm theo
+`sa-1-context/SKILL.md` Bước 2. Ngân sách/deadline dưới đây tham khảo `e-commerce/bid/`
+(`bid-config.md`, `30-implementation-plan.md`, `estimate.computed.json`) — đây là **hồ sơ thầu
+ước lượng của nhà thầu, Status `draft`, `cost.priceComplete=false`, KHÔNG phải hợp đồng đã ký**.
+Dùng làm điểm tham khảo duy nhất hiện có, ghi rõ độ tin cậy 🔴, KHÔNG coi là ràng buộc cứng cho
+tới khi PO xác nhận bằng số thật — theo đúng ghi chú người duyệt.*
+
+| ID | Nhóm | Ràng buộc | Nguồn (ai · ngày) | Cứng/Mềm | Hệ quả kiến trúc |
+|---|---|---|---|---|---|
+| `CON-01` | Tiền | Ngân sách hạ tầng/tháng và chi phí một lần **CHƯA được PO duyệt chính thức** (`00-project-brief.md` mục 6: "ngân sách/timeline chưa xác định"; mục 5 giả định: "ngân sách theo business case"). Tham khảo duy nhất hiện có: hồ sơ thầu ước lượng — lao động ≈ 3.420.500.000 VND (chưa VAT) + VAT 10% (342.050.000 VND) = **≈ 3.762.550.000 VND** cho 53,02 người-tháng/7 tháng thực hiện (`estimate.computed.json` → `cost.subtotal/vat/total`); **8 khoản chi phí không lao động** (hạ tầng AWS 3 môi trường, OpenSearch cluster, phí giao dịch VNPay/Momo, phí Email/SMS, phí API GHN/GHTK, domain/SSL/WAF, pentest/ASV hàng năm, đào tạo) đều `amount: null` — **chưa có số**, kể cả trong chính hồ sơ thầu. | `00-project-brief.md` mục 6 · `e-commerce/bid/estimate.computed.json` `cost` (Draft, chưa PO xác nhận) | **Chưa xác định cứng/mềm** — không có ngân sách nào được PO duyệt để đối chiếu | Không thể chấm điểm `TCO` (Bước 5, ngoài phạm vi lượt này) một cách có ý nghĩa cho tới khi có số ngân sách thật — xem `OQ-005` |
+| `CON-02` | Thời gian | Không có deadline hợp đồng/pháp lý bên ngoài được xác nhận (`bid-config.projectDeadline`/`submissionDeadline` rỗng; `estimate.computed.json` → `timeline.deadlineFit.fits = null`). **Hai con số tham khảo KHÔNG khớp nhau:** brief giả định định tính "~9-12 tháng" (mục 5, giả định cuối) vs hồ sơ thầu tính toán "7 tháng thực hiện" (`timeline.durationMonths=7`, teamSize trung bình 9, đỉnh điểm 10 người) + 12 tháng bảo hành sau đó (`bid-config.warrantyMonths=12`). | `00-project-brief.md` mục 5, giả định #7 · `e-commerce/bid/estimate.computed.json` `timeline` · `e-commerce/bid/30-implementation-plan.md` §B7.1, §B7.5 | Mềm (chưa có ràng buộc cứng nào được xác nhận bằng văn bản) | `OPT` Bước 4 (ngoài phạm vi lượt này) phải trình ≥2 kịch bản thời gian (7 tháng "đẩy nhanh" theo bid vs 9-12 tháng "chuẩn" theo brief) thay vì giả định một mốc duy nhất — xem `OQ-006` |
+| `CON-03` | Công nghệ | Cloud **AWS bắt buộc** — đã xác nhận tại vòng 3 Q&A của brief, không phải sở thích của kiến trúc sư | `00-project-brief.md` mục 5 (Q&A vòng 3: "cloud AWS") · `docs/sections/01-tong-quan.md` §1.5 | **Cứng** | Loại mọi phương án dùng cloud khác/on-prem ngay từ Bước 4 (`OPT`) |
+| `CON-04` | Công nghệ | Đối tác thanh toán **VNPay + Momo + COD**, đối tác vận chuyển **GHN + GHTK** đã xác nhận làm mặc định tích hợp (không phải "chờ chọn tuỳ ý") — nhưng dự án **chưa có tài liệu API/tài khoản sandbox thật** với bất kỳ đối tác nào trong bốn đối tác này | `00-project-brief.md` mục 1 vòng 1 & mục 4 vòng 1 | Cứng (danh tính đối tác đã chốt) / Mềm (thời điểm có sandbox/hợp đồng thật — phụ thuộc bên ngoài) | Thiết kế tích hợp (`ICD`, GĐ2) phải giả định theo tài liệu công khai của 4 đối tác này cho tới khi có sandbox thật xác nhận (kế thừa `ASM-01`/`ASM-02` của BA ở `RISK_CartCheckout_v1.0.md` §1, §3) |
+| `CON-05` | Con người | Số đội/số người/kỹ năng team thi công + đội vận hành sau go-live **CHƯA được PM/Tech Lead xác nhận số thật** — hiện dùng giả định tạm "team MVP chuẩn" theo `DEC-02` (SA, 🔴). Tham khảo duy nhất: hồ sơ thầu ước lượng teamSize trung bình **9 vị trí đồng thời**, đỉnh điểm **10 đầu người**, 8 vai trò (PM/BA/SA/UIUX/BE/FE/QA/DEVOPS) — đây là cách tổ chức nhân sự **do nhà thầu đề xuất cho hồ sơ thầu của chính họ**, không phải đội hình mà PO/chủ dự án đã cam kết tuyển/thuê nội bộ; toàn bộ tên/CV nhân sự trong hồ sơ thầu vẫn là `[[CẦN ĐIỀN]]` | `DEC-02` (SA) · `e-commerce/bid/30-implementation-plan.md` §B8.2 (tên/CV `[[CẦN ĐIỀN]]`), §B8.3 (đơn vị FTE, không phải cam kết nhân sự) | Chưa xác định — chỉ là số liệu tham khảo, không có giá trị ràng buộc | Ranh giới service ở `SAD` (GĐ2) không nên chốt cứng theo số liệu này cho tới khi có số team thật — xem `OQ-002` (mở từ v1.0) và `OQ-008` (mới, riêng phần đội vận hành sau go-live) |
+| `CON-06` | Pháp lý | Bắt buộc tuân thủ: **NĐ52/2013 + NĐ85/2021** (thông báo website TMĐT dạng sàn giao dịch với Bộ Công Thương), **NĐ13/2023** (bảo vệ dữ liệu cá nhân — cả PII khách hàng lẫn giấy tờ KYC seller), **PCI-DSS phạm vi thu hẹp** (SAQ A — không lưu thông tin thẻ, giao VNPay/Momo xử lý, cô lập trong một Payment Service duy nhất theo `SAD.md` §3.1) | `docs/sections/01-tong-quan.md` §1.5 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-05 · `SAD.md` §3.1, §8 (§8.4 pentest/ASV cho SAQ A) | **Cứng** (pháp luật, không thương lượng được) | Payment Service phải là biên cô lập duy nhất chạm dữ liệu thẻ (đã phản ánh trong `SAD.md`, GĐ2 SA kế thừa nguyên trạng, không thiết kế lại); mọi luồng chia sẻ địa chỉ/SĐT cho seller khi tách đơn phải qua rà soát Pháp chế trước go-live — **chưa có người rà soát** (kế thừa `RISK-03`/`OQ-003` của BA) |
+| `CON-07` | Pháp lý | Hoá đơn điện tử cho seller **đã xác nhận hoãn sang phase 2** (không thuộc MVP) — đây là **quyết định kinh doanh đã chốt**, không phải khoảng trống thông tin | `00-project-brief.md` mục 2, dòng "Hoá đơn điện tử cho seller — hoãn sang giai đoạn sau, đã xác nhận (vòng 3)" | Cứng (phạm vi đã chốt cho MVP) | Không thiết kế module hoá đơn điện tử ở GĐ2 MVP; ghi vào §6 "Ngoài phạm vi" và để cho `TRM` (GĐ4) khi có phase sau — xem `ASM-06` |
+| `CON-08` | Tổ chức/Vận hành | Đội vận hành (Ops) trực theo ca giờ hành chính + escalation 24/7 cho sự cố nghiêm trọng (do doanh thu phụ thuộc hệ thống) — hiện là **giả định mặc định đã chốt trong brief**, CHƯA xác nhận đội ops là nội bộ PO hay thuê ngoài, quy mô bao nhiêu người | `00-project-brief.md` §5, giả định cuối ("Vận hành: … đội ops trực theo ca…") · `docs/sections/02-phan-tich-yeu-cau.md` NFR-08 | Mềm (giả định, chưa xác nhận thật) | Thiết kế on-call/`INF` ở GĐ2 phải giả định một mô hình vận hành cụ thể cho tới khi có xác nhận thật — xem `OQ-008` |
+| `CON-09` | Tổ chức/Vận hành | Bảo hành 12 tháng sau nghiệm thu tổng thể (`bid-config.warrantyMonths=12`) là điều khoản **đề xuất của nhà thầu trong hồ sơ thầu**, chưa phải điều khoản hợp đồng đã ký; mô hình bàn giao vận hành lâu dài cho PO sau khi hết bảo hành (ai tiếp nhận, có chuyển giao kiến thức không) **chưa được mô tả ở đâu** | `e-commerce/bid/bid-config.md` (`warrantyMonths: 12`) · `e-commerce/bid/30-implementation-plan.md` §B7.2 Giai đoạn 7 | Mềm (đề xuất, chưa ký hợp đồng) | `AGD`/`DREV` ở GĐ3 (ngoài phạm vi lượt này) cần biết ai là đội vận hành lâu dài để viết guideline đúng đối tượng — ghi nhận sớm, không quyết thay PM/PO |
+
+**Cứng** = vi phạm thì dự án bị chặn (pháp luật, cloud bắt buộc). **Mềm** = đổi được nhưng tốn
+tiền/thời gian — ở đây phần lớn còn ghi "Mềm/Chưa xác định" vì các nguồn duy nhất hiện có
+(brief giả định, hồ sơ thầu ước lượng) chưa được PO/PM/Tech Lead xác nhận là ràng buộc thật.
+
+### 3.1 Nhóm ràng buộc chưa có thông tin (còn cần xác nhận thật)
+
+| Nhóm | Ai phải trả lời | Đã hỏi ngày | `OQ` | Chặn gì |
+|---|---|---|---|---|
+| Tiền (số ngân sách thật, không phải ước lượng thầu) | PO / tài chính | 2026-09-12 (qua tài liệu, chưa phải buổi hỏi trực tiếp) | `OQ-005` | `CON-01` (cứng/mềm), `TCO` Bước 5 |
+| Thời gian (deadline thật, nếu có) | PO / PM | 2026-09-12 | `OQ-006` | `CON-02`, kịch bản thời gian ở `OPT` Bước 4 |
+| Con người (đội vận hành sau go-live: nội bộ hay thuê ngoài, quy mô) | PM / SRE | 2026-09-12 | `OQ-008` | `CON-05`, `CON-08`, thiết kế `INF`/on-call GĐ2 |
+| Pháp lý (đại diện Pháp chế/Bảo mật xác nhận yêu cầu residency theo NĐ13/2023) | Legal / Security | 2026-09-12 (kế thừa `OQ-003` của BA, vẫn chưa có người) | `OQ-007` | `CON-06`, `ASM-04`, ranh giới hạ tầng dữ liệu ở `DAT`/`INF` GĐ2 |
+
+## 4. Hiện trạng (AS-IS)
+
+*Bước 3 của `sa-1-context`, chạy ở lượt này (hoạt động `as-is`). Dự án e-commerce là
+**greenfield** — không có hệ thống/dữ liệu cũ để khảo sát trực tiếp theo bốn mục
+`GUIDE.md` (hệ thống/dữ liệu/tích hợp/vận hành). Theo `SKILL.md` §Bước 3 và
+`artifact-map.md` §7 (loại LIFECYCLE=greenfield ⇒ rút gọn CTX phần as-is), "hiện trạng" ở đây
+gồm bốn phần: (a) khẳng định greenfield + hệ quả, (b) hệ sinh thái bên ngoài bắt buộc tích hợp
+(đây là "as-is" thật duy nhất của một dự án greenfield — các đối tác đã tồn tại và có ràng buộc
+kỹ thuật/pháp lý riêng của họ), (c) tài sản thiết kế nội bộ đã có (`SAD.md`/hồ sơ thầu), (d)
+kỹ năng/tài sản tổ chức đã biết.*
+
+### 4.1 Khẳng định greenfield và hệ quả
+
+**Khẳng định:** Dự án e-commerce là hệ thống **mới hoàn toàn** — không có hệ thống, cơ sở dữ
+liệu, hay quy trình thủ công nào đang chạy để thay thế/tích hợp cho lõi giao dịch (giỏ hàng →
+checkout → thanh toán → tách đơn theo seller → vận chuyển → hoa hồng/payout). Nguồn:
+`PROFILE_e-commerce.md` (`LIFECYCLE: greenfield`, PO chốt 2026-09-08) · `PROCESS_CartCheckout_v1.0.md`
+§0 ("dự án là marketplace hoàn toàn mới, không có hệ thống hay quy trình thủ công… 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").
+
+| # | Hệ quả của greenfield | Diễn giải cho GĐ1/GĐ2 SA | Nguồn |
+|---|---|---|---|
+| 1 | **Không có dữ liệu để migrate** | `OPT` (Bước 4) không cần kịch bản migration/rollback dữ liệu cũ, khác dự án loại 3 (migration) theo `SKILL.md` Bước 0.2; `DAT` ở GĐ2 thiết kế mô hình dữ liệu từ đầu, không cần ánh xạ từ schema cũ | `PROFILE_e-commerce.md`; `workflow.md §5` (bảng phân loại dự án) |
+| 2 | **Không có baseline tải/KPI đo được thật** | Mọi con số trong `DRV-02` (tỷ lệ bỏ giỏ ≤ baseline 1-seller + 10 điểm %), `DRV-04` (đỉnh "hàng nghìn–chục nghìn concurrent user"), `DRV-05` (uptime 99.9%) là **mục tiêu/giả định đã chốt trong brief**, KHÔNG phải số đo từ hệ thống đang chạy — xác nhận lại điều đã ghi ở các dòng `DRV` tương ứng (§2), không đổi nội dung `DRV` | `BRIEF_CartCheckout` §4 GOAL-01; `docs/sections/02-phan-tich-yeu-cau.md` NFR-02/03; `00-project-brief.md` §5 giả định #6 |
+| 3 | **Không có nợ kỹ thuật/hệ thống legacy** | GĐ2 (`SAD`/`ADR`) không cần rà soát tương thích ngược hay "strangler pattern"; toàn bộ ranh giới service trong `SAD.md` §3.1 có thể thiết kế theo domain lý tưởng, không bị ràng buộc bởi cấu trúc code cũ | `SAD.md` §3.1 |
+| 4 | **Không có người dùng/seller thật đang hoạt động cần continuity** | Không cần chiến lược cutover zero-downtime từ hệ thống cũ sang mới khi go-live; rủi ro go-live là "ra mắt lần đầu" (chưa từng có traffic thật để so sánh), không phải "chuyển đổi không được gián đoạn" | `PROFILE_e-commerce.md`; `PROCESS_CartCheckout_v1.0.md` §0 |
+
+🔴 **Hệ quả ngược nếu khẳng định greenfield sai** (VD phát hiện có một hệ thống nội bộ cũ dùng
+tạm cho vận hành thủ công mà brief chưa nhắc tới): phải chạy lại Bước 3 đầy đủ theo bốn mục
+`GUIDE.md` (hệ thống/dữ liệu/tích hợp/vận hành cũ), và `DRV-01` (blocker MVP) có thể phải viết
+lại vì đã có một phần luồng đang chạy thủ công — chưa có dấu hiệu này trong mọi tài liệu đã đọc.
+
+### 4.2 Hệ sinh thái bên ngoài phải tích hợp — trạng thái từng đối tác
+
+*Đây là "hiện trạng" thật của một dự án greenfield: các đối tác này đã tồn tại độc lập với dự
+án, có ràng buộc kỹ thuật/hợp đồng riêng của họ mà SA phải khảo sát trước khi thiết kế `ICD`
+(GĐ2). Cột "Trạng thái sẵn sàng" đối chiếu với `CON-04` (§3) — dự án **chưa có** tài liệu API
+sandbox/tài khoản thật với bất kỳ đối tác nào dưới đây.*
+
+| Đối tác | Vai trò trong luồng nghiệp vụ | Giao thức đề xuất (`SAD.md` §3.4) | Trạng thái sẵn sàng thật (khảo sát) | Nguồn |
+|---|---|---|---|---|
+| **VNPay** | Cổng thanh toán online (redirect + IPN callback xác nhận giao dịch), không lưu thẻ | REST/HTTPS, timeout 10s, retry callback idempotent ≤3 lần | 🔴 Chưa có tài khoản sandbox/hợp đồng — thiết kế timeout/retry ở `SAD.md` §3.4 là **đề xuất chưa xác minh với sandbox thật** (kế thừa `ASM-01`/`ASM-02` của BA, `DRV-08`) | `SAD.md` §3.4; `CON-04`; `RISK_CartCheckout` ASM-01 |
+| **Momo** | Cổng thanh toán online (redirect + IPN), không lưu thẻ | REST/HTTPS, timeout 10s, retry callback idempotent ≤3 lần | 🔴 Chưa có tài khoản sandbox/hợp đồng — tương tự VNPay | `SAD.md` §3.4; `CON-04` |
+| **COD** | Thu tiền mặt khi giao — không phải API bên ngoài, là luồng nghiệp vụ nội bộ xác nhận qua đơn vị vận chuyển | Không áp dụng (không phải tích hợp API) | 🟢 Không phụ thuộc đối tác công nghệ — phụ thuộc quy trình xác nhận thủ công của GHN/GHTK/Ops | `SAD.md` §3.4 |
+| **GHN** | Vận chuyển: tạo vận đơn, tra cứu trạng thái, webhook cập nhật | REST/HTTPS, timeout 8s, retry ≤3 lần, webhook idempotent | 🔴 Chưa có tài liệu API/sandbox thật — `SAD.md` §3.4 đề xuất fallback chéo sang GHTK khi GHN lỗi, **chưa kiểm chứng** khả năng fallback này có hoạt động đúng giữa hai API khác nhau trong thực tế | `SAD.md` §3.4; `CON-04` |
+| **GHTK** | Vận chuyển (tương tự GHN), fallback chéo cho GHN | REST/HTTPS, timeout 8s, retry ≤3 lần | 🔴 Chưa có tài liệu API/sandbox thật — tương tự GHN | `SAD.md` §3.4; `CON-04` |
+| **Email/SMS Provider** | Thông báo đơn hàng/giao hàng, nội dung đa ngôn ngữ | REST/HTTPS hoặc SDK qua queue, timeout 5s, retry ≤5 lần backoff | 🔴🔴 **Nhà cung cấp cụ thể CHƯA CHỐT** (SAD.md §3.4 tự ghi "đề xuất: SES/SNS hoặc SendGrid/Twilio — nhà cung cấp cụ thể chưa chốt, xem giả định") — mức độ chưa sẵn sàng cao hơn VNPay/Momo/GHN/GHTK vì còn chưa chọn đối tác, chưa dừng ở "chưa có sandbox" | `SAD.md` §3.4 |
+| **Ngân hàng (payout)** | Chuyển khoản hoa hồng/payout hàng tuần cho seller | Batch file chuẩn ngân hàng (VD NAPAS) hoặc API — *ngân hàng cụ thể chưa chốt* | 🔴🔴 Chưa chọn ngân hàng đối tác, chưa có định dạng batch xác nhận | `SAD.md` §3.4 |
+| **Google/Facebook OAuth** | Đăng nhập mạng xã hội (Should, không chặn MVP vì email/password vẫn hoạt động độc lập) | OAuth 2.0/OIDC redirect flow, timeout 10s | 🟡 Chuẩn mở, không cần hợp đồng riêng như các đối tác thương mại ở trên, nhưng vẫn chưa có app/client ID thật được đăng ký | `SAD.md` §3.4 |
+| **Hoá đơn điện tử cho seller** | Xuất hoá đơn điện tử tự động khi seller phát sinh doanh thu | *(không thiết kế ở MVP)* | ⏸️ **Hoãn sang phase 2 — đã xác nhận (vòng 3 brief), không phải khoảng trống thông tin.** Không phải rủi ro tích hợp of MVP; ghi nhận cho `TRM` (GĐ4) khi có phase sau | `00-project-brief.md` dòng "Ngoài phạm vi MVP… hoá đơn điện tử tự động cho seller"; `CON-07` |
+
+**Đọc bảng:** 🔴 = chưa sandbox/hợp đồng thật nhưng đối tác đã xác định danh tính (kế thừa từ
+Bước 1/2). 🔴🔴 = chưa cả chọn đối tác cụ thể (mức chưa sẵn sàng cao hơn). 🟡 = chuẩn mở, ít rủi
+ro hơn. 🟢 = không phụ thuộc đối tác công nghệ bên ngoài. ⏸️ = ngoài phạm vi MVP theo quyết định
+kinh doanh đã chốt, không phải rủi ro.
+
+Hệ quả cho GĐ2: `ICD` không thể chốt contract thật (owner, SLA, mã lỗi cụ thể) cho VNPay/Momo/
+GHN/GHTK/Email-SMS cho tới khi có tài liệu/sandbox thật — GĐ2 sẽ phải thiết kế theo tài liệu
+công khai của đối tác và đánh dấu `Confidence` 🔴 cho các `IF-nnn` tương ứng, kế thừa `ASM-01`
+(BA) và `CON-04` (SA).
+
+### 4.3 Tài sản thiết kế nội bộ đã có
+
+Dự án **không** ở tình trạng "trắng hoàn toàn" về mặt thiết kế — đã có hai tài sản tham khảo:
+
+| Tài sản | Trạng thái ghi trong chính tài liệu | Bản chất thật — SA phải hiểu đúng | Dùng làm gì ở GĐ1 SA |
+|---|---|---|---|
+| `e-commerce/docs/SAD.md` v0.2 (toàn bộ 9 mục `docs/sections/01…09`) | `status: approved` ở mọi mục con và ở bản ráp tổng thể (§0.2/§0.3 của `SAD.md`: "Product Owner/Kiến trúc sư trưởng đã phê duyệt") | Đây là **"approved" ở cấp phê duyệt nội bộ bản vẽ** (PO/Kiến trúc sư trưởng ký trên giấy khi làm hồ sơ), **KHÔNG phải kiến trúc đang chạy production**, không phải nghiệm thu vận hành, và không đi qua gate `AG1`/`AG2` của chính bộ `sa-*` này (được viết trước khi có pipeline `sa-lifecycle`) | Theo trả lời **`OQ-009` (đã đóng, xem `DEC-04`)**: dùng làm **điểm khởi đầu tham khảo** (baseline candidate) cho một trong các phương án ở Bước 4 (`OPT`) — KHÔNG mặc định là phương án thắng sẵn; Bước 4 vẫn phải dựng ≥1 phương án độc lập khác để so sánh thật (tránh bẫy "một phương án đã thắng sẵn", `GUIDE.md` "Bẫy thường gặp") |
+| `e-commerce/bid/` (`bid-config.md`, `30-implementation-plan.md`, `estimate.computed.json`) | `status: draft`, `cost.priceComplete: false` — tự ghi rõ là ước lượng dự thầu, chưa hợp đồng | Ước lượng của **nhà thầu** cho mục đích đấu thầu (nhân công, timeline, đội hình đề xuất) — khác mục đích với `TCO` (ước lượng vận hành 3 năm theo phương án kiến trúc SA chọn) đã ghi ở §6 "Ngoài phạm vi" | Tham khảo duy nhất hiện có cho `CON-01`/`CON-02`/`CON-05` (đã ghi ở §3) — không dùng làm số `TCO` thật ở Bước 5 |
+
+🔴 **Ranh giới thẩm quyền quan trọng:** "approved" trong `SAD.md` là do PO/Kiến trúc sư trưởng
+**nội bộ nhà thầu** ký trong quá trình chuẩn bị hồ sơ — không phải PO thật của dự án chạy thử
+này ký qua pipeline `sa-*`. Coi `SAD.md` là "đã chốt, không được đổi" là hiểu sai bản chất và vi
+phạm chính Bước 4 của `SKILL.md` (nguy cơ "một phương án duy nhất" — mục "Bẫy thường gặp").
+
+**Quyết định đóng `OQ-009`:** xem `DEC-04` (SA) — chấp nhận dùng `SAD.md`/hồ sơ thầu làm điểm
+khởi đầu tham khảo cho `OPT`, với điều kiện Bước 4 vẫn phải dựng và chấm điểm ≥1 phương án độc
+lập khác theo đúng quy trình bắt buộc của `SKILL.md` Bước 4.
+
+### 4.4 Kỹ năng/tài sản tổ chức đã biết
+
+| Tài sản/ràng buộc tổ chức | Trạng thái | Hệ quả cho `OPT`/GĐ2 | Nguồn |
+|---|---|---|---|
+| **AWS bắt buộc** | Cứng, đã xác nhận vòng 3 Q&A brief (không phải sở thích SA) | Loại mọi phương án cloud khác/on-prem ngay từ Bước 4; mọi dịch vụ managed đề xuất trong `SAD.md`/`docs/sections/09` (ECS Fargate/EKS, RDS, ElastiCache, MSK, OpenSearch, CloudFront, WAF, Secrets Manager, PagerDuty/OpsGenie tích hợp qua AWS) đều khả thi về mặt nền tảng — chưa khả thi về ngân sách (`OQ-005`) | `CON-03`; `00-project-brief.md` mục 5 |
+| **Team thi công + vận hành** | Chưa có số thật — dùng giả định tạm "team MVP chuẩn" theo `DEC-02` (🔴); tham khảo duy nhất là đội hình đề xuất của nhà thầu (9 vị trí TB, đỉnh 10, 8 vai trò) | Ranh giới ~10 service trong `SAD.md` §3.1 (mỗi service 3–6 kỹ sư theo mô tả §3.1) **chưa được đối chiếu** với số người thật của team dự án chạy thử này — rủi ro Conway nếu team thật nhỏ hơn nhiều | `CON-05`; `DEC-02`; `SAD.md` §3.1; `OQ-002`, `OQ-008` (còn mở) |
+| **Pipeline CI/CD, bảo mật vận hành đề xuất** | `docs/sections/09-van-hanh-kiem-thu.md` đề xuất: OIDC federation (CI ↔ AWS IAM), AWS Secrets Manager cho toàn bộ secret/API key đối tác, CloudWatch Logs + X-Ray/OpenTelemetry, PagerDuty/OpsGenie cho on-call | Tài liệu tự ghi rõ đây là **"đề xuất minh hoạ theo best practice AWS — không phải ràng buộc bắt buộc từ brief"** (brief không chỉ định công cụ cụ thể) — không coi là `CON`, chỉ là năng lực/công cụ tham khảo có sẵn trong thiết kế đề xuất | `docs/sections/09-van-hanh-kiem-thu.md` §9.3, ghi chú cuối |
+| **RTO/RPO đề xuất** | Kế thừa từ `SAD.md` §5.3.2, nhắc lại nguyên trạng ở §9.5.2 — tự ghi rõ "là **giả định** đã chốt (brief không có SLA hợp đồng cụ thể)" | Chưa phải ràng buộc cứng đã xác nhận bởi PO/SRE thật — dùng tham khảo cho `INF`/`ARISK` ở các bước sau, không coi là số đã chốt | `SAD.md` §5.3.2, §9.5.2 |
+| **Đội vận hành (Ops/SRE) sau go-live** | Chưa xác nhận nội bộ hay thuê ngoài, quy mô bao nhiêu người | Chặn thiết kế on-call/`INF` thật ở GĐ2 | `CON-08`; `OQ-008` (còn mở) |
+
+Không có bằng chứng về năng lực/kinh nghiệm thật của tổ chức với các công nghệ cụ thể (Kafka/MSK,
+OpenSearch, Kubernetes/EKS) ngoài việc chúng được đề xuất trong `SAD.md` — đây là khoảng trống
+cho `ARISK` (nguồn rủi ro "Con người": *"có ai trong team từng chạy production cái này chưa?"*)
+sẽ được lập ở Bước 5 (ngoài phạm vi lượt chạy này).
+
+## 5. Giả định — `ASM-nn`
+
+*Giả định cấp `CTX` (kiến trúc), sinh ra khi rà §3 Ràng buộc. Không copy `ASM-01…06` của BA ở
+`RISK_CartCheckout_v1.0.md` §1 — chỉ tham chiếu bằng ID, theo `artifact-map.md §7`. Đánh số
+độc lập, bắt đầu từ `ASM-01` cho sổ của `CTX`.*
+
+| ID | Giả định | Cách xác minh | Hệ quả nếu sai | Chủ | Hạn |
+|---|---|---|---|---|---|
+| `ASM-01` | Con số lao động trong hồ sơ thầu (≈3,76 tỷ VND đã VAT, 53,02 người-tháng) nằm "trong khoảng hợp lý" mà PO có thể chấp nhận — dùng làm điểm neo tạm cho `CON-01`, KHÔNG phải ngân sách đã duyệt | PO/tài chính xác nhận bằng văn bản: ngân sách hạ tầng/tháng đã duyệt + chi phí một lần cho phép | Nếu ngân sách thật thấp hơn nhiều: `OPT` Bước 4 phải loại các phương án kiến trúc nặng (Kafka/MSK, RDS Multi-AZ đầy đủ, OpenSearch cluster đa node đề xuất trong `SAD.md`) và chuyển hướng phương án rẻ hơn ngay từ đầu, tránh thiết kế xong mới phát hiện không đủ tiền vận hành | PO | Trước khi chạy Bước 4 (`OPT`) |
+| `ASM-02` | Không có mốc thời gian bên ngoài (hợp đồng/pháp lý/mùa vụ) ép buộc ngày ra mắt — deadline chỉ là "lộ trình MVP tiêu chuẩn" mang tính tham khảo, không phải cam kết cứng | PM/PO xác nhận `projectStartDate`/`projectDeadline` thật (hiện `[[CẦN ĐIỀN]]`/rỗng trong `bid-config.md`) | Nếu có deadline ngắn hơn 7 tháng ép buộc bởi bên ngoài (VD phải kịp mùa sale cụ thể): phải đánh đổi phạm vi MVP hoặc tăng song song hoá đội ngũ (rủi ro tăng chi phí phối hợp, theo chính `30-implementation-plan.md` §B7.5) | PM | Trước khi chạy Bước 4 (`OPT`) |
+| `ASM-03` | Đội vận hành sau go-live sẽ là một đội SRE/Ops (nội bộ hoặc thuê ngoài) trực theo ca hành chính + escalation 24/7 — kế thừa giả định "team MVP chuẩn" của `DEC-02` (🔴), CHƯA có số người/kỹ năng thật | PM/SRE xác nhận số người, kỹ năng, ai trực, mô hình on-call cụ thể | Nếu team vận hành thực tế rất nhỏ hoặc chưa tồn tại: ranh giới ~10 service theo `SAD.md` §3.1 có thể vi phạm Conway (đội quá nhỏ để vận hành nhiều service độc lập), phải gộp bớt ranh giới ở `OPT` Bước 4/GĐ2 | PM/SRE | Trước khi chốt ranh giới service ở GĐ2 |
+| `ASM-04` | Vùng cloud AWS hiện dùng trong `SAD.md` (ap-southeast-1 + region dự phòng cross-region) đáp ứng đủ yêu cầu residency của NĐ13/2023 cho dữ liệu cá nhân khách hàng + seller — NĐ13/2023 không tuyệt đối bắt buộc lưu trữ trong lãnh thổ VN cho mọi loại PII, nhưng giả định này **chưa được đại diện Pháp chế xác nhận** cho đúng mô hình marketplace hai loại chủ thể của dự án này | Đại diện Pháp chế/Bảo mật (chưa được chỉ định — kế thừa `OQ-003` của BA) xác nhận yêu cầu residency cụ thể | Nếu sai (bắt buộc lưu trong lãnh thổ VN cho một số loại dữ liệu): phải chuyển hạ tầng dữ liệu liên quan về region VN hoặc dùng nhà cung cấp trong nước, ảnh hưởng trực tiếp `CON-03`/`CON-06` và `TCO` | Legal/Security (chưa có người — `OQ-007`) | Trước GĐ2 (`DAT`/`INF`), chậm nhất trước go-live |
+| `ASM-05` | Kiến trúc/stack cụ thể mô tả sẵn trong `SAD.md`/hồ sơ thầu (modular "microservices" theo bounded-context ~10 service, Kafka/MSK, RDS PostgreSQL Multi-AZ database-per-service, Redis, OpenSearch, CDN) là **đề xuất của SA/nhà thầu**, có thể dùng làm điểm khởi đầu tham khảo cho Bước 4 (`OPT`) của chính GĐ1 SA này, nhưng KHÔNG coi là đã được khách hàng/PO chốt cứng | Tech Lead + PO xác nhận: chấp nhận `SAD.md` làm baseline cho `OPT`, hay yêu cầu SA dựng phương án độc lập không neo theo tài liệu có sẵn (tránh bẫy "một phương án duy nhất" đã thắng sẵn — xem `GUIDE.md` "Bẫy thường gặp") | Nếu sai (không được neo theo `SAD.md`): Bước 4 phải dựng ≥2 phương án hoàn toàn độc lập, tốn thêm thời gian nhưng giảm rủi ro "chấm điểm để hợp thức hoá lựa chọn đã có" | Tech Lead + PO | Trước khi bắt đầu Bước 4 (`OPT`) |
+| `ASM-06` | Quyết định "hoá đơn điện tử cho seller hoãn phase 2" (đã xác nhận vòng 3 brief) vẫn còn hiệu lực tại thời điểm `CTX` này — không có phản hồi trái ngược mới từ PO | PO xác nhận lại nếu có yêu cầu pháp lý mới bắt buộc hoá đơn điện tử sớm hơn (VD thay đổi quy định về hoá đơn điện tử cho sàn TMĐT) | Nếu sai: phải bổ sung `CON` pháp lý mới và mở rộng phạm vi MVP, ảnh hưởng cả `OPT`/`TCO`/lịch trình đã ước lượng trong hồ sơ thầu | PO | Trước khi chốt `OPT` Bước 4 |
+
+Giả định sai mà hệ quả lớn ⇒ nâng thành `ARISK` và xác minh ngay trong GĐ1. `ASM-01`, `ASM-03`,
+`ASM-04` có hệ quả đủ lớn (ảnh hưởng trực tiếp phạm vi/kiến trúc) — ứng viên rõ nhất để nâng
+thành `ARISK-nn` khi Bước 5 (`ARISK`) chạy ở lượt sau.
+
+## 6. Ngoài phạm vi
+
+*Những thứ người đọc có thể tưởng tài liệu này đã có, nhưng chưa có ở lượt chạy này:*
+
+- Khảo sát hiện trạng **kỹ thuật sâu hơn** cho các đối tác tích hợp (gọi thử sandbox thật, đọc
+  toàn bộ tài liệu API chi tiết của VNPay/Momo/GHN/GHTK) — §4.2 mới dừng ở mức "biết đối tác nào,
+  trạng thái sẵn sàng ở đâu" từ tài liệu sẵn có, chưa phải khảo sát kỹ thuật trực tiếp (gọi API
+  thử, đọc rate limit thật) theo đúng nghĩa `GUIDE.md` Bước 3 "Tích hợp — gọi thử nếu được".
+- `OPT` (phương án + chấm điểm), `TCO` (chi phí 3 năm), `ARISK` (rủi ro kiến trúc + POC) —
+  chưa chạy Bước 4–5. Không thể chạy các bước này một cách có ý nghĩa cho tới khi các `OQ-005`
+  (ngân sách), `OQ-006` (deadline), `OQ-008` (team vận hành) được trả lời bằng số thật — chấm
+  điểm phương án chỉ dựa trên ước lượng hồ sơ thầu (`CON-01`, `CON-02`, `CON-05` đều "Chưa xác
+  định/Mềm") là chấm bừa.
+- Driver của các module ngoài Giỏ hàng & Checkout (`DRV-04,05,06,09`) mới ở mức suy từ `SAD.md`,
+  **chưa** được xác nhận qua một vòng elicitation/BRIEF module hoá riêng như module Giỏ hàng &
+  Checkout — không nên coi các dòng này có độ tin cậy ngang với `DRV-01,02,03,07,08`.
+- Hoá đơn/mức giá cụ thể trong `e-commerce/bid/` (rateCard, VAT, các khoản non-labor còn
+  `amount: null`) **không phải** là `TCO` của GĐ1 SA — đây là ước lượng dự thầu cho một hợp
+  đồng, khác mục đích với `TCO` (ước lượng vận hành 3 năm theo phương án kiến trúc đã chọn).
+  SA sẽ tự tính `TCO` riêng ở Bước 5, có thể tham khảo nhưng không sao chép con số thầu.
+- Số liệu cứng/mềm ở `CON-01`, `CON-02`, `CON-05` mới là **đánh giá của SA dựa trên tài liệu
+  hiện có**, chưa phải xác nhận từ PO/PM/Tech Lead thật — không nên coi các dòng này đã "chốt".
+
+## 7. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
+|---|---|---|---|---|---|
+| `OQ-001` | BA chưa ký G1 chính thức cho `BRIEF_CartCheckout` (`OQ-001`/`OQ-007` của BA còn mở: tên thật stakeholder, baseline KPI). Xác nhận: có chấp nhận để `DRV-01,02,03,07,08` giữ Confidence 🔴 và tiếp tục sang Bước 2–5 của GĐ1 SA, hay dừng chờ BA ký G1 thật? | PO sàn (điều phối) + BA | 2026-09-12 | Nâng `Confidence` của toàn bộ `CTX`/`DRV` lên 🟡/🟢; ký AG1 thật (cần PO + Tech Lead, nhưng PO không nên ký trên driver còn 🔴 nếu tránh được) | Nếu PO/BA sau này đổi phát biểu bài toán ở `BRIEF §3` (VD: bỏ yêu cầu guest checkout, hoặc đổi mô hình tách đơn) ⇒ phải viết lại `DRV-01,02` và rà lại mọi `ADR` GĐ2 tham chiếu tới chúng |
+| `OQ-002` | Ràng buộc "Con người" (số đội, số người, kỹ năng, ai vận hành sau go-live) hoàn toàn chưa có thông tin — cần thiết để biến định hướng "kiến trúc module hoá độc lập theo nhóm" (NFR-07, §2.1) thành một `DRV`/`CON` có số liệu, thay vì chỉ là câu mô tả chung chung. | PM / Tech Lead | 2026-09-12 | Bước 2 (`CON` nhóm Con người); ranh giới service khả thi (Conway) ở GĐ2 | Nếu team thực tế rất nhỏ (VD 5 người) mà kiến trúc GĐ2 chia 8+ service theo domain (catalog/order/seller/payment/commission/loyalty/notification/CSKH) ⇒ vi phạm Conway, chậm release hơn cả kiến trúc gộp module |
+| `OQ-003` | Người dùng (điều phối) đã chọn phạm vi **Toàn sàn** cho GĐ1 SA dù được cảnh báo driver ngoài module Giỏ hàng & Checkout (`DRV-04,05,06,09`) chỉ có nguồn `SAD.md`, chưa qua BRIEF/RISK/STAKEHOLDER module hoá riêng như module Giỏ hàng & Checkout. Xác nhận: giữ nguyên phạm vi toàn sàn cho các bước 2–5 tiếp theo, hay thu hẹp về Giỏ hàng & Checkout để có Confidence cao hơn trước? | PO sàn + Tech Lead | 2026-09-12 | Khối lượng và độ tin cậy của `OPT`/`TCO`/`ARISK` ở các bước kế tiếp | Nếu giữ toàn sàn mà không bổ sung BRIEF module hoá cho Catalog/Seller/Commission/Loyalty, `OPT` GĐ1 SA sẽ phải chấm điểm phương án dựa trên driver suy diễn (không phải driver đã xác nhận) — rủi ro chọn sai phương án kiến trúc cho các module đó, phát hiện muộn ở GĐ2/GĐ3 |
+| `OQ-004` | Xác nhận ngoại lệ gate `DEC-01` (SA): chạy GĐ1 SA (Driver) khi BA chưa qua G1 — có đúng là quyết định của người có thẩm quyền điều phối dự án chạy thử, hay cần PO sàn thật xác nhận lại bằng văn bản riêng? | PO sàn (người thật, không phải vai trò) | 2026-09-12 | Tính hợp lệ của toàn bộ `CTX` này khi trình AG1 | Nếu PO thật sau này không công nhận ngoại lệ này, toàn bộ `CTX`/`DRV` phải làm lại sau khi BA ký G1 — chi phí làm lại phần Driver ước < 1 tuần (ít, vì đã có khung sẵn) |
+| `OQ-005` | Ngân sách hạ tầng/tháng và chi phí một lần đã duyệt cho dự án là bao nhiêu? Nguồn tham khảo duy nhất hiện có (`e-commerce/bid/estimate.computed.json`) là ước lượng dự thầu, **chưa hợp đồng**: lao động ≈3,76 tỷ VND đã VAT cho 53,02 người-tháng; 8 khoản chi phí không lao động (hạ tầng AWS, OpenSearch, phí VNPay/Momo, phí GHN/GHTK, Email/SMS, domain/SSL/WAF, pentest, đào tạo) đều chưa có số. **Câu trả lời tạm (2026-09-12, ghi tại §4.3):** chưa nhận được xác nhận số thật từ PO trong vòng chạy này — tạm dùng số hồ sơ thầu làm mốc tham khảo duy nhất, `Confidence` 🔴, `OQ-005` **giữ mở**. | PO / tài chính | 2026-09-12 | `CON-01` (cứng/mềm); `TCO` Bước 5; loại bớt phương án ở `OPT` Bước 4 | Nếu ngân sách thật thấp hơn đáng kể so với ước lượng thầu: phải loại các phương án kiến trúc nặng (Kafka/MSK, RDS Multi-AZ đầy đủ, OpenSearch đa node) ngay từ Bước 4, tránh thiết kế xong ở GĐ2 mới phát hiện không đủ tiền vận hành (tháng thứ 13 trở đi) |
+| `OQ-006` | Deadline dự án chính thức là ngày nào (nếu có)? Hai con số tham khảo hiện KHÔNG khớp: brief nói "~9-12 tháng" (định tính), hồ sơ thầu tính "7 tháng thực hiện" (teamSize trung bình 9, đỉnh điểm 10 người) + 12 tháng bảo hành — cả hai đều CHƯA được PO xác nhận là mốc thật (`bid-config.projectDeadline` rỗng). **Câu trả lời tạm (2026-09-12, ghi tại §4.3):** chưa nhận được xác nhận mốc thật từ PO trong vòng chạy này — tạm giữ song song cả hai con số tham khảo (7 tháng thầu / 9–12 tháng brief), không chọn một, `Confidence` 🔴, `OQ-006` **giữ mở**. | PO / PM | 2026-09-12 | `CON-02`; kịch bản thời gian ở `OPT` Bước 4 | Nếu deadline thật ngắn hơn 7 tháng (do ràng buộc bên ngoài mới xuất hiện): phải cắt phạm vi MVP hoặc tăng song song hoá đội ngũ — theo chính hồ sơ thầu (§B7.5), đòn bẩy này làm tăng chi phí phối hợp và rủi ro tích hợp, không miễn phí |
+| `OQ-007` | Ai là đại diện Pháp chế/Bảo mật xác nhận yêu cầu về nơi lưu trữ dữ liệu (residency) theo NĐ13/2023 cho mô hình marketplace có hai loại chủ thể dữ liệu (khách hàng + seller, gồm cả giấy tờ KYC)? *(kế thừa `OQ-003` của BA — vẫn chưa có người sau khi BA chạy GĐ1)* | PO sàn (chỉ định người) | 2026-09-12 | `CON-06`, `ASM-04`; ranh giới hạ tầng dữ liệu ở `DAT`/`INF` GĐ2 | Nếu về sau phát hiện bắt buộc lưu trữ trong lãnh thổ VN cho một số loại PII: phải chuyển hạ tầng dữ liệu liên quan (hoặc toàn bộ) về region VN/nhà cung cấp trong nước — phát hiện càng muộn (VD sau khi GĐ2 đã chốt `DAT`/`INF` theo `ap-southeast-1`) thì chi phí sửa càng cao, có thể phải viết lại `ADR` hạ tầng |
+| `OQ-008` | Đội vận hành (Ops/SRE) sau go-live là nội bộ PO hay thuê ngoài, quy mô bao nhiêu người, có sẵn sàng trực 24/7 cho sự cố nghiêm trọng theo giả định NFR-08 hay chưa? | PM / SRE | 2026-09-12 | `CON-05`, `CON-08`; thiết kế on-call/`INF` ở GĐ2; ranh giới service (Conway) | Nếu chưa có đội ops sẵn sàng khi go-live: phải tính thêm chi phí thuê ngoài/tuyển dụng vào `TCO` Bước 5, và mục tiêu uptime 99.9% (`DRV-05`) có thể không đạt được trong thực tế dù kiến trúc đúng thiết kế |
+| ~~`OQ-009`~~ | *(Đã đóng ở v1.2, xem "Open Question đã đóng" ngay dưới)* | — | — | — | — |
+
+### 7.1 Open Question đã đóng *(mới từ v1.2)*
+
+| ID | Câu hỏi | Trả lời | Ngày đóng | Người trả lời | Ghi chú |
+|---|---|---|---|---|---|
+| `OQ-009` | Có chấp nhận dùng kiến trúc/stack đã đề xuất sẵn trong `SAD.md`/hồ sơ thầu (modular microservices ~10 service, Kafka/MSK, RDS Multi-AZ, OpenSearch, Redis) làm điểm khởi đầu cho Bước 4 (`OPT`) của GĐ1 SA, hay yêu cầu SA dựng phương án hoàn toàn độc lập? | **Chấp nhận** dùng `SAD.md`/hồ sơ thầu làm **điểm khởi đầu tham khảo** cho một phương án ở Bước 4 — với điều kiện bắt buộc: Bước 4 vẫn phải dựng và chấm điểm ≥1 phương án độc lập khác theo đúng `SKILL.md` Bước 4, không mặc định `SAD.md` là phương án thắng sẵn. Xem §4.3, `DEC-04` (SA). | 2026-09-12 | Ghi chú người duyệt (đại diện PO/điều phối dự án) | `Confidence` của quyết định này: 🟡 (rõ ràng về điều kiện áp dụng, nhưng người duyệt là ghi chú điều phối, không phải PO/Tech Lead ký trực tiếp qua `sign`) |
+
+---
+
+## Tự chấm
+
+### ① Bảng tự chấm Gate AG1 *(`workflow.md §2`)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | `CTX` có `DRV-nn`, mỗi driver ghi rõ áp lực kinh doanh | ✅ | 9 `DRV` (`DRV-01…09`), mỗi dòng có áp lực định lượng (nơi có thể), nguồn, thuộc tính chất lượng bị ép. `DRV-04/05` dùng số mô tả định tính "lớn"/"99.9%" đã được chính nguồn (`00-project-brief`) gắn nhãn "giả định mặc định", không phải SA tự bịa |
+| 2 | `CTX` có `CON-nn` (ràng buộc 6 nhóm) | ✅ *(với lưu ý)* | Đủ 6 nhóm (`CON-01` Tiền … `CON-09` Tổ chức/Vận hành, xem §3). Nhưng phần lớn giá trị "Cứng/Mềm" ghi "Chưa xác định" vì nguồn chỉ là ước lượng hồ sơ thầu (Draft, chưa hợp đồng) — chưa phải số PO đã duyệt. Đạt tiêu chí "có mặt và đủ 6 nhóm", chưa đạt mức "đã xác nhận thật" |
+| 3 | `CTX` mô tả hiện trạng as-is: hệ thống, dữ liệu, tích hợp, hợp đồng vendor đang có | ✅ *(với lưu ý)* | §4 mới bổ sung ở v1.2: (a) khẳng định greenfield + hệ quả, (b) bảng trạng thái 9 đối tác tích hợp (VNPay/Momo/GHN/GHTK/Email-SMS/Ngân hàng/OAuth/hoá đơn điện tử), (c) tài sản thiết kế đã có (`SAD.md`/hồ sơ thầu, có ghi rõ ranh giới thẩm quyền), (d) kỹ năng/tài sản tổ chức. "Hệ thống/dữ liệu đang có" = None (greenfield, đã xác nhận nguồn `PROFILE_e-commerce.md`); "hợp đồng vendor đang có" = None (mọi đối tác đều 🔴/🔴🔴 chưa sandbox/hợp đồng thật) — đạt tiêu chí "mô tả hiện trạng", nội dung chính là "hiện trạng = chưa có gì tự vận hành, có đối tác bên ngoài chưa sẵn sàng" |
+| 4 | `OPT` có ≥2 phương án, chấm điểm, nêu phương án bị loại | ☐ | **Chưa tạo file `OPT`** — thuộc Bước 4, ngoài phạm vi lượt chạy này; phụ thuộc `OQ-005`/`OQ-006` trả lời trước (đã có nền: `OQ-009` đóng ở §4.3/§7.1 cho phép dùng `SAD.md` làm điểm khởi đầu tham khảo) |
+| 5 | `TCO` có chi phí 3 năm, ≥2 kịch bản tải | ☐ | **Chưa tạo file `TCO`** — thuộc Bước 5, ngoài phạm vi lượt chạy này |
+| 6 | `ARISK` có rủi ro cao kèm chủ + biện pháp | ☐ | **Chưa tạo file `ARISK`** — thuộc Bước 5, ngoài phạm vi lượt chạy này. §4.2/§4.4 đã nêu sẵn một số ứng viên rủi ro (đối tác chưa sandbox, năng lực team chưa xác nhận với Kafka/MSK/OpenSearch/EKS) để Bước 5 kế thừa |
+| 7 | Rủi ro cao chưa chứng minh được có kế hoạch POC | ☐ | Phụ thuộc `ARISK`, chưa làm |
+
+**Kết luận tự chấm AG1:** **Chưa đủ điều kiện ký** — đúng như phạm vi được giao (Driver +
+Ràng buộc + Hiện trạng). 3/7 tiêu chí ✅. Cần chạy tiếp Bước 4–5 (`OPT`, `TCO`, `ARISK`) trước
+khi PO + Tech Lead có thể ký AG1, và cần `OQ-005`/`OQ-006`/`OQ-007`/`OQ-008` được trả
+lời bằng số/người thật trước khi Bước 4–5 có ý nghĩa (`OQ-009` đã đóng). Ngoài ra, ngay cả `DRV` và `CON` đang ở
+`Confidence 🔴` vì lý do preflight (BA chưa ký G1) và vì `CON` dựa trên ước lượng hồ sơ thầu
+chưa xác nhận — nên **không đủ điều kiện baseline `CTX`** dù đã điền đủ nội dung của mục Driver,
+Ràng buộc và Hiện trạng.
+
+### ② Checklist D1–D12 *(`design-rules.md`)*
+
+| # | Mục | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| D1 | Một ADR một quyết định | N/A | Tài liệu này không có `ADR` |
+| D2 | Không NFR định tính; đủ 4 câu | 🟡 Một phần | Driver không phải `QAS` nên không bắt buộc đủ "4 câu", nhưng đã cố định lượng tối đa có thể (DRV-01,02,03,04,06,07,08 có con số/nguồn cụ thể); `DRV-05,09` còn dùng mô tả định tính do chính nguồn brief chỉ ghi ở mức đó — đã gắn nhãn rõ "giả định mặc định", không che giấu |
+| D3 | Nêu phương án bị loại | N/A | `OPT` (nơi bắt buộc nêu phương án loại) chưa chạy ở lượt này; `CON-05` đã ghi rõ số liệu team hồ sơ thầu KHÔNG được coi là phương án đã chọn |
+| D4 | Sơ đồ khai báo mức + legend | N/A | Không có sơ đồ mới thêm ở §3/§5 |
+| D5 | Interface có chủ/contract | N/A | Chưa tới `ICD` (GĐ2); `CON-04`/§4.2 đã nêu đối tác tích hợp bắt buộc và trạng thái sẵn sàng nhưng chưa có contract thật |
+| D6 | Phụ thuộc ngoài process có timeout/retry | N/A | Chưa tới `FAIL`/`SAD` (GĐ2); §4.2 kế thừa nguyên trạng timeout/retry **đề xuất** từ `SAD.md` §3.4 (VNPay/Momo 10s, GHN/GHTK 8s, Email/SMS 5s) — ghi rõ là đề xuất chưa kiểm chứng với sandbox thật, không phải ràng buộc SA tự đặt mới |
+| D7 | Một chủ sở hữu dữ liệu | N/A | Chưa tới `DAT` (GĐ2) |
+| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` (GĐ3) |
+| D9 | Con số hạ tầng quy ra tiền + nguồn | 🟡 Một phần | `CON-01` có trích dẫn con số (≈3,76 tỷ VND đã VAT) kèm nguồn (`estimate.computed.json`), nhưng đây là số của hồ sơ thầu (nhân công + VAT), KHÔNG phải con số hạ tầng quy đổi kiến trúc — `TCO`/`INF` thật (nơi D9 áp dụng đầy đủ) chưa chạy. §4.3/§4.4 không thêm số hạ tầng mới, chỉ dẫn nguồn cho các bước sau |
+| D10 | Không quyết định thay người có thẩm quyền | ✅ | Mọi chỗ chưa rõ (ngân sách, deadline, đội vận hành, residency pháp lý) đều ghi `OQ-005…008` kèm hệ quả phương án ngược bằng số/định tính rõ ràng, không tự quyết. `OQ-009` đã đóng nhưng bằng **ghi chú điều phối** (không phải PO/Tech Lead ký trực tiếp) — ghi rõ mức độ thẩm quyền thật ở §7.1, không che giấu. Riêng việc gán "Cứng/Mềm" cho từng `CON` và trạng thái 🔴/🔴🔴/🟡/🟢/⏸️ cho từng đối tác ở §4.2 là đánh giá kỹ thuật của SA dựa trên nguồn hiện có, không phải quyết định thay PO |
+| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §6 "Ngoài phạm vi" đầy đủ (đã cập nhật: as-is kỹ thuật sâu hơn — gọi sandbox thật — vẫn ngoài phạm vi); §5 có `ASM-01`…`ASM-06` cấp `CTX`, mỗi cái có cách xác minh, hệ quả, chủ, hạn (không sửa ở lượt này) |
+| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có câu chuẩn ngay sau Change Log |
+
+### ③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì
+
+Xem bảng đầy đủ ở §7. Tóm tắt tám câu hỏi đang chặn (`OQ-009` đã đóng, xem §7.1): **(1)** `OQ-001`
+chặn nâng `Confidence` của toàn `CTX` — hỏi PO sàn + BA; **(2)** `OQ-002` chặn số liệu team thật
+ở `CON-05` — hỏi PM/Tech Lead; **(3)** `OQ-003` chặn quyết định giữ/thu hẹp phạm vi toàn sàn —
+hỏi PO + Tech Lead; **(4)** `OQ-004` chặn tính hợp lệ của ngoại lệ gate `DEC-01` — hỏi PO sàn
+(người thật); **(5)** `OQ-005` chặn `CON-01`/`TCO` — hỏi PO/tài chính (có câu trả lời tạm, xem
+§7); **(6)** `OQ-006` chặn `CON-02`/kịch bản thời gian ở `OPT` — hỏi PO/PM (có câu trả lời tạm);
+**(7)** `OQ-007` chặn `CON-06`/`ASM-04` (residency pháp lý) — hỏi PO (chỉ định người); **(8)**
+`OQ-008` chặn `CON-05`/`CON-08` (đội vận hành) — hỏi PM/SRE.
+
+**Nhắc:** AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header `OPT`) trước khi chạy
+`/sa-2-architecture`. `OPT` chưa tồn tại — phải chạy tiếp Bước 4–5 của `sa-1-context` trước, và
+nên có `OQ-005/006/007/008` trả lời trước để Bước 4–5 không phải chấm bừa.

sa-output/e-commerce/01-context/OPT_e-commerce_v1.0.md

@@ -0,0 +1,368 @@
+# OPT — Solution Options & Trade-off — e-commerce
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | 2026-09-12 |
+| **Author** | SA (skill sa-1-context, chế độ `go`, hoạt động `options`) |
+| **Status** | 🟡 Draft *(duyệt từng phần — xem `Approved by`; §1 Khuyến nghị, §2 Bộ tiêu chí và trọng số mặc định (đóng `ASM-09`), §4 Bảng chấm điểm, §5 Phương án bị loại (P3/P4) đã được duyệt tạm để làm nền cho Bước 5/GĐ2 — **chọn P2** có điều kiện (`OQ-010`, `OQ-012`); đây **chưa phải** AG1 toàn phần — Tech Lead chưa ký, `OQ-004` còn mở, quyết định kiến trúc chính thức (`ADR`) vẫn để GĐ2; xem "Tự chấm" §① — vẫn 4/7 tiêu chí ✅)* |
+| **Approved by** | PO (uỷ quyền, chế độ chạy thử): **Điều phối dự án** — duyệt **từng phần** bản v1.0 · 2026-09-12: chấp nhận bộ tiêu chí và trọng số mặc định (§2, đóng `ASM-09`), bảng chấm điểm (§4), hai phương án bị loại P3/P4 (§5), và khuyến nghị P2 có điều kiện (§1). **Chọn P2** (modular monolith + managed AWS, tách riêng Payment) làm nền cho Bước 5 và GĐ2, điều kiện: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC SQS/EventBridge được ghi vào `ARISK` ở Bước 5 (`OQ-012`), trước khi chốt `ADR` message backbone GĐ2. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-06`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở. Duyệt này vẫn là duyệt **từng phần**, không phải AG1 toàn phần, và **không thay thế yêu cầu `ADR` chính thức ở GĐ2** (kiểu kiến trúc tổng thể là quyết định thuộc danh mục bắt buộc ADR theo `decision-radar.md §3`). · Tech Lead: — *(chưa ký)* |
+| **Source** | `01-context/CTX_e-commerce_v1.0.md` (v1.2 trong header) §2 (`DRV-01…09`), §3 (`CON-01…09`), §4.2 (đối tác 🔴), §4.4 (năng lực tổ chức) · `e-commerce/docs/SAD.md` v0.2 §3.1–§3.4 (`e-commerce/docs/sections/03-kien-truc.md`) · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` (FR/NFR) · `e-commerce/bid/estimate.computed.json` (Draft, `priceComplete:false`) · `e-commerce/bid/bid-config.md` (Draft) · `00-index/OQ_e-commerce.md` v1.4 · `00-index/DEC_e-commerce.md` v1.4 |
+| **Scope** | Toàn sàn e-commerce (marketplace đa seller) theo `SAD.md` v0.2 — phạm vi đã chốt cho lượt chạy này; `OQ-003` (giữ toàn sàn hay thu hẹp về Giỏ hàng & Checkout) **vẫn mở**, chưa ảnh hưởng cấu trúc phương án ở đây vì cả ba phương án đều mô tả ở mức kiến trúc tổng thể toàn sàn |
+| **Confidence** | 🔴 Giả định chưa xác minh — kế thừa nguyên nhân của `CTX` (BA chưa ký G1 thật, AG1 GĐ1 SA chưa từng chạy, ngoại lệ gate `DEC-01/03/04` tiếp tục ở `DEC-05`). Riêng phần điểm số ở đây còn thêm hai lý do: (a) `CON-01`/`CON-02`/`CON-05` — ba tiêu chí input trực tiếp cho bảng chấm — đều "Chưa xác định/Mềm" trong `CTX`, chỉ có số tham khảo từ hồ sơ thầu Draft; (b) con số hạ tầng dùng để so sánh P1/P2 ở đây là **số lượng/loại thành phần quản lý (managed component)**, không phải tiền — `TCO` bằng VND thật để Bước 5, ngoài phạm vi lượt chạy này. Duyệt từng phần theo `DEC-06`
+**không** nâng `Confidence` này (phê duyệt không phải bằng chứng nguồn mới) — vẫn chờ `OQ-004`
+(tính hợp lệ ký thay), `OQ-010` (kinh nghiệm team thật), `OQ-012` (POC SQS/EventBridge) |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR/DEC |
+|---|---|---|---|---|
+| 1.0 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `options`) | Bản đầu — Bước 4 của `sa-1-context`: chốt bộ tiêu chí (từ `DRV`/`CON`), dựng 3 phương án chấm điểm (P0 giữ nguyên, P1 modular microservices theo `SAD.md`/hồ sơ thầu, P2 modular monolith + managed AWS — phương án đối trọng độc lập), 2 phương án bị loại có lý do (P3 mua/tích hợp nền tảng sẵn có, P4 serverless-first). Khuyến nghị **P2 có điều kiện** — không tự quyết thay PO/Tech Lead (`D10`). Tiếp tục ngoại lệ gate `DEC-01`/`DEC-03`/`DEC-04`, ghi thêm `DEC-05`. Không sửa `CTX` §2–§5 đã duyệt từng phần; chỉ tham chiếu. `Confidence` 🔴 toàn tài liệu. | `DEC-05` |
+| 1.0 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **từng phần** bản v1.0: chấp nhận bộ tiêu chí và trọng số mặc định (§2, đóng `ASM-09`), bảng chấm điểm (§4), hai phương án bị loại P3/P4 (§5), khuyến nghị P2 có điều kiện (§1). **Chọn P2** (modular monolith + managed AWS, tách riêng Payment) làm nền cho Bước 5 và GĐ2, điều kiện: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC SQS/EventBridge (`ASM-07`) ghi vào `ARISK` ở Bước 5, trước khi chốt `ADR` message backbone GĐ2 (`OQ-012`). Không đổi nội dung chuyên môn. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-06`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở, Tech Lead **chưa ký**. `Confidence` giữ 🔴. Status **giữ** 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện (4/7 tiêu chí ✅, xem §①); quyết định kiến trúc chính thức vẫn để `ADR` ở GĐ2, DEC-06 chỉ ghi nhận hướng đi tạm. `OQ-011` đóng trong sổ `00-index/OQ_e-commerce.md` bằng chính câu trả lời có điều kiện này. | `DEC-06` |
+
+> ⚠️ **Đây là tài liệu PO + Tech Lead ký để qua AG1.** Đọc §1 và §5 là đủ để quyết. Tài liệu này
+> **chưa đủ điều kiện baseline AG1 một mình** — vẫn thiếu `TCO` (Bước 5) và `ARISK`/kế hoạch POC
+> (Bước 5), xem "Tự chấm" ở cuối `CTX_e-commerce_v1.0.md` §Tự chấm ① (cập nhật lại ở cuối file
+> này).
+
+> Sơ đồ thắng về **quan hệ và luồng** (ai gọi ai, đồng bộ/bất đồng bộ). Bảng/văn bản thắng về
+> **ràng buộc và con số** (timeout, quyền, đơn vị hạ tầng). Mâu thuẫn ngoài hai loại này là lỗi
+> tài liệu, phải sửa chứ không chọn bên (`D12`).
+
+---
+
+## 0. Ghi chú Preflight & ngoại lệ gate — tiếp nối `CTX`
+
+Gate AG1 (PO + Tech Lead) của chính GĐ1 SA **chưa từng chạy** cho dự án e-commerce, và BA vẫn
+chưa ký G1 chính thức (`BRIEF_CartCheckout` Draft) — như đã ghi ở `CTX §0`, `DEC-01`, `DEC-03`,
+`DEC-04`. Người dùng (vai điều phối dự án chạy thử) **tái khẳng định muốn tiếp tục** sang Bước 4
+(`OPT`) của `sa-1-context` dù các điều kiện trên chưa đạt.
+
+> **DEC-05 (SA)** — Tiếp tục chạy `sa-1-context` Bước 4 (Phương án — `OPT`) cho dự án e-commerce
+> trong khi BA vẫn chưa qua G1 và AG1 (gate của chính GĐ1 SA) vẫn chưa từng chạy — tiếp nối
+> `DEC-01`/`DEC-03`/`DEC-04`.
+> **Quyết định:** Tiếp tục, `Confidence 🔴` cho toàn bộ nội dung điểm số (dựa trên `CON` còn
+> "Chưa xác định/Mềm") cho tới khi có số ngân sách/deadline/team thật (`OQ-005`, `OQ-006`,
+> `OQ-008`).
+> **Người quyết:** Điều phối dự án (đại diện PO, dự án chạy thử).
+> **Radar (ước lượng):** ~3–4 (chi phí đảo ngược thấp — nội dung `OPT` sửa lại khi có số thật
+> không tốn nhiều · bán kính ảnh hưởng: toàn bộ quyết định kiến trúc GĐ2 phụ thuộc phương án
+> chọn ở đây, nhưng bản thân *việc ghi tài liệu dưới ngoại lệ* thì nhỏ · chưa chạm trực tiếp một
+> `QAS` cụ thể (`QAS` chưa tồn tại, đây vẫn là GĐ1) · không ràng buộc dài hạn (ngoại lệ tạm thời)
+> · không tranh cãi mới, tiếp nối tiền lệ) → **ghi `DEC-nn`, không cần `ADR`** theo
+> `decision-radar.md §1–§2`.
+> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng `sa-1-context` ở cuối Bước 3, không có `OPT` để
+> PO/Tech Lech tham khảo cho tới khi BA ký G1 thật và/hoặc AG1 chạy đủ vòng đầu — chậm tiến độ
+> chạy thử tương ứng.
+
+🔴 **Lưu ý quan trọng cho người ký:** bảng chấm điểm dưới đây dùng số liệu tham khảo từ hồ sơ
+thầu (`e-commerce/bid/`, Draft, `priceComplete:false`) cho các tiêu chí Chi phí/Thời gian/Team —
+đây là ước lượng của **nhà thầu cho mục đích đấu thầu**, không phải số đã được PO xác nhận
+(`OQ-005`, `OQ-006`, `OQ-008` vẫn mở). Điểm số vì vậy phản ánh **thứ tự tương đối** hợp lý giữa
+các phương án hơn là giá trị tuyệt đối đáng tin cậy.
+
+---
+
+## 1. Khuyến nghị *(đọc mục này trước)*
+
+| | |
+|---|---|
+| **Phương án khuyến nghị** | **P2 — Modular monolith + managed AWS services, tách riêng Payment Service** |
+| **Vì sao** | Khớp Conway với team giả định `DEC-02`/hồ sơ thầu (BE trung bình chỉ ~2,6 FTE/tháng trên 7 tháng — xem §3 P2 "Ai vận hành") — 10 service độc lập của P1 vượt quá năng lực vận hành thực tế của một team cỡ này (`CON-05`); đồng thời P2 vẫn giữ nguyên yêu cầu cứng `CON-06` (cô lập Payment Service cho PCI-DSS SAQ A) và không đổi vùng AWS (`CON-03`) |
+| **Chỗ phương án này THUA** | Thua P1 ở tiêu chí "Đáp ứng `DRV` Must" (4 so với 5) — khả năng scale-out **độc lập** Catalog/Search khỏi Cart/Checkout (`DRV-04`) yếu hơn khi cả hai còn chung một nhóm deployable ở giai đoạn đầu; đây là đánh đổi thật, không phải P2 thắng tuyệt đối |
+| **Điều kiện kèm theo** | (1) Tech Lead xác nhận đội thi công thật (không phải đề xuất hồ sơ thầu) — trả lời `OQ-010`; (2) trước khi chốt `ADR` message backbone ở GĐ2, chạy POC đo throughput SQS/EventBridge cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải tương đương `DRV-04` (`ASM-07`, `OQ-012`) — **POC fail (không đạt thông lượng cần thiết) ⇒ bổ sung Kafka/MSK riêng cho hot-path đặt hàng (kiến trúc lai), không chuyển hẳn sang P1** vì phần còn lại của P1 (10 service tách rời) vẫn vi phạm Conway; (3) PO xác nhận ngân sách đủ để về sau tách Catalog/Search ra khỏi monolith nếu traffic thật vượt ngưỡng dự kiến (`ASM-08`) |
+| **Quyết định này cần ai ký** | PO (đánh đổi giữa scale-out sớm và phù hợp năng lực team hiện tại) · Tech Lead (khả thi thi công/vận hành với team thật) — **chưa ký, đây vẫn là khuyến nghị của SA, không phải quyết định** (`D10`) |
+
+---
+
+## 2. Bộ tiêu chí *(chốt TRƯỚC khi mô tả phương án)*
+
+*Tiêu chí sinh từ `DRV` (Must trước) và `CON` (cứng là điều kiện loại, không phải điểm số).
+Trọng số dùng nguyên bộ mặc định của `sa-1-context/templates/option-tradeoff.md` — chưa có
+buổi duyệt trọng số riêng với PO/Tech Lead (kế thừa hạn chế elicitation của `CTX`), ghi nhận là
+giả định tiếp theo.*
+
+### 2.1 Điều kiện loại (gate cứng — pass/fail trước khi chấm điểm)
+
+| `CON` | Nội dung | Bắt buộc gì | P0 | P1 | P2 | P3 | P4 |
+|---|---|---|---|---|---|---|---|
+| `CON-03` | Cloud AWS bắt buộc | Không dùng cloud khác/on-prem | N/A (không xây) | ✅ Pass | ✅ Pass | ⚠️ Phụ thuộc bản build nền tảng — hầu hết nền tảng open-source multi-vendor có thể tự host trên AWS, coi là Pass được nếu tự triển khai | ✅ Pass (Lambda/Step Functions đều AWS) |
+| `CON-06` | PCI-DSS SAQ A (không lưu thẻ) + NĐ13/2023 (PII/KYC) — Payment phải là biên cô lập duy nhất | Thiết kế phải tách được Payment Service/module ra làm biên cô lập | N/A | ✅ Pass — đã thiết kế sẵn trong `SAD.md` §3.1 | ✅ Pass — Payment tách riêng dù phần còn lại gộp (xem §3 P2) | ❌ **Không kiểm chứng được** với lõi đóng gói sẵn của nền tảng mua/tích hợp mà không sửa sâu — xem §5 lý do loại | ⚠️ Chưa kiểm chứng cô lập Payment trong mô hình serverless (Lambda dùng chung VPC/role) — chưa loại nhưng là rủi ro cao, xem §5 |
+
+**Đọc bảng:** `CON-06` là lý do loại chính của P3. `P4` không bị loại bởi gate cứng nhưng bị
+loại ở bước chấm điểm rủi ro kỹ thuật + thiếu bằng chứng năng lực team (§5).
+
+### 2.2 Tiêu chí chấm điểm (áp dụng cho phương án đã qua gate cứng)
+
+| # | Tiêu chí | Trọng số | Sinh từ | Đo bằng |
+|---|---|---|---|---|
+| 1 | Đáp ứng `DRV` mức Must (`DRV-01,02,03,04,05,06,07,08`) | 25% | `DRV-01…08` | Có/không cho từng driver, quy về thang 1–5 |
+| 2 | Chi phí 3 năm (sơ bộ — số lượng/loại managed component, **không** phải VND; `TCO` VND thật ở Bước 5) | 20% | `CON-01` (chưa xác định số thật) | Số lượng thành phần hạ tầng quản lý riêng biệt phải vận hành |
+| 3 | Thời gian tới bản chạy được | 15% | `CON-02` (7 tháng thầu / 9–12 tháng brief) | Effort WBS liên quan tới việc dựng nền tảng (tuần/MD, theo `estimate.computed.json`) |
+| 4 | Rủi ro kỹ thuật | 15% | Nguồn rủi ro "Công nghệ mới"/"Phụ thuộc bên ngoài" (`decision-radar.md`) | Có bằng chứng team từng chạy production công nghệ này chưa (`CTX §4.4`) |
+| 5 | Phù hợp năng lực team & vận hành (Conway) | 15% | `CON-05`, `DEC-02` | Số service/module so với FTE BE trung bình thật (nguồn `estimate.computed.json.mmByRole`) |
+| 6 | Khả năng tiến hoá (chi phí đảo ngược) | 10% | — | Chi phí tách/gộp lại về sau |
+
+**Trọng số do ai duyệt · ngày:** Chưa ai duyệt chính thức — SA dùng bộ mặc định của template vì
+chưa có buổi làm việc PO/Tech Lech riêng cho trọng số (kế thừa hạn chế elicitation, xem `OQ-001`
+của `CTX`). Ghi nhận: nếu PO/Tech Lead muốn đổi trọng số (ví dụ tăng "Rủi ro kỹ thuật" hoặc "Chi
+phí" vì ngân sách hạn chế theo `CON-01`), chấm lại theo trọng số mới trước khi ký AG1.
+
+🔴 Trọng số này **không** được chốt trong một buổi làm việc PO xác nhận — nếu điểm tổng P2 so
+với P1 (§4) đổi thứ hạng khi tăng trọng số "Chi phí" hoặc "Năng lực team" (hai tiêu chí P2 đang
+mạnh), khuyến nghị càng vững; nếu PO tăng mạnh trọng số "Đáp ứng DRV Must" (tiêu chí P1 mạnh
+hơn), thứ hạng có thể đổi — xem `OQ-011`.
+
+---
+
+## 3. Các phương án
+
+### P0 — Không làm gì / giữ nguyên *(mốc so sánh, bắt buộc có)*
+
+| | |
+|---|---|
+| **Mô tả** | Không triển khai sàn e-commerce ở giai đoạn này. Vì đây là dự án **greenfield** (`CTX §4.1`), "giữ nguyên" nghĩa là **không có gì để giữ** — khách hàng/seller tiếp tục không có nền tảng giao dịch tập trung nào (không có quy trình thủ công đang chạy để so sánh, khác dự án loại "mở rộng") |
+| **Chi phí 3 năm** | Không phát sinh chi phí xây dựng/vận hành kiến trúc. **Chi phí cơ hội không định lượng được ở lượt này** — `DRV-01` đã ghi rõ: không có luồng giao dịch ⇒ **0 giao dịch ghi nhận, toàn bộ mô hình kinh doanh marketplace bị chặn hoàn toàn**, đây là hệ quả định tính nghiêm trọng nhất trong toàn bộ `CTX`, dù không quy ra được một con số tiền cụ thể (không có doanh thu mục tiêu bằng số trong nguồn hiện có) |
+| **Vì sao không chọn** | Vi phạm trực tiếp `DRV-01` (Must, blocker) — đây là driver mạnh nhất trong toàn bộ `CTX`. Giữ P0 làm mốc so sánh, không phải phương án khả thi |
+
+### P1 — Modular microservices theo `SAD.md` v0.2 / hồ sơ thầu (điểm khởi đầu tham khảo, `DEC-04`)
+
+| | |
+|---|---|
+| **Ý tưởng một câu** | ~10 service theo bounded-context, database-per-service, giao tiếp REST đồng bộ + Kafka/MSK bất đồng bộ cho chuỗi nghiệp vụ sau đặt hàng |
+| **Thành phần chính** | Identity, Catalog & Inventory, Search (OpenSearch), Cart & Order (+ Dispute), Payment, Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment — mỗi service một RDS PostgreSQL Multi-AZ logic riêng, ElastiCache Redis dùng chung cho cache/session/giỏ hàng, Kafka/MSK là xương sống bất đồng bộ, ECS Fargate/EKS auto-scaling theo domain, CloudFront + WAF phía trước |
+| **Mua gì / tự làm gì** | Toàn bộ business logic tự xây; hạ tầng dùng AWS managed service (RDS, MSK, ElastiCache, OpenSearch, ECS/EKS, CloudFront, WAF) — không mua phần mềm lõi thương mại nào |
+| **Dữ liệu nằm ở đâu, ai sở hữu** | Mỗi service sở hữu schema/DB riêng (database-per-service) — không service nào truy cập trực tiếp DB service khác, chỉ qua API/event (`SAD.md §3.2`) |
+| **Ai vận hành** | Đội DevOps/SRE phải vận hành ~10 service group riêng + 1 cụm Kafka/MSK + 1 cụm OpenSearch đa node — theo hồ sơ thầu, FTE DevOps trung bình toàn dự án chỉ **~4,92 MM/~7 tháng ≈ 0,7 FTE trung bình** (`estimate.computed.json.mmByRole.DEVOPS`), đỉnh điểm cao hơn ở WBS-01/02/03 |
+| **Thời gian tới bản chạy được** | Riêng hạng mục nền tảng dịch vụ & event backbone (`WBS-03`, complexity **XL**, risk **high**) đã ước **52 MD + 18,2 MD dự phòng (35%) = 70,2 MD** chỉ để dựng xương sống, **trước khi** làm bất kỳ nghiệp vụ nào (nguồn: `estimate.computed.json`) |
+| **Chi phí 3 năm (sơ bộ, số lượng thành phần — chưa quy đổi VND)** | ~10 RDS logic + 1 cụm MSK (Kafka) + 1 cụm OpenSearch đa node + ~10 ECS/EKS service group tự động mở rộng riêng — nhiều thành phần phải trả phí/quản lý độc lập nhất trong 3 phương án đã qua gate cứng. **8/8 khoản chi phí non-labor trong hồ sơ thầu đều `amount: null`** (`CON-01`) — không có số VND thật để so sánh, chỉ so sánh được số lượng/loại thành phần |
+| **Rủi ro chính** | (a) Không có bằng chứng team từng vận hành Kafka/MSK, OpenSearch cluster, EKS trong production (`CTX §4.4`); (b) 4 đối tác tích hợp bên ngoài (VNPay/Momo/GHN/GHTK) chưa sandbox thật (`CTX §4.2`, độc lập với lựa chọn kiến trúc nội bộ nhưng số lượng service tăng số điểm tích hợp phải xử lý retry/idempotent riêng lẻ); (c) `WBS (42,48 MM) lệch 54,47% so với UCP (27,5 MM)` — cảnh báo tự động trong `estimate.computed.json.crosscheck` vượt ngưỡng 25%, dấu hiệu ước lượng effort chưa ổn định. *(Chưa lập `ARISK-nn` chính thức — thuộc Bước 5, ngoài phạm vi lượt chạy này; ba điểm trên là ứng viên trực tiếp)* |
+| **Đảo ngược được không, tốn bao nhiêu** | Ranh giới service theo domain đã rõ — dễ **thay/rút bớt từng service riêng lẻ** về sau (ví dụ gộp Review vào Promotion nếu tải thấp) mà không phải viết lại toàn bộ; nhưng **gộp ngược lại thành ít service hơn** (nếu phát hiện team quá nhỏ để vận hành 10 service) tốn công tái cấu trúc network/DB đáng kể |
+
+**Sơ đồ mức khối** *(C4 Context/Container — chỉ hộp lớn, chưa phải component; xem legend §3.3)*
+
+```mermaid
+flowchart LR
+    subgraph P1["P1 — Modular microservices (~10 service, database-per-service)"]
+        Client1["Web/Seller/Admin Clients"] -->|"1 · HTTPS REST, sync"| GW1["API Gateway / BFF"]
+        GW1 -->|"2 · REST, sync"| SVC1["~10 bounded-context services\n(Identity, Catalog, Search, Cart&Order,\nPayment, Seller, Commission, Promo,\nReview, Notify, Shipping)"]
+        SVC1 -->|"3 · publish, async"| MQ1[("Kafka / Amazon MSK")]
+        MQ1 -->|"4 · consume, async"| SVC1
+        SVC1 -->|"5 · SQL, sync"| DB1[("RDS PostgreSQL Multi-AZ\ndatabase-per-service, ~10 logic DB")]
+        SVC1 -->|"6 · cache/session, sync"| CACHE1[("ElastiCache Redis")]
+        SVC1 -->|"7 · index/query, sync"| SEARCH1[("OpenSearch, đa node")]
+        SVC1 -->|"8 · REST/webhook, sync+async"| EXT1["VNPay · Momo · GHN · GHTK · Email/SMS"]
+    end
+```
+
+### P2 — Modular monolith + managed AWS services, tách riêng Payment *(phương án đối trọng độc lập)*
+
+| | |
+|---|---|
+| **Ý tưởng một câu** | Một (hoặc vài) deployable module hoá theo domain, chạy trên ECS Fargate với 2–3 nhóm service thay vì 10, dùng SQS/EventBridge thay Kafka/MSK, tách riêng duy nhất **Payment Service** để giữ ranh giới PCI-DSS |
+| **Thành phần chính** | Modular monolith gồm module: Identity, Catalog & Inventory, Cart & Order (+ Dispute), Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment — chạy trong 2–3 nhóm ECS Fargate service (ví dụ: nhóm "giao dịch" Cart/Order/Catalog tách riêng để scale nhanh hơn nhóm "hỗ trợ" Seller/Promo/Review/Notify/Shipping); **Payment Service** tách hoàn toàn độc lập (network + IAM riêng) — bắt buộc theo `CON-06`, không phải tuỳ chọn |
+| **Mua gì / tự làm gì** | Giống P1 về business logic tự xây; khác ở lựa chọn hạ tầng: SQS/EventBridge (không cần cụm Kafka tự quản lý), OpenSearch **hoãn** dùng managed service đa node ngay từ đầu — dùng Postgres full-text search cho giai đoạn đầu MVP, chuyển sang OpenSearch khi có bằng chứng cần (dựa `DRV-04` số liệu thật sau go-live) |
+| **Dữ liệu nằm ở đâu, ai sở hữu** | 1 RDS PostgreSQL Multi-AZ chính, chia theo schema-per-module (ranh giới logic rõ ràng dù chung instance) — **trừ** Payment có RDS riêng nhỏ, tách biệt hoàn toàn khỏi cụm chính (không service khác truy cập trực tiếp) |
+| **Ai vận hành** | Cùng team FTE như P1 (chưa có số thật khác biệt — cả hai phương án dùng chung giả định `DEC-02`), nhưng **số đơn vị triển khai cần vận hành/on-call giảm từ ~10 xuống ~3** (2–3 nhóm monolith + 1 Payment Service riêng) — khớp trực tiếp với FTE DevOps trung bình thấp (~0,7 FTE, nguồn giống P1) |
+| **Thời gian tới bản chạy được** | Không cần hạng mục dựng "event backbone Kafka/MSK" (XL, 35% contingency) như P1 — SQS/EventBridge là managed service dùng ngay, giảm phần lớn effort tương ứng trong `WBS-03`; các hạng mục nghiệp vụ (WBS-18…43) không đổi giữa P1/P2 vì cùng phạm vi FR |
+| **Chi phí 3 năm (sơ bộ, số lượng thành phần — chưa quy đổi VND)** | 1–2 RDS instance (thay vì ~10 logic DB cần theo dõi riêng) + SQS/EventBridge (không có cụm phải patch/scale thủ công như MSK) + Postgres FTS giai đoạn đầu (không cần cụm OpenSearch đa node ngay) + 2–3 ECS service group (thay vì ~10) — ít thành phần quản lý độc lập hơn hẳn P1. Cùng hạn chế: **8/8 khoản non-labor trong hồ sơ thầu `amount: null`** — không có số VND thật, chỉ so sánh số lượng/loại thành phần |
+| **Rủi ro chính** | (a) SQS/EventBridge chưa được đo throughput thật cho tải đỉnh `DRV-04` — `ASM-07`; (b) 1 RDS chính cho nhiều module chưa đo tải ghi/đọc gộp — `ASM-08`; (c) cùng rủi ro đối tác bên ngoài 🔴 như P1 (`CTX §4.2`, không phụ thuộc kiến trúc nội bộ); (d) nếu traffic thật vượt xa dự kiến, tách Catalog/Search ra khỏi monolith muộn sẽ tốn hơn tách từ đầu (đánh đổi đã nêu ở §1). *(Chưa lập `ARISK-nn` chính thức — Bước 5)* |
+| **Đảo ngược được không, tốn bao nhiêu** | Module hoá rõ theo domain trong code (namespace/package riêng biệt) giúp tách thành service riêng về sau **có kế hoạch** khi có bằng chứng tải thật cần (khác gộp ngược từ 10 service như P1) — nhưng tốn công tách hạ tầng (network, DB, CI/CD riêng) tại thời điểm tách, không miễn phí |
+
+**Sơ đồ mức khối** *(C4 Context/Container — chỉ hộp lớn; xem legend §3.3)*
+
+```mermaid
+flowchart LR
+    subgraph P2["P2 — Modular monolith + managed AWS, Payment tách riêng"]
+        Client2["Web/Seller/Admin Clients"] -->|"1 · HTTPS REST, sync"| GW2["API Gateway / ALB"]
+        GW2 -->|"2 · REST, sync"| MONO2["Modular monolith\n(Identity, Catalog, Cart&Order, Seller,\nCommission, Promo, Review, Notify, Shipping)\n2-3 nhóm ECS Fargate"]
+        GW2 -->|"2b · REST, sync, cô lập mạng riêng"| PAY2["Payment Service\n(tách bắt buộc — CON-06 PCI-DSS SAQ A)"]
+        MONO2 -->|"3 · publish, async"| BUS2[("SQS / EventBridge")]
+        PAY2 -->|"3b · publish, async"| BUS2
+        BUS2 -->|"4 · consume, async"| MONO2
+        MONO2 -->|"5 · SQL, sync"| DB2[("RDS PostgreSQL Multi-AZ\n1 cụm chính, schema-per-module")]
+        PAY2 -->|"5b · SQL, sync"| DBPAY2[("RDS riêng, nhỏ — chỉ Payment")]
+        MONO2 -->|"6 · cache/session, sync"| CACHE2[("ElastiCache Redis")]
+        MONO2 -->|"7 · index/query, sync"| SEARCH2[("Postgres full-text (giai đoạn đầu)\n→ OpenSearch khi có bằng chứng cần")]
+        MONO2 -->|"8 · REST/webhook, sync+async"| EXT2["GHN · GHTK · Email/SMS"]
+        PAY2 -->|"8b · REST/webhook, sync+async"| EXTPAY2["VNPay · Momo"]
+    end
+```
+
+### 3.3 Legend cho cả hai sơ đồ P1/P2 *(bắt buộc theo `D4`)*
+
+| Số | Loại mũi tên | Giao thức | Sync/Async | Ghi chú |
+|---|---|---|---|---|
+| 1 | Client → Gateway | HTTPS REST | Sync | Người dùng chờ phản hồi |
+| 2 / 2b | Gateway → Service | REST (nội bộ) | Sync | 2b (P2): Payment nằm sau ranh giới mạng/IAM riêng, không chung network với monolith |
+| 3 / 3b | Service → Message bus | Publish event | Async | Domain event (VD `OrderPlaced`) |
+| 4 | Message bus → Service | Consume event | Async | Xử lý chuỗi sau đặt hàng (hoa hồng, payout, notify, loyalty) |
+| 5 / 5b | Service → Database | SQL (JDBC/driver) | Sync | 5b (P2): Payment có RDS riêng, không service khác truy cập |
+| 6 | Service → Cache | Redis protocol | Sync | Session, giỏ hàng, cache đọc |
+| 7 | Service → Search | Query API | Sync | P1: OpenSearch ngay từ đầu · P2: Postgres FTS giai đoạn đầu |
+| 8 / 8b | Service ↔ Đối tác ngoài | REST/webhook (theo `SAD.md §3.4`) | Sync (gọi) + Async (webhook/IPN) | Timeout/retry cụ thể: xem `CTX §4.2`, kế thừa `SAD.md §3.4` — **chưa kiểm chứng với sandbox thật** (🔴, `CON-04`) |
+
+*C4 mức: **Container** (không phải Component) — mỗi hộp là một đơn vị triển khai/nhóm đơn vị
+triển khai, chưa xuống tới class/module code. Không trộn mức.*
+
+---
+
+## 4. Bảng chấm điểm
+
+*Thang 1–5. Chỉ chấm các phương án đã qua gate cứng §2.1 (P0, P1, P2). P3, P4 bị loại ở §5,
+không chấm điểm đầy đủ.*
+
+| Tiêu chí | Trọng số | P0 | P1 | P2 |
+|---|---|---|---|---|
+| 1. Đáp ứng `DRV` Must | 25% | 1 | 5 | 4 |
+| 2. Chi phí 3 năm (sơ bộ) | 20% | 5 | 2 | 4 |
+| 3. Thời gian tới bản chạy được | 15% | 5 | 2 | 4 |
+| 4. Rủi ro kỹ thuật | 15% | 5 | 2 | 4 |
+| 5. Năng lực team & vận hành (Conway) | 15% | 5 | 2 | 5 |
+| 6. Khả năng tiến hoá | 10% | 1 | 4 | 3 |
+| **Tổng có trọng số** | 100% | **3.60** | **2.95** | **4.05** |
+
+**Lý do từng ô**
+
+| Tiêu chí | P0 | P1 | P2 |
+|---|---|---|---|
+| 1. `DRV` Must | Không xây gì ⇒ vi phạm trực tiếp `DRV-01` (blocker) — điểm sàn | Đáp ứng đầy đủ nhất: scale-out **độc lập** Catalog/Search khỏi Checkout ngay từ đầu (`DRV-04`), event backbone tách chuỗi hoa hồng/payout khỏi luồng chính (`DRV-06`) | Đáp ứng phần lớn nhưng scale-out Catalog/Search **chưa độc lập** ở giai đoạn đầu (chung nhóm monolith) — thua P1 đúng một bậc, không giả vờ ngang bằng |
+| 2. Chi phí (sơ bộ) | Không phát sinh chi phí hạ tầng | Nhiều thành phần managed độc lập nhất phải vận hành (~10 RDS logic + MSK + OpenSearch đa node + ~10 ECS group) — chi phí vận hành sơ bộ cao nhất trong 2 phương án đã qua gate | Ít thành phần hơn hẳn (1–2 RDS + SQS/EventBridge + Postgres FTS + 2–3 ECS group) — chi phí vận hành sơ bộ thấp hơn P1 |
+| 3. Thời gian | Có ngay, 0 effort | `WBS-03` (dựng nền tảng dịch vụ & event backbone) một mình đã 70,2 MD (XL, +35% contingency) trước khi làm nghiệp vụ | Không cần dựng cụm Kafka/MSK — dùng managed service có sẵn ngay, effort nền tảng thấp hơn đáng kể so với P1 |
+| 4. Rủi ro kỹ thuật | Không có rủi ro kỹ thuật (không xây) | Không có bằng chứng team từng vận hành Kafka/MSK, OpenSearch, EKS production (`CTX §4.4`); cảnh báo lệch WBS↔UCP 54,47% (`estimate.computed.json.crosscheck`) | Công nghệ managed phổ biến hơn (RDS, SQS/EventBridge, ECS Fargate) — rủi ro "công nghệ mới" thấp hơn; rủi ro đối tác bên ngoài 🔴 giữ nguyên như P1 (không đổi bởi kiến trúc nội bộ) |
+| 5. Năng lực team (Conway) | Không cần team | ~10 service độc lập trong khi FTE BE trung bình toàn dự án chỉ **~18,31 MM/~7 tháng ≈ 2,6 FTE trung bình** (`estimate.computed.json.mmByRole.BE`) — mỗi kỹ sư BE ôm trung bình 3–4 service, vi phạm Conway rõ theo `DEC-02` | Số đơn vị triển khai cần vận hành giảm còn ~3 (2–3 nhóm monolith + Payment) — khớp với cùng FTE BE ~2,6 trung bình tốt hơn P1 |
+| 6. Khả năng tiến hoá | Giữ nguyên = không tiến hoá được, mỗi ngày trì hoãn là một ngày mất cơ hội thị trường không thu hồi được | Ranh giới service đã tách sẵn — dễ thay/rút từng service riêng lẻ về sau | Module hoá trong code dễ tách dần khi có bằng chứng tải thật, nhưng tách hạ tầng lúc đó tốn công hơn P1 (đã tách sẵn) — thua P1 đúng ở tiêu chí này |
+
+🔴 **Điểm tổng P1 (2.95) và P2 (4.05) chênh 1.10 — đủ phân biệt**, không rơi vào bẫy "chênh <0.3".
+P0 (3.60) và P2 (4.05) chênh 0.45 — cũng đủ phân biệt, nhưng nhắc lại: **P0 vi phạm `DRV-01`
+(Must, blocker)** nên dù điểm tổng gần P2, P0 **không phải lựa chọn khả thi** — đây là lý do
+điểm P0 cao ở nhiều tiêu chí "chi phí/thời gian/rủi ro" (vì không làm gì thì các tiêu chí đó tự
+nhiên thấp) nhưng lại thua tuyệt đối ở tiêu chí có trọng số cao nhất (Đáp ứng `DRV` Must, 25%).
+
+---
+
+## 5. Phương án bị loại và lý do *(bắt buộc — quy tắc `D3`)*
+
+| Phương án | Đã cân nhắc vì | Loại vì | Gắn với | Điều kiện nào thì xét lại |
+|---|---|---|---|---|
+| **P3 — Mua/tích hợp nền tảng multi-vendor mã nguồn mở** (VD Medusa.js, Bagisto) + tuỳ biến tách đơn đa seller, hoa hồng/payout, KYC seller | Có thể giảm effort xây lõi catalog/cart/order từ đầu, tăng tốc thời gian ra bản chạy được — đúng như gợi ý cân nhắc trong ghi chú người duyệt | (a) Không có bằng chứng nền tảng ứng viên nào hỗ trợ sẵn mô hình hold 3–7 ngày + audit trail tài chính riêng theo đúng `DRV-06`/FR-21/22 — phải sửa lõi sâu, mất lợi thế "mua sẵn"; (b) **không kiểm chứng được cô lập Payment Service** cho PCI-DSS SAQ A nếu không sửa sâu lõi nền tảng — vi phạm `CON-06` (gate cứng §2.1); (c) chưa có bằng chứng năng lực team với stack cụ thể của nền tảng này (PHP/Laravel hay Node tuỳ nền tảng) — `ASM` mới, không phải số liệu đã có | `CON-06` (loại cứng), `CON-05` (rủi ro năng lực) | Nếu Tech Lead xác nhận có kinh nghiệm sâu với một nền tảng cụ thể **và** nền tảng đó chứng minh được (qua POC) khả năng cô lập Payment đúng yêu cầu SAQ A mà không sửa lõi — xét lại cho các module không nhạy cảm tài chính (VD Catalog/Review) |
+| **P4 — Serverless-first** (Lambda + API Gateway + Step Functions + DynamoDB/Aurora Serverless, EventBridge cho toàn bộ luồng, không container) | Chi phí theo request, không cần quản lý cluster, scale tự động cho flash sale — đúng gợi ý cân nhắc trong ghi chú người duyệt | (a) Cold-start của Lambda cho luồng checkout đồng bộ có nguy cơ ảnh hưởng trải nghiệm ở đúng bước `DRV-02` (bỏ giỏ) — **chưa có POC đo cold-start trong ngữ cảnh VPC + kết nối RDS**; (b) chưa có bằng chứng năng lực team với serverless-at-scale (`CON-05`); (c) mô hình chi phí theo request khó ước lượng ở quy mô "hàng nghìn–chục nghìn concurrent user" (`DRV-04`) mà không có bài đo — rủi ro hoá đơn tăng phi tuyến (nguồn rủi ro "Chi phí", `SKILL.md` Bước 5) | `DRV-02`, `CON-05` | Nếu có POC đo cold-start đạt yêu cầu checkout và Tech Lead xác nhận năng lực serverless-at-scale — xét lại cho các luồng bất đồng bộ thuần (VD Notification, Commission batch) như một lựa chọn lai với P2, không nhất thiết toàn bộ hệ thống |
+
+*"Team quen công nghệ X" là lý do hợp lệ — ở đây áp dụng ngược: P3/P4 bị loại một phần vì
+**chưa có bằng chứng** team quen (`ASM` mới), không phải vì SA không thích công nghệ đó.*
+
+---
+
+## 6. Bảng đánh đổi trình PO
+
+*Dịch lựa chọn kỹ thuật thành ngôn ngữ PO hiểu được — so sánh P1 và P2 (P0 đã loại ở §4 vì vi
+phạm `DRV-01`).*
+
+| Nếu chọn | Được | Mất | Tiền chênh 3 năm | Thời gian chênh |
+|---|---|---|---|---|
+| **P1** (giữ theo `SAD.md`/hồ sơ thầu) | Scale-out độc lập Catalog/Search khỏi Checkout **ngay từ đầu**; không cần thiết kế lại nếu traffic tăng nhanh hơn dự kiến | Rủi ro Conway cao với team hiện tại (mỗi BE ôm 3–4 service); effort dựng nền tảng lớn hơn; nhiều thành phần managed phải vận hành hơn (MSK, OpenSearch đa node) | **Chưa quy đổi VND** (`TCO` Bước 5) — sơ bộ **cao hơn P2** vì số lượng managed component nhiều hơn (8/8 khoản non-labor hồ sơ thầu đều chưa có số, không thể so tuyệt đối) | +70,2 MD riêng cho nền tảng event backbone (`WBS-03`) so với P2 không cần cụm Kafka/MSK riêng |
+| **P2** (khuyến nghị SA) | Khớp Conway với team giả định `DEC-02`; thời gian tới bản chạy được nhanh hơn; ít managed component phải vận hành hơn | Scale-out độc lập Catalog/Search **kém hơn ngay từ đầu** — có thể phải tách service khi traffic thật vượt ngưỡng, tốn chi phí tái cấu trúc lúc đó (không miễn phí, không định lượng được ở lượt này) | **Chưa quy đổi VND** — sơ bộ **thấp hơn P1** | **-70,2 MD** so với P1 ở riêng hạng mục nền tảng; effort nghiệp vụ (WBS-18…43) không đổi giữa hai phương án |
+
+---
+
+## 7. Cắt gì thì giảm bao nhiêu
+
+*Chưa áp dụng ở lượt chạy này.* `TCO` bằng VND thật (Bước 5) chưa tồn tại, và `CON-01` (ngân
+sách) vẫn "Chưa xác định" (`OQ-005` còn mở) — không có số ngân sách đã duyệt để đối chiếu và đề
+xuất cắt giảm có ý nghĩa. Mục này sẽ điền khi `TCO` (Bước 5) hoàn thành **và** `OQ-005` có câu
+trả lời bằng số thật.
+
+---
+
+## 8. Giả định & Ngoài phạm vi
+
+**Giả định** — `ASM-nn` ảnh hưởng tới lựa chọn này *(tiếp số từ `CTX §5`, bắt đầu `ASM-07`)*:
+
+| ID | Giả định | Nếu sai thì phương án nào đổi |
+|---|---|---|
+| `ASM-07` | Amazon SQS/EventBridge (không phải Kafka/MSK) đủ đáp ứng thông lượng cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải đỉnh flash sale (`DRV-04`, "hàng nghìn–chục nghìn concurrent user") — **chưa có POC đo throughput thật trong ngữ cảnh này**. Cách xác minh: POC đo SQS FIFO/EventBridge với payload tương tự `OrderPlaced` ở tải giả lập tương ứng `DRV-04`. Chủ: Tech Lead. Hạn: trước khi chốt `ADR` message backbone ở GĐ2 | Nếu sai (không đủ throughput): P2 phải bổ sung Kafka/MSK riêng cho hot-path đặt hàng (kiến trúc lai P1+P2 cho riêng luồng này), không chuyển hẳn sang P1 vì phần còn lại của P1 vẫn vi phạm Conway |
+| `ASM-08` | 1 cụm RDS PostgreSQL Multi-AZ chính (schema-per-module) đủ chịu tải ghi/đọc gộp cho toàn bộ module ngoại trừ Payment tách riêng — **chưa đo**. Cách xác minh: POC load test theo kịch bản `NFR-01`/`NFR-02`. Chủ: Tech Lead/DBA. Hạn: trước GĐ2 (`DAT`) | Nếu sai: phải tách read replica/DB riêng cho Catalog/Search sớm hơn dự kiến trong P2, tăng chi phí vận hành tiệm cận P1 cho phần đó |
+| `ASM-09` | Bộ tiêu chí và trọng số ở §2.2 (mặc định từ template, chưa qua buổi duyệt riêng với PO/Tech Lead) phản ánh đúng ưu tiên thật của dự án — xem cảnh báo cuối §2.2 | Nếu PO tăng mạnh trọng số "Đáp ứng `DRV` Must", thứ hạng P1/P2 có thể đổi (P1 mạnh nhất ở tiêu chí này) — xem `OQ-011` |
+
+*Giả định `ASM-01…06` của `CTX` (ngân sách, deadline, đội vận hành, residency, dùng `SAD.md` làm
+điểm khởi đầu, hoá đơn điện tử hoãn) vẫn áp dụng nguyên trạng cho toàn bộ `OPT` — không lặp lại
+nội dung ở đây, chỉ tham chiếu.*
+
+**Ngoài phạm vi:**
+
+- `TCO` bằng VND thật, 3 năm, ≥2 kịch bản tải — thuộc Bước 5, **chưa làm** ở lượt chạy này. Mọi
+  con số "chi phí" trong tài liệu này là **số lượng/loại thành phần hạ tầng để so sánh tương
+  đối**, không phải tiền.
+- `ARISK` (sổ rủi ro kiến trúc chính thức) và kế hoạch POC có tiêu chí pass/fail viết trước —
+  thuộc Bước 5, **chưa lập**. `ASM-07`/`ASM-08` ở trên là ứng viên trực tiếp để nâng thành
+  `ARISK-nn` khi Bước 5 chạy.
+- Thiết kế chi tiết ranh giới service/module (contract cụ thể, tên bảng, tên topic/queue) —
+  thuộc GĐ2 (`SAD`, `ADR`), **không** được vẽ ở đây dù đã có gợi ý từ `SAD.md`/hồ sơ thầu.
+- Quyết định cuối cùng chọn P1 hay P2 (hay phương án lai) — đây là khuyến nghị của SA, **chưa
+  phải quyết định**; quyết định thật cần PO + Tech Lead ký (`OQ-011`).
+- Đối chiếu chi tiết với `OQ-003` (giữ toàn sàn hay thu hẹp phạm vi) — cả ba phương án ở đây mô
+  tả kiến trúc tổng thể toàn sàn theo phạm vi đã chốt của lượt chạy này; nếu `OQ-003` sau này
+  quyết định thu hẹp, bảng chấm điểm có thể cần chấm lại với phạm vi hẹp hơn.
+
+---
+
+## 9. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
+|---|---|---|---|---|---|
+| `OQ-010` | Tech Lead xác nhận: đội thi công **thật** (không phải đề xuất trong hồ sơ thầu) có kinh nghiệm vận hành production nào với Kafka/MSK, OpenSearch cluster, EKS chưa? Đây là input trực tiếp cho tiêu chí "Rủi ro kỹ thuật" đã chấm P1=2/P2=4 ở §4. | Tech Lead | 2026-09-12 | Điểm "Rủi ro kỹ thuật" của P1 trong `OPT`; `ARISK` Bước 5 | Nếu đội thật có kinh nghiệm Kafka/MSK/OpenSearch/EKS production: nâng điểm rủi ro kỹ thuật P1 lên 3–4, thu hẹp khoảng cách điểm tổng với P2 (từ 1.10 xuống có thể ~0.4–0.7) — vẫn cần xem lại tiêu chí "Năng lực team & vận hành" (Conway) vì đó không phụ thuộc kinh nghiệm công nghệ mà phụ thuộc **số người** so với **số service** |
+| `OQ-011` | PO + Tech Lead chọn phương án nào giữa P1 (theo `SAD.md`/hồ sơ thầu hiện có) và P2 (khuyến nghị SA), hay yêu cầu SA dựng thêm phương án lai (VD P2 nhưng tách Catalog/Search từ đầu)? Đây chính là nội dung cần ký ở AG1 cho `OPT`. | PO + Tech Lead | 2026-09-12 | Ký AG1 cho `OPT`; bắt đầu Bước 5 (`TCO`/`ARISK`) theo đúng phương án đã chọn | Nếu chọn P1 dù rủi ro Conway cao: phải tăng team BE thật lên gần mức bid đề xuất (đỉnh điểm 10 người, chủ yếu BE) **hoặc** giảm số service xuống dưới 10 trước khi GĐ2 chốt ranh giới — nếu không, ranh giới service ở `SAD` GĐ2 sẽ vi phạm Conway ngay từ thiết kế, phát hiện muộn hơn và tốn hơn theo đúng cảnh báo của `GUIDE.md` |
+| `OQ-012` | Có cần chạy POC đo throughput SQS/EventBridge (`ASM-07`) **trước khi** chốt P2 làm phương án chính thức, hay chấp nhận rủi ro tạm thời và bổ sung `ARISK` + kế hoạch POC ở Bước 5 rồi mới đo? | Tech Lead | 2026-09-12 | `ADR` message backbone ở GĐ2; kế hoạch POC ở `ARISK` Bước 5 | Nếu không đo trước khi chốt `ADR` GĐ2 mà đo sau mới phát hiện SQS/EventBridge không đủ throughput: phải viết lại `ADR` (Supersede) sau khi đã thiết kế chi tiết — tốn hơn phát hiện ở GĐ1 theo đúng nguyên tắc `workflow.md §6` "GĐ2 → GĐ1" |
+
+---
+
+## Tự chấm
+
+### ① Bảng tự chấm Gate AG1 *(`workflow.md §2`, cập nhật từ `CTX`)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | `CTX` có `DRV-nn`, mỗi driver ghi rõ áp lực kinh doanh | ✅ | Không đổi — xem `CTX §2` |
+| 2 | `CTX` có `CON-nn` (ràng buộc 6 nhóm) | ✅ *(với lưu ý)* | Không đổi — xem `CTX §3` |
+| 3 | `CTX` mô tả hiện trạng as-is | ✅ *(với lưu ý)* | Không đổi — xem `CTX §4` |
+| 4 | `OPT` có ≥2 phương án được chấm điểm, nêu rõ phương án bị loại + lý do | ✅ | **Mới đạt ở lượt này** — 3 phương án chấm điểm (P0, P1, P2) + 2 phương án bị loại có lý do gắn `CON`/`DRV` cụ thể (P3, P4). Trọng số tiêu chí **chưa qua buổi duyệt riêng với PO/Tech Lead** (`ASM-09`) — đây là hạn chế cần ghi nhận, không phải lý do đánh rớt tiêu chí này (tiêu chí AG1 chỉ đòi hỏi "có ≥2 phương án chấm điểm + nêu loại", không đòi hỏi trọng số đã duyệt) |
+| 5 | `TCO` có chi phí 3 năm, ≥2 kịch bản tải | ☐ | **Chưa tạo file `TCO`** — thuộc Bước 5, ngoài phạm vi lượt chạy này. `OPT` chỉ so sánh số lượng/loại thành phần hạ tầng, không phải VND |
+| 6 | `ARISK` có rủi ro cao kèm chủ + biện pháp | ☐ | **Chưa tạo file `ARISK`** — thuộc Bước 5. `ASM-07`/`ASM-08` ở §8 là ứng viên trực tiếp để nâng thành `ARISK-nn` |
+| 7 | Rủi ro cao chưa chứng minh được có kế hoạch POC | ☐ | Phụ thuộc `ARISK`, chưa làm. `OQ-012` đã đặt câu hỏi về thời điểm chạy POC SQS/EventBridge |
+
+**Kết luận tự chấm AG1:** **Vẫn chưa đủ điều kiện ký** — 4/7 tiêu chí ✅ (tăng từ 3/7 ở `CTX`).
+Cần Bước 5 (`TCO`, `ARISK` + kế hoạch POC) trước khi PO + Tech Lead có thể ký AG1 đầy đủ. Ngay
+cả khi ký AG1 chỉ dựa trên `OPT` này, **khuyến nghị không ký cho tới khi `OQ-005`/`OQ-006`/
+`OQ-008`/`OQ-010`/`OQ-011` có câu trả lời** vì bảng chấm điểm ở đây dùng số liệu tham khảo hồ sơ
+thầu (Draft), không phải số đã xác nhận.
+
+### ② Checklist D1–D12 *(`design-rules.md`)*
+
+| # | Mục | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| D1 | Một ADR một quyết định | N/A | Tài liệu này không tạo `ADR` — quyết định kiến trúc chính thức (nếu có) sẽ thành `ADR` ở GĐ2 sau khi P1/P2 được PO/Tech Lead chọn |
+| D2 | Không NFR định tính | N/A | `OPT` không chứa `QAS`; các con số hạ tầng dùng nguồn cụ thể (`estimate.computed.json`), không phải mô tả định tính |
+| D3 | Nêu phương án bị loại + lý do gắn `CON`/`QAS` | ✅ | §5 — P3 loại vì `CON-06` (gate cứng); P4 loại vì `DRV-02`/`CON-05` (rủi ro + thiếu bằng chứng năng lực). Cả hai đều có điều kiện xét lại rõ ràng, không phải loại vĩnh viễn theo cảm tính |
+| D4 | Sơ đồ khai báo mức C4 + legend | ✅ | P1/P2 đều khai báo "C4 mức Container", có bảng legend chung §3.3 giải thích từng loại mũi tên + sync/async |
+| D5 | Interface có chủ/contract | N/A | Chưa tới `ICD` (GĐ2) — §3.4 `SAD.md` chỉ kế thừa nguyên trạng đề xuất, ghi rõ chưa xác minh sandbox thật (`CON-04`) |
+| D6 | Phụ thuộc ngoài process có timeout/retry | N/A | Chưa tới `FAIL` (GĐ2); bảng legend §3.3 dòng 8/8b dẫn về `CTX §4.2`/`SAD.md §3.4` cho chi tiết timeout/retry hiện có (đề xuất, chưa kiểm chứng) |
+| D7 | Một chủ sở hữu dữ liệu | ✅ *(ở mức khối)* | Cả P1 và P2 đều ghi rõ Payment có DB riêng, không service/module khác truy cập trực tiếp — chi tiết từng thực thể để `DAT` (GĐ2) |
+| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` (GĐ3) |
+| D9 | Con số hạ tầng quy ra tiền + nguồn; `INF` khớp `TCO` | 🟡 Một phần | Mọi con số hạ tầng ở đây có **nguồn** (`estimate.computed.json`, `SAD.md §3.1-3.4`) nhưng **chưa quy ra tiền** — đúng theo yêu cầu "chỉ mức sơ bộ để so sánh tương đối" của ghi chú người duyệt; quy đổi VND đầy đủ + khớp `TCO`/`INF` là việc của Bước 5/GĐ2 |
+| D10 | Không quyết định thay người có thẩm quyền | ✅ | §1 ghi rõ "khuyến nghị… chưa phải quyết định"; mọi lựa chọn cuối (P1 vs P2, trọng số tiêu chí, thời điểm chạy POC) đều để `OQ-010/011/012` kèm hệ quả phương án ngược bằng số/định tính cụ thể, không tự quyết |
+| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §8 đầy đủ — `ASM-07/08/09` mới, có cách xác minh/chủ/hạn; mục "Ngoài phạm vi" liệt kê rõ `TCO`/`ARISK`/thiết kế chi tiết GĐ2/quyết định cuối cùng đều chưa làm |
+| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có ngay sau Change Log |
+
+### ③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì
+
+Ba câu hỏi mới của `OPT` (`OQ-010`, `OQ-011`, `OQ-012`) cộng với các câu hỏi còn mở từ `CTX`
+(`OQ-001`, `OQ-002` *(đã đóng, xem `CTX`)*, `OQ-003`, `OQ-004`, `OQ-005`, `OQ-006`, `OQ-007`,
+`OQ-008`) — xem sổ đầy đủ tại `00-index/OQ_e-commerce.md` (đã đồng bộ ở Change Log v1.5).
+Ba câu quan trọng nhất cho việc ký AG1 của chính `OPT` này: **`OQ-011`** (chọn P1/P2 — chặn ký
+AG1 trực tiếp), **`OQ-010`** (kinh nghiệm team thật — chặn độ tin cậy điểm "Rủi ro kỹ thuật"),
+**`OQ-005`/`OQ-006`/`OQ-008`** (ngân sách/deadline/team thật — chặn `TCO`/`ARISK` Bước 5 có ý
+nghĩa).
+
+**Nhắc:** AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header file này) trước khi chạy
+`/sa-2-architecture`. Cần chạy tiếp Bước 5 (`TCO`, `ARISK`) của `sa-1-context` trước khi bảng tự
+chấm AG1 đạt đủ 7/7 tiêu chí.

sa-output/e-commerce/01-context/TCO_e-commerce_v1.0.md

@@ -0,0 +1,397 @@
+# TCO — Cost Model — e-commerce · Phương án P2 (chính) và P1 (đối chiếu)
+
+| | |
+|---|---|
+| **Version** | 1.1 |
+| **Date** | 2026-09-12 |
+| **Author** | SA (skill sa-1-context, chế độ `go`, hoạt động `cost-risk`) |
+| **Status** | 🟡 Draft *(duyệt từng phần — xem `Approved by`; chấp nhận cấu trúc 4 nhóm chi phí (§3–§6), 2 kịch bản tải A/B (§2), và kết luận thứ tự tương đối "P2 rẻ hơn P1" ở cả hai kịch bản (§1, §7); đơn giá AWS (`ASM-11`), tỷ giá (`ASM-12`), số FTE vận hành (`ASM-14`) và 5 khoản non-labor (`OQ-013…017`) **chưa xác nhận** — đây **chưa phải** AG1 toàn phần, Tech Lead chưa ký, `OQ-004` còn mở; xem "Tự chấm" §①)* |
+| **Approved by** | PO (uỷ quyền, chế độ chạy thử): **Điều phối dự án** — duyệt **từng phần** bản v1.1 · 2026-09-12 (sau khi đã sửa lỗi chép số §1 P2-B: dòng "Vận hành/nhân sự (3 năm)" P2-B = 5.600 triệu, Tổng 3 năm P2-B = 13.977,5 triệu): chấp nhận cấu trúc 4 nhóm chi phí (hạ tầng AWS · license/SaaS · vận hành/nhân sự · chi phí một lần xây dựng), 2 kịch bản tải A/B, và kết luận thứ tự tương đối **P2 rẻ hơn P1** ở cả hai kịch bản. **Chưa xác nhận** (giữ `Confidence` 🔴): đơn giá AWS (`ASM-11`), tỷ giá quy đổi USD/VND (`ASM-12`), số FTE đội Ops (`ASM-14`), và 5 khoản non-labor chưa tính được (`OQ-013…017`). Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-09`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở. Status **giữ** 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện. · Tech Lead: — *(chưa ký)* |
+| **Source** | `01-context/CTX_e-commerce_v1.0.md` (v1.2 trong header) §2 `DRV-04/05/06`, §3 `CON-01/02/03/04/05/08`, §4.1, §4.2, §4.4 · `01-context/OPT_e-commerce_v1.0.md` §1, §3 (P1/P2), §4, §8 `ASM-07/08/09` · `e-commerce/bid/estimate.computed.json` (`totals`, `cost`, `timeline`, `staffing`) · `e-commerce/bid/bid-config.md` (`rateCard`, `vatPct`) · `e-commerce/bid/40-financial-proposal.md` §C2–C5 · `e-commerce/docs/sections/03-kien-truc.md` §3.2–§3.4 · `e-commerce/docs/sections/09-van-hanh-kiem-thu.md` §9.3–§9.5 · `ba-output/e-commerce/01-discovery/RISK_CartCheckout_v1.0.md` (tham chiếu ID, không copy) |
+| **Scope** | Chi phí 3 năm cho **P2** (modular monolith + managed AWS, Payment tách riêng — phương án chính theo `DEC-06`) và **P1** (modular microservices theo `SAD.md`/hồ sơ thầu — đối chiếu), mỗi phương án tính theo 2 kịch bản tải. Đơn vị tiền: **VND**. Đơn giá hạ tầng AWS quy đổi từ USD (khu vực tham chiếu `ap-southeast-1`, xem `ASM-11`) |
+| **Confidence** | 🔴 Giả định chưa xác minh — kế thừa nguyên nhân của `CTX`/`OPT` (BA chưa ký G1, AG1 GĐ1 SA chưa từng chạy, ngoại lệ gate `DEC-01/03/04/05` tiếp tục ở `DEC-07`). Thêm hai lý do riêng của `TCO`: (a) đơn giá AWS **không** được truy vấn từ AWS Pricing Calculator/báo giá đại lý thời điểm hiện tại — là ước tính từ tri thức bảng giá công khai đã biết, **bắt buộc xác minh lại** trước khi PO dùng để duyệt ngân sách (`ASM-11`); (b) không có baseline tải thật (greenfield, `CTX §4.1`) nên toàn bộ kịch bản tải là giả định suy từ `DRV-04` (`ASM-10`), không phải đo lường |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR/DEC |
+|---|---|---|---|---|
+| 1.1 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `cost-risk`) | Sửa lỗi chép số §1 P2-B theo phát hiện của người duyệt 2026-09-12: dòng "Vận hành/nhân sự (3 năm)" P2 — Kịch bản B đổi từ 5.800 triệu → **5.600 triệu** (đúng theo chi tiết cộng dồn ở §5: 5.400 nhân sự + 200 surge); Tổng 3 năm P2-B đổi từ 14.177,5 triệu (~14,18 tỷ) → **13.977,5 triệu (~13,98 tỷ)**, khớp số đã có sẵn ở §7. Viết lại ghi chú 🔴 "Ghi chú khớp số" ở §7 — nguyên nhân lệch là lỗi chép số ở §1, không phải làm tròn. Đã rà soát: dải tổng ở §1 "So sánh nhanh"/ARISK-07/OQ-005 (~11,2–19,1 tỷ) **không đổi** vì cận dưới (P2-A ~11,17 tỷ) và cận trên (P1-B ~19,06 tỷ) không liên quan tới ô bị sửa. Không sửa ARISK/OQ (không trích đúng con số 14.177,5/14,18). Không chạy lại ước lượng, không đổi Status/Confidence/Approved by. | — |
+| 1.1 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **từng phần** bản v1.1 (sau khi sửa lỗi chép số §1 P2-B ở dòng trên): chấp nhận cấu trúc 4 nhóm chi phí, 2 kịch bản tải A/B, kết luận thứ tự tương đối **P2 rẻ hơn P1**. Không đổi nội dung chuyên môn. Đơn giá AWS (`ASM-11`), tỷ giá (`ASM-12`), số FTE vận hành (`ASM-14`) và 5 khoản non-labor (`OQ-013…017`) **chưa xác nhận** — `Confidence` giữ 🔴. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-09`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở, Tech Lead **chưa ký**. Status **giữ** 🟡 Draft — AG1 toàn phần chưa đủ điều kiện (xem "Tự chấm" §①). | `DEC-09` |
+| 1.0 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `cost-risk`) | Bản đầu — Bước 5 (phần `TCO`) của `sa-1-context`. Tính chi phí 3 năm cho P2 (chính, theo `DEC-06`) và P1 (đối chiếu) theo 2 kịch bản tải (A — tải dự kiến, B — đỉnh flash sale/tăng trưởng, neo `DRV-04`). Tách 4 nhóm: hạ tầng AWS · license/SaaS · vận hành/nhân sự · chi phí một lần (xây dựng). Mọi con số hạ tầng có công thức + nguồn hoặc gắn `ASM-nn` kèm cờ "cần xác minh" theo `D9`. 8 khoản non-labor còn `amount: null` trong `estimate.computed.json` được xử lý: NL-01/NL-02 (hạ tầng AWS, OpenSearch) tính bằng công thức riêng của SA (mục đích khác ước lượng thầu); NL-03/04/05/07/08 chưa có cơ sở tính (phí giao dịch/vận chuyển/pentest/đào tạo phụ thuộc hợp đồng nhà cung cấp) — ghi `OQ-014…OQ-017`. Tiếp tục ngoại lệ gate `DEC-01/03/04/05`, ghi thêm `DEC-07`. `Confidence` 🔴 toàn tài liệu. | `DEC-07` |
+
+> Sơ đồ thắng về **quan hệ và luồng** (không có sơ đồ mới trong tài liệu này — xem sơ đồ khối P1/P2 ở `OPT §3`). Bảng/văn bản thắng về **ràng buộc và con số**. Mâu thuẫn ngoài hai loại này là lỗi tài liệu (`D12`).
+
+---
+
+## 0. Ghi chú Preflight & ngoại lệ gate — tiếp nối `CTX`/`OPT`
+
+Gate AG1 (PO + Tech Lead) chưa từng chạy cho dự án e-commerce; BA vẫn chưa ký G1 chính thức.
+Người dùng (vai điều phối dự án chạy thử) **tái khẳng định muốn tiếp tục** sang phần `TCO` của
+Bước 5 (`sa-1-context`) theo đúng ghi chú người duyệt của lượt chạy này.
+
+> **DEC-07 (SA)** — Tiếp tục chạy `sa-1-context` Bước 5 (phần `TCO`) cho e-commerce trong khi BA
+> vẫn chưa qua G1 và AG1 vẫn chưa từng chạy — tiếp nối `DEC-01/03/04/05`.
+> **Quyết định:** Tiếp tục, `Confidence 🔴` cho toàn bộ con số (giả định tải + giả định đơn giá
+> AWS) cho tới khi có số liệu tải thật (sau go-live) và báo giá AWS/đại lý chính thức.
+> **Người quyết:** Điều phối dự án (đại diện PO, dự án chạy thử).
+> **Radar (ước lượng):** ~3–4 (chi phí đảo ngược thấp — sửa lại `TCO` khi có số thật không tốn
+> nhiều · bán kính ảnh hưởng: `INF`/ngân sách GĐ2 phụ thuộc con số này nhưng bản thân việc ghi
+> tài liệu dưới ngoại lệ thì nhỏ · chưa chạm một `QAS` cụ thể · không ràng buộc dài hạn · không
+> tranh cãi mới, tiếp nối tiền lệ) → **ghi `DEC-nn`, không cần `ADR`**.
+> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng Bước 5, GĐ1 SA không đủ 4 artifact để audit AG1,
+> chậm tiến độ chạy thử tương ứng thời gian BA/PO hoàn tất các điều kiện gate thật.
+
+🔴 **Lưu ý quan trọng cho người ký:** đơn giá AWS dưới đây **không phải báo giá thật** — đây là
+ước tính dựa trên tri thức bảng giá công khai của AWS (không truy vấn AWS Pricing Calculator hay
+báo giá đại lý tại thời điểm chạy skill này), khu vực tham chiếu `ap-southeast-1` (Singapore, gần
+nhất với ràng buộc `CON-03`/`ASM-04` cho tới khi `OQ-007` xác nhận residency VN). **Bắt buộc**
+chạy lại qua AWS Pricing Calculator hoặc xin báo giá đại lý AWS tại Việt Nam trước khi dùng các
+con số này để duyệt ngân sách chính thức — xem `ASM-11`, `OQ-013`.
+
+---
+
+## 1. Tóm tắt cho người quyết định
+
+| | P2 — Kịch bản A | P2 — Kịch bản B | P1 — Kịch bản A | P1 — Kịch bản B |
+|---|---|---|---|---|
+| **Chi phí một lần (xây dựng, đã VAT)** | 3.552,2 triệu | 3.552,2 triệu | 3.762,6 triệu | 3.762,6 triệu |
+| **OpEx hạ tầng AWS (3 năm)** | 1.818,8 triệu | 4.425,8 triệu | 3.776,1 triệu | 7.339,2 triệu |
+| **License/SaaS (3 năm)** | 349,5 triệu | 349,5 triệu | 409,5 triệu | 409,5 triệu |
+| **Vận hành/nhân sự (3 năm)** | 5.400 triệu | 5.600 triệu | 6.750 triệu | 7.350 triệu |
+| **Đào tạo (một lần, Năm 1)** | 50 triệu | 50 triệu | 200 triệu | 200 triệu |
+| **Tổng 3 năm (VND)** | **≈ 11.170,5 triệu (~11,17 tỷ)** | **≈ 13.977,5 triệu (~13,98 tỷ)** | **≈ 14.898,2 triệu (~14,90 tỷ)** | **≈ 19.061,3 triệu (~19,06 tỷ)** |
+| **So với `CON-01` (ngân sách duyệt)** | ❌ **Không đối chiếu được** — `CON-01` mới có số lao động build (~3,76 tỷ, từ hồ sơ thầu), **không có** ngân sách vận hành 3 năm đã duyệt để so sánh (`OQ-005` còn mở) | | | |
+
+🔴 **Phát hiện quan trọng nhất của `TCO` này, cần trình PO ngay:** con số duy nhất PO/tài chính
+từng thấy (~3,76 tỷ VND, hồ sơ thầu) **chỉ là chi phí xây dựng một lần**. Chi phí vận hành 3 năm
+(hạ tầng + license + con người) — phần mà mọi dự án thật sự phải trả sau go-live — **lớn hơn**
+chi phí xây dựng ban đầu **2,1–4,0 lần** tuỳ phương án/kịch bản. Đây chính xác là điều `GUIDE.md`
+cảnh báo: *"TCO ra con số quá lớn, khách sẽ sốc — đó là giá trị của TCO, không phải vấn đề của
+nó."* `OQ-005` (ngân sách) cần được hỏi lại với con số full 3 năm này, không phải con số build.
+
+**P2 rẻ hơn P1 ở cả hai kịch bản** (~2,7 tỷ ở kịch bản A, ~4,9 tỷ ở kịch bản B) — khớp hướng
+khuyến nghị định tính của `OPT` (P2 ít managed component hơn, không cần cụm Kafka/MSK + OpenSearch
+đa node chạy 24/7 bất kể tải).
+
+---
+
+## 2. Giả định tải — nền của mọi con số dưới đây
+
+*Dự án greenfield (`CTX §4.1`) — không có baseline tải thật. Toàn bộ số dưới đây là `ASM-10`,
+suy từ `DRV-04` ("hàng trăm nghìn SKU, hàng trăm nghìn–hàng triệu user, đỉnh hàng nghìn–chục
+nghìn concurrent user mùa flash sale"), chọn **cận dưới/giữa dải** cho kịch bản A và **cận dưới
+của dải "chục nghìn"** cho kịch bản B — không phải số đo được.*
+
+| Chỉ số | Kịch bản A *(tải dự kiến)* | Kịch bản B *(đỉnh flash sale)* | Nguồn |
+|---|---|---|---|
+| Người dùng hoạt động | 200.000 | 600.000 | `ASM-10`, suy từ `DRV-04` |
+| SKU | 300.000 | 500.000 (tăng trưởng) | `ASM-10` |
+| Giao dịch/ngày (trung bình) | 5.000 đơn | 15.000 đơn (≈ 625 đơn/giờ đỉnh × hệ số dồn) | `ASM-10` |
+| Giao dịch/giờ (đỉnh) | ~400 đơn/giờ | ~15.000 đơn/giờ (≈ 4,2 đơn/giây) | `ASM-10`, tương ứng "chục nghìn concurrent" của `DRV-04` |
+| Concurrent user (đỉnh) | 2.000 | 10.000 | `ASM-10`, cận dưới dải `DRV-04` |
+| Dung lượng dữ liệu năm 1 / 3 | ~50GB / ~110GB | ~80GB / ~200GB | `ASM-10` |
+| Tốc độ tăng dữ liệu | ~5GB/tháng | ~10GB/tháng | `ASM-10` |
+| Băng thông ra ngoài (egress qua CDN) | ~400GB/tháng | ~1.200GB/tháng (1,2TB) | `ASM-10` |
+
+🔴 **`ASM-10`** — Chủ: PM/Tech Lead. Cách xác minh: đo lại sau 4–6 tuần soft-launch (khớp
+`DRV-02` §GOAL-01 của `CTX`), thay số giả định bằng số đo thật. Nếu sai lệch > 50%: toàn bộ bảng
+chi phí hạ tầng bên dưới phải tính lại — đây là điểm nhạy cảm nhất của `TCO`, xem §8.
+
+---
+
+## 3. Chi phí hạ tầng AWS — theo phương án
+
+*Tất cả đơn giá dưới đây: `ASM-11` — ước tính bảng giá công khai AWS, khu vực `ap-southeast-1`,
+**không tra cứu API Pricing thời gian thực**, cờ 🔴 **cần xác minh**. Tỷ giá quy đổi dùng
+`ASM-12`: 1 USD ≈ 25.000 VND (**cần xác minh tỷ giá thật tại ngày duyệt ngân sách**).*
+
+### 3.1 Đơn giá tham khảo dùng chung *(`ASM-11`, tất cả 🔴 cần xác minh)*
+
+| Hạng mục | Đơn giá ước tính (USD) | Nguồn/ghi chú |
+|---|---|---|
+| ECS Fargate (Linux/x86) | $0,0466/vCPU-giờ · $0,0051/GB-giờ | Bảng giá công khai AWS Fargate, `ap-southeast-1` |
+| RDS PostgreSQL Multi-AZ, `db.r6g.xlarge` (4vCPU/32GB) | ≈ $0,973/giờ | Ước tính ~2× đơn giá Single-AZ tương ứng |
+| RDS PostgreSQL Multi-AZ, `db.t4g.medium` (2vCPU/4GB) | ≈ $0,146/giờ | Ước tính, dùng cho DB nhỏ (Payment riêng, hoặc từng logic DB của P1) |
+| RDS PostgreSQL Multi-AZ, `db.r6g.2xlarge` (8vCPU/64GB) | ≈ $1,946/giờ | Ước tính, dùng khi scale DB chính P2 kịch bản B |
+| ElastiCache Redis `cache.r6g.large` | ≈ $0,252/giờ/node | Ước tính |
+| ElastiCache Redis `cache.r6g.xlarge` | ≈ $0,504/giờ/node | Ước tính, dùng kịch bản B |
+| Amazon MSK broker `kafka.m5.large` | ≈ $0,21/giờ/broker + $0,10/GB-tháng lưu trữ | Ước tính — **chỉ P1 dùng**, cụm tối thiểu 3 broker chạy 24/7 bất kể tải |
+| OpenSearch `r6g.large.search` | ≈ $0,167/giờ/node + $0,135/GB-tháng EBS | Ước tính — P1 dùng ngay từ đầu (3 node tối thiểu); P2 hoãn dùng Postgres FTS ở kịch bản A |
+| SQS/EventBridge | $0,40/triệu request (SQS chuẩn) · $1,00/triệu event (EventBridge) | Ước tính — rẻ, rủi ro nằm ở **throughput/độ trễ** (`ASM-07`), không phải chi phí |
+| S3 Standard | $0,025/GB-tháng | Ước tính |
+| CloudFront (egress) | ≈ $0,085/GB | Ước tính, tier đầu |
+| WAF | $5/tháng + ~$1/rule + $0,60/triệu request | Ước tính |
+| ALB | $0,0225/giờ + LCU | Ước tính |
+| NAT Gateway (2 AZ) | $0,045/giờ/gateway + $0,045/GB xử lý | Ước tính |
+
+### 3.2 P2 — Modular monolith + managed AWS (phương án chính)
+
+| Hạng mục | Cấu hình (A) | Tiền/tháng (A) | Cấu hình (B) | Tiền/tháng (B) |
+|---|---|---|---|---|
+| Compute (ECS Fargate) — monolith + Payment | ~4 tasks×1vCPU/2GB (monolith) + 2 tasks×0,5vCPU/1GB (Payment) | ≈ $207 | ~10 tasks×1vCPU/2GB + 4 tasks×0,5vCPU/1GB | ≈ $498 |
+| CSDL (RDS) — 1 cụm chính + Payment riêng | `r6g.xlarge` Multi-AZ + `t4g.medium` Multi-AZ (Payment) | ≈ $817 | `r6g.2xlarge` Multi-AZ + 1 read replica + Payment `r6g.large` Multi-AZ | ≈ $2.470 |
+| Cache | `r6g.large` × 1 node | ≈ $184 | `r6g.xlarge` × 1 node + 1 replica | ≈ $736 |
+| Message broker (SQS/EventBridge) | ~750K msg/tháng | ≈ $2 | ~2,25M msg/tháng | ≈ $6 |
+| Lưu trữ đối tượng (S3) | ~500GB | ≈ $12,5 | ~1,5TB | ≈ $38 |
+| Load balancer/gateway (ALB) | | ≈ $31 | | ≈ $61 |
+| **Băng thông ra (CloudFront)** | ~400GB | ≈ $34 | ~1,2TB | ≈ $102 |
+| WAF | | ≈ $25 | | ≈ $35 |
+| NAT Gateway | | ≈ $85 | | ≈ $125 |
+| Backup & DR | Automated backup + cross-region snapshot (Payment) | ≈ $30 | | ≈ $60 |
+| Observability (log/metric/trace, ~25% hạ tầng — xem cảnh báo `cost-model.md` §3) | | ≈ $357 | | ≈ $1.033 |
+| Môi trường non-prod (dev/stg, ~35% Production) | | ≈ $624 | | ≈ $700 |
+| **Cộng hạ tầng/tháng (Production + non-prod)** | | **≈ $2.409** | | **≈ $5.862** |
+| **Quy đổi VND/tháng** (`ASM-12`) | | **≈ 60,2 triệu** | | **≈ 146,6 triệu** |
+
+**P2 3 năm** *(Năm 1 = 5 tháng vận hành sau go-live tháng 7; Năm 2 = 12 tháng; Năm 3 = 12 tháng
+× 1,1 tăng trưởng, `ASM-15`)*:
+
+| | Kịch bản A | Kịch bản B |
+|---|---|---|
+| Năm 1 (5 tháng) | 301,1 triệu | 732,8 triệu |
+| Năm 2 (12 tháng) | 722,7 triệu | 1.758,6 triệu |
+| Năm 3 (12 tháng × 1,1) | 795,0 triệu | 1.934,5 triệu |
+| **Tổng hạ tầng 3 năm** | **1.818,8 triệu** | **4.425,8 triệu** |
+
+### 3.3 P1 — Modular microservices theo `SAD.md`/hồ sơ thầu (đối chiếu)
+
+| Hạng mục | Cấu hình (A) | Tiền/tháng (A) | Cấu hình (B) | Tiền/tháng (B) |
+|---|---|---|---|---|
+| Compute (ECS Fargate) — ~10 service × 2 task (HA) | 20 task × 0,5vCPU/1GB | ≈ $415 | scale ~40 task | ≈ $829 |
+| CSDL (RDS) — ~10 logic DB Multi-AZ | 10 × `t4g.medium` Multi-AZ | ≈ $1.066 | 3 DB nâng `r6g.large` + 7 DB `t4g.medium` | ≈ $1.762 |
+| **Message broker (Kafka/MSK) — chạy 24/7 bất kể tải** | 3 broker `m5.large` + 900GB lưu trữ | ≈ $550 | 6 broker + 1,8TB lưu trữ | ≈ $1.100 |
+| **Search (OpenSearch, dùng ngay từ đầu)** | 3 node `r6g.large.search` + 300GB | ≈ $406 | 5 node + 500GB | ≈ $677 |
+| Cache | `r6g.large` × 1 node | ≈ $184 | `r6g.xlarge` + 1 replica | ≈ $736 |
+| Lưu trữ đối tượng (S3) | ~500GB | ≈ $12,5 | ~1,5TB | ≈ $38 |
+| Load balancer/gateway | | ≈ $31 | | ≈ $61 |
+| Băng thông ra (CloudFront) | ~400GB | ≈ $34 | ~1,2TB | ≈ $102 |
+| WAF | | ≈ $25 | | ≈ $35 |
+| NAT Gateway | | ≈ $85 | | ≈ $125 |
+| Backup & DR (10 DB + 2 cụm) | | ≈ $50 | | ≈ $90 |
+| Observability (~25%) | | ≈ $715 | | ≈ $1.389 |
+| Môi trường non-prod (~40% — Kafka/OpenSearch tối thiểu vẫn cần ở Staging) | | ≈ $1.429 | | ≈ $2.777 |
+| **Cộng hạ tầng/tháng** | | **≈ $5.002** | | **≈ $9.721** |
+| **Quy đổi VND/tháng** | | **≈ 125,0 triệu** | | **≈ 243,0 triệu** |
+
+**P1 3 năm** *(cùng cách tính Năm 1/2/3 như P2)*:
+
+| | Kịch bản A | Kịch bản B |
+|---|---|---|
+| Năm 1 (5 tháng) | 625,2 triệu | 1.215,1 triệu |
+| Năm 2 (12 tháng) | 1.500,5 triệu | 2.916,2 triệu |
+| Năm 3 (12 tháng × 1,1) | 1.650,5 triệu | 3.207,9 triệu |
+| **Tổng hạ tầng 3 năm** | **3.776,1 triệu** | **7.339,2 triệu** |
+
+🔴 Chênh lệch hạ tầng P1 so với P2 đến chủ yếu từ **hai cụm chạy 24/7 bất kể tải** (Kafka/MSK +
+OpenSearch đa node) mà P1 phải có ngay từ ngày một, trong khi P2 hoãn OpenSearch và dùng
+SQS/EventBridge managed (không cụm phải patch/scale) — đúng như nhận định định tính ở `OPT §4`.
+
+---
+
+## 4. License & dịch vụ mua ngoài
+
+*Không phương án nào cần license phần mềm lõi thương mại (P3 — mua nền tảng — đã bị loại ở
+`OPT §5`). Các dòng dưới đây là công cụ/dịch vụ hỗ trợ vận hành.*
+
+| Hạng mục | Mô hình tính giá | Đơn giá ước tính | P2/năm | P1/năm | Nguồn |
+|---|---|---|---|---|---|
+| PagerDuty/OpsGenie (on-call) | Theo user | ~$21/user/tháng × 5 user | ≈ 31,5 triệu | ≈ 31,5 triệu | `ASM-11`, đề xuất minh hoạ ở `docs/sections/09` §9.4.1 |
+| Domain/SSL (ACM miễn phí + Route53) | Cố định | ~$15/năm domain + $6/tháng hosted zone | ≈ 5 triệu | ≈ 5 triệu | `ASM-11` |
+| SAST/SCA/APM tooling (SonarQube/Snyk/X-Ray) | Theo seat/gói | Gói nhỏ ước tính | ≈ 80 triệu | ≈ 80 triệu | `ASM-11`, `docs/sections/09` §9.3.1 |
+| Quản trị cụm Kafka/MSK bổ sung (Confluent Control Center hoặc tương đương) | — | — | N/A (không cần) | ≈ 20 triệu | Chỉ P1 cần — MSK cần công cụ giám sát cụm riêng |
+| **Cộng/năm** | | | **≈ 116,5 triệu** | **≈ 136,5 triệu** | |
+| **Cộng 3 năm** | | | **≈ 349,5 triệu** | **≈ 409,5 triệu** | |
+
+🔴 **Mô hình tính giá quan trọng hơn đơn giá** — PagerDuty tính theo user, tăng cùng quy mô đội
+vận hành; nếu `OQ-008` (đội vận hành) trả lời số người lớn hơn 5, chi phí này tăng tuyến tính.
+
+**8 khoản non-labor trong hồ sơ thầu (`NL-01…NL-08`, `estimate.computed.json`) — đối chiếu:**
+
+| NL | Hạng mục | Xử lý trong `TCO` này |
+|---|---|---|
+| NL-01 | Hạ tầng cloud AWS năm đầu | Tính bằng công thức riêng ở §3 (không dùng số thầu, vì thầu chưa có số) |
+| NL-02 | OpenSearch cluster | Tính trong §3 (P1: có ngay; P2: hoãn tới khi có bằng chứng cần) |
+| NL-03 | Phí giao dịch VNPay/Momo | **Chưa tính được** — cần GMV (tổng giá trị giao dịch) giả định + biểu phí thật của VNPay/Momo, cả hai đều chưa có → `OQ-014` |
+| NL-04 | Phí Email/SMS | **Chưa tính được** — nhà cung cấp cụ thể chưa chốt (`SAD.md §3.4`) nên chưa có biểu phí → `OQ-016` |
+| NL-05 | Phí API GHN/GHTK | **Chưa tính được** — phí theo hợp đồng đơn vị vận chuyển, chưa có hợp đồng → `OQ-015` |
+| NL-06 | Domain/SSL/WAF | Tính trong §3 (WAF) và §4 (domain/SSL) |
+| NL-07 | Pentest/ASV | **Chưa tính được** — cần báo giá nhà cung cấp pentest tại VN, SA không có cơ sở để tự ước lượng đáng tin cậy → `OQ-017` |
+| NL-08 | Đào tạo & tài liệu bàn giao | Trùng lặp một phần với §5 "Đào tạo" bên dưới (WBS-09 lao động đã tính trong chi phí xây dựng §6) — không cộng hai lần |
+
+---
+
+## 5. Vận hành
+
+*Kế thừa giả định "team MVP chuẩn" `DEC-02` (🔴) — số người/kỹ năng thật chưa xác nhận
+(`OQ-008` còn mở). `ASM-14`: giả định 2 FTE Ops/SRE (P2) hoặc 2,5 FTE (P1, do nhiều service +
+Kafka/OpenSearch cần vận hành hơn) ở mức lương `DEVOPS` theo rate card hồ sơ thầu
+(75.000.000 VND/người-tháng).*
+
+| Hạng mục | Cách tính | P2/năm | P1/năm | Nguồn |
+|---|---|---|---|---|
+| Nhân sự vận hành (Ops/SRE) | P2: 2 FTE × 75tr × 12 · P1: 2,5 FTE × 75tr × 12 | 1.800 triệu | 2.250 triệu | `ASM-14`, `DEC-02`, `bid-config.rateCard.DEVOPS` |
+| Trực sự cố / surge mùa cao điểm (kịch bản B, chỉ Năm 2/3) | Ước tính phụ phí on-call mùa flash sale | +200 triệu (2 năm) | +600 triệu (2 năm) | `ASM-14` |
+| Đào tạo kỹ năng mới *(sinh từ `CON-05`/`OQ-010`)* | P2: AWS ECS/SQS phổ biến hơn · P1: cần đào tạo Kafka/MSK/OpenSearch/EKS — kế thừa rủi ro năng lực team (`ARISK-05`) | 50 triệu (Năm 1, một lần) | 200 triệu (Năm 1, một lần) | `ASM-14`, tham chiếu `OPT §4` tiêu chí "Rủi ro kỹ thuật" |
+| Công cụ (đã tính ở §4) | — | (xem §4) | (xem §4) | |
+| **Cộng vận hành 3 năm (kịch bản A)** | | **5.400 triệu + 50 triệu = 5.450 triệu** | **6.750 triệu + 200 triệu = 6.950 triệu** | |
+| **Cộng vận hành 3 năm (kịch bản B)** | | **5.400 + 200 + 50 = 5.650 triệu** | **6.750 + 600 + 200 = 7.550 triệu** | |
+
+🔴 `CON-05`/`OQ-008` chưa trả lời số đội vận hành thật — nếu đội thật nhỏ hơn 2 FTE (VD PO chỉ
+định 1 người kiêm nhiệm), dòng này giảm nhưng rủi ro không đáp ứng `DRV-05` (99.9% uptime,
+escalation 24/7) tăng — đây là đánh đổi PO/PM phải quyết, không phải SA tự chọn số nhỏ hơn cho
+`TCO` đẹp hơn.
+
+---
+
+## 6. Chi phí xây dựng (một lần)
+
+*Lấy nền từ `estimate.computed.json`/`40-financial-proposal.md` §C2–C5 (lao động dự thầu). Vì
+hồ sơ thầu ước lượng theo kiến trúc gốc kiểu P1 (Kafka/MSK, `WBS-03` XL/high risk, 52 MD + 18,2 MD
+dự phòng = 70,2 MD), P2 cần tách riêng: SQS/EventBridge managed nhẹ hơn đáng kể — `ASM-13` ước
+tính effort `WBS-03` tương đương P2 chỉ bằng ~30% P1 (15,6 MD cơ sở + 20% dự phòng thấp hơn vì
+rủi ro công nghệ managed thấp hơn = 18,7 MD), **chưa qua ước lượng lại chi tiết của nhà thầu**.*
+
+| Hạng mục | P1 (theo hồ sơ thầu, VND) | P2 (điều chỉnh theo `ASM-13`, VND) |
+|---|---|---|
+| Lao động (43 hạng mục WBS, 53,02 MM) | 3.420.500.000 | 3.420.500.000 − 191.200.000 *(giảm `WBS-03`)* ≈ **3.229.300.000** |
+| VAT (10%) | 342.050.000 | 322.930.000 |
+| **Tổng (đã VAT)** | **3.762.550.000** | **3.552.230.000** |
+
+Chi tiết `ASM-13` (công thức giảm `WBS-03`): P1 `WBS-03` = 70,2 MD, đơn giá bình quân theo tỷ
+trọng vai trò tham gia (PM 3,85% · SA 28,85% · BE 48,08% · DEVOPS 19,23%) ≈ 3.714.000 VND/MD ⇒
+70,2 MD × 3.714.000 ≈ **260,7 triệu VND**. P2 `WBS-03` ước 18,7 MD cùng tỷ trọng ⇒ 18,7 × 3.714.000
+≈ **69,5 triệu VND**. Chênh lệch ≈ **191,2 triệu VND** (chưa VAT), khớp hướng "**-70,2 MD** so với
+P1" đã nêu ở `OPT §6`.
+
+🔴 **`ASM-13`** — Chủ: Tech Lead + PM. Cách xác minh: nhà thầu/đội thi công ước lượng lại WBS-03
+riêng cho kiến trúc P2 (SQS/EventBridge) thay vì suy tỷ lệ %. Hệ quả nếu sai: chi phí xây dựng
+một lần của P2 có thể lệch ±100–150 triệu VND so với số ở trên — không đổi kết luận "P2 rẻ hơn
+P1" (chênh lệch hạ tầng 3 năm lớn hơn nhiều biên độ sai số này).
+
+Effort nghiệp vụ (`WBS-18…43`) **không đổi** giữa P1/P2 (đã xác nhận ở `OPT §6`) — không lặp lại
+bảng chi tiết ở đây, chỉ tham chiếu `40-financial-proposal.md` §C2.
+
+---
+
+## 7. Tổng hợp 3 năm
+
+| Nhóm | P2 — A | P2 — B | P1 — A | P1 — B |
+|---|---|---|---|---|
+| Hạ tầng | 1.818,8 triệu | 4.425,8 triệu | 3.776,1 triệu | 7.339,2 triệu |
+| License | 349,5 triệu | 349,5 triệu | 409,5 triệu | 409,5 triệu |
+| Vận hành (gồm đào tạo) | 5.450 triệu | 5.650 triệu | 6.950 triệu | 7.550 triệu |
+| Xây dựng (một lần, Năm 1) | 3.552,2 triệu | 3.552,2 triệu | 3.762,6 triệu | 3.762,6 triệu |
+| **Tổng 3 năm** | **11.170,5 triệu** | **13.977,5 triệu** | **14.898,2 triệu** | **19.061,3 triệu** |
+
+**Ghi chú khớp số (sửa tại v1.1):** bảng §1 trước đây (v1.0) ghi nhầm dòng "Vận hành/nhân sự (3
+năm)" của P2 — Kịch bản B là 5.800 triệu và Tổng 3 năm là 14.177,5 triệu (~14,18 tỷ) — đây là
+**lỗi chép số ở §1**, không phải sai lệch do làm tròn. Số đúng theo chi tiết cộng dồn ở §5 (2 FTE
+× 75tr × 12 × 3 năm = 5.400 triệu + surge kịch bản B 200 triệu = 5.600 triệu; cộng đào tạo 50
+triệu = 5.650 triệu vận hành, khớp dòng "Vận hành (gồm đào tạo)" ở bảng này) là: dòng
+"Vận hành/nhân sự (3 năm)" P2-B = **5.600 triệu**, Tổng 3 năm P2-B = **13.977,5 triệu (~13,98
+tỷ)**. Bảng §1 đã được sửa lại khớp số này (xem Change Log v1.1). Các cột P2-A, P1-A, P1-B không
+bị ảnh hưởng bởi lỗi này.
+
+---
+
+## 8. Điểm nhạy cảm
+
+| Giả định | Nếu sai ±50% thì tổng 3 năm lệch | Cách giảm bất định |
+|---|---|---|
+| `ASM-10` (kịch bản tải) | Có thể đổi hẳn kịch bản áp dụng (A↔B), chênh lệch tới ~3–5 tỷ VND | Đo tải thật sau soft-launch 4–6 tuần (khớp `DRV-02`) |
+| `ASM-11` (đơn giá AWS) | ±50% đơn giá ⇒ hạ tầng 3 năm lệch ±0,9–3,7 tỷ VND tuỳ phương án/kịch bản | Chạy AWS Pricing Calculator thật hoặc xin báo giá đại lý AWS tại VN trước khi duyệt ngân sách |
+| `ASM-12` (tỷ giá USD/VND) | Tỷ lệ thuận với toàn bộ dòng hạ tầng | Dùng tỷ giá bán ra của ngân hàng tại ngày lập ngân sách chính thức |
+| `ASM-14` (số FTE vận hành) | ±50% ⇒ lệch ±2,7–3,5 tỷ VND (dòng chi phí lớn nhất trong toàn `TCO`) | `OQ-008` cần trả lời trước khi con số này được coi là đáng tin |
+| `ASM-13` (tách effort xây dựng P2) | ±100–150 triệu VND (biên độ nhỏ so với tổng) | Ước lượng lại WBS-03 riêng cho P2 khi vào GĐ2 |
+
+🔴 **Dòng nhạy cảm nhất là `ASM-14` (vận hành/nhân sự)** — không phải hạ tầng AWS như trực giác
+thường nghĩ. Nếu PO/PM chỉ có thể xác nhận 1 điều trước khi dùng `TCO` này, nên là `OQ-008`.
+
+---
+
+## 9. Điểm hoà vốn so với P0 *(giữ nguyên hiện trạng)*
+
+**Không áp dụng theo đúng nghĩa template** — dự án là **greenfield** (`CTX §4.1`, `OPT` P0):
+không có hệ thống/chi phí vận hành hiện tại để so sánh, và P0 ("không làm gì") không tạo ra
+doanh thu để tính "tiết kiệm được". `OPT §3` đã ghi rõ: hệ quả của P0 là **định tính nghiêm
+trọng nhất** (chặn toàn bộ mô hình kinh doanh marketplace theo `DRV-01`) nhưng **không quy ra
+được một con số tiền cụ thể** vì không có doanh thu mục tiêu bằng số trong nguồn hiện có. Đây là
+giới hạn đã biết của lượt chạy này — không phải SA bỏ sót.
+
+---
+
+## 10. Giả định & Ngoài phạm vi
+
+**Giả định** *(tiếp số từ `CTX §5`/`OPT §8`, bắt đầu `ASM-10`)*:
+
+| ID | Giả định | Nếu sai |
+|---|---|---|
+| `ASM-10` | Kịch bản tải A/B (§2) phản ánh đúng độ lớn thực tế của `DRV-04` | Toàn bộ `TCO` phải tính lại theo kịch bản đúng |
+| `ASM-11` | Đơn giá AWS `ap-southeast-1` ước tính ở §3.1 gần đúng với giá thật tại thời điểm duyệt ngân sách | Chi phí hạ tầng 3 năm lệch tỷ lệ thuận — xem §8 |
+| `ASM-12` | Tỷ giá 1 USD ≈ 25.000 VND giữ ổn định trong 3 năm | Chi phí hạ tầng lệch theo biến động tỷ giá thật |
+| `ASM-13` | Effort xây dựng `WBS-03` của P2 ước bằng ~30% P1 theo tỷ lệ suy diễn, chưa qua ước lượng lại chi tiết | Chi phí xây dựng một lần của P2 lệch ±100–150 triệu VND |
+| `ASM-14` | Đội vận hành 2 FTE (P2)/2,5 FTE (P1) đủ đáp ứng `DRV-05` (99.9% uptime, escalation 24/7) | Nếu đội thật nhỏ hơn: rủi ro không đạt `DRV-05`; nếu lớn hơn: chi phí vận hành tăng — xem `ARISK-08` |
+| `ASM-15` | Tăng trưởng chi phí hạ tầng Năm 3 so với Năm 2 là +10% (không có số liệu thị trường cụ thể, chỉ là hệ số làm tròn hợp lý) | Nếu tăng trưởng thật nhanh hơn (VD traffic tăng gấp đôi mỗi năm theo mô hình kinh doanh thành công), Năm 3 phải tính lại theo đúng kịch bản B hoặc kịch bản mới |
+
+**Ngoài phạm vi:**
+
+- Phí giao dịch VNPay/Momo, phí API GHN/GHTK, phí Email/SMS, phí pentest/ASV — không tính được
+  vì thiếu biểu phí/hợp đồng nhà cung cấp thật, xem `OQ-014…OQ-017`.
+- Chi phí dịch thuật nội dung đa ngôn ngữ (`FR-15`) — đã loại trừ tường minh trong
+  `40-financial-proposal.md` §C1.1, không thuộc `TCO` kiến trúc này.
+- Ứng dụng di động native, affiliate marketing, subscription, hoá đơn điện tử tự động cho seller,
+  SSO doanh nghiệp — ngoài phạm vi MVP theo `40-financial-proposal.md` §C1.1 và `CON-07`.
+- Chi phí cơ hội của việc trì hoãn go-live (P0) — không quy ra được số, xem §9.
+- Kịch bản lai (P2 + Kafka/MSK riêng cho hot-path nếu `POC-01` fail) — chưa tính; nếu `POC-01`
+  (xem `ARISK_e-commerce_v1.0.md`) thất bại, `TCO` P2 phải cộng thêm một phần chi phí MSK của P1
+  (§3.3, dòng "Message broker") cho riêng hot-path đặt hàng.
+
+---
+
+## Tự chấm
+
+### ① Bảng tự chấm Gate AG1 *(`workflow.md §2`, cập nhật từ `CTX`/`OPT`)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | `CTX` có `DRV-nn` | ✅ | Không đổi — xem `CTX §2` |
+| 2 | `CTX` có `CON-nn` | ✅ *(với lưu ý)* | Không đổi — xem `CTX §3` |
+| 3 | `CTX` mô tả hiện trạng as-is | ✅ *(với lưu ý)* | Không đổi — xem `CTX §4` |
+| 4 | `OPT` có ≥2 phương án, chấm điểm, nêu phương án bị loại | ✅ | Không đổi — xem `OPT §4`/§5 |
+| 5 | `TCO` có chi phí 3 năm, ≥2 kịch bản tải | ✅ | **Mới đạt ở lượt này** — §1/§3/§7, 2 phương án × 2 kịch bản tải, tách 4 nhóm (hạ tầng/license/vận hành/xây dựng). Đơn giá AWS/tỷ giá/GMV nhiều chỗ 🔴 chưa xác minh (`OQ-013…017`) — đạt tiêu chí "có mặt và đủ cấu trúc", chưa đạt mức "số đã xác nhận thật" |
+| 6 | `ARISK` có rủi ro cao kèm chủ + biện pháp | ✅ | Xem `ARISK_e-commerce_v1.0.md` §3 — 6 rủi ro 🔴, mỗi cái có chủ + biện pháp cụ thể (không phải "sẽ theo dõi") |
+| 7 | Rủi ro cao chưa chứng minh được có kế hoạch POC | ✅ | Xem `ARISK_e-commerce_v1.0.md` §6 — `POC-01`/`POC-02` có tiêu chí pass/fail viết trước |
+
+**Kết luận tự chấm AG1:** **7/7 tiêu chí có mặt về mặt cấu trúc** — GĐ1 SA nay đủ 4 artifact
+(`CTX`/`OPT`/`TCO`/`ARISK`) để audit AG1. **Nhưng chưa đủ điều kiện ký chính thức**: nhiều dòng
+vẫn ở `Confidence` 🔴 vì (a) BA chưa ký G1 thật, (b) `OQ-005/006/007/008/010/012` (ngân sách,
+deadline, residency, đội vận hành, năng lực team, thời điểm POC) còn mở, (c) `OQ-013…017` (đơn
+giá AWS, phí đối tác) mới phát sinh ở `TCO`. Khuyến nghị: chạy `POC-01`/`POC-02` và trả lời tối
+thiểu `OQ-005`/`OQ-008`/`OQ-010` trước khi PO + Tech Lead ký AG1 thật.
+
+### ② Checklist D1–D12 *(`design-rules.md`)*
+
+| # | Mục | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| D1 | Một ADR một quyết định | N/A | Tài liệu này không có `ADR` |
+| D2 | Không NFR định tính | N/A | `TCO` không chứa `QAS` |
+| D3 | Nêu phương án bị loại + lý do | N/A | Đã nêu ở `OPT §5`; `TCO` chỉ định lượng hai phương án còn lại |
+| D4 | Sơ đồ khai báo mức + legend | N/A | Không có sơ đồ mới ở `TCO` |
+| D5 | Interface có chủ/contract | N/A | Chưa tới `ICD` |
+| D6 | Phụ thuộc ngoài process có timeout/retry | N/A | Chưa tới `FAIL` |
+| D7 | Một chủ sở hữu dữ liệu | N/A | Chưa tới `DAT` |
+| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` |
+| D9 | Con số hạ tầng quy ra tiền + nguồn; `INF` khớp `TCO` | ✅ *(với cờ cần xác minh)* | Mọi dòng hạ tầng ở §3 có công thức + đơn giá + nguồn (`ASM-11`, region, ngày tham chiếu ghi rõ "cần xác minh"); `INF` (GĐ2) sẽ phải khớp con số này hoặc giải thích chênh lệch |
+| D10 | Không quyết định thay người có thẩm quyền | ✅ | Ngân sách vượt/không vượt để PO quyết (§1 "phát hiện quan trọng nhất"); mọi giả định đơn giá/FX/team đều gắn `OQ` kèm hệ quả, không tự quyết |
+| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §10 đầy đủ, `ASM-10…15` có cách xác minh/hệ quả |
+| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có ngay sau Change Log |
+
+### ③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì
+
+`OQ-013…017` (mới, xem §4/§8) cộng các câu còn mở từ `CTX`/`OPT` (`OQ-001, 003, 004, 005, 006,
+007, 008, 010, 012` — xem sổ đầy đủ `00-index/OQ_e-commerce.md`). Quan trọng nhất cho `TCO`:
+**`OQ-005`** (ngân sách — chặn việc coi con số `TCO` này là "đã duyệt hay chưa"), **`OQ-008`**
+(đội vận hành — dòng nhạy cảm nhất, xem §8), **`OQ-013`** (đơn giá AWS thật).
+
+**Nhắc:** AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header `OPT`) trước khi chạy
+`/sa-2-architecture`.