init git

.claude/skills/sa-1-context/GUIDE.md

@@ -0,0 +1,191 @@
+# Hướng dẫn sử dụng — `sa-1-context` (Giai đoạn 1)
+
+## Giai đoạn này giải quyết gì
+
+Đầu vào là một câu kiểu *"cần xây hệ thống đối soát cho POS"* hoặc *"nên chuyển sang
+microservices không"*. Đầu ra là **một phương án đã chọn, có lý do viết ra được, có giá tiền
+3 năm, có danh sách rủi ro kèm người chịu trách nhiệm**.
+
+**Không làm ở giai đoạn này:** vẽ component, thiết kế API, chọn thư viện, viết schema. Thấy
+mình đang làm mấy thứ đó ⇒ đã trượt sang GĐ2.
+
+## Khi nào gọi
+
+| Tình huống | Có nên gọi |
+|---|---|
+| Hệ thống mới hoàn toàn | ✅ Chạy đầy đủ 5 bước |
+| Mở rộng hệ thống đang chạy, không đổi mô hình dữ liệu | ✅ Chạy rút gọn — chỉ `CON` delta + `ARISK` |
+| Thay thế hệ thống cũ (migration) | ✅ Chạy đầy đủ, **bắt buộc** có phần dữ liệu legacy |
+| Khách hỏi "nên dùng công nghệ gì" | ✅ Đúng mục đích — nhưng phải làm Bước 1 trước, đừng trả lời ngay |
+| Cần con số cho báo giá/đấu thầu | ✅ Gọi và nói rõ "chỉ cần `OPT` + `TCO`" |
+| Đã chốt phương án, cần thiết kế chi tiết | ❌ Sang thẳng `/sa-2-architecture` |
+| Thêm một màn hình vào module đã có | ❌ Không cần SA giai đoạn này |
+
+## Cú pháp
+
+```
+/sa-1-context <PROJECT> [--mode new|extend|replace] [--focus ctx|opt|tco|risk] [--out <path>] [go]
+```
+
+| Tham số | Ý nghĩa |
+|---|---|
+| `--mode new` | Hệ thống mới — chạy đủ 5 bước *(mặc định)* |
+| `--mode extend` | Mở rộng — Bước 2 (chỉ ràng buộc mới), Bước 5 (rủi ro) |
+| `--mode replace` | Thay thế hệ thống cũ — đủ 5 bước + phần dữ liệu legacy bắt buộc |
+| `--focus <artifact>` | Chỉ sinh một artifact, ví dụ `--focus tco` khi cần gấp con số |
+| `go` | Bỏ bước dừng xác nhận input |
+
+Kèm file input bằng cách đính kèm trong hội thoại hoặc ghi đường dẫn:
+
+```
+/sa-1-context Settlement --mode new
+  input: ba-output/Settlement/01-discovery/BRIEF_Settlement_v1.0.md,
+         báo giá cloud từ anh Tuấn, ảnh chụp dashboard hệ thống POS
+```
+
+## Chuẩn bị gì trước khi gọi
+
+**Tối thiểu** (không có thì skill vẫn chạy nhưng `Confidence` sẽ là 🔴):
+- Mô tả bài toán, dù mơ hồ
+- Biết ai trả lời được về ngân sách
+
+**Nên có** — mỗi thứ dưới đây nâng chất lượng output rõ rệt:
+
+| Chuẩn bị | Nó quyết định cái gì |
+|---|---|
+| `BRIEF` + `GOAL` của bộ BA | `DRV-nn` — không có thì driver là suy đoán |
+| Ngân sách hạ tầng đã duyệt | Loại bỏ phương án ngay từ đầu, tiết kiệm cả tuần |
+| Chuẩn công nghệ của doanh nghiệp / EA | Tránh bị bác ở phút chót |
+| Quyền đọc DB và dashboard hệ thống hiện tại | Thay ước lượng bằng số thật |
+| Tài liệu API của hệ thống phải tích hợp | Phát hiện sớm ràng buộc không đổi được |
+| Danh sách team + kỹ năng + ai vận hành sau go-live | Ranh giới service khả thi (Conway) |
+| Hoá đơn cloud 3 tháng gần nhất | Mốc để `TCO` không phải bịa |
+
+## Quy trình 5 bước — bạn tham gia ở đâu
+
+| Bước | Skill làm | Bạn làm |
+|---|---|---|
+| 1. Driver | Chưng cất `BRIEF`/mô tả thành `DRV-nn`, chặn "công nghệ giả dạng driver" | Xác nhận con số áp lực với PO |
+| 2. Ràng buộc | Sinh bộ câu hỏi 6 nhóm, đánh dấu nhóm còn trống | **Đi hỏi** — skill không hỏi thay bạn |
+| 3. Hiện trạng | Sinh khung khảo sát, gợi ý chỗ phải nhìn tận mắt | **Mở DB, xem dashboard, gọi thử API** |
+| 4. Phương án | Dựng ≥2 phương án, chấm điểm, nêu cái bị loại | Duyệt trọng số tiêu chí với PO |
+| 5. Chi phí & rủi ro | Dựng `TCO` 3 năm × 2 kịch bản, rà 6 nguồn rủi ro | Cung cấp báo giá, chỉ định chủ rủi ro |
+
+🔴 **Bước 3 là bước skill không làm thay được.** Nó liệt kê cái cần nhìn; việc mở database
+thật và đọc hoá đơn cloud thật là của bạn. Đưa số liệu thô vào, skill sẽ chưng cất.
+
+## Bạn sẽ nhận được gì
+
+Bốn file trong `sa-output/<PROJECT>/01-context/`:
+
+```
+CTX_<PROJECT>_v1.0.md      ← driver, ràng buộc, hiện trạng
+OPT_<PROJECT>_v1.0.md      ← phương án + chấm điểm + khuyến nghị. PO+Tech Lead ký cái này
+TCO_<PROJECT>_v1.0.md      ← chi phí 3 năm, 2 kịch bản tải
+ARISK_<PROJECT>_v1.0.md    ← rủi ro + kế hoạch POC
+```
+
+Cộng ba bảng in ra màn hình: Gate AG1 · quy tắc D1–D12 · danh sách `OQ` mở.
+
+## Đọc bảng chấm điểm phương án thế nào
+
+```
+Tiêu chí                        Trọng số   P1 Mua SaaS   P2 Tự xây   P3 Giữ nguyên
+Đáp ứng DRV Must                  25%         4 (×)         5           1
+Chi phí 3 năm                     20%         3             4           5
+Thời gian tới bản chạy được       15%         5             2           5
+Rủi ro kỹ thuật                   15%         4             2           5
+Phù hợp năng lực team             15%         5             3           5
+Khả năng tiến hoá                 10%         2 (×)         5           1
+────────────────────────────────────────────────────────────────────────────
+Tổng có trọng số                             3.85          3.65        3.60
+
+(×) = chỗ phương án này THUA. Đọc hai ô này trước khi đọc điểm tổng.
+```
+
+🔴 **Điểm tổng gần nhau (3.85 vs 3.65) nghĩa là bộ tiêu chí chưa phân biệt được.** Đừng chọn
+theo chênh lệch 0.2 — quay lại hỏi PO tiêu chí nào thực sự quan trọng nhất, tăng trọng số của
+nó, rồi chấm lại. Hoặc chấp nhận rằng cả hai đều được và chọn theo tiêu chí phụ (ví dụ: cái
+nào đảo ngược rẻ hơn).
+
+## Ví dụ hội thoại
+
+```
+Bạn:    /sa-1-context Settlement
+        Cần xây hệ thống đối soát doanh thu POS. Khách bảo muốn dùng microservices.
+        Đính kèm: BRIEF_Settlement_v1.0.md
+
+Claude: [Bước 0]
+        Input dùng được:
+        | BRIEF_Settlement_v1.0.md | GOAL-01..03, RQ-001..018 | Cao |
+        | "khách muốn microservices" | Định hướng khách gợi ý | Thấp — chưa phải driver |
+
+        Phân loại: hệ thống MỚI (BRIEF §5 nói chưa có hệ thống đối soát).
+
+        ⚠️ "Muốn dùng microservices" là giải pháp, không phải driver. Tôi sẽ ghi vào
+        cột "Định hướng khách gợi ý" và hỏi ngược: chuyển xong thì cái gì tốt lên?
+
+        Ràng buộc tôi CHƯA có — cần bạn đi hỏi:
+        - Ngân sách hạ tầng/tháng (PO)
+        - Kakao có bắt buộc cloud/stack nào không (Tech Lead/EA)
+        - Dữ liệu POS có ràng buộc lãnh thổ không (Legal)
+        - Ai vận hành sau go-live (PM)
+
+        Cách hiểu: driver thật là phát hiện chênh lệch muộn 22 ngày (GOAL-02),
+        thuộc tính chất lượng bị ép là độ trễ xử lý + độ chính xác dữ liệu.
+
+        Ghi vào sa-output/Settlement/01-context/. Xác nhận giúp tôi.
+
+Bạn:    Ngân sách 15tr/tháng. Bắt buộc AWS ap-northeast-2. Dữ liệu phải ở Hàn.
+        Vận hành: đội SRE chung, 3 người, không có ai chuyên Kafka.
+
+Claude: [sinh CTX với DRV-01..03, CON-01..07, khung khảo sát hiện trạng
+         + cảnh báo: CON-05 "SRE không có kinh nghiệm Kafka" sẽ loại phương án
+         event-driven nặng, hoặc buộc phải tính chi phí đào tạo vào TCO]
+```
+
+## Lỗi thường gặp
+
+**"Skill toàn hỏi, chưa cho tôi câu trả lời nào."**
+Đúng như thiết kế ở Bước 2–3. Chọn kiến trúc mà không biết ngân sách và ràng buộc pháp lý là
+chọn bừa. Danh sách câu hỏi chính là danh sách việc bạn cần đi hỏi — mỗi câu trả lời loại bớt
+phương án, tiết kiệm nhiều hơn thời gian đi hỏi.
+
+**"Khách đã chốt công nghệ rồi, sao còn dựng phương án?"**
+Vì "khách đã chốt" thường là *một người* đã chốt dựa trên *một bài blog*. Dựng phương án thứ
+hai mất nửa ngày; phát hiện phương án đã chốt không chạy được mất ba tháng. Nếu khách vẫn giữ
+lựa chọn của họ sau khi xem bảng so sánh — ghi thành `CON-nn` ("ràng buộc do khách chỉ định")
+và đi tiếp, vậy là hợp lệ.
+
+**"Không lấy được số liệu tải hiện tại."**
+Đừng bỏ trống. Ghi `ASM-nn` + đề xuất cách ước: đếm số bản ghi trong DB chia cho số ngày, đọc
+log 1 tuần, hoặc hỏi người vận hành "ngày đông nhất bao nhiêu đơn". Ước lượng có ghi rõ cách
+ước vẫn tốt hơn không có gì — nhưng phải đánh dấu 🔴.
+
+**"TCO ra con số quá lớn, khách sẽ sốc."**
+Đó là giá trị của `TCO`, không phải vấn đề của nó. Con số lớn xuất hiện ở GĐ1 thì còn đổi
+được phương án; xuất hiện ở tháng thứ 13 thì đã muộn. Trình kèm bảng "cắt cái gì thì giảm bao
+nhiêu" để PO có lựa chọn.
+
+**"Phương án tôi thích thắng mọi tiêu chí."**
+Bộ tiêu chí đang được viết ngược từ kết luận. Thêm tiêu chí "chi phí đảo ngược" và "phù hợp
+năng lực vận hành" — hai tiêu chí này thường lật ngược kết quả.
+
+## Ra khỏi giai đoạn này khi nào
+
+Đủ cả bốn:
+
+1. Bảng tự chấm AG1 toàn ✅
+2. PO **và** Tech Lead đã điền `Approved by` vào header `OPT`
+3. Mọi `ARISK` mức cao có chủ, có biện pháp cụ thể (không phải "theo dõi")
+4. Rủi ro cao chưa chứng minh được đã có POC **đã chạy xong**, kết quả ghi vào `ARISK`
+
+Rồi chạy `/sa-2-architecture <PROJECT>`.
+
+## Liên quan
+
+- Tiêu chí gate AG1: `../sa-lifecycle/references/workflow.md` §2
+- Quy tắc viết: `../sa-lifecycle/references/design-rules.md`
+- Khi nào cần POC: `../sa-lifecycle/references/decision-radar.md` §6
+- Template: `templates/solution-context.md` · `templates/option-tradeoff.md` ·
+  `templates/cost-model.md` · `templates/architecture-risk.md`

