sys-analysis-design/sa-output/e-commerce/00-index/OQ_e-commerce.md

# OQ — Sổ Open Question (kiến trúc) — e-commerce

| | |
|---|---|
| **Version** | 1.25 |
| **Date** | 2026-09-15 |
| **Author** | SA (qua skill sa-1-context, sa-2-architecture) |
| **Status** | 🟡 Draft — cập nhật liên tục qua các giai đoạn |
| **Approved by** | — *(sổ theo dõi, không cần baseline riêng)* |
| **Source** | `01-context/CTX_e-commerce_v1.0.md` (v1.2 trong header) §3, §4, §7, §7.1 · `01-context/OPT_e-commerce_v1.0.md` §1, §2, §9 · `01-context/TCO_e-commerce_v1.0.md` §4, §8 · `01-context/ARISK_e-commerce_v1.0.md` §8 · `02-architecture/QAS_e-commerce_v1.0.md` §E · `02-architecture/ASR_e-commerce_v1.0.md` §E · `02-architecture/SAD_e-commerce_v1.0.md` v1.3 §6.1, §8, §11 · `02-architecture/ICD_e-commerce_v1.0.md` §0.1, §8 · `02-architecture/FAIL_e-commerce_v1.0.md` v1.1 §1.2, §10 · `02-architecture/adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md` · `02-architecture/DAT_e-commerce_v1.0.md` §4.1, §4.3, §7.3, §10, §12 · `02-architecture/SEC_e-commerce_v1.0.md` §2.4, §5.3, §11 · `02-architecture/INF_e-commerce_v1.0.md` §10, §15 |
| **Scope** | Toàn dự án e-commerce (kiến trúc) |
| **Confidence** | 🔴 Theo `CTX`/`OPT`/`TCO`/`ARISK`/`QAS`/`ASR`/`SAD` gốc — BA chưa ký G1, AG1 chưa ký, xem `DEC-01`/`DEC-11`/`DEC-12`/`DEC-14`/`DEC-15`/`DEC-16`/`DEC-27` (SA) |

## Change Log

