| 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 |
| 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 |
| 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 |