.claude/skills/sa-1-context/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: sa-1-context
+description: Giai đoạn 1 của quy trình Solution Architect — xác lập bối cảnh và chọn phương án giải pháp. Dùng khi cần làm rõ driver kinh doanh đứng sau một hệ thống, liệt kê ràng buộc (ngân sách, deadline, cloud/stack bắt buộc, kỹ năng team, pháp lý), khảo sát hiện trạng as-is, dựng và chấm điểm 2-3 phương án build/buy/integrate, ước lượng TCO 3 năm, và lập sổ rủi ro kiến trúc kèm kế hoạch POC. Kích hoạt khi người dùng nói "nên dùng công nghệ gì", "so sánh phương án", "build hay mua", "ước lượng chi phí hạ tầng", "TCO", "rủi ro kỹ thuật", "khảo sát hiện trạng hệ thống", "đánh giá khả thi kỹ thuật", "cần POC gì". Output ghi vào sa-output/<PROJECT>/01-context/ và phải qua Gate AG1 trước khi sang sa-2-architecture.
+---
+
+# GĐ1 · CONTEXT — Bối cảnh, ràng buộc & lựa chọn phương án
+
+Mục tiêu duy nhất: **chốt được chọn phương án nào, vì sao, tốn bao nhiêu, rủi ro ở đâu** —
+trước khi bất kỳ ai vẽ một hộp nào.
+
+Output: `CTX` · `OPT` · `TCO` · `ARISK` trong `sa-output/<PROJECT>/01-context/`
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa ràng buộc** — thiếu thông tin ⇒ `OQ-nnn`, không điền con số "hợp lý".
+2. **Không quyết định thay PO** — trade-off nghiệp vụ và ngân sách là của PO; SA trình bảng
+   đánh đổi kèm hệ quả bằng số.
+3. **Mọi phương án phải truy vết được** về `DRV-nn` và `CON-nn`. Không nguồn ⇒ `ASM-nn`.
+4. **Không ghi đè tài liệu đã qua gate** — sửa qua `ADR` mới hoặc `DEC-nn` kèm Change Log.
+
+Nạp thêm: `../sa-lifecycle/references/design-rules.md` (D1–D12) và
+`../sa-lifecycle/references/artifact-map.md` §3 (header bắt buộc, kể cả `Confidence`).
+
+## Bước 0 — Chốt input rồi dừng lại
+
+**Chưa được ghi file.** Làm năm việc rồi **dừng chờ người dùng trả lời**:
+
+1. **Input dùng được** — bảng `File/Nguồn | Vai trò | Độ tin cậy`. Ưu tiên: file người dùng
+   đưa trong hội thoại > `ba-output/<PROJECT>/01-discovery/` (`BRIEF`, `GOAL`) >
+   `ba-output/…/02-analysis/` (`BACKLOG`, `IMPACT`) > source code hiện có > `docs/`.
+2. **Phân loại bài toán** — hệ thống **mới hoàn toàn** / **mở rộng hệ thống đang chạy** /
+   **thay thế hệ thống cũ (migration)**. Ba loại này khác nhau hoàn toàn về khối lượng GĐ1:
+   loại 2 rút gọn `CTX` (chỉ phần delta), loại 3 bắt buộc có phần dữ liệu legacy trong `OPT`.
+3. **Ai trả lời được ràng buộc** — ngân sách (PO), stack/cloud bắt buộc (Tech Lead/EA), pháp
+   lý (Legal/Security), năng lực vận hành (SRE). Chưa biết ⇒ nói rõ.
+4. **Cách hiểu bài toán** — 2–3 câu, kèm tên file định ghi ra.
+5. **Hỏi người dùng** xác nhận bốn điểm trên.
+
+Bỏ bước dừng khi lệnh có `go` — khi đó ghi phần tự đánh giá input vào mục Open Questions của
+`CTX` và đặt `Confidence` 🔴.
+
+## Thực hiện — 5 bước
+
+### Bước 1 — Driver trước, giải pháp sau
+
+Điền `templates/solution-context.md` §Driver.
+
+**`DRV-nn` là áp lực kinh doanh, không phải tính năng.** Phép thử: câu đó có nói được bằng
+tiền, thời gian, rủi ro, hoặc số người không?
+
+```
+DRV-02 | Đối soát thủ công tốn 2 người × 4 giờ/ngày và phát hiện chênh lệch trung bình
+         sau 22 ngày. Mỗi ngày chậm ≈ 30 triệu tiền treo không thu hồi được.
+         Nguồn: BRIEF §2 GOAL-02 · Ai xác nhận: chị Lan (2026-08-22)
+         Thuộc tính chất lượng bị ép: độ trễ xử lý, độ chính xác dữ liệu
+```
+
+🔴 **Bẫy công nghệ giả dạng driver.** "Cần chuyển sang microservices" không phải driver — hỏi
+ngược: *"Chuyển xong thì cái gì tốt lên, đo bằng gì?"*. Câu trả lời ("ba team đang phải chờ
+nhau release, mỗi lần chờ 2 tuần") mới là `DRV`. Ghi mong muốn công nghệ của khách vào cột
+riêng "Định hướng khách gợi ý" — có giá trị tham khảo, không phải driver.
+
+Cột **"Thuộc tính chất lượng bị ép"** ở mỗi `DRV` là cầu nối sang GĐ2: nó chính là danh sách
+`QAS` cần lượng hoá.
+
+### Bước 2 — Ràng buộc, rà đủ sáu nhóm
+
+Điền `templates/solution-context.md` §Ràng buộc. `CON-nn` là thứ **không thương lượng được**,
+khác với sở thích.
+
+| Nhóm | Câu hỏi phải hỏi | Hỏi ai | Bỏ sót thì sao |
+|---|---|---|---|
+| **Tiền** | Ngân sách hạ tầng/tháng đã duyệt? Chi phí một lần cho phép? | PO / tài chính | Thiết kế xong mới biết không đủ tiền chạy |
+| **Thời gian** | Mốc bắt buộc nào có ràng buộc bên ngoài (hợp đồng, luật, mùa vụ)? | PO / PM | Chọn phương án đúng nhưng không kịp |
+| **Công nghệ** | Cloud/stack/chuẩn doanh nghiệp bắt buộc? License đã mua? | Tech Lead / EA | Kiến trúc bị EA bác ở phút chót |
+| **Con người** | Team bao nhiêu, kỹ năng gì, ai vận hành sau go-live? | PM / SRE | Chia 8 service cho 5 người (trái Conway) |
+| **Pháp lý** | Dữ liệu phải nằm trong lãnh thổ nào? Luật nào áp dụng? Kiểm toán gì? | Legal / Security | Phải làm lại toàn bộ tầng dữ liệu |
+| **Hiện trạng** | Hệ thống nào bắt buộc phải tích hợp? Vendor nào đang khoá? | Tech Lead | Phát hiện ở GĐ2 khi đã cam kết thiết kế |
+
+🔴 Ba nhóm hay bị bỏ nhất: **con người** (ai vận hành hệ thống sau khi team dự án giải tán),
+**pháp lý** (người có quyền phủ quyết muộn nhất và đau nhất), **tiền vận hành** (ai cũng ước
+lượng effort dev, ít ai ước lượng hoá đơn cloud tháng thứ 13).
+
+### Bước 3 — Khảo sát hiện trạng
+
+Điền `templates/solution-context.md` §Hiện trạng. Không có bước này thì `OPT` chỉ là so sánh
+công nghệ trên giấy.
+
+Bốn thứ phải nhìn tận mắt, **không nhận qua mô tả**:
+
+| Khảo sát | Cách làm | Ghi lại gì |
+|---|---|---|
+| Hệ thống as-is | Đọc code / sơ đồ / hỏi người đang vận hành | Sơ đồ C4 mức Context của **hiện tại** |
+| Dữ liệu | Mở DB thật, đếm bản ghi, xem chất lượng dữ liệu | Số bảng, số bản ghi lớn nhất, tỉ lệ dữ liệu bẩn |
+| Tích hợp | Đọc tài liệu API bên kia, gọi thử nếu được | Danh sách interface, ai sở hữu, SLA của họ |
+| Vận hành | Xem dashboard, log, hoá đơn cloud, lịch sử sự cố | Traffic thật, p95 hiện tại, chi phí/tháng, sự cố 6 tháng |
+
+🔴 **Dữ liệu không biết nói dối.** Khách nói "khoảng 2.000 đơn/ngày", DB nói 340 đơn/ngày với
+đỉnh 11.000 vào ngày khuyến mãi. Cả hai con số đều quan trọng và chỉ số thứ hai định hình
+kiến trúc. Không truy cập được dữ liệu thật ⇒ ghi `ASM-nn` + `OQ`, hạ `Confidence` 🔴.
+
+### Bước 4 — Dựng và chấm phương án
+
+Điền `templates/option-tradeoff.md`. **Tối thiểu 2 phương án thực sự khác nhau**, cộng phương
+án "không làm gì / giữ nguyên" làm mốc so sánh.
+
+Quy trình bắt buộc, theo đúng thứ tự:
+
+1. **Chốt bộ tiêu chí trước khi mô tả phương án.** Tiêu chí sinh từ `DRV` và `CON`, có trọng
+   số, PO duyệt trọng số. Chốt tiêu chí sau khi đã có phương án yêu thích là tự lừa mình.
+2. **Mô tả mỗi phương án** đủ để ước lượng: thành phần chính, cái gì mua/cái gì tự làm, dữ
+   liệu ở đâu, ai vận hành.
+3. **Chấm điểm** từng tiêu chí, kèm **một câu lý do** cho mỗi ô. Ô không có lý do là ô bịa.
+4. **Nêu rõ phương án bị loại và lý do loại** — bắt buộc theo `D3`.
+5. **Khuyến nghị** của SA, kèm điều kiện: *"Khuyến nghị P2, với điều kiện POC-01 chứng minh
+   được throughput ≥ 500 msg/s. POC fail ⇒ chuyển sang P1."*
+
+Bộ tiêu chí mặc định (cắt/thêm theo dự án, giữ trọng số cộng lại 100%):
+
+| Tiêu chí | Trọng số gợi ý | Đo bằng |
+|---|---|---|
+| Đáp ứng `DRV` mức Must | 25% | Có/không cho từng driver |
+| Chi phí 3 năm (`TCO`) | 20% | Tiền |
+| Thời gian tới bản chạy được | 15% | Tuần |
+| Rủi ro kỹ thuật | 15% | Số `ARISK` mức cao |
+| Phù hợp năng lực team & vận hành | 15% | Kỹ năng phải tuyển/đào tạo |
+| Khả năng tiến hoá (đổi được về sau) | 10% | Chi phí đảo ngược |
+
+🔴 **Đừng chấm điểm để hợp thức hoá lựa chọn đã có.** Dấu hiệu: phương án yêu thích thắng mọi
+tiêu chí. Kiến trúc thật luôn có đánh đổi — phương án thắng phải **thua** ở ít nhất một tiêu
+chí, và chỗ thua đó phải được nói ra.
+
+### Bước 5 — Chi phí và rủi ro
+
+**`TCO`** — điền `templates/cost-model.md`. Ba nguyên tắc:
+
+- Tính **3 năm**, không tính một lần. Chi phí kiến trúc nằm ở năm thứ hai và ba.
+- Bốn nhóm, thiếu nhóm nào cũng sai: hạ tầng · license · vận hành (người + công cụ) · xây dựng.
+- Tối thiểu **2 kịch bản tải** (dự kiến, và dự kiến × 3). Kiến trúc chỉ chạy đúng ở một mức
+  tải là kiến trúc chưa xong.
+
+**`ARISK`** — điền `templates/architecture-risk.md`. Rà đủ sáu nguồn rủi ro:
+
+| Nguồn | Câu hỏi |
+|---|---|
+| Công nghệ mới | Có ai trong team từng chạy production cái này chưa? |
+| Phụ thuộc bên ngoài | Bên kia có SLA không? Ta có phương án khi họ hỏng/đổi/ngừng? |
+| Dữ liệu | Migration có rollback được không? Dữ liệu bẩn tới mức nào? |
+| Hiệu năng | Con số throughput/latency lấy từ đâu — bài đo hay suy đoán? |
+| Con người | Người duy nhất biết hệ thống cũ có còn ở công ty không? |
+| Chi phí | Hoá đơn cloud có thành phần nào tăng theo tải một cách phi tuyến không? |
+
+Mỗi `ARISK-nn`: mô tả · xác suất × tác động · **chủ** · biện pháp hạ rủi ro · **hạn**.
+Rủi ro mức cao mà biện pháp là "sẽ theo dõi" ⇒ chưa có biện pháp. Phải là POC, spike, đàm
+phán hợp đồng, hoặc đổi phương án.
+
+**Kế hoạch POC** — mọi rủi ro cao chưa chứng minh được phải có POC với **tiêu chí pass/fail
+viết trước khi làm** (xem `../sa-lifecycle/references/decision-radar.md` §6).
+
+## Trước khi kết thúc
+
+In ba thứ:
+
+**① Bảng tự chấm Gate AG1** (checklist ở `../sa-lifecycle/references/workflow.md` §2) dạng
+☐/✅. Mục chưa đạt phải nói rõ thiếu gì — **không đánh ✅ cho có**.
+
+**② Checklist D1–D12** (`../sa-lifecycle/references/design-rules.md`) dạng ☐/✅.
+
+**③ Danh sách `OQ` mở** kèm người phải trả lời, deadline đề xuất, và **cái nó chặn**.
+
+Rồi nhắc người dùng: AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header `OPT`)
+trước khi chạy `/sa-2-architecture`.
+
+## Bẫy thường gặp
+
+**Nhảy sang thiết kế quá sớm.** Dấu hiệu: trong `CTX` đã xuất hiện tên service, tên bảng, tên
+queue. GĐ1 chỉ nói *áp lực*, *ràng buộc*, *phương án ở mức khối*. Thấy mình đang vẽ component
+⇒ dừng, quay lại hỏi "driver nào ép ra cái này".
+
+**Một phương án duy nhất.** "Chúng ta sẽ dùng X" không phải lựa chọn, đó là thói quen được
+viết hoa. Bắt buộc dựng phương án thứ hai đủ nghiêm túc để nó có thể thắng.
+
+**Ước lượng chỉ có effort dev.** Hỏi ba câu: hoá đơn cloud tháng thứ 13 bao nhiêu? Ai trực
+sự cố? Chi phí license khi số người dùng gấp đôi?
+
+**Lấy con số hiệu năng từ blog.** "Kafka làm được 1 triệu msg/s" — trong ngữ cảnh của họ, phần
+cứng của họ, kích thước message của họ. Con số dùng để quyết định phải đến từ POC trong ngữ
+cảnh của bạn, hoặc được đánh dấu 🔴 giả định.
+
+**Bỏ qua phương án "không làm gì".** Nó là mốc so sánh, và đôi khi nó thắng. Không đưa nó vào
+thì không ai biết dự án tạo ra bao nhiêu giá trị so với hiện trạng.

