71 KiB
71 KiB
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 stakeholderOQ-001, buổi làm việc trực tiếpOQ-005, baseline KPI thậtOQ-007).- Không có
BRIEF/RISK/STAKEHOLDERcấ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 pipelineba-*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ắnConfidence 🔴cho toàn bộDRVcho 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ộtQAScụ thể (chưa cóQASvì đâ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 → ghiDEC-nn, không cầnADRtheodecision-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.mdBướ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ácOQ-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ớiDRV-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ònamount: null) không phải làTCOcủa GĐ1 SA — đây là ước lượng dự thầu cho một hợp đồng, khác mục đích vớiTCO(ước lượng vận hành 3 năm theo phương án kiến trúc đã chọn). SA sẽ tự tínhTCOriê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-05mớ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.