init git

.claude/skills/sa-4-evolution/GUIDE.md

@@ -0,0 +1,174 @@
+# Hướng dẫn sử dụng — `sa-4-evolution` (Giai đoạn 4)
+
+## Giai đoạn này giải quyết gì
+
+Hệ thống đã chạy thật. Câu hỏi bây giờ không còn là "thiết kế thế nào" mà là **"kiến trúc ta
+thiết kế và kiến trúc đang chạy có phải một không"**.
+
+Đầu vào là số liệu vận hành thật. Đầu ra là **bảng đối chiếu cam kết × thực tế**, và một
+roadmap kỹ thuật PO duyệt được.
+
+**Không làm ở giai đoạn này:** thiết kế lại hệ thống (đó là vòng mới, quay về `sa-1-context`),
+post-mortem vận hành (thuộc SRE — ở đây chỉ làm phần kiến trúc).
+
+## Khi nào gọi
+
+| Tình huống | Có nên gọi |
+|---|---|
+| Một tháng sau go-live | ✅ `--focus conf` — lần đối chiếu đầu tiên |
+| Định kỳ hàng tháng | ✅ `--focus conf` |
+| Hoá đơn cloud tăng bất thường | ✅ `--focus conf`, đọc §b trước |
+| Vừa có sự cố nghiêm trọng | ✅ `--focus review` sau khi SRE xong post-mortem vận hành |
+| Lập kế hoạch quý | ✅ `--focus roadmap` |
+| Đánh giá kiến trúc định kỳ | ✅ `--focus review` mỗi quý |
+| Cần thiết kế một hệ thống mới | ❌ `/sa-1-context` |
+| Chưa có telemetry gì | ⚠️ Chạy được, nhưng `CONF` sẽ toàn "chưa đo được" — đó cũng là một phát hiện |
+
+## Cú pháp
+
+```
+/sa-4-evolution <PROJECT> [--focus conf|roadmap|review] [--period 2026-09] [--out <path>] [go]
+```
+
+| Tham số | Ý nghĩa |
+|---|---|
+| `--focus conf` | Đối chiếu `QAS`/`TCO`/sự cố/drift với thực tế |
+| `--focus roadmap` | Lập `TRM` từ phát hiện của `CONF` |
+| `--focus review` | Đánh giá kiến trúc định kỳ hoặc post-mortem sau sự cố |
+| `--period <YYYY-MM>` | Kỳ đối chiếu, mặc định tháng gần nhất |
+| `go` | Bỏ bước dừng xác nhận input |
+
+```
+/sa-4-evolution Settlement --focus conf --period 2026-09
+/sa-4-evolution Settlement --focus review   "sự cố INC-2026-0912: batch đối soát chạy 3 giờ, chặn báo cáo sáng"
+```
+
+## Chuẩn bị gì trước khi gọi
+
+🔴 **Đây là giai đoạn phụ thuộc dữ liệu nhiều nhất.** Không có số thì skill chỉ in ra bảng
+trống — và đó là kết luận, không phải lỗi.
+
+| Cần | Lấy ở đâu | Dùng cho |
+|---|---|---|
+| Số đo p50/p95/p99 các thao tác chính | APM / dashboard | `QAS` × thực tế |
+| Uptime thật + tổng downtime trong kỳ | uptime monitor | `QAS` sẵn sàng |
+| Thông lượng thật, đỉnh trong kỳ | metric | `QAS` thông lượng |
+| **Hoá đơn cloud chi tiết theo dịch vụ** | cổng thanh toán cloud | `TCO` × thực tế |
+| Danh sách sự cố trong kỳ + nguyên nhân | log sự cố / ticket | Sự cố × `ADR` |
+| Lịch sử `FIT` trên CI | CI | Drift |
+| Trace/log để biết interface thật đang gọi nhau thế nào | tracing | Drift |
+
+## Bạn sẽ nhận được gì
+
+```
+sa-output/<PROJECT>/04-evolution/
+├── CONF_<PROJECT>_<YYYY-MM>.md   ← mỗi kỳ một file, không ghi đè
+├── TRM_<PROJECT>_v1.0.md         ← roadmap, lên version
+└── PMR_<PROJECT>_<YYYY-Qn>.md    ← đánh giá định kỳ
+    PMR_<PROJECT>_<INC-id>.md     ← post-mortem sau sự cố
+```
+
+## Đọc bảng đối chiếu thế nào
+
+```
+QAS × thực tế · kỳ 2026-09
+┌──────────┬──────────────────┬──────────────┬──────────┬─────────────────────────┐
+│ QAS-001  │ p95 ≤ 300ms      │ p95 = 240ms  │ ✅ đạt   │                         │
+│ QAS-004  │ batch ≤ 45 phút  │ 52 phút      │ ❌       │ TD-05 · TRM mục 1       │
+│ QAS-007  │ SLA 99.9%        │ 99.94%       │ ✅ đạt   │ downtime 26/43 phút     │
+│ QAS-011  │ cảnh báo ≤ 3 phút│ chưa đo được │ ⚠️       │ thiếu bài đo — bài học  │
+└──────────┴──────────────────┴──────────────┴──────────┴─────────────────────────┘
+```
+
+- ✅ đạt · ❌ không đạt ⇒ vào `TRM` · ⚠️ **chưa đo được** ⇒ AG2 định nghĩa cách đo không khả
+  thi, hoặc observability thiếu
+
+⚠️ **không xấu hơn ❌.** Nó xấu hơn: ❌ ta biết mình đang ở đâu, ⚠️ ta không biết gì cả.
+
+## Ví dụ hội thoại
+
+```
+Bạn:    /sa-4-evolution Settlement --focus conf --period 2026-09
+        Đính kèm: hoá đơn AWS tháng 9, export dashboard Grafana, log sự cố
+
+Claude: [Bước 0]
+        Input: QAS v1.1 ✅, TCO v1.0 ✅, hoá đơn AWS 09/2026, Grafana export, 3 sự cố.
+        Đủ để đối chiếu QAS (8/11 mục) và TCO (đầy đủ).
+        Thiếu: bài đo cho QAS-009 và QAS-011 (observability) → sẽ ghi "chưa đo được".
+        Xác nhận ghi vào CONF_Settlement_2026-09.md?
+
+Bạn:    ok
+
+Claude: ② QAS × thực tế: 6 đạt · 2 không đạt · 3 chưa đo được
+
+        ③ TCO × hoá đơn:
+        | Compute        | ước 4,2tr | thật 4,0tr | −5%   ✅ |
+        | CSDL           | ước 3,5tr | thật 3,3tr | −6%   ✅ |
+        | Observability  | ước 1,0tr | thật 3,8tr | +280% 🔴 |
+        | Egress         | ước 0,5tr | thật 2,1tr | +320% 🔴 |
+        | Tổng           | ước 11tr  | thật 15,4tr| +40%     |
+
+        Truy nguyên hai khoản vượt:
+        - Observability: đang giữ log 90 ngày, INF §8 thiết kế 30 ngày.
+          → drift cấu hình. Giảm về 30 ngày tiết kiệm ~2,5tr/tháng.
+        - Egress: báo cáo tải file PDF trực tiếp từ service, không qua CDN.
+          → không có trong thiết kế. Không thuộc 4 loại lý do hợp lệ ⇒ có thứ
+            chạy mà thiết kế không biết. Cần xác nhận với dev.
+
+        ④ Sự cố:
+        - INC-0912 (batch 3 giờ)     → truy về QAS-004 không đạt, đã biết trước
+        - INC-0918 (5xx 12 phút)     → truy về ASM-04 "API POS luôn trả trong 2s" SAI
+                                       thực tế có lúc 30s ⇒ FM-02 timeout đặt quá cao
+        - INC-0925 (sai số báo cáo)  → 🔴 ĐIỂM MÙ MỚI: cache không invalidate khi
+                                       sửa đơn hàng cũ. DAT §7 không nói tới trường hợp này.
+
+        Điểm mù mới là phát hiện giá trị nhất kỳ này → đề xuất QAS mới + FIT mới.
+
+        ▶ Ba mục đầu cho TRM (PO xếp thứ tự):
+        1. Giảm retention log về 30 ngày   · 0,5 ngày công · −2,5tr/tháng
+        2. Đưa tải file qua CDN            · 3 ngày công   · −1,8tr/tháng
+        3. Sửa chiến lược cache            · 5 ngày công   · ngăn tái diễn INC-0925
+```
+
+## Lỗi thường gặp
+
+**"Không có dashboard, không đo được gì."**
+Vậy kết luận của kỳ này là *"hệ thống đang chạy mà không ai biết nó chạy thế nào"* — một phát
+hiện nghiêm trọng và đáng trình. Mục đầu tiên của `TRM` là dựng observability.
+
+**"Chi phí vẫn trong ngân sách nên không cần xem."**
+Trong ngân sách nhưng gấp 3 lần ước lượng nghĩa là mô hình chi phí sai — và nó sẽ sai tiếp,
+lớn hơn, khi tải tăng. Truy nguyên chênh lệch kể cả khi chưa vượt.
+
+**"Sự cố do dev quên đặt timeout, không phải lỗi kiến trúc."**
+Câu hỏi kiến trúc không phải "ai quên" mà "vì sao hệ thống cho phép một lời gọi không timeout
+tồn tại". Câu trả lời thường là một `FIT` mới — và nó ngăn cả lớp lỗi đó, không chỉ một lần.
+
+**"PO không duyệt mục nào trong roadmap kỹ thuật."**
+Roadmap đang viết bằng ngôn ngữ kỹ thuật. Đổi "tái cấu trúc module Order" thành "giảm 2 ngày
+cho mỗi tính năng chạm Order; quý tới có 6 tính năng như vậy ⇒ tiết kiệm 12 ngày". PO duyệt
+con số, không duyệt danh từ kỹ thuật.
+
+**"ADR-005 hoá ra sai, tôi sửa lại nội dung cho đúng."**
+Đừng. Viết `ADR` mới có `Supersedes: ADR-005`, đổi trạng thái bản cũ thành `Superseded by`.
+Giá trị lớn nhất của ADR là ghi lại điều ta *đã tin* lúc đó — sửa đi là xoá mất bài học.
+
+## Ra khỏi giai đoạn này khi nào
+
+Đủ cả bốn:
+
+1. Bảng tự chấm AG4 toàn ✅
+2. **PO + SRE + EA** đã ký
+3. Mọi sự cố trong kỳ đã truy về `ADR`, `ASM`, hoặc được ghi nhận là điểm mù mới
+4. `TRM` đã được PO xếp thứ tự và các mục đầu đã vào backlog
+
+Sau đó: quay lại `--focus conf` ở kỳ tiếp theo, hoặc mở vòng kiến trúc mới bằng
+`/sa-1-context` nếu driver kinh doanh đã đổi.
+
+## Liên quan
+
+- Tiêu chí gate AG4: `../sa-lifecycle/references/workflow.md` §2
+- Nhịp chạy đề xuất: `../sa-lifecycle/references/workflow.md` §7
+- Vòng đời ADR: `../sa-lifecycle/references/artifact-map.md` §4
+- Template: `templates/conformance-report.md` · `templates/technical-roadmap.md` ·
+  `templates/architecture-review.md`