.claude/skills/sa-1-context/templates/architecture-risk.md

@@ -0,0 +1,116 @@
+# ARISK — Architecture Risk Register & POC Plan — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-1-context) |
+| **Status** | 🟡 Draft |
+| **Approved by** | Tech Lead: — · PM: — |
+| **Source** | CTX_… v1.0 · OPT_… v1.0 |
+| **Scope** | |
+| **Confidence** | 🟡 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi |
+|---|---|---|---|
+| 1.0 | | | Bản đầu |
+
+> Sổ này **sống suốt dự án**, không đóng ở AG1. Mỗi rủi ro chỉ đóng khi có bằng chứng, không
+> đóng vì hết hạn.
+
+---
+
+## 1. Tóm tắt
+
+| Mức | Số lượng | Đã có biện pháp cụ thể | Quá hạn |
+|---|---|---|---|
+| 🔴 Cao | | | |
+| 🟠 Trung bình | | | |
+| 🟡 Thấp | | | |
+
+**Ba rủi ro cần chú ý nhất tuần này:** `ARISK-…`, `ARISK-…`, `ARISK-…`
+
+## 2. Cách chấm mức
+
+| | Tác động thấp | Tác động vừa | Tác động lớn *(lệch tiến độ >4 tuần, vượt ngân sách, không đáp ứng `DRV` Must)* |
+|---|---|---|---|
+| **Xác suất cao** | 🟠 | 🔴 | 🔴 |
+| **Xác suất vừa** | 🟡 | 🟠 | 🔴 |
+| **Xác suất thấp** | 🟡 | 🟡 | 🟠 |
+
+## 3. Sổ rủi ro
+
+| ID | Rủi ro | Nguồn | XS | TĐ | Mức | Biện pháp hạ rủi ro | Chủ | Hạn | Trạng thái |
+|---|---|---|---|---|---|---|---|---|---|
+| `ARISK-01` | | công nghệ mới | | | 🔴 | POC-01 | | | Mở |
+| `ARISK-02` | | phụ thuộc ngoài | | | | | | | |
+
+**Trạng thái:** Mở · Đang hạ · Đã đóng (kèm bằng chứng) · Đã chấp nhận (kèm ai chấp nhận)
+
+🔴 **Biện pháp "sẽ theo dõi" không phải biện pháp.** Biện pháp hợp lệ là: POC, spike, đàm phán
+hợp đồng, đổi phương án, mua bảo hiểm kỹ thuật (fallback), hoặc **chấp nhận có người ký**.
+
+## 4. Rà sáu nguồn rủi ro *(checklist — mỗi dòng phải trả lời)*
+
+| Nguồn | Câu hỏi | Trả lời | Sinh `ARISK` nào |
+|---|---|---|---|
+| Công nghệ mới | Có ai trong team từng chạy production cái này chưa? | | |
+| Phụ thuộc ngoài | Bên kia có SLA không? Ta làm gì khi họ hỏng/đổi/ngừng? | | |
+| Dữ liệu | Migration có rollback được không? Dữ liệu bẩn tới mức nào? | | |
+| Hiệu năng | Con số throughput/latency lấy từ bài đo hay từ suy đoán? | | |
+| Con người | Người duy nhất biết hệ thống cũ có còn ở công ty không? | | |
+| Chi phí | Khoản nào tăng phi tuyến theo tải? | | |
+
+## 5. Rủi ro đã chấp nhận
+
+*Rủi ro không hạ được và có người ký chấp nhận. Ghi lại để sau này không ai ngạc nhiên.*
+
+| ID | Rủi ro | Vì sao chấp nhận | Ai ký · ngày | Dấu hiệu cảnh báo sớm | Kế hoạch dự phòng |
+|---|---|---|---|---|---|
+
+## 6. Kế hoạch POC
+
+*Mọi `ARISK` 🔴 chưa chứng minh được phải có POC. Tiêu chí pass/fail viết **trước** khi làm —
+POC không có tiêu chí trước là POC luôn "thành công".*
+
+### POC-01 — <tên>
+
+| | |
+|---|---|
+| **Hạ rủi ro** | `ARISK-01` |
+| **Câu hỏi cần trả lời** | *(đúng một câu, có thể trả lời bằng số)* |
+| **Tiêu chí PASS** | *(số cụ thể, ví dụ: ≥ 500 msg/s với payload 2KB, p99 ≤ 200ms, chạy 30 phút không mất message)* |
+| **Tiêu chí FAIL** | *(và khi fail thì làm gì — chuyển sang phương án nào)* |
+| **Phạm vi** | *(cái gì KHÔNG làm trong POC — POC không có giới hạn sẽ thành dự án nhỏ)* |
+| **Thời lượng tối đa** | … ngày · **dừng khi hết thời lượng dù chưa xong** |
+| **Ai làm** | |
+| **Môi trường** | *(phải gần production ở điểm nào — cấu hình máy, kích thước dữ liệu, độ trễ mạng)* |
+
+**Kết quả** *(điền sau khi chạy)*
+
+| | |
+|---|---|
+| **Ngày chạy** | |
+| **Kết quả đo** | |
+| **PASS / FAIL** | |
+| **Điều bất ngờ phát hiện được** | *(thường có giá trị hơn cả kết quả chính)* |
+| **Quyết định rút ra** | ⟶ `ADR-nnn` |
+
+🔴 **POC fail vẫn phải ghi lại đầy đủ.** Nó là bằng chứng cho một phương án bị loại ở `OPT` §5,
+và nó ngăn người khác đề xuất lại đúng phương án đó sau sáu tháng.
+
+### POC-02 — <tên>
+
+*(cùng cấu trúc)*
+
+## 7. Rủi ro đã đóng
+
+| ID | Rủi ro | Đóng ngày | Bằng chứng |
+|---|---|---|---|
+
+## 8. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|