| Version | Date | Người sửa | Thay đổi | ADR/DEC |
|---|---|---|---|---|
| 1.0 | 2026-09-10 | SA (qua skill sa-lifecycle) | Khởi tạo sổ OQ kiến trúc, khung rỗng | — |
| 1.1 | 2026-09-12 | SA (qua skill sa-1-context) | Thêm `OQ-001..OQ-004` từ `CTX_e-commerce_v1.0.md` (hoạt động Driver, GĐ1) | `DEC-01` |
| 1.2 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ sign | Đóng `OQ-002` bằng quyết định dùng giả định tạm "team MVP chuẩn" (🔴) cho Bước 2, xem `DEC-02` | `DEC-02` |
| 1.3 | 2026-09-12 | SA (qua skill sa-1-context, hoạt động `constraints`) | Thêm `OQ-005..OQ-009` từ `CTX_e-commerce_v1.0.md (v1.1 trong header)` §3/§7 (ngân sách, deadline, đại diện Pháp chế cho residency NĐ13/2023, đội vận hành sau go-live, có neo theo `SAD.md`/hồ sơ thầu cho Bước 4 hay không) | `DEC-03` |
| 1.4 | 2026-09-12 | SA (qua skill sa-1-context, hoạt động `as-is`) | Đóng `OQ-009` (chấp nhận `SAD.md`/hồ sơ thầu làm điểm khởi đầu tham khảo cho Bước 4, với điều kiện vẫn dựng ≥1 phương án độc lập) — xem `DEC-04`. Bổ sung "câu trả lời tạm" cho `OQ-005`/`OQ-006` (giữ 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) theo `CTX_e-commerce_v1.0.md (v1.2 trong header)` §4.3, §7 | `DEC-04` |
| 1.5 | 2026-09-12 | SA (qua skill sa-1-context, hoạt động `options`) | Thêm `OQ-010..OQ-012` từ `OPT_e-commerce_v1.0.md` §9 (kinh nghiệm team thật với Kafka/MSK/OpenSearch/EKS; chọn P1 hay P2 — nội dung cần ký AG1; thời điểm chạy POC throughput SQS/EventBridge) | `DEC-05` |
| 1.6 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ sign | Đóng `OQ-011` bằng quyết định duyệt từng phần: chọn **P2** làm nền cho Bước 5/GĐ2, điều kiện `OQ-010`/`OQ-012` (xem `DEC-06`). `OQ-010`, `OQ-012`, `OQ-004` giữ mở nguyên trạng | `DEC-06` |
| 1.7 | 2026-09-12 | SA (qua skill sa-1-context, hoạt động `cost-risk`) | Thêm `OQ-013..OQ-017` từ `TCO_e-commerce_v1.0.md` §4/§8 và `ARISK_e-commerce_v1.0.md` §8 (xác minh đơn giá AWS; biểu phí VNPay/Momo + GMV; biểu phí GHN/GHTK; nhà cung cấp Email/SMS; báo giá pentest/ASV) | `DEC-07`, `DEC-08` |
| 1.8 | 2026-09-14 | SA (qua skill sa-2-architecture, hoạt động `qas`) | Thêm `OQ-018..OQ-023` từ `QAS_e-commerce_v1.0.md` §E (ngưỡng latency `GET /v1/cart` và `PATCH`/`DELETE /v1/cart/items` — SA đề xuất, nối `OQ-033` của BA; cửa sổ bảo trì loại trừ ngân sách lỗi; tần suất job đối soát thanh toán; lịch diễn tập DR đầu tiên; ngưỡng rate limit Guest) | `DEC-11` |
| 1.9 | 2026-09-14 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `QAS_e-commerce_v1.0.md` | `OQ-018/019/020/021` **giữ nguyên mở** (chỉ chấp nhận TẠM số đề xuất làm baseline, chưa xác nhận thật). `OQ-022` cập nhật: đã chốt điều kiện "diễn tập DR phải thực hiện trước khi ký AG2", ngày/lịch cụ thể vẫn chờ Ops/SRE — **giữ mở**. `OQ-023` không đổi. | `DEC-12` |
| 1.10 | 2026-09-14 | SA (qua skill sa-2-architecture, hoạt động `asr`) | Thêm `OQ-024..OQ-025` từ `ASR_e-commerce_v1.0.md` §E (phương thức MFA cho Admin — TOTP/SMS/khoá cứng; phạm vi i18n cho nội dung seller tự nhập và ai cung cấp bản dịch) | `DEC-13` |
| 1.11 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `ASR_e-commerce_v1.0.md` | `OQ-024`/`OQ-025` **giữ nguyên mở** — chỉ chấp nhận TẠM hướng đi mặc định (`OQ-024`: TOTP app theo `ASM-20`; `OQ-025`: không dịch nội dung seller ở MVP theo `ASM-21`) làm baseline cho hoạt động `sad`/`sec` kế tiếp, chưa xác nhận thật bởi Security/PO. | `DEC-14` |
| 1.12 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `sad`) | Thêm `OQ-026..OQ-027` từ `SAD_e-commerce_v1.0.md` §7/§11 (khớp số ECS Fargate "monolith" của `TCO §3.2` với ranh giới 2 nhóm triển khai của `ASR-001`/`ASR-014`; vị trí Identity & Access trong nhóm triển khai nào, `ASM-22`) | `DEC-15` |
| 1.13 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `SAD_e-commerce_v1.0.md` | `OQ-026`/`OQ-027` **giữ nguyên mở** — chỉ chấp nhận TẠM hướng đi mặc định (`OQ-026`: 2 ECS Fargate service riêng theo Nhóm Giao dịch/Nhóm Hỗ trợ, `ASM-23`; `OQ-027`: Identity & Access thuộc Nhóm Giao dịch, `ASM-22`) làm baseline cho hoạt động `icd`/`dat`/`sec`/`inf`/`fail` kế tiếp, chưa xác nhận thật bởi Tech Lead/Ops. | `DEC-16` |
| 1.14 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `icd`) | Thêm `OQ-028..OQ-033` từ `ICD_e-commerce_v1.0.md` §8 (ranh giới mạng `IF-021` mâu thuẫn giữa `SAD §4` legend và `OQ-026`; chênh lệch "22 vs 17" `IF-nn` của `SAD`; xác nhận schema sự kiện `OrderPlaced`/`PaymentConfirmed` + request `IF-006`; tên header correlation-id; chiều gọi `IF-022`; denormalize `sellerName` vào `CartItem`). Ghi nhận: `ICD` xác nhận/đóng đề xuất cho `OQ-034(BA)` (cấu trúc `GET /v1/cart` nhóm theo seller) và `OQ-032(BA)` (ownership Guest cùng cơ chế JWT) trong sổ BA — BA cần tự cập nhật sổ của mình để đóng chính thức. | `DEC-18` |
| 1.15 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `ICD_e-commerce_v1.0.md` | `OQ-028`, `OQ-030`, `OQ-032`, `OQ-033` chốt TẠM hướng đi đề xuất của `ICD` (`ASM-24/25/26`, denormalize `sellerName`) làm baseline cho hoạt động `dat`/`sec`/`inf`/`fail` kế tiếp — cả bốn **giữ nguyên mở**, chờ Tech Lead thật xác nhận. `OQ-029` (chênh lệch số `IF-nn`) và `OQ-031` (tên header correlation-id) không đổi. | `DEC-19` |
| 1.16 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `sad`, sửa lỗi theo yêu cầu người duyệt) | **Đóng `OQ-029`**: rà toàn bộ `SAD` kết luận "22" là đếm nhầm, đúng 17 `IF-nn` (không bỏ sót interface nào) — `SAD_e-commerce_v1.0.md` sửa lên v1.2. `OQ-028` không đóng (vẫn chờ Tech Lead thật xác nhận ranh giới mạng `IF-021`) nhưng ghi nhận `SAD` nay đã hết mâu thuẫn nội bộ (legend §4, §4.1, §5, §6.1, §6.3, §7 đều nhất quán cross-network theo `ASM-24`). Ghi ngoại lệ tiếp tục gate ở `DEC-20`. | `DEC-20` |
| 1.17 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `fail`) | Thêm `OQ-034..040` từ `FAIL_e-commerce_v1.0.md` §10 (xung đột ngân sách timeout cộng dồn checkout — VNPay/Momo 10s kế thừa không dùng được nguyên trạng trong nhánh đồng bộ `IF-006`→`IF-007/008`, vượt `QAS-002` ~7% ngay cả sau khi siết còn 1.500ms; ngưỡng circuit breaker; DLQ retention SQS/EventBridge; bulkhead RDS/adapter đối tác; giữ transaction DB mở xuyên lời gọi Payment + thiếu mã lỗi US-004 Checkout; SLA xử lý thủ công khi GHN+GHTK cùng lỗi; thiếu cache nội dung giỏ hàng cho fallback khi RDS chậm). | `DEC-21` |
| 1.18 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `FAIL_e-commerce_v1.0.md` | **`OQ-034`** cập nhật: chọn **Lựa chọn B** (bất đồng bộ hoá bước khởi tạo thanh toán) — trạng thái chuyển "đã chọn hướng B, chờ `ADR-013` (chưa viết) + Tech Lead/PO thật xác nhận", **giữ nguyên mở**. `OQ-035`/`OQ-036`/`OQ-037` chốt TẠM hướng đi/số đề xuất của `FAIL` (circuit breaker, DLQ retention 14 ngày + cảnh báo lag >5 phút, bulkhead chờ `POC-02`) làm baseline — cả ba **giữ nguyên mở**, chờ Tech Lead/SRE thật xác nhận. `OQ-038`, `OQ-039`, `OQ-040` không đổi. | `DEC-22` |
| 1.19 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `adr`) | Viết `ADR-013` (`Proposed`, bất đồng bộ hoá bước khởi tạo thanh toán — hiện thực hoá Lựa chọn B đã chọn ở `OQ-034`/`DEC-22`) và sửa nhất quán `SAD_e-commerce_v1.0.md` (lên v1.3, §6.1/§8) + `FAIL_e-commerce_v1.0.md` (lên v1.1, §1.2). **`OQ-034` cập nhật**: "đã chọn hướng B, đã có `ADR-013`, chờ Tech Lead + PO thật xác nhận trước khi `Accepted`" — **giữ nguyên mở**. Thêm `OQ-041` (cơ chế FE lấy `redirectUrl` — polling hay SSE/WebSocket) và `OQ-042` (thời gian giữ `Order` ở `PENDING_PAYMENT_INIT` trước khi coi là kẹt, cần job dọn dẹp) từ `ADR-013 §3`. Không sửa ADR khác, không sửa 12 ADR cũ. | `DEC-23`, `ADR-013` |
| 1.20 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `dat`) | Thêm `OQ-043..047` từ `DAT_e-commerce_v1.0.md` §12 (cardinality `Payment`/`Order` — 1 hay tách theo `OrderSeller`; chấp nhận Transactional Outbox pattern cho khoảng trống `FAIL §7` hay job quét đơn giản hơn, radar ~6, `ADR` bắt buộc chưa viết; công cụ migration schema Flyway/Liquibase; routing đọc `Cart`/`Catalog` sang read replica; thiếu `CMP` Audit & Compliance riêng ở P2 so với `docs/05` P1). **Bổ sung nội dung cho `OQ-007`** (đề xuất phân loại PII/retention + whitelist chia sẻ seller theo `ADR-008` PA-2 — vẫn chờ Pháp chế/Bảo mật, giữ mở), **`OQ-040`** (đánh giá 2 phương án cache nội dung `Cart` kèm hệ quả — SA nghiêng phương án B, giữ mở), **`OQ-042`** (đề xuất ngưỡng quét 5 phút + hành động job dọn `Order` kẹt — giữ mở, chờ Tech Lead). Không đóng `OQ` nào. | `DEC-24` |
| 1.21 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `DAT_e-commerce_v1.0.md` | **`OQ-041`** (cơ chế FE): chốt TẠM **polling** làm baseline — giữ nguyên mở. **`OQ-042`** (ngưỡng job quét `Order` kẹt): chốt TẠM **5 phút** — giữ nguyên mở. **`OQ-044`** (Outbox vs job quét): chọn TẠM **Transactional Outbox** — yêu cầu SA viết `ADR-014` (`Proposed`) ở lượt hoạt động `adr` kế tiếp trước khi coi là chốt kiến trúc — giữ nguyên mở. **`OQ-047`** (kiến trúc audit trail): chọn TẠM **phương án (a)** — mỗi module tự ghi `audit_log` riêng, **không thêm `CMP-16`** — giữ nguyên mở, chờ Tech Lead + Security thật xác nhận. `OQ-043`, `OQ-045`, `OQ-046` **không đổi** — chưa có hướng TẠM nào được chọn. `OQ-007` (§5 DAT — PII/retention/whitelist): ghi nhận đề xuất DAT **CHƯA CÓ HIỆU LỰC**, vẫn chờ đại diện Pháp chế/Bảo mật phủ quyết — giữ nguyên mở. Tất cả chấp nhận ở mức TẠM (🔴), không phải xác nhận thật. | `DEC-25` |
| 1.22 | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `sec`) | Thêm `OQ-048..053` từ `SEC_e-commerce_v1.0.md` §11 (hình thức tích hợp redirect/iframe với VNPay/Momo cho phạm vi SAQ A; cơ chế chữ ký/HMAC webhook cụ thể của 4 đối tác; chọn phương án service-to-service authn giữa Nhóm Giao dịch/Nhóm Hỗ trợ/Payment — PA-3 service JWT đề xuất, `ADR` ứng viên chưa viết; số cụ thể TTL/refresh/thu hồi JWT Customer; ngưỡng account lockout + rate-limit login; mức che 3 trường whitelist PII cho seller). **Bổ sung nội dung cho `OQ-007`** (SEC ghi rõ toàn bộ §5/§8.2 của `SEC` là đề xuất chờ Legal/Security phủ quyết, không coi là đã xác nhận — giữ mở) và **`OQ-023`** (SEC đề xuất số cụ thể 30 req/phút cho Guest cart `PATCH`/`DELETE` kèm hệ quả hai chiều, không tự quyết thay Security — giữ mở). `OQ-024` không đổi hướng TẠM (TOTP app), chỉ bổ sung ghi chú về backup code chưa thiết kế. Không đóng `OQ` nào. | `DEC-27` |
| 1.23 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `SEC_e-commerce_v1.0.md` | **`OQ-050`** chốt TẠM hướng **PA-3** (service JWT ngắn hạn) cho service-to-service authn — yêu cầu SA viết `ADR-015` (`Proposed`) ở lượt hoạt động `adr` kế tiếp cùng `ADR-014` đang nợ; **giữ nguyên mở**, chờ Security + Ops/SRE thật xác nhận trước khi `Accepted`. `OQ-007` (SEC §5/§8.2 vẫn là đề xuất chờ Legal/Security, KHÔNG ký thay Security) và `OQ-023`/`OQ-024` **không đổi thêm** ở lượt sign này — giữ nguyên như đã ghi ở v1.22. | `DEC-28` |
| 1.24 | 2026-09-15 | SA (qua skill `sa-2-architecture`, chế độ `go`, hoạt động `inf`) | Thêm `OQ-054..OQ-063` từ `INF_e-commerce_v1.0.md` (hoạt động `inf`, GĐ2): `OQ-054` (mâu thuẫn `TCO §3.2` "cross-region snapshot Payment" vs `ADR-009` "không multi-region"), `OQ-055` (split ECS task GD/HT + ngưỡng auto-scaling, nối `OQ-026`), `OQ-056` (lịch diễn tập DR thật, nối `OQ-022`), `OQ-057` (IP allowlist đối tác ngoài), `OQ-058` (SPOF ElastiCache kịch bản A — thêm replica hay chấp nhận), `OQ-059` (retention log/backup, tỉ lệ sample X-Ray), `OQ-060` (công cụ IaC + ngưỡng coverage test cho P2), `OQ-061` (kích thước connection pool RDS/HTTP, nối `OQ-037`), `OQ-062` (tách VPC/account non-prod), `OQ-063` (nối `OQ-008`, đội Ops thật — không lặp lại nội dung, chỉ tham chiếu). | `DEC-29` |
| 1.25 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ sign trên `INF_e-commerce_v1.0.md` | **`OQ-058`** chốt TẠM hướng **giữ nguyên `TCO`** — không thêm replica Redis ở kịch bản A, chấp nhận SPOF với hành vi fail-closed theo `FAIL`; **giữ nguyên mở**, chờ PO xác nhận cuối (đánh đổi chi phí/rủi ro thuộc thẩm quyền PO). `OQ-054`/`OQ-055`/`OQ-056`/`OQ-057` **không đổi** ở lượt sign này — giữ nguyên như đã ghi ở v1.24. | `DEC-30` |