.claude/skills/sa-4-evolution/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: sa-4-evolution
+description: Giai đoạn 4 của quy trình Solution Architect — vận hành và tiến hoá kiến trúc sau khi hệ thống chạy thật. Dùng để đối chiếu telemetry production với NFR đã cam kết, so chi phí hạ tầng thực tế với TCO đã ước lượng, phát hiện drift giữa kiến trúc thiết kế và kiến trúc đang chạy, truy nguyên sự cố về quyết định hoặc giả định kiến trúc, đánh giá kiến trúc định kỳ (ATAM rút gọn), và lập roadmap kỹ thuật cho vòng sau. Kích hoạt khi người dùng nói "hệ thống chạy có đạt không", "đo lại NFR", "chi phí cloud tăng", "tối ưu chi phí hạ tầng", "kiến trúc lệch so với thiết kế", "đánh giá kiến trúc", "post-mortem", "sau sự cố", "roadmap kỹ thuật", "kế hoạch migrate", "modernize". Output vào sa-output/<PROJECT>/04-evolution/ và kết thúc bằng Gate AG4.
+---
+
+# GĐ4 · EVOLUTION — Vận hành & tiến hoá
+
+Mục tiêu duy nhất: **đối chiếu kiến trúc đã thiết kế với kiến trúc đang chạy thật**, và biến
+chênh lệch đó thành kế hoạch chứ không thành ngạc nhiên.
+
+Output: `CONF` · `TRM` · `PMR` trong `sa-output/<PROJECT>/04-evolution/`
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa số liệu vận hành** — không đo được ⇒ ghi "chưa đo được vì …", không suy đoán.
+2. **Không quyết định thay PO** về ưu tiên roadmap. Trình chi phí và rủi ro, PO xếp thứ tự.
+3. **Mọi kết luận phải truy vết được** về một bài đo, một sự cố có mã, hoặc một hoá đơn.
+4. **Không sửa `ADR` cũ để hợp thức hoá thực tế** — thực tế bác bỏ quyết định ⇒ `ADR` mới có
+   `Supersedes:`, giữ nguyên bản cũ.
+
+Nạp thêm: `../sa-lifecycle/references/design-rules.md` ·
+`../sa-lifecycle/references/artifact-map.md` §4 (vòng đời ADR).
+
+## Bước 0 — Chốt input rồi dừng lại
+
+**Chưa được ghi file.** Làm bốn việc rồi **dừng chờ người dùng trả lời**:
+
+1. **Input dùng được** — `sa-output/…/02-architecture/` (`QAS`, `SAD`, `ADR`, `INF`),
+   `01-context/TCO`, `03-enablement/` (`FIT`, `TDEBT`), cộng **số liệu vận hành thật**:
+   dashboard, log sự cố, hoá đơn cloud, kết quả `FIT` trên CI.
+2. **Kiểm dữ liệu vận hành** — có đủ để đối chiếu không? Thiếu cái gì? Không có telemetry thì
+   `CONF` chỉ là bảng "chưa đo được" — nói rõ điều đó trước khi chạy.
+3. **Chọn phạm vi** — `--focus conf|roadmap|review`. Sau một sự cố lớn thì `--focus review`;
+   định kỳ hàng tháng thì `--focus conf`.
+4. **Hỏi người dùng** xác nhận ba điểm trên.
+
+Bỏ bước dừng khi lệnh có `go`.
+
+## Thực hiện — 3 hoạt động
+
+### 1 — Conformance report `CONF`  *(`--focus conf`)*
+
+Điền `templates/conformance-report.md`. Bốn đối chiếu:
+
+**a. `QAS` × telemetry thật**
+
+Mỗi `QAS` một dòng: mục tiêu · đo được thật · đạt/không đạt/**chưa đo được**.
+
+🔴 **"Chưa đo được" là một kết quả hợp lệ và phải ghi ra.** Nó có nghĩa là AG2 định nghĩa cách
+đo không khả thi, hoặc observability thiếu — cả hai đều là phát hiện có giá trị. Che nó bằng
+một con số ước lượng là cách tệ nhất.
+
+**b. `TCO` × hoá đơn thật**
+
+Từng hạng mục. **Chênh lệch > 20% phải giải thích được** bằng một trong bốn lý do: tải khác dự
+kiến · cấu hình khác thiết kế · hạng mục bị bỏ sót khi ước lượng · đơn giá thay đổi. Không
+thuộc bốn loại ⇒ đang có thứ gì đó chạy mà không ai biết.
+
+**c. Sự cố × quyết định kiến trúc**
+
+Mỗi sự cố trong kỳ truy về một trong ba:
+
+| Truy về | Nghĩa là | Hành động |
+|---|---|---|
+| Một `ADR` | Quyết định đó có hệ quả đã ghi hoặc chưa ghi | Cập nhật mục "Hệ quả" của `ADR`; nếu quyết định sai ⇒ `ADR` mới |
+| Một `ASM` | Giả định sai | Sửa giả định, rà mọi thứ dựa trên nó |
+| **Điểm mù mới** | Không ai nghĩ tới | Giá trị cao nhất — thêm `QAS`/`FM` mới |
+
+**d. Kiến trúc thiết kế × kiến trúc đang chạy (drift)**
+
+| Nguồn phát hiện drift | Cách kiểm |
+|---|---|
+| `FIT` đỏ hoặc bị tắt | Đọc lịch sử CI |
+| Component có trong code mà không có trong `SAD` | So sơ đồ với cấu trúc repo/deployment thật |
+| Interface đang gọi mà không có trong `ICD` | Đọc trace/log, không đọc code |
+| Whitelist `FIT` quá hạn | `FIT` §3 |
+| `TD` quá hạn xét lại | `TDEBT` |
+
+🔴 **Đọc trace và log để tìm interface thật, đừng chỉ đọc code.** Lời gọi phát sinh lúc chạy
+(cấu hình, plugin, job) không lộ ra khi đọc code tĩnh.
+
+### 2 — Technical roadmap `TRM`  *(`--focus roadmap`)*
+
+Điền `templates/technical-roadmap.md`.
+
+Nguồn đầu vào của roadmap, theo thứ tự ưu tiên:
+
+1. `QAS` không đạt ở `CONF` — cam kết đang bị phá
+2. `TD` mức cao có lãi suất lớn — đang làm chậm mọi thứ
+3. Drift phải đóng — kiến trúc thật đang trôi khỏi kiến trúc thiết kế
+4. Chi phí vượt `TCO` — tiền chảy mỗi tháng
+5. Rủi ro mới (vendor, cuối vòng đời công nghệ, tuân thủ)
+6. Chuẩn bị cho tải/tính năng đã biết trước trong roadmap sản phẩm
+
+Mỗi mục: vấn đề · phương án · chi phí · **lợi ích bằng số** · rủi ro nếu không làm · phụ thuộc.
+
+🔴 **Không xếp thứ tự thay PO.** Trình bảng "chi phí × lợi ích × rủi ro nếu không làm" và để PO
+xếp. Ngoại lệ duy nhất: mục thuộc tuân thủ pháp lý hoặc bảo mật mức cao — nêu rõ đó là ràng
+buộc, không phải lựa chọn.
+
+Với mục là migration, bắt buộc có: các bước cắt chuyển · cách chạy song song · **cách rollback
+ở từng bước** · tiêu chí đi tiếp.
+
+### 3 — Architecture review / post-mortem `PMR`  *(`--focus review`)*
+
+Điền `templates/architecture-review.md`. Hai chế độ:
+
+**a. Định kỳ (ATAM rút gọn)** — mỗi quý:
+
+1. Rà lại `QAS`: còn đúng với nhu cầu hiện tại không? Cái nào thừa, cái nào thiếu?
+2. Với mỗi `QAS` quan trọng, tìm **điểm nhạy cảm** (chỗ một thay đổi nhỏ làm thuộc tính đó
+   đổi nhiều) và **điểm đánh đổi** (chỗ cải thiện thuộc tính này làm hỏng thuộc tính kia)
+3. Rà `ADR` `Accepted`: điều kiện xét lại ở §7 của mỗi ADR đã chạm ngưỡng chưa?
+4. Rà rủi ro mới: vendor, cuối vòng đời, tuân thủ, nhân sự
+
+**b. Sau sự cố (post-mortem kiến trúc)** — chỉ cho sự cố có nguyên nhân kiến trúc:
+
+Post-mortem vận hành thuộc SRE. Phần kiến trúc trả lời ba câu:
+
+1. Kiến trúc đã **cho phép** sự cố này xảy ra ở chỗ nào? *(không phải "ai làm sai")*
+2. Thiết kế đã dự đoán tình huống này chưa? Có trong `FAIL` không?
+3. Sửa ở tầng nào là đúng: code · cấu hình · kiến trúc · quy trình?
+
+🔴 **Không đổ lỗi cho người.** "Dev quên đặt timeout" là triệu chứng; câu hỏi kiến trúc là "vì
+sao hệ thống cho phép một lời gọi không timeout tồn tại, và làm sao để lần sau không thể".
+Câu trả lời thường là một `FIT` mới.
+
+## Trước khi kết thúc
+
+In bốn thứ:
+
+**① Bảng tự chấm Gate AG4** (`../sa-lifecycle/references/workflow.md` §2) dạng ☐/✅.
+
+**② Bảng `QAS` × thực tế** — đạt / không đạt / chưa đo được, kèm số.
+
+**③ Bảng `TCO` × hoá đơn** — chênh lệch từng hạng mục, giải thích cho chênh > 20%.
+
+**④ Ba mục đầu của `TRM`** kèm chi phí và lợi ích bằng số, để PO xếp thứ tự.
+
+Rồi nhắc người dùng: AG4 cần **PO + SRE + Enterprise Architect ký**.
+
+## Bẫy thường gặp
+
+**Không đo được vì AG2 không định nghĩa cách đo.** Đây là hậu quả trực tiếp của việc để lọt
+`QAS` thiếu dòng "đo bằng cách nào". Ghi nhận thành bài học trong `PMR`, đừng lấp liếm bằng
+ước lượng.
+
+**Chỉ nhìn giá trị trung bình.** Trung bình luôn đẹp. `QAS` viết theo phân vị thì đo theo phân
+vị — p95 và p99 mới là chỗ người dùng khó chịu.
+
+**Bỏ qua chi phí vì "vẫn trong ngân sách".** Trong ngân sách nhưng gấp 3 lần ước lượng nghĩa
+là mô hình chi phí sai, và nó sẽ sai tiếp khi tải tăng. Truy nguyên chênh lệch dù chưa vượt.
+
+**Sửa `ADR` cũ cho khớp thực tế.** Làm mất giá trị lớn nhất của ADR: ghi lại điều ta *đã tin*
+lúc đó. Viết `ADR` mới có `Supersedes:` và để bản cũ nguyên vẹn.
+
+**Post-mortem thành cuộc tìm người có lỗi.** Sự cố lặp lại được nghĩa là hệ thống cho phép nó
+lặp lại. Câu hỏi đúng là "làm sao để lần sau không thể xảy ra", và câu trả lời thường là một
+bài kiểm tự động, không phải một lời nhắc nhở.
+
+**Roadmap kỹ thuật toàn mục "tái cấu trúc".** PO sẽ không duyệt. Mỗi mục phải có lợi ích bằng
+số theo ngôn ngữ của họ: giảm bao nhiêu tiền/tháng, nhanh hơn bao nhiêu ngày mỗi tính năng,
+giảm bao nhiêu sự cố.

.claude/skills/sa-4-evolution/templates/architecture-review.md

@@ -0,0 +1,173 @@
+# PMR — Architecture Review / Post-mortem — <PROJECT>
+
+| | |
+|---|---|
+| **Loại** | 🔄 Đánh giá định kỳ *(ATAM rút gọn)* / 🚨 Post-mortem sau sự cố |
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-4-evolution) |
+| **Status** | 🟡 Draft |
+| **Approved by** | Tech Lead: — · EA: — |
+| **Source** | CONF_… · QAS_… · ADR-… · log sự cố … |
+| **Scope** | Kỳ … / Sự cố `INC-…` |
+| **Confidence** | 🟢 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi |
+|---|---|---|---|
+| 1.0 | | | Bản đầu |
+
+---
+
+# CHẾ ĐỘ A — Đánh giá định kỳ (ATAM rút gọn)
+
+*Dùng mỗi quý. Xoá phần B nếu dùng chế độ này.*
+
+## A1. `QAS` còn đúng không
+
+*Nhu cầu đổi thì thuộc tính chất lượng cũng đổi. `QAS` viết một năm trước có thể đang bảo vệ
+thứ không ai cần nữa.*
+
+| `QAS` | Còn đúng | Lý do | Hành động |
+|---|---|---|---|
+| `QAS-001` | ✅ | | |
+| `QAS-006` | ❌ thừa | Tính năng đã bỏ | Đánh dấu `[DROPPED]`, giữ ID |
+| — | ❌ thiếu | Nhu cầu mới: … | Thêm `QAS-nnn` |
+
+## A2. Điểm nhạy cảm
+
+*Chỗ một thay đổi nhỏ làm một thuộc tính chất lượng đổi nhiều. Đây là chỗ phải cẩn thận nhất
+khi sửa, và là chỗ phải có `FIT` bảo vệ.*
+
+| # | Điểm | Thuộc tính bị ảnh hưởng | Thay đổi nhỏ nào cũng gây tác động lớn | Có `FIT` bảo vệ |
+|---|---|---|---|---|
+| 1 | | `QAS-nnn` | | ☐ |
+
+## A3. Điểm đánh đổi
+
+*Chỗ cải thiện thuộc tính này làm hỏng thuộc tính kia. Phải được nói ra để người sau không
+"tối ưu" một chiều rồi phá chiều còn lại.*
+
+| # | Điểm | Cải thiện | Đánh đổi bằng | Cân bằng hiện tại | Ai quyết |
+|---|---|---|---|---|---|
+| 1 | | `QAS-nnn` | `QAS-nnn` | | PO |
+
+## A4. `ADR` chạm điều kiện xét lại
+
+| `ADR` | Điều kiện (§7 của ADR) | Ngưỡng | Thực tế | Chạm chưa | Hành động |
+|---|---|---|---|---|---|
+
+## A5. Rủi ro mới
+
+| Nguồn | Rủi ro | Mức | Hành động | `ARISK` |
+|---|---|---|---|---|
+| Vendor | *(đổi giá, đổi điều khoản, ngừng dịch vụ)* | | | |
+| Vòng đời công nghệ | *(phiên bản hết hỗ trợ, thư viện ngừng bảo trì)* | | | |
+| Tuân thủ | *(luật mới, chuẩn kiểm toán mới)* | | | |
+| Nhân sự | *(người duy nhất biết một phần hệ thống)* | | | |
+| Quy mô | *(tải sắp vượt ngưỡng thiết kế)* | | | |
+
+## A6. Kết luận định kỳ
+
+| | |
+|---|---|
+| **Kiến trúc còn phù hợp không** | ✅ còn / ⚠️ còn nhưng có điểm phải xử lý / ❌ cần vòng thiết kế mới |
+| **Ba việc quan trọng nhất** | ⟶ `TRM` |
+| **Có cần mở vòng `sa-1-context` mới không** | ☐ · vì sao |
+
+---
+
+# CHẾ ĐỘ B — Post-mortem kiến trúc sau sự cố
+
+*Chỉ cho sự cố có nguyên nhân kiến trúc. Post-mortem vận hành (dòng thời gian, cách xử lý,
+hành động khắc phục ngay) thuộc SRE — tài liệu này không lặp lại phần đó. Xoá phần A nếu dùng
+chế độ này.*
+
+## B1. Tham chiếu
+
+| | |
+|---|---|
+| **Sự cố** | `INC-…` |
+| **Post-mortem vận hành** | *(đường dẫn — đọc trước tài liệu này)* |
+| **Ảnh hưởng** | … phút · … người dùng · … giao dịch |
+| **Ngân sách lỗi tiêu tốn** | … / … phút của tháng |
+
+## B2. Ba câu hỏi kiến trúc
+
+> 🔴 **Không đổ lỗi cho người.** "Dev quên đặt timeout" là triệu chứng. Câu hỏi kiến trúc là
+> "vì sao hệ thống cho phép một lời gọi không timeout tồn tại, và làm sao để lần sau không
+> thể". Câu trả lời thường là một `FIT` mới, không phải một lời nhắc nhở.
+
+### Câu 1 — Kiến trúc đã CHO PHÉP sự cố này ở chỗ nào
+
+| Điều kiện cho phép | Ở đâu | Có trong thiết kế không |
+|---|---|---|
+| | `SAD` §… / `FAIL` `FM-nn` / không có ở đâu cả | |
+
+### Câu 2 — Thiết kế đã dự đoán tình huống này chưa
+
+| | |
+|---|---|
+| **Có trong `FAIL` không** | ☐ có (`FM-nn`) — vậy vì sao biện pháp không hiệu lực? · ☐ không — đây là điểm mù |
+| **Có `QAS` liên quan không** | |
+| **Có `ASM` nào sai không** | `ASM-nn`: … |
+
+**Nếu ĐÃ có trong thiết kế mà vẫn xảy ra** — vấn đề nằm ở một trong ba:
+
+| | Kiểm |
+|---|---|
+| Biện pháp không được cài đặt | ☐ |
+| Cài đặt nhưng tham số sai *(timeout, ngưỡng)* | ☐ |
+| Cài đặt đúng nhưng không đủ *(giả định về quy mô sai)* | ☐ |
+
+### Câu 3 — Sửa ở tầng nào
+
+| Tầng | Sửa gì | Ngăn được lần sau | Chi phí | Chọn |
+|---|---|---|---|---|
+| Code | | chỉ chỗ này | | ☐ |
+| Cấu hình | | chỉ chỗ này | | ☐ |
+| **Kiến trúc** | | cả lớp vấn đề | | ☐ |
+| Quy trình / bài kiểm tự động | | cả lớp vấn đề, không phụ thuộc trí nhớ | | ☐ |
+
+🔴 **Sửa ở tầng code chỉ ngăn được đúng lần này.** Hỏi thêm: *"Còn bao nhiêu chỗ khác trong hệ
+thống có cùng vấn đề?"* — nếu > 1 thì phải sửa ở tầng kiến trúc hoặc bài kiểm.
+
+## B3. Chỗ khác có cùng vấn đề
+
+| Chỗ | Đã kiểm | Có cùng vấn đề | Xử lý |
+|---|---|---|---|
+
+## B4. Hành động
+
+| # | Hành động | Tầng | Chủ | Hạn | Ngăn được gì | Ghi ở đâu |
+|---|---|---|---|---|---|---|
+| 1 | | `FIT` mới | | | cả lớp lỗi này | `FIT-nn` |
+| 2 | | `ADR` mới | | | | `ADR-nnn` |
+| 3 | | cập nhật `FAIL` | | | | `FM-nn` |
+
+## B5. Cập nhật tài liệu
+
+| Tài liệu | Cập nhật gì | Đã làm |
+|---|---|---|
+| `FAIL` | Thêm `FM-nn` cho tình huống này | ☐ |
+| `QAS` | Thêm `QAS-nnn` về thời gian phát hiện | ☐ |
+| `ADR-nnn` | Bổ sung hệ quả chưa lường trước vào §5 | ☐ |
+| `ASM` | Sửa giả định sai, rà mọi thứ dựa trên nó | ☐ |
+| `AGD` | Thêm ràng buộc | ☐ |
+
+*Không sửa quyết định trong `ADR` cũ — chỉ bổ sung hệ quả quan sát được. Quyết định sai ⇒ ADR
+mới có `Supersedes:`.*
+
+---
+
+## Bài học *(cả hai chế độ)*
+
+| Bài học | Áp dụng vào | Ai chịu trách nhiệm |
+|---|---|---|
+| | dự án này / dự án sau / chuẩn chung của tổ chức | |
+
+## Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|

.claude/skills/sa-4-evolution/templates/conformance-report.md

@@ -0,0 +1,163 @@
+# CONF — Architecture Conformance Report — <PROJECT> · kỳ <YYYY-MM>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-4-evolution) |
+| **Status** | 🟡 Draft |
+| **Approved by** | PO: — · SRE: — · EA: — |
+| **Source** | QAS_… v1.1 · TCO_… v1.0 · INF_… v1.0 · hoá đơn … · dashboard … · log sự cố … |
+| **Scope** | Kỳ … |
+| **Confidence** | 🟢 *(số đo thật)* / 🟡 *(một phần ước lượng)* |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi |
+|---|---|---|---|
+| 1.0 | | | Bản đầu |
+
+> Mỗi kỳ một file, **không ghi đè kỳ trước**. So sánh giữa các kỳ là nơi xu hướng lộ ra.
+
+---
+
+## 1. Tóm tắt
+
+| | Đạt | Không đạt | **Chưa đo được** |
+|---|---|---|---|
+| `QAS` mức Must | | | |
+| `QAS` mức Should | | | |
+
+| | Ước lượng | Thực tế | Chênh |
+|---|---|---|---|
+| Chi phí hạ tầng/tháng | | | % |
+
+| | Số |
+|---|---|
+| Sự cố trong kỳ | |
+| — truy về một `ADR` | |
+| — truy về một `ASM` sai | |
+| — **điểm mù mới** | |
+| Drift phát hiện được | |
+
+**Ba việc cần xử lý trước:** … *(dẫn sang `TRM`)*
+
+---
+
+## 2. `QAS` × telemetry thật
+
+| `QAS` | Mục tiêu | Đo được | Nguồn đo | Kết quả | Ghi chú / `TD` |
+|---|---|---|---|---|---|
+| `QAS-001` | p95 ≤ 300ms | | Grafana … | ✅ / ❌ / ⚠️ | |
+| `QAS-004` | ≤ 45 phút | | | | |
+
+**Ký hiệu:** ✅ đạt · ❌ không đạt · ⚠️ **chưa đo được**
+
+🔴 **⚠️ không nhẹ hơn ❌ — nó nặng hơn.** ❌ nghĩa là ta biết mình đang ở đâu; ⚠️ nghĩa là ta
+không biết gì cả. Mỗi mục ⚠️ phải ghi rõ vì sao chưa đo được:
+
+| `QAS` | Vì sao chưa đo được | Cần gì để đo được | Vào `TRM` |
+|---|---|---|---|
+| | cách đo ở AG2 không khả thi / thiếu observability / chưa có bài đo | | ☐ |
+
+**Xu hướng so với kỳ trước**
+
+| `QAS` | Kỳ trước | Kỳ này | Xu hướng |
+|---|---|---|---|
+| | | | ↗ xấu đi · → ổn định · ↘ tốt lên |
+
+## 3. `TCO` × hoá đơn thật
+
+| Hạng mục | Ước lượng | Thực tế | Chênh | Giải thích |
+|---|---|---|---|---|
+| Compute | | | % | |
+| CSDL | | | | |
+| Cache | | | | |
+| Lưu trữ | | | | |
+| Message broker | | | | |
+| **Egress** | | | | |
+| Observability | | | | |
+| Non-prod | | | | |
+| **Tổng** | | | % | |
+
+**Chênh lệch > 20% — truy nguyên** *(phải thuộc một trong bốn loại)*
+
+| Hạng mục | Chênh | Loại nguyên nhân | Chi tiết | Hành động |
+|---|---|---|---|---|
+| | | ① tải khác dự kiến · ② cấu hình khác thiết kế · ③ bỏ sót khi ước lượng · ④ đơn giá đổi | | |
+
+🔴 **Không thuộc bốn loại trên ⇒ đang có thứ gì đó chạy mà không ai biết.** Đây là phát hiện
+nghiêm trọng, không phải chuyện kế toán.
+
+**Chi phí trên đơn vị nghiệp vụ** *(chỉ số này ổn định hơn tổng chi phí)*
+
+| | Kỳ trước | Kỳ này |
+|---|---|---|
+| Chi phí / 1.000 giao dịch | | |
+| Chi phí / người dùng hoạt động | | |
+
+## 4. Sự cố × quyết định kiến trúc
+
+| Sự cố | Ngày | Ảnh hưởng | Truy về | Chi tiết | Hành động |
+|---|---|---|---|---|---|
+| `INC-…` | | … phút downtime | `ADR-nnn` | Hệ quả đã ghi trong ADR §5 | Không cần đổi |
+| `INC-…` | | | `ASM-nn` **sai** | Giả định "…" không đúng thực tế | Sửa `ASM`, rà mọi thứ dựa trên nó |
+| `INC-…` | | | 🔴 **điểm mù mới** | Không tài liệu nào nói tới | Thêm `QAS-nnn` + `FM-nn` + `FIT-nn` |
+
+🔴 **Điểm mù mới là phát hiện có giá trị nhất của cả báo cáo.** Nó là thứ không ai nghĩ tới —
+và bây giờ đã nghĩ tới. Ghi kỹ, đừng gộp vào các dòng khác.
+
+**Ngân sách lỗi**
+
+| `QAS` sẵn sàng | Ngân sách/tháng | Đã dùng | Còn lại |
+|---|---|---|---|
+| `QAS-007` 99.9% | 43 phút | | |
+
+Dùng hết ngân sách lỗi ⇒ dừng phát hành tính năng mới, ưu tiên ổn định. Quy tắc này ai chốt: …
+
+## 5. Drift — thiết kế × đang chạy
+
+| # | Loại drift | Phát hiện bằng | Chi tiết | Mức | Hành động |
+|---|---|---|---|---|---|
+| 1 | `FIT` đỏ hoặc bị tắt | lịch sử CI | | | |
+| 2 | Component có trong code, không có trong `SAD` | so repo/deployment | | | Cập nhật `SAD` hoặc gỡ bỏ |
+| 3 | Interface đang gọi, không có trong `ICD` | **trace/log** | | | |
+| 4 | Cấu hình khác `INF` | so IaC thật | | | |
+| 5 | Whitelist `FIT` quá hạn | `FIT` §3 | | | |
+| 6 | `TD` quá hạn xét lại | `TDEBT` | | | |
+
+🔴 **Loại 3 phải tìm bằng trace/log, không bằng đọc code.** Lời gọi phát sinh lúc chạy (qua
+cấu hình, plugin, job định kỳ) không lộ ra khi đọc code tĩnh.
+
+**Kết luận về drift:** kiến trúc đang chạy *(còn khớp thiết kế / đã trôi ở …)*
+
+## 6. `ADR` cần xem lại
+
+| `ADR` | Điều kiện xét lại (§7 của ADR) | Đã chạm ngưỡng | Hành động |
+|---|---|---|---|
+| `ADR-nnn` | thông lượng vượt … | ☐ | |
+
+| `ADR` | Bị thực tế bác bỏ ở đâu | ADR thay thế |
+|---|---|---|
+| | | `ADR-nnn` |
+
+*Không sửa nội dung `ADR` cũ. Viết ADR mới có `Supersedes:`.*
+
+## 7. Bài học kỳ này
+
+| Bài học | Sinh từ | Áp dụng vào đâu |
+|---|---|---|
+| | sự cố / drift / chênh lệch chi phí | `AGD` / `FIT` / quy trình / dự án sau |
+
+## 8. Đề xuất cho `TRM`
+
+*Xếp theo lợi ích/chi phí. **Không xếp thứ tự ưu tiên thay PO** — trình bảng, PO xếp.*
+
+| # | Việc | Chi phí | Lợi ích *(bằng số)* | Rủi ro nếu không làm | Sinh từ |
+|---|---|---|---|---|---|
+| 1 | | … ngày công | … /tháng | | §3 |
+
+## 9. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|

.claude/skills/sa-4-evolution/templates/technical-roadmap.md

@@ -0,0 +1,137 @@
+# TRM — Technical Roadmap & Migration Plan — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-4-evolution) |
+| **Status** | 🟡 Draft |
+| **Approved by** | PO: — · Tech Lead: — |
+| **Source** | CONF_…_YYYY-MM · TDEBT_… · ARISK_… · PMR_… |
+| **Scope** | Kỳ kế hoạch: … |
+| **Confidence** | 🟡 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi |
+|---|---|---|---|
+| 1.0 | | | Bản đầu |
+
+> 🔴 **Mỗi mục phải có lợi ích bằng số theo ngôn ngữ PO**: giảm bao nhiêu tiền/tháng, nhanh
+> hơn bao nhiêu ngày mỗi tính năng, giảm bao nhiêu sự cố. Roadmap toàn danh từ kỹ thuật
+> ("tái cấu trúc module X") sẽ không được duyệt, và đúng như vậy.
+
+---
+
+## 1. Bảng trình PO — xếp thứ tự
+
+| # | Việc | Vấn đề nó giải quyết | Chi phí | **Lợi ích/tháng** | Hoà vốn | Rủi ro nếu không làm | Nguồn | PO xếp |
+|---|---|---|---|---|---|---|---|---|
+| 1 | | | … ngày công | … tiền / … ngày công | … tháng | | `CONF` §3 | |
+| 2 | | | | | | | `TDEBT` `TD-05` | |
+
+**Ràng buộc, không phải lựa chọn** *(SA nêu rõ — PO không xếp thứ tự những mục này)*
+
+| Việc | Vì sao là ràng buộc | Hạn cứng |
+|---|---|---|
+| | tuân thủ pháp lý / lỗ hổng bảo mật mức cao / công nghệ hết hỗ trợ | |
+
+## 2. Nguồn đầu vào — đã rà đủ chưa
+
+| Nguồn | Đã rà | Số mục đưa vào roadmap |
+|---|---|---|
+| `QAS` không đạt (`CONF` §2) | ☐ | |
+| `TD` mức cao, lãi suất lớn (`TDEBT` §1) | ☐ | |
+| Drift phải đóng (`CONF` §5) | ☐ | |
+| Chi phí vượt `TCO` (`CONF` §3) | ☐ | |
+| Rủi ro mới: vendor, hết vòng đời, tuân thủ | ☐ | |
+| Tải/tính năng đã biết trước trong roadmap sản phẩm | ☐ | |
+
+## 3. Chi tiết từng mục
+
+### TRM-01 — <tên>
+
+| | |
+|---|---|
+| **Vấn đề** | *(nói bằng hệ quả, không bằng kỹ thuật)* |
+| **Bằng chứng** | `CONF` §… · số đo · hoá đơn |
+| **Phương án đề xuất** | |
+| **Phương án khác đã cân nhắc** | *(quy tắc `D3` vẫn áp dụng)* |
+| **Chi phí** | … ngày công · … chi phí hạ tầng phát sinh |
+| **Lợi ích** | *(bằng số, hàng tháng)* |
+| **Rủi ro khi làm** | |
+| **Rủi ro nếu không làm** | |
+| **Phụ thuộc** | *(phải làm sau mục nào)* |
+| **Cần `ADR` mới không** | ☐ · `ADR-nnn` |
+| **Đo thế nào để biết đã xong** | *(tiêu chí nghiệm thu bằng số)* |
+
+### TRM-02 — <tên>
+
+*(cùng cấu trúc)*
+
+## 4. Phụ thuộc & thứ tự
+
+```mermaid
+flowchart LR
+```
+
+| Mục | Phải xong trước | Vì sao |
+|---|---|---|
+
+## 5. Kế hoạch migration *(nếu có mục là migration)*
+
+### 5.1 Tổng quan
+
+| | |
+|---|---|
+| **Từ** | |
+| **Sang** | |
+| **Kiểu cắt chuyển** | một lần / song song hai hệ thống / cuốn chiếu theo nhóm |
+| **Thời lượng dự kiến** | |
+| **Cửa sổ cắt chuyển** | |
+
+### 5.2 Các bước
+
+| Bước | Việc | Tiêu chí đi tiếp | **Cách rollback ở bước này** | Thời lượng | Chủ |
+|---|---|---|---|---|---|
+| 1 | | | | | |
+| 2 | | | | | |
+
+🔴 **Mỗi bước phải rollback được độc lập.** Kế hoạch chỉ rollback được ở bước cuối là kế hoạch
+một chiều — bước 3 hỏng thì không có đường lui.
+
+### 5.3 Chạy song song
+
+| | |
+|---|---|
+| Hai hệ thống chạy song song bao lâu | |
+| Nguồn sự thật trong thời gian đó | *(chỉ một — xem `DAT` §1)* |
+| Cách đối chiếu dữ liệu hai bên | *(truy vấn nào, tần suất nào)* |
+| Ngưỡng chênh lệch chấp nhận được | |
+| Ai quyết định cắt hẳn | |
+
+### 5.4 Tiêu chí hoàn tất
+
+| Tiêu chí | Đo bằng | Ngưỡng |
+|---|---|---|
+
+## 6. Việc KHÔNG làm trong kỳ này
+
+*Ghi ra để không ai tưởng nó đang được xử lý.*
+
+| Việc | Vì sao hoãn | Xét lại khi nào | Rủi ro chấp nhận trong lúc chờ |
+|---|---|---|---|
+
+## 7. Theo dõi
+
+| Mục | Trạng thái | % hoàn thành | Lợi ích đo được thực tế | So với dự kiến |
+|---|---|---|---|---|
+| TRM-01 | chưa bắt đầu / đang làm / xong | | | |
+
+*Cột "lợi ích đo được thực tế" là cột làm cho roadmap kỳ sau được tin. Không đo lại thì lần
+sau PO không có lý do gì để duyệt.*
+
+## 8. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|