.claude/skills/sa-1-context/templates/cost-model.md

@@ -0,0 +1,137 @@
+# TCO — Cost Model — <PROJECT> · phương án P…
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-1-context) |
+| **Status** | 🟡 Draft |
+| **Approved by** | PO: — |
+| **Source** | CTX_… v1.0 · báo giá … · hoá đơn cloud tháng … |
+| **Scope** | Phương án P… · 3 năm · đơn vị tiền: VND/tháng |
+| **Confidence** | 🟡 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi |
+|---|---|---|---|
+| 1.0 | | | Bản đầu |
+
+---
+
+## 1. Tóm tắt
+
+| | Kịch bản A *(tải dự kiến)* | Kịch bản B *(tải × 3)* |
+|---|---|---|
+| **Năm 1** | | |
+| **Năm 2** | | |
+| **Năm 3** | | |
+| **Tổng 3 năm** | | |
+| **So với `CON-01` (ngân sách duyệt)** | ✅ trong ngân sách / ❌ vượt … % | |
+
+🔴 Vượt ngân sách ⇒ **không im lặng đi tiếp**. Trình `OPT` §7 "Cắt gì thì giảm bao nhiêu" để
+PO có lựa chọn.
+
+## 2. Giả định tải — nền của mọi con số dưới đây
+
+| Chỉ số | Kịch bản A | Kịch bản B | Nguồn |
+|---|---|---|---|
+| Người dùng hoạt động | | | `CTX` §4.4 / ước lượng của … |
+| Giao dịch/ngày (trung bình) | | | |
+| Giao dịch/giờ (đỉnh) | | | |
+| Dung lượng dữ liệu năm 1 / 3 | | | |
+| Tốc độ tăng dữ liệu | /tháng | | |
+| Băng thông ra ngoài | GB/tháng | | |
+
+🔴 **Egress (băng thông ra) là khoản hay bị quên nhất và tăng phi tuyến.** Luôn có dòng này.
+
+## 3. Chi phí hạ tầng
+
+| Hạng mục | Cấu hình | Đơn giá | SL (A) | Tiền (A) | SL (B) | Tiền (B) | Nguồn giá |
+|---|---|---|---|---|---|---|---|
+| Compute | | | | | | | báo giá … ngày … |
+| CSDL | | | | | | | |
+| Cache | | | | | | | |
+| Lưu trữ đối tượng | | | | | | | |
+| Message broker | | | | | | | |
+| Load balancer / gateway | | | | | | | |
+| **Băng thông ra (egress)** | | | | | | | |
+| Backup & DR | | | | | | | |
+| Observability (log/metric/trace) | | | | | | | |
+| Môi trường non-prod (dev/stg) | | | | | | | |
+| **Cộng hạ tầng/tháng** | | | | | | | |
+
+🔴 **Observability và non-prod thường chiếm 20–35% hoá đơn** và gần như luôn bị bỏ khỏi ước
+lượng ban đầu. Giữ hai dòng này kể cả khi chưa có số.
+
+## 4. License & dịch vụ mua ngoài
+
+| Hạng mục | Mô hình tính giá | Đơn giá | Năm 1 | Năm 2 | Năm 3 | Nguồn |
+|---|---|---|---|---|---|---|
+| | theo user / theo core / theo giao dịch | | | | | |
+
+🔴 **Mô hình tính giá quan trọng hơn đơn giá.** License tính theo user thì chi phí tăng cùng
+thành công của sản phẩm — hỏi rõ ngưỡng bậc giá tiếp theo ở đâu.
+
+## 5. Vận hành
+
+| Hạng mục | Cách tính | Năm 1 | Năm 2 | Năm 3 |
+|---|---|---|---|---|
+| Nhân sự vận hành | … người × … % thời gian × chi phí/người | | | |
+| Trực sự cố (on-call) | | | | |
+| Đào tạo kỹ năng mới | *(sinh từ `CON-04` — kỹ năng team chưa có)* | | | |
+| Công cụ (CI, scanner, APM…) | | | | |
+| **Cộng vận hành/năm** | | | | |
+
+🔴 Nếu `CON-04` ghi team chưa có kỹ năng nào đó, dòng "Đào tạo" **không được bằng 0**. Chi phí
+đó có thật, chỉ là nó nằm ở chỗ khác trong tổ chức.
+
+## 6. Chi phí xây dựng (một lần)
+
+| Hạng mục | Effort (người-tuần) | Tiền |
+|---|---|---|
+| Thiết kế & POC | | |
+| Phát triển | | |
+| Kiểm thử | | |
+| Migration dữ liệu | | |
+| Triển khai & tài liệu | | |
+| **Cộng** | | |
+
+## 7. Tổng hợp 3 năm
+
+| Nhóm | Năm 1 | Năm 2 | Năm 3 | Tổng | % |
+|---|---|---|---|---|---|
+| Hạ tầng | | | | | |
+| License | | | | | |
+| Vận hành | | | | | |
+| Xây dựng | | | — | — | |
+| **Tổng** | | | | | 100% |
+
+## 8. Điểm nhạy cảm
+
+*Con số nào sai thì tổng lệch nhiều nhất — đây là chỗ cần đo trước, không cần đo hết.*
+
+| Giả định | Nếu sai ±50% thì tổng 3 năm lệch | Cách giảm bất định |
+|---|---|---|
+| | | POC / báo giá chính thức / đo trên môi trường thật |
+
+## 9. Điểm hoà vốn so với P0 *(giữ nguyên hiện trạng)*
+
+| | |
+|---|---|
+| Chi phí hiện tại (P0)/năm | |
+| Tiết kiệm dự kiến/năm | |
+| **Hoà vốn sau** | … tháng |
+
+## 10. Giả định & Ngoài phạm vi
+
+**Giả định:**
+
+| ID | Giả định | Nếu sai |
+|---|---|---|
+| `ASM-nn` | Tỉ giá, đơn giá cloud giữ nguyên 3 năm | |
+
+**Ngoài phạm vi:** *(ví dụ: chưa tính chi phí bản quyền hệ điều hành, chưa tính chi phí kiểm
+toán bảo mật hàng năm)*
+
+- 