---

## Open Question đang mở

| ID | Nội dung | Hỏi ai | Từ ngày | Chặn gì | Nguồn |
|---|---|---|---|---|---|
| OQ-001 | BA chưa ký G1 chính thức cho `BRIEF_CartCheckout` (`OQ-001`/`OQ-007` của BA còn mở). Xác nhận: chấp nhận để `DRV-01,02,03,07,08` giữ `Confidence` 🔴 và tiếp tục 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 `CTX`; ký AG1 | `CTX_e-commerce_v1.0.md` §7 |
| OQ-003 | Giữ nguyên phạm vi **Toàn sàn** cho Bước 2–5 GĐ1 SA hay thu hẹp về Giỏ hàng & Checkout để có Confidence cao hơn (driver các module khác chưa qua BRIEF/RISK module hoá)? | PO sàn + Tech Lead | 2026-09-12 | Khối lượng/độ tin cậy `OPT`/`TCO`/`ARISK` | `CTX_e-commerce_v1.0.md` §7 |
| OQ-004 | Xác nhận ngoại lệ gate `DEC-01` (SA) — chạy GĐ1 SA khi BA chưa qua G1 — có 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) | 2026-09-12 | Tính hợp lệ của `CTX` khi trình AG1 | `CTX_e-commerce_v1.0.md` §0, §7 |
| 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ó là hồ sơ thầu (`e-commerce/bid/estimate.computed.json`, Draft, chưa hợp đồng): lao động ≈3,76 tỷ VND đã VAT/53,02 người-tháng; 8 khoản chi phí không lao động chưa có số. | PO / tài chính | 2026-09-12 | `CON-01`; `TCO` Bước 5; loại bớt phương án ở `OPT` Bước 4 | `CTX_e-commerce_v1.0.md (v1.1 trong header)` §3, §7 |
| OQ-006 | Deadline dự án chính thức là ngày nào (nếu có)? Brief giả định "~9-12 tháng"; hồ sơ thầu tính "7 tháng thực hiện" + 12 tháng bảo hành — hai số này KHÔNG khớp và đều chưa được PO xác nhận là mốc thật. | PO / PM | 2026-09-12 | `CON-02`; kịch bản thời gian ở `OPT` Bước 4 | `CTX_e-commerce_v1.0.md (v1.1 trong header)` §3, §7 |
| OQ-007 | Ai là đại diện Pháp chế/Bảo mật xác nhận yêu cầu residency (nơi lưu trữ dữ liệu) theo NĐ13/2023 cho mô hình marketplace hai loại chủ thể dữ liệu (khách hàng + seller, gồm KYC)? *(kế thừa `OQ-003` của BA — vẫn chưa có người)* **Bổ sung (2026-09-15, `DAT §5`):** SA đã phân loại PII/Payment/nghiệp vụ đầy đủ + đề xuất retention (30 ngày ẩn danh hoá PII khách hàng, 5 năm KYC, 10 năm tài chính — tham khảo `docs/05`, `ASM-37`) và whitelist chia sẻ seller (`recipient_name`/`phone`/`address_line`, hiện thực hoá `ADR-008` PA-2) — **vẫn chờ đại diện Pháp chế/Bảo mật phủ quyết**, giữ nguyên mở. **Bổ sung (2026-09-15, `SEC §5`/`§8.2`):** SEC ghi rõ toàn bộ phân loại dữ liệu, mã hoá, masking, và tuân thủ NĐ13/2023 trong `SEC` là **đề xuất chờ phủ quyết**, không phải quyết định cuối — SEC **chưa có hiệu lực phủ quyết AG2** cho tới khi có người này. Giữ nguyên mở. | 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; hiệu lực phủ quyết `SEC` | `CTX_e-commerce_v1.0.md (v1.1 trong header)` §3, §5, §7 · `DAT_e-commerce_v1.0.md` §5, §5.2 · `SEC_e-commerce_v1.0.md` §0.1, §5, §8.2 |
| 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 (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) | `CTX_e-commerce_v1.0.md (v1.1 trong header)` §3, §5, §7 |
| OQ-010 | Tech Lead xác nhận: đội thi công thật (không phải đề xuất hồ sơ thầu) có kinh nghiệm vận hành production nào với Kafka/MSK, OpenSearch cluster, EKS chưa? Input trực tiếp cho tiêu chí "Rủi ro kỹ thuật" đã chấm P1=2/P2=4 trong `OPT`. | Tech Lead | 2026-09-12 | Điểm "Rủi ro kỹ thuật" của P1 trong `OPT`; `ARISK` Bước 5 | `OPT_e-commerce_v1.0.md` §4, §9 |
| 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? | Tech Lead | 2026-09-12 | `ADR` message backbone GĐ2; kế hoạch POC `ARISK` Bước 5 | `OPT_e-commerce_v1.0.md` §8, §9 |
| 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`) | `TCO_e-commerce_v1.0.md` §3, §8 |
| OQ-014 | Biểu phí giao dịch VNPay/Momo thật (theo % hay phí cố định) và GMV dự kiến năm 1 là bao nhiêu, để tính `NL-03` trong `TCO`? | PO/tài chính + đàm phán VNPay/Momo | 2026-09-12 | `TCO §4` (khoản chưa tính được) | `TCO_e-commerce_v1.0.md` §4 |
| 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` | `TCO_e-commerce_v1.0.md` §4; `ARISK_e-commerce_v1.0.md` §3 |
| OQ-016 | Nhà cung cấp Email/SMS cụ thể là gì, biểu phí bao nhiêu (`NL-04`)? | PM/Tech Lead | 2026-09-12 | `TCO §4`; `ARISK-10`; `ICD` GĐ2 | `TCO_e-commerce_v1.0.md` §4; `ARISK_e-commerce_v1.0.md` §3 |
| OQ-017 | Báo giá pentest ứng dụng hàng năm + ASV scan hàng quý (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` | `TCO_e-commerce_v1.0.md` §4 |
| OQ-018 | Ngưỡng p95 cho `GET /v1/cart` là bao nhiêu? SA đề xuất ≤500ms (nối `OQ-033` của BA). | PO + Tech Lead | 2026-09-14 | `QAS-003` baseline; bài đo `FIT` ở GĐ3 | `QAS_e-commerce_v1.0.md` §A3, §E |
| OQ-019 | Ngưỡng p95 cho `PATCH`/`DELETE /v1/cart/items` là bao nhiêu? SA đề xuất ≤300ms (nối `OQ-033` của BA). | PO + Tech Lead | 2026-09-14 | `QAS-004` baseline; bài đo `FIT` ở GĐ3 | `QAS_e-commerce_v1.0.md` §A3, §E |
| OQ-020 | Cửa sổ bảo trì có báo trước (nếu có) được loại trừ khỏi ngân sách lỗi 99.9%/tháng là bao nhiêu giờ? SA đề xuất ≤2 giờ/tháng. | PO | 2026-09-14 | `QAS-007` (ngân sách lỗi thật); chính sách release ở `INF` (chưa chạy) | `QAS_e-commerce_v1.0.md` §A3, §E |
| OQ-021 | Tần suất chạy job đối soát thanh toán (reconciliation) là bao nhiêu? SA đề xuất ≤15 phút/lần. | Tech Lead | 2026-09-14 | `QAS-014`; thiết kế job đối soát ở `DAT`/`INF` (chưa chạy) | `QAS_e-commerce_v1.0.md` §A3, §E |
| OQ-022 | Lịch diễn tập DR (failover drill) đầu tiên cho nhóm service giao dịch cốt lõi là khi nào? **Điều kiện đã chốt (sign 2026-09-14, `DEC-12`): phải diễn tập TRƯỚC khi ký AG2** — ngày cụ thể vẫn chờ Ops/SRE. | Ops/SRE | 2026-09-14 | `QAS-008` (nâng `Confidence`); điều kiện tiên quyết ký AG2 (bắt buộc, không còn tuỳ chọn) | `QAS_e-commerce_v1.0.md` §A3, §E, header |
| OQ-023 | Ngưỡng rate limit cụ thể (số request/phút theo IP) cho `PATCH`/`DELETE /v1/cart/items` của Guest là bao nhiêu? **Bổ sung (2026-09-15, `SEC §5.3`):** SA đề xuất **30 request/phút theo `session_id`** + 60 req/phút theo IP (phòng vệ phụ), kèm hệ quả cả hai chiều (chặt hơn/lỏng hơn) — **không tự quyết thay Security**, giữ nguyên mở. | Tech Lead + Security | 2026-09-14 | Hoạt động `sec`/`icd` kế tiếp; `NFR-SEC-03` của BA | `QAS_e-commerce_v1.0.md` §A3, §E · `SEC_e-commerce_v1.0.md` §5.3 |
| OQ-024 | Phương thức MFA cho Admin là gì — TOTP app, SMS OTP, hay khoá bảo mật cứng? **Chốt TẠM (sign 2026-09-15, `DEC-14`): TOTP app (`ASM-20`)** làm baseline cho `sad`/`sec` — chưa phải xác nhận thật của Security, **giữ mở**. | Tech Lead + Security | 2026-09-14 | `ASR-009`; thiết kế `SEC` (mô hình xác thực) | `ASR_e-commerce_v1.0.md` §B2 (ASR-009), §E |
| OQ-025 | Nội dung do seller tự nhập có cần dịch sang 5 ngôn ngữ ở MVP không? Nếu cần, ai cung cấp bản dịch? **Chốt TẠM (sign 2026-09-15, `DEC-14`): không dịch nội dung seller ở MVP, chỉ i18n UI hệ thống (`ASM-21`)** — chưa phải xác nhận thật của PO, **giữ mở**. | PO + Tech Lead | 2026-09-14 | `ASR-015`; `DAT` (mô hình lưu trữ đa ngôn ngữ) | `ASR_e-commerce_v1.0.md` §B2 (ASR-015), §E |
| OQ-026 | `TCO §3.2` tính compute ECS Fargate P2 là 1 dòng "monolith" gộp — có đúng là 2 ECS service riêng (Nhóm Giao dịch/Nhóm Hỗ trợ, như `ASR-001`/`ASR-014`/`OPT §3` mô tả) hay chỉ 1 ECS service duy nhất chưa tách nhóm? **Chốt TẠM (sign 2026-09-15, `DEC-16`): 2 ECS Fargate service riêng để scale độc lập (`ASM-23`)** làm baseline cho `icd`/`dat`/`sec`/`inf`/`fail` — chưa phải xác nhận thật của Tech Lead/Ops, **giữ mở**. | Tech Lead + Ops/SRE | 2026-09-15 | `SAD §7` deployment view; `ADR-012`; khả năng đáp ứng `DRV-04` | `SAD_e-commerce_v1.0.md` §7, §11 |
| OQ-027 | Identity & Access nên thuộc Nhóm Giao dịch (suy từ `ASM-22`, dựa trên `ASR-010`/`011`) hay là nhóm riêng/thuộc Nhóm Hỗ trợ? `OPT §3` không nói rõ vị trí của Identity. **Chốt TẠM (sign 2026-09-15, `DEC-16`): Identity & Access thuộc Nhóm Giao dịch (`ASM-22`)** làm baseline cho `sad`/`sec`/`inf` kế tiếp — chưa phải xác nhận thật của Tech Lead, **giữ mở**. | Tech Lead | 2026-09-15 | `CMP-02`; `SAD §4.1/§7`; `ADR-012` | `SAD_e-commerce_v1.0.md` §4.1, §10, §11 |
| OQ-028 | `IF-021` (Cart&Order → Promotion&Loyalty) là in-process call (theo `SAD §4` legend) hay cross-network REST (theo `OQ-026` TẠM: 2 ECS service riêng)? Hai mô tả trong `SAD` mâu thuẫn nhau. **Chốt TẠM (sign 2026-09-15, `DEC-19`):** cross-network REST (`ASM-24`) làm baseline cho thiết kế `FAIL`/ngân sách `QAS-002` — chưa phải xác nhận thật của Tech Lead, **giữ mở**. | Tech Lead | 2026-09-15 | `ICD §3.6`; thiết kế `FAIL` cho `IF-021`; ngân sách `QAS-002` | `ICD_e-commerce_v1.0.md` §2, §7, §8 |
| OQ-030 | Xác nhận thiết kế schema sự kiện `OrderPlaced`/`PaymentConfirmed` (`ICD §4`) và request `IF-006` (`ICD §3.3`, đặc biệt Payment Service nhận `sellerId` ngay lúc khởi tạo) — đề xuất mới của `ICD`, chưa có nguồn khác xác nhận. **Chốt TẠM (sign 2026-09-15, `DEC-19`):** chấp nhận thiết kế đề xuất — Payment Service nhận `sellerId` ngay tại `IF-006` (`ASM-26`) — làm baseline cho thi công; schema sự kiện giữ nguyên đề xuất — chưa phải xác nhận thật của Tech Lead, **giữ mở**. | Tech Lead | 2026-09-15 | Thi công Cart&Order/Payment/message backbone; `DAT` (hoạt động 5) | `ICD_e-commerce_v1.0.md` §3.3, §4, §8 |
| OQ-031 | Tên header chuẩn cho correlation id ở request là gì? Đề xuất SA: `X-Request-Id`. | Tech Lead | 2026-09-15 | Chuẩn hoá logging/observability (input `inf`) | `ICD_e-commerce_v1.0.md` §1, §8 |
| OQ-032 (SA) | `IF-022` (Cart&Order ↔ Seller Management) — `SAD §4.1` liệt kê cả `CMP-04` và `CMP-05` đều có `IF-022` ở cột "Interface ra" — chiều gọi thật là gì? *(khác `OQ-032` của sổ BA — xem `ba-output/.../00-index/OQ_e-commerce.md`)* **Chốt TẠM (sign 2026-09-15, `DEC-19`):** chiều gọi Cart&Order → Seller Management (`ASM-25`) làm baseline cho §3.7/denormalize `sellerName` — chưa phải xác nhận thật của Tech Lead, **giữ mở**. | Tech Lead | 2026-09-15 | `ICD §3.7`; denormalize `sellerName`; rà lại `SAD §4.1` | `ICD_e-commerce_v1.0.md` §2, §3.7, §7, §8 |
| OQ-033 (SA) | Có chấp nhận denormalize `sellerName` snapshot vào `CartItem` (tương tự `unit_price_snapshot`) để tránh gọi `IF-022` runtime mỗi lần `GET /v1/cart` không? *(khác `OQ-033` của sổ BA)* **Chốt TẠM (sign 2026-09-15, `DEC-19`):** chấp nhận denormalize `sellerName` snapshot vào `CartItem` làm baseline cho `DAT` kế tiếp — chưa phải xác nhận thật của Tech Lead + DBA, **giữ mở**. | Tech Lead + DBA | 2026-09-15 | `DAT` (hoạt động 5); `QAS-003` (ngân sách latency) | `ICD_e-commerce_v1.0.md` §3.1.1, §3.7, §5, §8 |
| OQ-034 | Ngân sách timeout cộng dồn đường găng checkout vượt `QAS-002` (~3.220ms > 3.000ms, xem `FAIL v1.0 §1.2`) ngay cả sau khi siết timeout VNPay/Momo xuống 1.500ms (thay 10s kế thừa). Chọn Lựa chọn A (siết timeout hơn nữa) hay Lựa chọn B (bất đồng bộ hoá bước khởi tạo thanh toán, cần `ADR` mới sửa `SAD §6.1`)? **Chốt (sign 2026-09-15, `DEC-22`): chọn Lựa chọn B.** **Cập nhật (2026-09-15, `DEC-23`): đã viết `ADR-013` (`Proposed`) và sửa nhất quán `SAD §6.1`/`§8` (lên v1.3) + `FAIL §1.2` (lên v1.1)** — tổng ngân sách đồng bộ nay ≤3.000ms cho cả nhánh COD (1.720ms) và VNPay/Momo (1.120ms). Trạng thái: "đã chọn hướng B, đã có `ADR-013`, chờ Tech Lead + PO **thật** xác nhận trước khi `Accepted`" — chưa phải xác nhận thật, **giữ mở**. | Tech Lead + PO | 2026-09-15 | `ADR-013` chuyển `Accepted`; BA viết `SRS`/`AC` cho US-004 Checkout theo trạng thái mới; `ICD` lượt sau chốt endpoint polling/retry/chuyển COD | `FAIL_e-commerce_v1.0.md` §1.2, §10 · `SAD_e-commerce_v1.0.md` §6.1, §8 · `adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md` |
| OQ-041 | Cơ chế FE lấy `redirectUrl` sau khi khởi tạo thanh toán online bất đồng bộ hoàn tất (`ADR-013 §3.2`) — polling (đề xuất mặc định) hay kênh đẩy (SSE/WebSocket)? **Chốt TẠM (sign 2026-09-15, `DEC-25`): polling** làm baseline cho `ICD` lượt sau — chưa phải xác nhận thật của Tech Lead/FE, **giữ mở**. | Tech Lead (kèm ý kiến FE) | 2026-09-15 | Contract endpoint mới ở `ICD` lượt sau; thiết kế FE cho US-004 | Chọn polling mà tải cao bất thường: tăng số request nhỏ không cần thiết (giảm thiểu bằng interval + dừng sau 15s). Chọn SSE/WebSocket mà đội chưa có kinh nghiệm vận hành kênh kết nối lâu dài (`OQ-010` mở): rủi ro sự cố khó chẩn đoán đúng lúc ra mắt | `adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md` §3.2 |
| OQ-042 | `Order` giữ trạng thái `PENDING_PAYMENT_INIT` bao lâu trước khi coi là "kẹt" (async init không bao giờ hoàn tất) và cần job dọn dẹp/hủy tự động? SA đề xuất ngưỡng UX 15 giây (10s timeout đối tác + margin), nhưng thời gian giữ trước khi job dọn dẹp chạy (khác ngưỡng UX) chưa chốt. **Bổ sung (2026-09-15, `DAT §4.3`):** SA đề xuất ngưỡng quét **5 phút** (kể từ `order.placed_at`) + job chạy mỗi 5 phút, hành động: cập nhật `payment_init_status = payment_init_failed`, giải phóng `inventory_stock.quantity_reserved`, ghi `order_status_history`, cảnh báo Ops nếu số lượng phát hiện bất thường (>5 đơn/lần quét) — **chưa tự quyết**, giữ nguyên mở, chờ Tech Lead xác nhận. **Chốt TẠM (sign 2026-09-15, `DEC-25`): ngưỡng quét 5 phút** làm baseline — chưa phải xác nhận thật của Tech Lead, **giữ mở**. | Tech Lead | 2026-09-15 | Thiết kế job quét dọn ở hoạt động `dat`/`inf` lượt sau; cùng bản chất khoảng trống outbox đã ghi ở `FAIL §7` | Ngưỡng quá ngắn: huỷ nhầm `Order` đang xử lý bình thường (VNPay/Momo chỉ chậm, chưa timeout thật). Ngưỡng quá dài: `Order` "ma" tồn đọng lâu, gây nhiễu báo cáo/tồn kho reserve không giải phóng đúng lúc | `adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md` §3.1, §5 · `DAT_e-commerce_v1.0.md` §4.3 |
| OQ-035 | Xác nhận ngưỡng circuit breaker (mở/nửa mở/đóng) đề xuất cho `FM-01/02/03/04/12/13` — số cụ thể là đề xuất SA, chưa đo thật. **Chốt TẠM (sign 2026-09-15, `DEC-22`):** chấp nhận ngưỡng đề xuất §3.1 làm baseline cấu hình — chưa phải xác nhận thật của Tech Lead/SRE, **giữ mở**. | Tech Lead + SRE | 2026-09-15 | Cấu hình circuit breaker thi công; `FIT-19/20/21` (GĐ3) | `FAIL_e-commerce_v1.0.md` §3.1, §10 |
| OQ-036 | Thời gian giữ DLQ (đề xuất 14 ngày) cho SQS FIFO/EventBridge và ngưỡng cảnh báo lag hàng đợi (đề xuất >5 phút) là bao nhiêu? Ai xử lý message DLQ theo domain? **Chốt TẠM (sign 2026-09-15, `DEC-22`):** chấp nhận 14 ngày + ngưỡng cảnh báo >5 phút làm baseline — phân công xử lý theo domain vẫn chưa chốt, chưa phải xác nhận thật của Tech Lead/SRE, **giữ mở**. | Tech Lead + SRE | 2026-09-15 | Thiết kế `inf` (retention, alerting) | `FAIL_e-commerce_v1.0.md` §1.1 (`FM-09/10`), §7, §10 |
| OQ-037 | Kích thước bulkhead (connection pool riêng) cho RDS chính theo module (ghi checkout vs đọc catalog) và cho từng adapter đối tác ngoài — phụ thuộc kết quả `POC-02` chưa chạy. **Chốt TẠM (sign 2026-09-15, `DEC-22`):** giữ nguyên chờ `POC-02` (chưa chạy) trước khi chốt số — DBA/Tech Lead thật xác nhận sau, **giữ mở**. | DBA + Tech Lead | 2026-09-15 | Cấu hình pool thi công; chống nghẽn chéo module | `FAIL_e-commerce_v1.0.md` §3.3, §10 |
| OQ-038 | Giữ transaction DB mở xuyên suốt lời gọi đồng bộ `IF-006`/`IF-007/008` có chấp nhận được không, hay cần tách 2 bước? Đồng thời xác nhận bộ mã lỗi mới đề xuất cho US-004 Checkout (`E-CHECKOUT-0001/0002`, `W-CHECKOUT-0001`, `E-CART-0007`) chưa có trong `SRS`/`API` của BA. | Tech Lead + BA | 2026-09-15 | Transaction boundary `SAD §6.1`; `SRS`/`AC` US-004 (BA) | `FAIL_e-commerce_v1.0.md` §1.2, §5, §10 |
| OQ-039 | SLA xử lý thủ công khi cả GHN và GHTK đều lỗi (`AWAITING_MANUAL_FULFILLMENT`) là bao lâu? Ai (CSKH/Ops) chịu trách nhiệm? | PO + Ops | 2026-09-15 | Runbook vận hành (`inf`, GĐ3) | `FAIL_e-commerce_v1.0.md` §1.1 (`FM-03/04`), §10 |
| OQ-040 | Có cần thêm cache nội dung `Cart`/`CartItem` vào Redis để `GET /v1/cart` có fallback thật khi RDS chậm không (hiện chỉ cache session/ownership, không cache nội dung giỏ)? Đồng thời xác nhận mã lỗi `E-CART-0007` cho ownership check lỗi kỹ thuật (fail-closed, khác 403 thật). **Bổ sung (2026-09-15, `DAT §7.3`):** SA đã đánh giá 2 phương án (A — không cache, B — cache-aside có write-through invalidation) kèm hệ quả bằng bảng so sánh; **nghiêng về Phương án B** nếu Tech Lead chấp nhận độ phức tạp invalidation (chi phí hạ tầng thấp, cải thiện khả dụng đúng lúc flash sale) — **chưa tự quyết**, giữ nguyên mở. | Tech Lead | 2026-09-15 | Thiết kế `DAT`/`inf` (cache strategy); mã lỗi mới cho `SRS` (BA) | `FAIL_e-commerce_v1.0.md` §4, §5, §10 · `DAT_e-commerce_v1.0.md` §7.3 |
| OQ-043 | 1 `Order` (cha) có đúng 1 `Payment` (đa seller, 1 phương thức chung, theo `BR_CartCheckout §4` ERD) hay có ngoại lệ tách `Payment` theo `OrderSeller`/phương thức? (nối `OQ-030` của `ICD`) | Tech Lead + PO | 2026-09-15 | Mô hình `payment.order_id`; `IF-006` request/response (`ICD §3.3`); `order.payment_init_status` | `DAT_e-commerce_v1.0.md` §1.4.1, §2.1, §11 (`ASM-35`) |
| OQ-044 | Chấp nhận **Transactional Outbox pattern** (`outbox_event` + relay poller) làm cơ chế chính thức xử lý khoảng trống "commit `Order` nhưng publish event thất bại" (`FAIL §7`) không, hay dùng job quét đối chiếu đơn giản hơn (PA-1)? Radar ước lượng ~6/10 — `ADR` bắt buộc, chưa viết. **Chốt TẠM (sign 2026-09-15, `DEC-25`): chọn Transactional Outbox** — yêu cầu SA viết `ADR-014` (`Proposed`) ở lượt hoạt động `adr` kế tiếp trước khi coi là chốt kiến trúc chính thức; chưa phải xác nhận thật của Tech Lead, **giữ mở**. | Tech Lead | 2026-09-15 | `ADR` mới (`ADR-014`) ở hoạt động `adr` kế tiếp; thiết kế relay ở `inf` | `DAT_e-commerce_v1.0.md` §4.1 |
| OQ-045 | Công cụ quản lý migration schema — Flyway hay Liquibase (hoặc khác)? | Tech Lead | 2026-09-15 | Quy trình CI/CD; khả năng rollback schema | `DAT_e-commerce_v1.0.md` §8.2 |
| OQ-046 | Đọc `Cart`/`Order` có nên route sang RDS read replica (chỉ có ở kịch bản B) hay luôn đọc primary? SA đề xuất: chỉ Catalog dùng replica, Cart&Order luôn đọc primary. | Tech Lead | 2026-09-15 | Cấu hình routing đọc ở `inf`; độ tươi dữ liệu `GET /v1/cart` (`ASM-36`) | `DAT_e-commerce_v1.0.md` §7.2 |
| OQ-047 | P2 (`SAD` 15 `CMP`) không có `CMP` Audit & Compliance riêng như P1 (`docs/05` v3) — audit trail xuyên module (`RBAC_CartCheckout §5`, `ADR-008 §6`) nên kiến trúc theo cách nào: (a) mỗi module tự ghi `audit_log` trong schema riêng, hay (b) thêm 1 `CMP` Audit tập trung? **Chốt TẠM (sign 2026-09-15, `DEC-25`): phương án (a)** — mỗi module tự ghi `audit_log` riêng, **không thêm `CMP-16`** — làm baseline; chưa phải xác nhận thật của Tech Lead + Security, **giữ mở**. **Bổ sung (2026-09-15, `SEC §7`):** SEC chốt trường bắt buộc (actor/action/resource/correlation_id/timestamp/result), retention (10 năm cho hành động tài chính, 5 năm còn lại — đề xuất) và cơ chế append-only theo schema — vẫn theo phương án (a), giữ nguyên mở. | Tech Lead + Security | 2026-09-15 | Danh sách `CMP` (không thêm `CMP-16` theo hướng TẠM); `ADR-001` nếu sau này đổi hướng ảnh hưởng cấu trúc tổng thể | `DAT_e-commerce_v1.0.md` §10, §11 · `SEC_e-commerce_v1.0.md` §7 |
| OQ-048 | VNPay/Momo có hỗ trợ tích hợp dạng redirect thuần (không iframe/SDK nhập thẻ trên domain sàn) không — điều kiện để giữ phạm vi PCI-DSS SAQ A (`ASM-39`)? | Tech Lead + Security (khi có người) | 2026-09-15 | `SEC §8.1`; giả định nền của `ASR-002`/`ADR-002` | `SEC_e-commerce_v1.0.md` §8.1, §10, §11 |
| OQ-049 | Cơ chế xác thực chữ ký/HMAC webhook cụ thể của VNPay, Momo, GHN, GHTK là gì (thuật toán, header, cách tính chữ ký)? | Tech Lead (khi có tài liệu đối tác) | 2026-09-15 | `THR-17`/`THR-22` (`SEC`); kiểm chứng `ADR-004` thật | `SEC_e-commerce_v1.0.md` §4.5, §4.6, §8.1, §11 |
| OQ-050 | Chấp nhận đề xuất PA-3 (service JWT ngắn hạn ký bởi Identity & Access) cho service-to-service authn giữa Nhóm Giao dịch ↔ Nhóm Hỗ trợ ↔ Payment (`IF-006`/`IF-021`/`IF-022`) không, hay chọn PA-2 (mTLS/App Mesh, cần thêm hạ tầng)? Radar ước lượng ~5 — `ADR` bắt buộc. **Cập nhật (2026-09-15, `DEC-28`):** Tech Lead (ký thay, ngoại lệ `DEC-01`) chốt TẠM hướng **PA-3** làm baseline — yêu cầu SA viết `ADR-015` (`Proposed`) ở lượt hoạt động `adr` kế tiếp cùng `ADR-014`. **Giữ nguyên mở** — chưa `Accepted`, chờ Security + Ops/SRE thật xác nhận. | Tech Lead + Security + Ops/SRE | 2026-09-15 | `ADR-015` (chưa viết) ở hoạt động `adr` kế tiếp; thiết kế `inf` cho TB3/TB4; `THR-09`/`THR-13` | `SEC_e-commerce_v1.0.md` §2.4, §11 · `DEC_e-commerce.md` `DEC-28` |
| OQ-051 | Xác nhận số cụ thể cho Customer JWT: TTL access (đề xuất 15 phút), TTL refresh (đề xuất 14 ngày), cơ chế thu hồi tức thời (đề xuất denylist Redis theo `jti`), tần suất xoay khoá ký (đề xuất 90 ngày), rotation Guest session lúc chuyển đổi thành Customer | Tech Lead | 2026-09-15 | Thiết kế `CMP-02` (Identity & Access) khi tới lượt module đó | `SEC_e-commerce_v1.0.md` §2, §2.1, §2.2, §11 |
| OQ-052 | Xác nhận ngưỡng account lockout theo vai trò (đề xuất: customer/seller 5 lần sai/15 phút; admin 3 lần sai/30 phút) và rate-limit login theo IP (đề xuất 10 request/phút) | Tech Lead + Security | 2026-09-15 | `THR-28`/`THR-31` (`SEC`); thiết kế `CMP-02` | `SEC_e-commerce_v1.0.md` §2.3, §5.3, §11 |
| OQ-053 | Ba trường whitelist chia sẻ cho seller (`recipient_name`/`phone`/`address_line`, `ADR-008` PA-2) hiển thị đầy đủ hay che một phần (VD số điện thoại che 3-4 số giữa)? | Security/Legal (khi có người) + PO | 2026-09-15 | `DAT §5.2`; UI hiển thị đơn hàng cho Seller (ngoài phạm vi US-002/003) | `SEC_e-commerce_v1.0.md` §5.2, §11 |
| OQ-054 | `TCO §3.2` tính "cross-region snapshot (Payment)" (~$30/A, ~$60/B) trong dòng Backup & DR — có mâu thuẫn với `ADR-009` (chọn PA-1, không multi-region) không, hay đây chỉ là snapshot phụ không nằm trong cam kết RTO≤1h? | Tech Lead + Ops/SRE + PO | 2026-09-15 | `INF §5.2`/§10 đối chiếu `TCO`; nội dung `ADR-009` | `INF_e-commerce_v1.0.md` §5.2, §10, §15 |
| OQ-055 | Xác nhận split ECS task đề xuất giữa Nhóm Giao dịch/Nhóm Hỗ trợ (A: 2/2, B: 6/4) và ngưỡng auto-scaling (CPU 60%/70%, request count) — nối `OQ-026` | Tech Lead + Ops/SRE | 2026-09-15 | `INF §4.2`, §10; cấu hình Terraform thật ở GĐ3 | `INF_e-commerce_v1.0.md` §4.2, §10, §15 |
| OQ-056 | Lịch diễn tập DR thật (3 kịch bản DR-1/2/3 ở `INF §5.4`) là ngày nào? SA đề xuất trong vòng 2 tuần kể từ khi xác định Ops/SRE, trước khi trình AG2 — nối `OQ-022` | Ops/SRE | 2026-09-15 | Điều kiện tiên quyết ký AG2 (`DEC-12`) | `INF_e-commerce_v1.0.md` §5.4, §15 |
| OQ-057 | VNPay/Momo/GHN/GHTK/Email-SMS có yêu cầu IP allowlist cho traffic outbound từ sàn không? Nếu có, cần đăng ký 2 Elastic IP NAT với từng đối tác | Tech Lead (khi có tài liệu đối tác thật) | 2026-09-15 | `INF §8.3`; phối hợp hành chính với đối tác trước go-live | `INF_e-commerce_v1.0.md` §8.3, §15 |
| OQ-058 | Chấp nhận ElastiCache kịch bản A không có replica (SPOF) hay muốn thêm 1 replica ngay (chi phí ước tính +~$92/tháng, chưa xác nhận)? **Cập nhật (2026-09-15, `DEC-30`):** Tech Lead (ký thay, ngoại lệ `DEC-01`) chốt TẠM hướng **giữ nguyên `TCO`** — không thêm replica ở kịch bản A, chấp nhận SPOF với hành vi fail-closed theo `FAIL` (không mất dữ liệu nghiệp vụ, chỉ gián đoạn dịch vụ tạm thời). **Giữ nguyên mở** — đây là đánh đổi chi phí/rủi ro của PO, chưa phải quyết định cuối, chờ PO xác nhận. | PO + Ops/SRE | 2026-09-15 | `INF §4.3`; cấu hình ElastiCache thật ở GĐ3 | `INF_e-commerce_v1.0.md` §4.1, §4.3, §15 · `DEC_e-commerce.md` `DEC-30` |
| OQ-059 | Xác nhận (a) retention log CloudWatch/S3 archive, (b) tỉ lệ lấy mẫu X-Ray trace, (c) retention backup RDS (đề xuất 7 ngày, khác 35 ngày ở tài liệu P1 gốc) | Tech Lead + Ops/SRE | 2026-09-15 | `INF §6.1`, §5.2; chi phí lưu trữ thực tế | `INF_e-commerce_v1.0.md` §5.2, §6.1, §15 |
| OQ-060 | Xác nhận công cụ IaC (Terraform, đề xuất — `ADR-017` ứng viên) và ngưỡng coverage unit test cho P2 (đề xuất kế thừa 70%/50% từ tài liệu P1, cần xác nhận lại) | Tech Lead | 2026-09-15 | `INF §11` (`ADR-017`); §7.1 pipeline | `INF_e-commerce_v1.0.md` §7.1, §11, §15 |
| OQ-061 | Kích thước connection pool RDS theo module (ghi checkout vs đọc catalog) và pool HTTP theo từng adapter đối tác ngoài — phụ thuộc `POC-02` chưa chạy — nối `OQ-037` | DBA + Tech Lead | 2026-09-15 | Cấu hình RDS parameter group thật ở GĐ3 | `INF_e-commerce_v1.0.md` §14, §15 |
| OQ-062 | Non-prod (dev/stg) nên tách VPC riêng trong cùng account hay tách hẳn AWS account riêng (đề xuất SA: account riêng theo AWS Organizations)? | Tech Lead + Ops/SRE | 2026-09-15 | `INF §2`, §3 (bảng "Non-prod") | `INF_e-commerce_v1.0.md` §2, §3, §15 |
| OQ-063 | *(nối `OQ-008`, không lặp lại)* Đội Ops/SRE thật (nội bộ/thuê ngoài, quy mô) — chặn trực tiếp khả năng đáp ứng on-call và tần suất diễn tập DR | PM/SRE | 2026-09-12 *(đã mở từ `CTX`)* | `INF §5.4`, §6.5 | `CTX_e-commerce_v1.0.md` §7 · `INF_e-commerce_v1.0.md` §6.5, §15 |

**Câu trả lời tạm (bổ sung 2026-09-12, hoạt động `as-is`):** `OQ-005` và `OQ-008` ở trên chưa có
xác nhận thật từ PO/PM/tài chính trong vòng chạy này. Riêng `OQ-005`/`OQ-006` (deadline, xem
dòng phía trên các mục pháp lý/vận hành) có ghi "câu trả lời tạm" tại
`CTX_e-commerce_v1.0.md (v1.2 trong header)` §4.3, §7: tạm dùng số hồ sơ thầu (`e-commerce/bid/`)
làm mốc tham khảo duy nhất, `Confidence` 🔴, cả hai **giữ mở** cho tới khi có số PO xác nhận thật.

## Open Question đã đóng

| ID | Nội dung | Trả lời | Ngày đóng | Người trả lời |
|---|---|---|---|---|
| OQ-029 | `SAD §4` nêu "22 `IF-nn` ứng viên" nhưng chỉ 17 ID riêng biệt xuất hiện trong nội dung — 5 `IF` bị bỏ sót khi viết `SAD`, hay con số "22" đếm nhầm? | **Đếm nhầm** — rà toàn bộ sơ đồ Context/Container/Component (`SAD §3/§4/§5`) đối chiếu bảng `CMP-nn` (§4.1) và bảng phụ thuộc (§6.3): chỉ 17 ID thực sự xuất hiện (`IF-001…009, 015…022`), không có `IF-010…014` ở bất kỳ đâu, không có mũi tên nào thiếu ID. **Không có interface nào bị bỏ sót** — không bổ sung `IF` mới. `SAD_e-commerce_v1.0.md` đã sửa "22"→"17" ở header/Change Log/Tự chấm tại v1.2 (2026-09-15). | 2026-09-15 | SA (qua skill sa-2-architecture, hoạt động `sad`, sửa lỗi theo yêu cầu người duyệt) |
| 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) chưa có thông tin — cần để biến định hướng "kiến trúc module hoá độc lập" (NFR-07) thành `DRV`/`CON` có số liệu. | Dùng giả định tạm "team MVP chuẩn" ở `Confidence` 🔴 cho Bước 2 (`CON` nhóm Con người), xem `DEC-02` (SA). **Không phải số thật** — số đội/số người/kỹ năng thật vẫn cần PM/Tech Lead xác nhận trước khi ranh giới service GĐ2 được coi là vững; nếu team thực tế khác biệt đáng kể (VD rất nhỏ so với giả định "chuẩn"), phải rà lại `CON` và ranh giới domain đã chia. | 2026-09-12 | Điều phối dự án (đại diện PO, dự án chạy thử) — ký thay, không phải PM/Tech Lead thật |
| 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 độc lập? | **Chấp nhận** dùng làm điểm khởi đầu tham khảo cho một phương án ở Bước 4 — điều kiện bắt buộc: vẫn phải dựng và chấm điểm ≥1 phương án độc lập khác (không mặc định `SAD.md` thắng sẵn). Xem `CTX_e-commerce_v1.0.md` §4.3, §7.1, `DEC-04` (SA). | 2026-09-12 | Ghi chú người duyệt (đại diện PO/điều phối dự án, dự án chạy thử) — không phải PO/Tech Lead ký trực tiếp qua tác vụ `sign` |
| OQ-011 | PO + Tech Lead chọn phương án nào giữa P1 (theo `SAD.md`/hồ sơ thầu) và P2 (khuyến nghị SA), hay yêu cầu SA dựng thêm phương án lai? Đây là nội dung cần ký AG1 cho `OPT`. | **Chọn P2** (modular monolith + managed AWS, tách riêng Payment Service) làm nền cho Bước 5 (`TCO`/`ARISK`) và GĐ2 — **có điều kiện**: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC đo throughput SQS/EventBridge (`ASM-07`) ghi vào `ARISK` ở Bước 5, trước khi chốt `ADR` message backbone GĐ2 (`OQ-012`, vẫn mở). Đây **không phải** chữ ký AG1 toàn phần của PO + Tech Lead thật — chỉ là hướng đi tạm dưới ngoại lệ ký thay (`DEC-01`); `OPT` giữ Status Draft, Tech Lead chưa ký (`OQ-004` giữ mở). Xem `DEC-06` (SA). | 2026-09-12 | Điều phối dự án (đại diện PO, dự án chạy thử) — ký thay theo ngoại lệ `DEC-01`, không phải chữ ký PO/Tech Lead thật |

## Ghi chú

- Sổ này dùng chung ID-space `OQ-nnn` với bộ BA nhưng là sổ riêng của SA
  (`sa-output/e-commerce/00-index/OQ_e-commerce.md`), không ghi đè
  `ba-output/e-commerce/00-index/OQ_e-commerce.md`. Khi một câu hỏi thuộc cả hai bộ (ví dụ
  ràng buộc BA cần SA xác nhận về kiến trúc), tham chiếu chéo bằng ID + đường dẫn, không copy
  nội dung.
- Tại thời điểm khởi tạo, bộ BA của e-commerce có `OQ-001..OQ-034` đang mở/đóng ở
  `ba-output/e-commerce/00-index/OQ_e-commerce.md`; sổ SA sẽ đánh số `OQ-001` trở đi độc lập
  khi `sa-1-context` bắt đầu ghi câu hỏi kiến trúc đầu tiên — cần Grep cả hai sổ trước khi cấp
  ID mới để tránh trùng khi tham chiếu chéo.