.claude/skills/sa-1-context/templates/option-tradeoff.md

@@ -0,0 +1,160 @@
+# OPT — Solution Options & Trade-off — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-1-context) |
+| **Status** | 🟡 Draft |
+| **Approved by** | PO: — · Tech Lead: — |
+| **Source** | CTX_… v1.0 · TCO_… v1.0 · ARISK_… v1.0 |
+| **Scope** | |
+| **Confidence** | 🟡 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR/DEC |
+|---|---|---|---|---|
+| 1.0 | | | Bản đầu | — |
+
+> ⚠️ **Đây là tài liệu PO + Tech Lead ký để qua AG1.** Đọc §1 và §5 là đủ để quyết.
+
+---
+
+## 1. Khuyến nghị *(đọc mục này trước)*
+
+| | |
+|---|---|
+| **Phương án khuyến nghị** | P… |
+| **Vì sao** | *(một câu, gắn với `DRV` và `CON` cụ thể)* |
+| **Chỗ phương án này THUA** | *(bắt buộc — phương án không thua ở đâu là phương án chưa được chấm thật)* |
+| **Điều kiện kèm theo** | *(ví dụ: với điều kiện POC-01 đạt ≥ … ; POC fail ⇒ chuyển sang P…)* |
+| **Quyết định này cần ai ký** | PO (ngân sách) · Tech Lead (khả thi) |
+
+---
+
+## 2. Bộ tiêu chí *(chốt TRƯỚC khi mô tả phương án)*
+
+*Tiêu chí sinh từ `DRV` và `CON`. PO duyệt trọng số. Trọng số cộng lại = 100%.*
+
+| # | Tiêu chí | Trọng số | Sinh từ | Đo bằng |
+|---|---|---|---|---|
+| 1 | Đáp ứng `DRV` mức Must | 25% | `DRV-01`, `DRV-02` | Có/không từng driver |
+| 2 | Chi phí 3 năm | 20% | `CON-01` | Tiền (từ `TCO`) |
+| 3 | Thời gian tới bản chạy được | 15% | `CON-02` | Tuần |
+| 4 | Rủi ro kỹ thuật | 15% | — | Số `ARISK` mức cao |
+| 5 | Phù hợp năng lực team & vận hành | 15% | `CON-04` | Kỹ năng phải tuyển/đào tạo |
+| 6 | Khả năng tiến hoá | 10% | — | Chi phí đảo ngược |
+
+**Trọng số do ai duyệt · ngày:** …
+
+🔴 Chốt tiêu chí sau khi đã có phương án yêu thích là tự lừa mình. Nếu tiêu chí được sửa sau
+khi chấm, ghi rõ vào Change Log **vì sao**.
+
+---
+
+## 3. Các phương án
+
+### P0 — Không làm gì / giữ nguyên *(mốc so sánh, bắt buộc có)*
+
+| | |
+|---|---|
+| **Mô tả** | Giữ quy trình hiện tại |
+| **Chi phí 3 năm** | *(chi phí thủ công đang tốn — đây là con số dự án phải thắng)* |
+| **Vì sao không chọn** | |
+
+### P1 — <tên phương án>
+
+| | |
+|---|---|
+| **Ý tưởng một câu** | |
+| **Thành phần chính** | |
+| **Mua gì / tự làm gì** | |
+| **Dữ liệu nằm ở đâu, ai sở hữu** | |
+| **Ai vận hành** | |
+| **Thời gian tới bản chạy được** | … tuần |
+| **Chi phí 3 năm** | *(tham chiếu `TCO` §…)* |
+| **Rủi ro chính** | `ARISK-nn`, `ARISK-nn` |
+| **Đảo ngược được không, tốn bao nhiêu** | |
+
+**Sơ đồ mức khối** *(C4 Context — chỉ hộp lớn, chưa phải component)*
+
+```mermaid
+flowchart LR
+```
+
+### P2 — <tên phương án>
+
+*(cùng cấu trúc)*
+
+---
+
+## 4. Bảng chấm điểm
+
+*Thang 1–5. **Mỗi ô phải có một câu lý do** — ô không lý do là ô bịa.*
+
+| Tiêu chí | Trọng số | P0 | P1 | P2 |
+|---|---|---|---|---|
+| 1. Đáp ứng `DRV` Must | 25% | | | |
+| 2. Chi phí 3 năm | 20% | | | |
+| 3. Thời gian | 15% | | | |
+| 4. Rủi ro kỹ thuật | 15% | | | |
+| 5. Năng lực team & vận hành | 15% | | | |
+| 6. Khả năng tiến hoá | 10% | | | |
+| **Tổng có trọng số** | 100% | | | |
+
+**Lý do từng ô**
+
+| Tiêu chí | P1 | P2 |
+|---|---|---|
+| 1 | | |
+| 2 | | |
+
+🔴 **Điểm tổng chênh nhau < 0.3 nghĩa là bộ tiêu chí chưa phân biệt được.** Đừng chọn theo
+chênh lệch đó. Quay lại hỏi PO tiêu chí nào thực sự quan trọng nhất, hoặc chọn theo tiêu chí
+phụ (thường là: cái nào đảo ngược rẻ hơn).
+
+---
+
+## 5. Phương án bị loại và lý do *(bắt buộc — quy tắc `D3`)*
+
+| Phương án | Đã cân nhắc vì | Loại vì | Gắn với | Điều kiện nào thì xét lại |
+|---|---|---|---|---|
+| | | | `CON-nn` / `QAS-nnn` | |
+
+*"Team quen công nghệ X" là lý do hợp lệ — nhưng phải viết thành `CON-nn` có tên, để sau này
+biết quyết định gắn với con người chứ không phải với kỹ thuật.*
+
+---
+
+## 6. Bảng đánh đổi trình PO
+
+*Dịch lựa chọn kỹ thuật thành ngôn ngữ PO hiểu được và quyết được trong một lần đọc.*
+
+| Nếu chọn | Được | Mất | Tiền chênh 3 năm | Thời gian chênh |
+|---|---|---|---|---|
+| P1 | | | | |
+| P2 | | | | |
+
+## 7. Cắt gì thì giảm bao nhiêu
+
+*Dùng khi `TCO` vượt `CON-01`. Cho PO lựa chọn thay vì chỉ báo tin xấu.*
+
+| Cắt phần nào | Tiết kiệm/3 năm | Mất gì | `DRV` nào bị ảnh hưởng |
+|---|---|---|---|
+
+## 8. Giả định & Ngoài phạm vi
+
+**Giả định** — `ASM-nn` ảnh hưởng tới lựa chọn này:
+
+| ID | Giả định | Nếu sai thì phương án nào đổi |
+|---|---|---|
+
+**Ngoài phạm vi:**
+
+- 
+
+## 9. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
+|---|---|---|---|---|---|

.claude/skills/sa-1-context/templates/solution-context.md

@@ -0,0 +1,132 @@
+# CTX — Solution Context & Drivers — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-1-context) |
+| **Status** | 🟡 Draft |
+| **Approved by** | PO: — · Tech Lead: — |
+| **Source** | BRIEF_… v1.0 · biên bản … · dashboard … |
+| **Scope** | <hệ thống / phạm vi kiến trúc> |
+| **Confidence** | 🟡 Ước lượng có cơ sở |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR/DEC |
+|---|---|---|---|---|
+| 1.0 | YYYY-MM-DD | | Bản đầu | — |
+
+> Sơ đồ thắng về **quan hệ và luồng**. Bảng/văn bản thắng về **ràng buộc và con số**.
+
+---
+
+## 1. Tóm tắt cho người quyết định
+
+*Ba câu. Đọc xong biết bài toán kiến trúc là gì và cái gì đang bó tay ta.*
+
+---
+
+## 2. Driver — `DRV-nn`
+
+*Áp lực kinh doanh ép ra hệ thống này. Nói được bằng tiền / thời gian / rủi ro / số người.
+Không nói được ⇒ chưa phải driver, quay lại hỏi.*
+
+| 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` | | BRIEF §… GOAL-nn | | độ trễ · thông lượng · độ chính xác · sẵn sàng · bảo mật · chi phí | Must |
+| `DRV-02` | | | | | Should |
+
+**Cột "Thuộc tính chất lượng bị ép" là cầu nối sang GĐ2** — nó chính là danh sách `QAS` phải
+lượng hoá. Driver không ép thuộc tính nào ⇒ có thể không phải việc của kiến trúc.
+
+### 2.1 Định hướng khách gợi ý *(tham khảo, KHÔNG phải driver)*
+
+| Khách 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 |
+|---|---|---|---|
+| "muốn dùng microservices" | | ☐ | |
+
+🔴 Mỗi dòng ở đây phải được hỏi ngược *"làm xong thì cái gì tốt lên, đo bằng gì"* trước khi
+đưa vào bảng `DRV`.
+
+---
+
+## 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.*
+
+| 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 | PO · | Cứng | Loại phương án … |
+| `CON-02` | Thời gian | | PM · | | |
+| `CON-03` | Công nghệ | Bắt buộc cloud … vùng … | EA · | Cứng | |
+| `CON-04` | Con người | Team … người · kỹ năng … · vận hành sau go-live: … | PM/SRE · | | Ranh giới service tối đa … (Conway) |
+| `CON-05` | Pháp lý | Dữ liệu phải lưu tại … · luật áp dụng … | Legal · | Cứng | |
+| `CON-06` | Hiện trạng | Bắt buộc tích hợp … · vendor khoá … | Tech Lead · | | |
+
+**Cứng** = vi phạm thì dự án bị chặn. **Mềm** = đổi được nhưng tốn tiền/thời gian, ghi rõ tốn bao nhiêu.
+
+### 3.1 Nhóm ràng buộc chưa có thông tin
+
+| Nhóm | Ai phải trả lời | Đã hỏi ngày | `OQ` | Chặn gì |
+|---|---|---|---|---|
+
+---
+
+## 4. Hiện trạng (AS-IS)
+
+### 4.1 Sơ đồ hệ thống hiện tại
+
+*C4 mức Context. Có legend. Nếu chưa có hệ thống nào ⇒ ghi rõ "chưa có", không bỏ trống mục.*
+
+```mermaid
+flowchart LR
+```
+
+### 4.2 Dữ liệu — số thật, không phải mô tả
+
+| Nguồn dữ liệu | Bảng/tập chính | Số bản ghi | Tốc độ tăng | Chất lượng | Nguồn số |
+|---|---|---|---|---|---|
+| | | | /tháng | % bản ghi thiếu/sai: | truy vấn ngày … |
+
+🔴 Không truy cập được dữ liệu thật ⇒ ghi `ASM-nn`, hạ `Confidence` toàn tài liệu xuống 🔴.
+
+### 4.3 Tích hợp đang có
+
+| Hệ thống | Giao thức | Ai sở hữu | SLA của họ | Tài liệu | Đã gọi thử chưa |
+|---|---|---|---|---|---|
+| | | | | đường dẫn | ☐ |
+
+### 4.4 Vận hành — số thật
+
+| Chỉ số | Giá trị hiện tại | Đỉnh ghi nhận | Nguồn |
+|---|---|---|---|
+| Traffic | /ngày | /giờ, ngày … | dashboard … |
+| p95 latency | ms | ms | |
+| Chi phí hạ tầng | /tháng | | hoá đơn tháng … |
+| Sự cố 6 tháng qua | lần · tổng downtime … | | log sự cố |
+
+🔴 **Đỉnh quan trọng hơn trung bình.** Trung bình 340 đơn/ngày với đỉnh 11.000 vào ngày khuyến
+mãi là hai bài toán kiến trúc khác nhau. Luôn ghi cả hai cột.
+
+---
+
+## 5. Giả định — `ASM-nn`
+
+| ID | Giả định | Cách xác minh | Hệ quả nếu sai | Chủ | Hạn |
+|---|---|---|---|---|---|
+| `ASM-01` | | | | | |
+
+Giả định sai mà hệ quả lớn ⇒ nâng thành `ARISK` và xác minh ngay trong GĐ1.
+
+## 6. Ngoài phạm vi
+
+*Những thứ người đọc có thể tưởng là có.*
+
+- 
+
+## 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` | | | | AG1 · `OPT` | |