init git

.claude/skills/sa-3-enablement/GUIDE.md

@@ -0,0 +1,171 @@
+# Hướng dẫn sử dụng — `sa-3-enablement` (Giai đoạn 3)
+
+## Giai đoạn này giải quyết gì
+
+Đầu vào là bộ thiết kế đã ký (AG2). Đầu ra là **kiến trúc đó tồn tại trong code và ở lại đó**
+— có chuẩn dev dùng được, có bài kiểm tự động, có sổ nợ khi phải lệch, có nhật ký quyết định
+phát sinh trong lúc thi công.
+
+**Không làm ở giai đoạn này:** thiết kế lại kiến trúc, viết code sản phẩm, quản lý sprint.
+
+## Vì sao giai đoạn này quyết định thành bại
+
+Kiến trúc trên giấy không có giá trị. Ba thứ làm nó biến mất trong 6 tháng:
+
+1. Dev không biết ràng buộc tồn tại ⇒ **`AGD` + reference implementation**
+2. Biết nhưng không ai kiểm ⇒ **`FIT`**
+3. Phải lệch vì gấp, rồi quên ⇒ **`TDEBT`**
+
+Bỏ một trong ba thì hai cái còn lại cũng vô dụng.
+
+## Khi nào gọi
+
+| Tình huống | Có nên gọi |
+|---|---|
+| Vừa qua AG2, dev sắp bắt đầu | ✅ `--focus agd` trước, ngay trong tuần đầu |
+| CI chưa kiểm gì về kiến trúc | ✅ `--focus fit` |
+| Dev đề xuất một thay đổi chạm thiết kế | ✅ `--focus review` |
+| Phải lệch thiết kế vì deadline | ✅ `--focus debt` — ghi lại ngay, đừng để nhớ sau |
+| Codebase kế thừa, không rõ kiến trúc thật là gì | ✅ `--focus fit` để đo hiện trạng trước |
+| Dev hỏi "hàm này đặt tên gì" | ❌ Thuộc Tech Lead |
+| Muốn đổi một quyết định kiến trúc | ❌ Sang `/sa-2-architecture --focus adr` |
+
+## Cú pháp
+
+```
+/sa-3-enablement <PROJECT> [--focus agd|fit|review|debt|all] [--out <path>] [go]
+```
+
+| `--focus` | Sinh ra | Khi nào chạy |
+|---|---|---|
+| `agd` | `AGD` + đề cương reference implementation | Ngay sau AG2 |
+| `fit` | `FIT` — danh sách bài kiểm + cấu hình CI đề xuất | Tuần 1–2 của thi công |
+| `review` | Một mục trong `DREV` | Mỗi lần có thay đổi chạm kiến trúc |
+| `debt` | Một mục trong `TDEBT` | Mỗi lần chấp nhận lệch |
+| `all` | Cả bốn | |
+
+Review một thay đổi cụ thể:
+
+```
+/sa-3-enablement Settlement --focus review
+  "Dev đề xuất gọi trực tiếp DB của module Order từ module Report cho nhanh,
+   thay vì qua API. Lý do: query join 3 bảng qua API mất 4 giây."
+```
+
+## Chuẩn bị gì trước khi gọi
+
+| Cho bước | Chuẩn bị |
+|---|---|
+| `agd` | `SAD`, `ADR`, `ICD`, `FAIL` đã ký · quy ước code hiện có của team |
+| `fit` | Cấu hình CI hiện tại · ngôn ngữ/framework · quyền sửa pipeline |
+| `review` | Mô tả thay đổi + lý do dev đưa ra + code/PR nếu có |
+| `debt` | Lệch cụ thể là gì · vì sao phải lệch · ai chấp nhận |
+
+## Bạn sẽ nhận được gì
+
+```
+sa-output/<PROJECT>/03-enablement/
+├── AGD_<PROJECT>_v1.0.md      ← dev đọc cái này
+├── FIT_<PROJECT>_v1.0.md      ← danh sách bài kiểm + trạng thái xanh/đỏ
+├── DREV_<PROJECT>.md          ← nhật ký, ghi thêm liên tục, không lên version
+└── TDEBT_<PROJECT>.md         ← sổ nợ, ghi thêm liên tục
+```
+
+`DREV` và `TDEBT` là **sổ sống** — ghi thêm mỗi lần, không tạo version mới.
+
+## Fitness function: bắt đầu thế nào
+
+Đừng cố phủ hết ngay. Thứ tự đem lại giá trị nhanh nhất:
+
+```
+Tuần 1  ① Phụ thuộc giữa tầng/module          ← rẻ nhất, chặn được nhiều lỗi nhất
+        ② Quét secret trong mã nguồn           ← rủi ro cao, công cụ có sẵn
+Tuần 2  ③ Quét lỗ hổng thư viện
+        ④ Lint contract (OpenAPI)
+Tuần 3  ⑤ Kiểm thử hiệu năng QAS mức Must      ← tốn công dựng nhất, để sau
+Tuần 4  ⑥ Kiểm tra IaC / policy hạ tầng
+```
+
+Mỗi bài kiểm bật ở **chế độ cảnh báo** trước, công bố ngày chuyển sang **chặn merge**, dọn nợ
+trước ngày đó.
+
+```
+FIT-01  Tầng domain không import tầng infra
+        Nguồn : ADR-002
+        Công cụ: ArchUnit · chạy ở CI bước `test`
+        Chế độ : ⚠️ cảnh báo (từ 2026-09-01) → 🚫 chặn (từ 2026-09-20)
+        Hiện tại: 🔴 12 vi phạm → TD-03, chủ: anh Nam, hạn 2026-09-18
+```
+
+## Ví dụ hội thoại — design review
+
+```
+Bạn:    /sa-3-enablement Settlement --focus review
+        Dev muốn gọi thẳng DB module Order từ module Report vì query qua API mất 4 giây.
+
+Claude: Chấm điểm radar:
+        - Chi phí đảo ngược:      1 (sửa được trong ~2 tuần)
+        - Bán kính ảnh hưởng:     2 (phá ranh giới module, ảnh hưởng mọi thay đổi Order sau này)
+        - Chạm QAS:               2 (QAS-003 p95 báo cáo ≤ 3s — đây chính là vấn đề)
+        - Ràng buộc dài hạn:      2 (khi tách service, chỗ này sẽ chặn)
+        - Tranh cãi:              1
+        → 8/10 ⇒ cần ADR, không phải quyết định trong PR.
+
+        Đối chiếu: ADR-004 chốt module chỉ giao tiếp qua interface công khai.
+        QAS-003 yêu cầu p95 ≤ 3s — thiết kế hiện tại KHÔNG đạt. Dev đúng về vấn đề.
+
+        Bốn phương án, không chỉ hai:
+        1. Giữ ranh giới + thêm read model cho báo cáo   → đúng ADR-004, +1 tuần
+        2. Giữ ranh giới + cache kết quả                 → nhanh nhất, dữ liệu trễ ≤ 5 phút
+        3. Gọi thẳng DB                                  → vi phạm ADR-004
+        4. Nới QAS-003 lên 5s                            → cần PO chấp nhận
+
+        Khuyến nghị: PA-2 nếu PO chấp nhận trễ 5 phút (rẻ nhất), PA-1 nếu không.
+        PA-3 chỉ chấp nhận như TDEBT có hạn, kèm FIT-01 whitelist tạm thời.
+
+        Cần ai quyết: PO (trễ 5 phút có chấp nhận được không) → OQ-034
+        Ghi vào DREV-012.
+```
+
+## Lỗi thường gặp
+
+**"Guideline viết xong không ai đọc."**
+Bình thường nếu nó dài. Kiểm tra: quy tắc nào không truy được về `ADR`/`QAS` thì cắt. Phần
+còn lại chuyển thành reference implementation — dev đọc code, không đọc văn bản.
+
+**"Bật fitness function thì CI đỏ 200 chỗ."**
+Đúng như dự kiến với codebase đã có. Bật chế độ cảnh báo, ghi số vi phạm hiện tại làm mốc,
+đặt quy tắc "không tăng thêm", rồi giảm dần. Chuyển sang chặn khi về 0.
+
+**"Dev bảo kiến trúc không thực tế."**
+Nghe kỹ trước khi bảo vệ thiết kế. Ba lần trở lên cùng một phản hồi về cùng một chỗ ⇒ khả năng
+cao thiết kế sai thật. Kết luận "thiết kế sai, cần `ADR` mới" là kết luận hợp lệ và là dấu
+hiệu của một SA làm việc tốt, không phải thất bại.
+
+**"Sổ nợ chỉ tăng, không bao giờ giảm."**
+Thiếu cột "lãi suất". Viết bằng con số PM hiểu: *"module này khiến mỗi tính năng mới tốn thêm
+2 ngày; đã có 6 tính năng chạm nó trong quý"* — 12 ngày đó sẽ tự tìm được chỗ trong sprint.
+
+**"Tôi thành nút thắt, mọi PR đều chờ tôi."**
+Đang review quá rộng. Chấm radar: điểm < 3 trả lại Tech Lead. Và đầu tư vào `FIT` — bài kiểm
+tự động review nhanh hơn bạn và không nghỉ phép.
+
+## Ra khỏi giai đoạn này khi nào
+
+Đủ cả năm:
+
+1. Bảng tự chấm AG3 toàn ✅
+2. **Tech Lead + QA + SRE** đã ký
+3. Mọi `FIT` cho ràng buộc quan trọng đang **xanh trên CI**, không phải "đã viết"
+4. Mọi `QAS` mức Must có **bài đo thật đã chạy**, không phải ước lượng
+5. Mọi `TD-nn` có chủ và hạn — không còn mục "sẽ sửa sau" trống
+
+Rồi go-live, và chạy `/sa-4-evolution <PROJECT>` sau kỳ vận hành đầu tiên.
+
+## Liên quan
+
+- Tiêu chí gate AG3: `../sa-lifecycle/references/workflow.md` §2
+- Quy tắc `D8` (ràng buộc phải verify được): `../sa-lifecycle/references/design-rules.md`
+- Chấm điểm thay đổi có cần ADR không: `../sa-lifecycle/references/decision-radar.md` §2
+- Template: `templates/architecture-guidelines.md` · `templates/fitness-functions.md` ·
+  `templates/design-review-log.md` · `templates/tech-debt-register.md`

.claude/skills/sa-3-enablement/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: sa-3-enablement
+description: Giai đoạn 3 của quy trình Solution Architect — đồng hành cùng team trong lúc thi công. Dùng để biến kiến trúc thành thứ dev dùng được (architecture guideline, reference implementation, skeleton), dựng fitness function kiểm thử ràng buộc kiến trúc tự động trên CI, điều hành design review cho thay đổi chạm kiến trúc, trả lời câu hỏi thiết kế của dev, và quản lý sổ nợ kỹ thuật có chủ có hạn. Kích hoạt khi người dùng nói "chuẩn code", "architecture guideline", "reference implementation", "dev hỏi về thiết kế", "review thiết kế", "kiểm thử kiến trúc", "ArchUnit", "fitness function", "nợ kỹ thuật", "tech debt", "code không đúng kiến trúc", "lệch so với thiết kế". Input là SAD/ADR đã qua AG2; output vào sa-output/<PROJECT>/03-enablement/ và phải qua Gate AG3 (Build conformance) trước khi go-live.
+---
+
+# GĐ3 · ENABLEMENT — Đồng hành thi công
+
+Mục tiêu duy nhất: **kiến trúc trên giấy trở thành kiến trúc trong code** — và ở lại đó khi
+người viết tài liệu không còn ngồi cạnh.
+
+Output: `AGD` · `FIT` · `DREV` · `TDEBT` trong `sa-output/<PROJECT>/03-enablement/`
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa ràng buộc** — thiếu ⇒ `OQ-nnn`, không tự thêm quy tắc không có trong `ADR`.
+2. **Không quyết định thay Tech Lead** về quy ước code và công cụ. SA chỉ can thiệp khi quyết
+   định đó chạm `QAS` hoặc một `ADR`.
+3. **Mọi ràng buộc phải truy vết được** về một `ADR` hoặc `QAS`. Ràng buộc không nguồn là sở
+   thích cá nhân, và team sẽ nhận ra điều đó.
+4. **Không sửa `ADR` đã Accepted** — thi công phát hiện thiết kế sai ⇒ `ADR` mới có `Supersedes:`.
+
+Nạp thêm: `../sa-lifecycle/references/design-rules.md` (đặc biệt `D8`) ·
+`../sa-lifecycle/references/decision-radar.md` (để phân loại câu hỏi của dev).
+
+## 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/` (`SAD`, `ADR`, `ICD`, `QAS`, `FAIL`),
+   source code hiện có, cấu hình CI, `ba-output/…/03-specification/` (`SRS`).
+2. **Kiểm AG2** — `SAD` đã `✅ Baselined` chưa, Security và SRE đã ký chưa? Chưa ⇒ báo rõ:
+   ban hành guideline dựa trên kiến trúc chưa chốt sẽ phải ban hành lại.
+3. **Chọn phạm vi** — `--focus agd|fit|review|debt`. Ban hành guideline và dựng fitness
+   function là hai việc khác nhau về khối lượng.
+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 — 4 hoạt động
+
+### 1 — Architecture Guidelines `AGD`  *(`--focus agd`)*
+
+Điền `templates/architecture-guidelines.md`.
+
+**Nguyên tắc: guideline chỉ chứa thứ truy được về `ADR` hoặc `QAS`.** Quy ước đặt tên biến và
+thứ tự import thuộc Tech Lead, không thuộc tài liệu này. Trộn hai loại vào nhau làm dev ngừng
+phân biệt cái nào quan trọng.
+
+Mỗi quy tắc trong `AGD` phải có **bốn cột**: quy tắc · nguồn (`ADR`/`QAS`) · ví dụ đúng/sai ·
+cách kiểm (`FIT-nn` hoặc `⚠️ Khuyến nghị`).
+
+**Reference implementation là bắt buộc, không phải phần thêm.** Một module chạy được, thể hiện
+đúng các quyết định kiến trúc, có kiểm thử. Dev đọc code nhanh gấp nhiều lần đọc văn bản.
+
+| Reference implementation phải thể hiện | Vì sao |
+|---|---|
+| Cấu trúc module chuẩn | Dev copy cấu trúc, không copy nhầm |
+| Xử lý lỗi và mã lỗi theo `ICD` | Thống nhất từ file đầu tiên |
+| Log có correlation id | Thêm sau rất tốn |
+| Gọi phụ thuộc ngoài có timeout/retry theo `FAIL` | Đây là chỗ dev hay tự bịa nhất |
+| Kiểm thử ở đủ các mức | Đặt chuẩn cho cả dự án |
+
+### 2 — Fitness function `FIT`  *(`--focus fit`)*
+
+Điền `templates/fitness-functions.md`. **Quy tắc `D8`: ràng buộc không kiểm tự động được thì
+chỉ là khuyến nghị.**
+
+Với mỗi ràng buộc trong `AGD` và mỗi `QAS` mức Must, chọn một trong hai:
+
+- Viết một bài kiểm chạy trên CI ⇒ `FIT-nn`
+- Ghi thẳng nhãn `⚠️ Khuyến nghị — không tự kiểm được` + cách kiểm thủ công + tần suất
+
+Bảng công cụ theo loại ràng buộc:
+
+| Loại ràng buộc | Công cụ | Ví dụ |
+|---|---|---|
+| Phụ thuộc giữa module/tầng | ArchUnit (JVM), dependency-cruiser (JS/TS), import-linter (Python) | "Tầng domain không được import tầng infra" |
+| Ranh giới package/thư mục | lint rule tuỳ biến, eslint boundaries | "Module A không gọi trực tiếp repository của module B" |
+| Hiệu năng | k6 / JMeter / Gatling chạy trên stg | `QAS-004` p95 ≤ … |
+| Kích thước & thời gian build | script CI | "Bundle JS ≤ … KB" |
+| Bảo mật | quét thư viện, quét secret, quét ảnh container | `THR-nn` |
+| Hạ tầng | kiểm tra IaC (tfsec, checkov), policy-as-code | "Mọi bucket phải bật mã hoá" |
+| Contract | kiểm thử contract (Pact), lint OpenAPI | `IF-nnn` không đổi breaking |
+
+Mỗi `FIT-nn` ghi: ràng buộc kiểm · `ADR`/`QAS` nguồn · công cụ · **chạy ở đâu trong CI** ·
+**vi phạm thì chặn merge hay chỉ cảnh báo** · ai sửa khi đỏ.
+
+🔴 **Bắt đầu bằng cảnh báo, chuyển sang chặn sau.** Bật chế độ chặn ngay trên codebase đã có
+nợ sẽ làm CI đỏ toàn bộ và team sẽ tắt nó. Ghi rõ ngày chuyển từ cảnh báo sang chặn.
+
+### 3 — Design review `DREV`  *(`--focus review`)*
+
+Điền `templates/design-review-log.md`.
+
+**Chỉ review thay đổi chạm kiến trúc.** Chấm nhanh theo
+`../sa-lifecycle/references/decision-radar.md` §2: điểm ≥ 5 ⇒ cần review và có thể cần `ADR`;
+điểm < 3 ⇒ trả lại cho Tech Lead.
+
+Quy trình mỗi lần review:
+
+1. **Phân loại yêu cầu** — câu hỏi làm rõ (trả lời trong ngày) / đề xuất thay đổi thiết kế
+   (review) / phát hiện thiết kế sai (có thể cần `ADR` mới)
+2. **Đối chiếu** với `SAD`, `ADR` liên quan, `QAS` bị ảnh hưởng
+3. **Kết luận một trong bốn**: đúng thiết kế · lệch nhưng chấp nhận được (⇒ `TDEBT`) · lệch
+   phải sửa · **thiết kế sai, cần `ADR` mới**
+4. **Ghi vào `DREV`** kèm người quyết và ngày. Không ghi thì tháng sau tranh luận lại.
+
+**Thời gian chờ tối đa 2 ngày làm việc.** Review chậm hơn thì dev sẽ đi tiếp mà không chờ —
+và lúc đó review thành phê bình sau khi đã code xong, vô ích và gây mâu thuẫn.
+
+🔴 **Kết luận thứ tư là kết luận quan trọng nhất và khó nhất.** Thi công là lúc giả định gặp
+thực tế; kiến trúc sai mà không chịu thừa nhận sẽ được team lách qua chứ không được sửa.
+
+### 4 — Technical debt `TDEBT`  *(`--focus debt`)*
+
+Điền `templates/tech-debt-register.md`.
+
+Mỗi lệch so với kiến trúc **được chấp nhận có ý thức** phải trở thành một `TD-nn`:
+mô tả · vì sao chấp nhận · **lãi suất** (chi phí phải trả mỗi tháng nếu không sửa) · chi phí
+sửa · chủ · hạn xét lại.
+
+Phân loại nợ để xử lý khác nhau:
+
+| Loại | Ví dụ | Xử lý |
+|---|---|---|
+| **Nợ có ý thức, có kế hoạch** | "Dùng bảng tạm cho đến khi có event bus ở quý sau" | Ghi hạn, theo dõi |
+| **Nợ có ý thức, chưa có kế hoạch** | "Biết là sai nhưng chưa biết sửa thế nào" | Ghi, đưa vào `TRM` |
+| **Nợ vô ý** | Phát hiện qua review hoặc `FIT` đỏ | Đánh giá rồi xếp vào một trong hai loại trên |
+| **Nợ do kiến trúc sai** | Thiết kế không khả thi | **Không phải nợ** — là `ADR` mới |
+
+🔴 **Nợ không có "lãi suất" thì không ai ưu tiên trả.** Viết bằng con số: "mỗi tính năng mới
+chạm module này tốn thêm 2 ngày", "gây trung bình 1 sự cố/tháng". Đó là ngôn ngữ PM và PO hiểu.
+
+Mục "sẽ sửa sau" không có chủ và hạn ⇒ **không phải mục nợ hợp lệ**, chặn AG3.
+
+## Trước khi kết thúc
+
+In bốn thứ:
+
+**① Bảng tự chấm Gate AG3** (`../sa-lifecycle/references/workflow.md` §2) dạng ☐/✅.
+
+**② Bảng trạng thái `FIT`** — mỗi fitness function: xanh/đỏ/chưa bật · chế độ (cảnh báo/chặn).
+
+**③ Bảng `QAS` mức Must × bài đo thật** — đã đo / chưa đo / kết quả. AG3 yêu cầu **đã đo**,
+không chấp nhận ước lượng.
+
+**④ Danh sách `TD-nn` mới phát sinh** kèm chủ và hạn.
+
+Rồi nhắc người dùng: AG3 cần **Tech Lead + QA + SRE ký**.
+
+## Bẫy thường gặp
+
+**Ban hành guideline dài 40 trang.** Không ai đọc. Giữ `AGD` ngắn, mọi thứ dài chuyển vào
+reference implementation — code luôn thắng văn bản về khả năng được đọc.
+
+**Fitness function bật chế độ chặn ngay ngày đầu.** CI đỏ toàn bộ, team tắt nó, và không ai
+bật lại. Bắt đầu bằng cảnh báo, công bố ngày chuyển sang chặn, dọn nợ trước ngày đó.
+
+**Review mọi PR.** SA không phải người gác cổng code. Review mọi thứ nghĩa là trở thành nút
+thắt, và team sẽ tìm cách đi vòng. Chỉ review cái chạm kiến trúc.
+
+**Trả lời câu hỏi của dev bằng "xem tài liệu đi".** Nếu dev phải hỏi thì tài liệu chưa rõ.
+Trả lời câu hỏi, **rồi sửa tài liệu** — câu hỏi là dữ liệu về chất lượng tài liệu của bạn.
+
+**Coi mọi lệch so với thiết kế là lỗi của dev.** Đôi khi dev đúng và thiết kế sai. Kết luận
+"thiết kế sai, cần `ADR` mới" phải là một lựa chọn thật, không phải lối thoát danh dự.
+
+**Sổ nợ chỉ tăng không giảm.** Nợ không bao giờ được trả nghĩa là nó chưa bao giờ được ưu
+tiên — thường vì thiếu cột "lãi suất". Thêm con số vào, PM sẽ tự đưa vào sprint.

.claude/skills/sa-3-enablement/templates/architecture-guidelines.md

@@ -0,0 +1,162 @@
+# AGD — Architecture Guidelines — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-3-enablement) |
+| **Status** | 🟡 Draft |
+| **Approved by** | Tech Lead: — |
+| **Source** | SAD_… v1.0 · ADR-001..0nn · ICD_… v1.0 · FAIL_… v1.0 |
+| **Scope** | |
+| **Confidence** | 🟢 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR |
+|---|---|---|---|---|
+| 1.0 | | | Bản đầu | — |
+
+> **Tài liệu này chỉ chứa thứ truy được về một `ADR` hoặc `QAS`.** Quy ước đặt tên biến, thứ
+> tự import, độ dài hàm thuộc Tech Lead và nằm ở tài liệu khác. Trộn hai loại làm dev ngừng
+> phân biệt cái nào quan trọng.
+
+---
+
+## 1. Đọc gì trước
+
+| Bạn là | Đọc theo thứ tự |
+|---|---|
+| Dev mới vào dự án | §2 → reference implementation → `SAD` §4 |
+| Dev thêm một tính năng | §3 (ràng buộc) → `ICD` cho interface liên quan |
+| Dev sửa một bug | §4 (đường lỗi) → `FAIL` |
+| Người review PR | §3 + bảng `FIT` |
+
+## 2. Reference implementation
+
+| | |
+|---|---|
+| **Đường dẫn** | `<repo>/<module mẫu>` |
+| **Chạy thử** | `<lệnh>` |
+| **Thể hiện các quyết định** | `ADR-002`, `ADR-004`, `ADR-007` |
+
+Module mẫu thể hiện đủ sáu thứ. Thiếu thứ nào thì dev sẽ tự bịa thứ đó:
+
+| # | Thể hiện | Ở file nào |
+|---|---|---|
+| 1 | Cấu trúc module chuẩn | |
+| 2 | Xử lý lỗi + mã lỗi theo `ICD` §3 | |
+| 3 | Log có correlation id | |
+| 4 | Gọi phụ thuộc ngoài có timeout/retry theo `FAIL` | |
+| 5 | Kiểm tra quyền theo `SEC` §3 | |
+| 6 | Kiểm thử ở đủ các mức | |
+
+🔴 **Code luôn thắng văn bản về khả năng được đọc.** Mọi thứ giải thích dài hơn 10 dòng nên
+chuyển thành code mẫu.
+
+## 3. Ràng buộc kiến trúc
+
+*Bốn cột bắt buộc. Ràng buộc không có nguồn là sở thích cá nhân, và team sẽ nhận ra.*
+
+### 3.1 Ranh giới module & phụ thuộc
+
+| # | Ràng buộc | Nguồn | Ví dụ đúng / sai | Cách kiểm |
+|---|---|---|---|---|
+| 1 | Tầng domain không import tầng infra | `ADR-002` | ✅ `domain/Order.ts` không import `infra/` · ❌ import `infra/db` | `FIT-01` |
+| 2 | Module chỉ giao tiếp qua interface công khai | `ADR-004` | | `FIT-02` |
+
+### 3.2 Dữ liệu
+
+| # | Ràng buộc | Nguồn | Ví dụ đúng / sai | Cách kiểm |
+|---|---|---|---|---|
+| | Chỉ hệ thống chủ được ghi thực thể X | `DAT` §1 | | |
+| | Truy vấn danh sách phải có phân trang | `QAS-001` | | |
+| | Không dùng dữ liệu production ở non-prod | `SEC` §5 | | `FIT-nn` |
+
+### 3.3 Interface & contract
+
+| # | Ràng buộc | Nguồn | Ví dụ đúng / sai | Cách kiểm |
+|---|---|---|---|---|
+| | Số lớn (id, tiền) truyền dạng `string` | `ICD` §1 | ✅ `"1234567890123456789"` · ❌ `1234567890123456789` | `FIT-nn` |
+| | Thời gian dùng ISO-8601 UTC | `ICD` §1 | | |
+| | Lỗi nghiệp vụ trả HTTP 4xx | `ICD` §1 | ❌ 200 kèm `{success:false}` | |
+| | Đổi contract breaking phải qua `ADR` | `ICD` §3 | | `FIT-nn` (Pact) |
+
+### 3.4 Bảo mật
+
+| # | Ràng buộc | Nguồn | Ví dụ đúng / sai | Cách kiểm |
+|---|---|---|---|---|
+| | Không có secret trong mã nguồn | `SEC` §6 | | `FIT-nn` |
+| | Kiểm quyền ở tầng service, không chỉ ở gateway | `SEC` §3 | | ⚠️ Khuyến nghị |
+| | Không log dữ liệu PII | `SEC` §5 | | ⚠️ Khuyến nghị |
+
+### 3.5 Ràng buộc chỉ là khuyến nghị
+
+*Quy tắc `D8`: không kiểm tự động được ⇒ phải ghi nhãn, kèm cách kiểm thủ công.*
+
+| Ràng buộc | Vì sao không tự kiểm được | Kiểm thủ công thế nào | Tần suất |
+|---|---|---|---|
+
+---
+
+## 4. Đường lỗi — dev phải làm gì
+
+*Trích từ `FAIL`. Đây là chỗ dev hay tự bịa nhất, nên viết cực cụ thể.*
+
+| Gọi tới | Timeout | Retry | Idempotent | Hết retry | Người dùng thấy gì |
+|---|---|---|---|---|---|
+| CSDL chính | … ms | 0 | — | trả 503 | |
+| API ngoài … | … ms | 3 · mũ + jitter | ✅ khoá … | vào hàng đợi | |
+
+**Mẫu code chuẩn:** `<đường dẫn trong reference implementation>`
+
+🔴 **Không tự đặt timeout.** Ngân sách timeout theo tầng ở `FAIL` §2 — đặt sai một tầng làm
+sai cả chuỗi.
+
+## 5. Log, metric, trace
+
+| | Quy tắc | Nguồn |
+|---|---|---|
+| Định dạng log | JSON, các trường bắt buộc: `ts`, `level`, `correlationId`, `service`, `msg` | `SAD` §9 |
+| Correlation id | lấy từ header `…`, truyền xuống mọi lời gọi | `SAD` §9 |
+| Mức log | `error` cho lỗi cần người xử lý · `warn` cho lỗi tự hồi phục | |
+| **Cấm log** | PII, secret, toàn bộ request body | `SEC` §5 |
+| Metric bắt buộc mỗi endpoint | số request, tỉ lệ lỗi, phân vị độ trễ | `QAS` |
+
+## 6. Kiểm thử
+
+| Mức | Kiểm gì | Bắt buộc khi nào | Ngưỡng |
+|---|---|---|---|
+| Đơn vị | logic nghiệp vụ thuần | mọi rule trong `BR` của BA | |
+| Tích hợp | ranh giới với CSDL/hàng đợi | mọi repository | |
+| Contract | `IF-nnn` không đổi breaking | mọi interface công khai | `FIT-nn` |
+| Hiệu năng | `QAS` mức Must | trước mỗi release | `FIT-nn` |
+
+## 7. Khi nào phải hỏi SA
+
+*Ranh giới rõ ràng giúp team không bị chặn, và SA không thành nút thắt.*
+
+| Tình huống | Quyết định bởi |
+|---|---|
+| Đặt tên, cấu trúc thư mục trong module, chọn thư viện tiện ích | **Dev / Tech Lead** — không cần hỏi |
+| Thêm một bảng vào CSDL của chính module mình | Tech Lead |
+| Thêm một endpoint theo đúng chuẩn `ICD` | Tech Lead |
+| Gọi trực tiếp dữ liệu của module khác | **Hỏi SA** — chạm `ADR-004` |
+| Thêm một phụ thuộc hạ tầng mới (cache, queue, dịch vụ ngoài) | **Hỏi SA** |
+| Đổi contract công khai theo hướng breaking | **Hỏi SA** — cần `ADR` |
+| Bỏ qua một ràng buộc ở §3 vì gấp | **Hỏi SA** — thành `TD-nn` có hạn |
+
+Chấm nhanh: `../../sa-lifecycle/references/decision-radar.md` §2. Điểm ≥ 5 ⇒ hỏi SA.
+
+## 8. Ngoài phạm vi
+
+*Những gì tài liệu này KHÔNG quy định:*
+
+- Quy ước đặt tên, format code, độ dài hàm ⟶ tài liệu của Tech Lead
+- Quy trình Git, đặt tên nhánh, mẫu commit ⟶ tài liệu quy trình
+- Thiết kế giao diện, design system ⟶ tài liệu thiết kế
+
+## 9. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|

.claude/skills/sa-3-enablement/templates/design-review-log.md

@@ -0,0 +1,150 @@
+# DREV — Design Review Log — <PROJECT>
+
+| | |
+|---|---|
+| **Cập nhật** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-3-enablement) |
+| **Scope** | |
+
+> **Đây là sổ sống** — ghi thêm liên tục, không lên version, không archive. Mục cũ không bao
+> giờ sửa; sai thì thêm mục mới tham chiếu ngược.
+
+---
+
+## 1. Tóm tắt
+
+| Trạng thái | Số mục |
+|---|---|
+| Đang chờ SA (⏳) | |
+| Đã kết luận, đang thực hiện | |
+| Đã đóng | |
+| Sinh ra `ADR` mới | |
+| Sinh ra `TD` | |
+
+**Thời gian chờ trung bình:** … ngày · **mục tiêu: ≤ 2 ngày làm việc**
+
+🔴 Chờ lâu hơn 2 ngày thì dev sẽ đi tiếp mà không chờ — và review thành phê bình sau khi đã
+code xong: vô ích và gây mâu thuẫn.
+
+## 2. Nhật ký
+
+### DREV-nnn — <tiêu đề ngắn>
+
+| | |
+|---|---|
+| **Ngày nhận** | |
+| **Người hỏi** | |
+| **Loại** | ❓ câu hỏi làm rõ · 🔧 đề xuất thay đổi thiết kế · ⚠️ phát hiện thiết kế sai |
+| **Trạng thái** | ⏳ chờ SA · 🔄 đang thực hiện · ✅ đóng |
+| **Ngày kết luận** | |
+
+**Bối cảnh** — *(dev mô tả gì, đang gặp vấn đề gì thật)*
+
+**Điểm radar** *(theo `../../sa-lifecycle/references/decision-radar.md` §2)*
+
+| Tiêu chí | Điểm | Lý do |
+|---|---|---|
+| Chi phí đảo ngược | | |
+| Bán kính ảnh hưởng | | |
+| Chạm thuộc tính chất lượng | | |
+| Ràng buộc dài hạn | | |
+| Tranh cãi | | |
+| **Tổng** | /10 | ⇒ *(0–2 trả Tech Lead · 3–4 `DEC` · 5–7 `ADR` · 8–10 `ADR` + POC)* |
+
+**Đối chiếu thiết kế**
+
+| Tài liệu | Nội dung liên quan | Có mâu thuẫn không |
+|---|---|---|
+| `ADR-nnn` | | |
+| `QAS-nnn` | | |
+| `SAD` §… | | |
+
+**Phương án** — *(≥ 2, kể cả khi dev chỉ đưa 1. Phần lớn giá trị của review nằm ở đây.)*
+
+| # | Phương án | Ưu | Nhược | Chi phí |
+|---|---|---|---|---|
+| 1 | | | | |
+| 2 | | | | |
+
+**Kết luận** — chọn đúng một trong bốn:
+
+- [ ] ✅ **Đúng thiết kế** — không cần làm gì
+- [ ] 🟡 **Lệch nhưng chấp nhận được** ⇒ `TD-nn`, hạn …
+- [ ] 🔴 **Lệch phải sửa** ⇒ việc: …, chủ: …, hạn: …
+- [ ] ⚠️ **Thiết kế sai, cần `ADR` mới** ⇒ `ADR-nnn` (`Supersedes: ADR-nnn`)
+
+**Người quyết · ngày:** …
+
+**Việc phát sinh**
+
+| Việc | Chủ | Hạn | Ghi ở đâu |
+|---|---|---|---|
+
+---
+
+### DREV-nnn — <tiêu đề>
+
+*(cùng cấu trúc)*
+
+---
+
+## 3. Mẫu tham khảo — một mục đã hoàn chỉnh
+
+### DREV-012 — Gọi thẳng CSDL module Order từ module Report
+
+| | |
+|---|---|
+| **Ngày nhận** | 2026-09-12 |
+| **Người hỏi** | anh Nam (dev) |
+| **Loại** | 🔧 đề xuất thay đổi thiết kế |
+| **Trạng thái** | ✅ đóng |
+| **Ngày kết luận** | 2026-09-13 |
+
+**Bối cảnh** — Báo cáo tổng hợp cần join 3 bảng của module Order. Gọi qua interface công khai
+mất 4,1 giây, vượt `QAS-003` (p95 ≤ 3s). Dev đề xuất truy vấn thẳng CSDL của Order.
+
+**Điểm radar: 8/10** — chi phí đảo ngược 1 · bán kính 2 · chạm `QAS` 2 · ràng buộc dài hạn 2 ·
+tranh cãi 1 ⇒ cần `ADR`, không quyết trong PR.
+
+**Đối chiếu:** `ADR-004` chốt module chỉ giao tiếp qua interface công khai. `QAS-003` yêu cầu
+p95 ≤ 3s — **thiết kế hiện tại không đạt**. Dev đúng về vấn đề, sai về cách giải.
+
+**Phương án**
+
+| # | Phương án | Ưu | Nhược | Chi phí |
+|---|---|---|---|---|
+| 1 | Giữ ranh giới + read model riêng cho báo cáo | Đúng `ADR-004`, mở đường tách service | Thêm cơ chế đồng bộ | +1 tuần |
+| 2 | Giữ ranh giới + cache kết quả | Rẻ nhất, +2 ngày | Dữ liệu trễ ≤ 5 phút | +2 ngày |
+| 3 | Gọi thẳng CSDL | Nhanh nhất | Vi phạm `ADR-004`, chặn việc tách service sau này | +0 |
+| 4 | Nới `QAS-003` lên 5s | Không phải làm gì | Cần PO chấp nhận | +0 |
+
+**Kết luận:** ⚠️ hỏi PO trước (`OQ-034`: báo cáo trễ 5 phút có chấp nhận được không).
+PO trả lời 2026-09-13: chấp nhận ⇒ chọn **PA-2**.
+
+**Người quyết:** SA + Tech Lead, sau khi PO trả lời `OQ-034` · 2026-09-13
+
+**Việc phát sinh**
+
+| Việc | Chủ | Hạn | Ghi ở đâu |
+|---|---|---|---|
+| Bổ sung `QAS-003` ghi rõ "dữ liệu báo cáo trễ ≤ 5 phút" | SA | 2026-09-15 | `QAS` v1.1 |
+| Ghi `DEC-07` về mức trễ chấp nhận được | SA | 2026-09-15 | `00-index/DEC` |
+| Cài cache + cơ chế làm mới | anh Nam | 2026-09-19 | |
+
+---
+
+## 4. Câu hỏi lặp lại ⇒ tài liệu chưa rõ
+
+*Cùng một câu hỏi từ ≥ 2 người ⇒ không phải lỗi của dev, là lỗi của tài liệu.*
+
+| Câu hỏi | Số lần bị hỏi | Tài liệu phải sửa | Đã sửa |
+|---|---|---|---|
+| | | `AGD` §… / `ICD` §… | ☐ |
+
+## 5. Phản hồi "kiến trúc không thực tế"
+
+*Cùng một phản hồi về cùng một chỗ, ≥ 3 lần ⇒ khả năng cao thiết kế sai thật.*
+
+| Chỗ bị phản hồi | Số lần | Ai | Đã đánh giá lại | Kết luận |
+|---|---|---|---|---|
+| | | | ☐ | |

.claude/skills/sa-3-enablement/templates/fitness-functions.md

@@ -0,0 +1,126 @@
+# FIT — Fitness Functions — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-3-enablement) |
+| **Status** | 🟡 Draft |
+| **Approved by** | Tech Lead: — · QA: — |
+| **Source** | AGD_… v1.0 · QAS_… v1.0 · ADR-… |
+| **Scope** | |
+| **Confidence** | 🟢 |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi |
+|---|---|---|---|
+| 1.0 | | | Bản đầu |
+
+> **Quy tắc `D8`:** ràng buộc không kiểm tự động được thì chỉ là khuyến nghị. Tài liệu này là
+> chỗ biến ràng buộc thành thứ CI cưỡng chế được.
+
+---
+
+## 1. Bảng trạng thái
+
+| ID | Ràng buộc | Nguồn | Công cụ | Bước CI | Chế độ | Trạng thái | Vi phạm | `TD` |
+|---|---|---|---|---|---|---|---|---|
+| `FIT-01` | Tầng domain không import infra | `ADR-002` | ArchUnit | `test` | 🚫 chặn | 🟢 | 0 | |
+| `FIT-02` | Không có secret trong mã nguồn | `SEC` §6 | gitleaks | `pre-build` | 🚫 chặn | 🟢 | 0 | |
+| `FIT-03` | `QAS-004` batch ≤ 45 phút | `QAS-004` | k6 | `perf` (nightly) | ⚠️ cảnh báo | 🔴 | 52 phút | `TD-05` |
+
+**Chế độ:** ⚠️ cảnh báo · 🚫 chặn merge · ⏸ chưa bật
+**Trạng thái:** 🟢 xanh · 🔴 đỏ · ⚪ chưa chạy lần nào
+
+## 2. Lộ trình bật
+
+*Đừng cố phủ hết ngay. Thứ tự đem lại giá trị nhanh nhất, và mọi bài kiểm bắt đầu ở chế độ
+cảnh báo.*
+
+| Tuần | Bật gì | Vì sao thứ tự này |
+|---|---|---|
+| 1 | Phụ thuộc giữa tầng/module · quét secret | Rẻ nhất, chặn được nhiều lỗi nhất |
+| 2 | Quét lỗ hổng thư viện · lint contract | Công cụ có sẵn, cấu hình nhanh |
+| 3 | Kiểm thử hiệu năng `QAS` mức Must | Tốn công dựng nhất |
+| 4 | Kiểm tra IaC / policy hạ tầng | Cần quyền trên pipeline hạ tầng |
+
+**Lịch chuyển cảnh báo → chặn**
+
+| `FIT` | Bật cảnh báo | Vi phạm lúc bật | Ngày chuyển sang chặn | Ai dọn nợ | Trạng thái |
+|---|---|---|---|---|---|
+| `FIT-01` | 2026-09-01 | 12 | 2026-09-20 | anh Nam | |
+
+🔴 **Bật chế độ chặn ngay trên codebase đã có nợ sẽ làm CI đỏ toàn bộ và team sẽ tắt nó.**
+Quy tắc chuyển tiếp: bật cảnh báo → ghi số vi phạm làm mốc → quy tắc "không tăng thêm" →
+giảm dần về 0 → chuyển sang chặn.
+
+## 3. Chi tiết từng fitness function
+
+### `FIT-01` — <tên>
+
+| | |
+|---|---|
+| **Ràng buộc kiểm** | *(phát biểu chính xác, kiểm chứng được)* |
+| **Nguồn** | `ADR-002` / `QAS-nnn` / `SEC` §… |
+| **Công cụ** | |
+| **File bài kiểm** | `<đường dẫn trong repo>` |
+| **Chạy ở đâu** | bước `<tên>` trong `<file CI>` · mỗi PR / nightly / trước release |
+| **Thời gian chạy** | … s |
+| **Chế độ** | ⚠️ cảnh báo → 🚫 chặn từ … |
+| **Đỏ thì ai sửa** | |
+| **Ngoại lệ được phép** | *(danh sách whitelist + lý do + hạn — whitelist không có hạn là whitelist vĩnh viễn)* |
+
+**Cấu hình mẫu**
+
+```
+<đoạn cấu hình/code thật, để người khác nhân bản được>
+```
+
+### `FIT-02` — <tên>
+
+*(cùng cấu trúc)*
+
+## 4. Bảng phủ — ràng buộc nào chưa có bài kiểm
+
+*Mọi ràng buộc trong `AGD` §3 và mọi `QAS` mức Must phải xuất hiện ở đây.*
+
+| Ràng buộc / `QAS` | Có `FIT` | Nếu không: nhãn `⚠️ Khuyến nghị` | Cách kiểm thủ công | Tần suất |
+|---|---|---|---|---|
+| `AGD` §3.1-1 | `FIT-01` | — | — | — |
+| `AGD` §3.4-2 | ❌ | ⚠️ Khuyến nghị | review PR có checklist | mỗi PR chạm authz |
+| `QAS-007` | ❌ | ⚠️ Khuyến nghị | diễn tập thủ công | mỗi quý |
+
+🔴 Dòng không có `FIT` **và** không có nhãn `⚠️ Khuyến nghị` ⇒ chặn AG3. Trong sáu tháng nó sẽ
+bị vi phạm và không ai biết.
+
+## 5. `QAS` mức Must × bài đo thật
+
+*AG3 yêu cầu **đã đo**, không chấp nhận ước lượng.*
+
+| `QAS` | Mục tiêu | Bài đo | Môi trường | Lần đo gần nhất | Kết quả | Đạt |
+|---|---|---|---|---|---|---|
+| `QAS-001` | p95 ≤ 300ms | `perf/api.js` | stg | | | ☐ |
+| `QAS-004` | ≤ 45 phút | `perf/batch.js` | stg | | 52 phút | ❌ |
+
+**Sai lệch môi trường** — stg khác prod ở đâu, và sai số ước tính bao nhiêu:
+
+| Khác biệt | Ảnh hưởng tới `QAS` nào | Sai số ước tính | Cách bù |
+|---|---|---|---|
+
+## 6. Bảo trì bộ fitness function
+
+| Việc | Tần suất | Ai |
+|---|---|---|
+| Rà whitelist quá hạn | hàng tháng | |
+| Rà bài kiểm chạy quá lâu (làm chậm CI) | hàng tháng | |
+| Rà `FIT` không còn đúng vì `ADR` đã superseded | sau mỗi `ADR` mới | |
+| Rà bài kiểm luôn xanh vì nó không kiểm gì cả | mỗi quý | |
+
+🔴 **Bài kiểm luôn xanh từ ngày đầu là bài kiểm đáng nghi.** Thử phá nó một lần để chắc chắn
+nó đỏ được — bài kiểm không bao giờ đỏ là bài kiểm không kiểm gì.
+
+## 7. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|

.claude/skills/sa-3-enablement/templates/tech-debt-register.md

@@ -0,0 +1,101 @@
+# TDEBT — Technical Debt Register — <PROJECT>
+
+| | |
+|---|---|
+| **Cập nhật** | YYYY-MM-DD |
+| **Author** | <SA> (skill sa-3-enablement) |
+| **Scope** | |
+
+> **Đây là sổ sống** — ghi thêm liên tục, không lên version. Mục đóng vẫn giữ lại.
+
+---
+
+## 1. Tóm tắt
+
+| | Số mục | Tổng lãi suất/tháng | Tổng chi phí trả nợ |
+|---|---|---|---|
+| 🔴 Cao | | … ngày công/tháng | … ngày công |
+| 🟠 Trung bình | | | |
+| 🟡 Thấp | | | |
+| ✅ Đã trả | | — | — |
+
+**Ba mục nên trả trước** *(lãi suất cao / chi phí trả thấp)*: `TD-…`, `TD-…`, `TD-…`
+
+🔴 **Cột "lãi suất" là cột làm cho nợ được ưu tiên.** Không có nó, sổ nợ chỉ tăng không giảm.
+Viết bằng ngôn ngữ PM hiểu: *"mỗi tính năng chạm module này tốn thêm 2 ngày"*, *"gây trung bình
+1 sự cố/tháng"*.
+
+## 2. Phân loại
+
+| Loại | Nghĩa | Xử lý |
+|---|---|---|
+| 🎯 **Có ý thức, có kế hoạch** | Chấp nhận để kịp mốc, biết rõ sẽ sửa khi nào | Ghi hạn, theo dõi |
+| 🌫️ **Có ý thức, chưa có kế hoạch** | Biết là sai, chưa biết sửa thế nào | Ghi, đưa vào `TRM` |
+| 💥 **Vô ý** | Phát hiện qua review hoặc `FIT` đỏ | Đánh giá rồi xếp vào 2 loại trên |
+| ⚠️ **Do kiến trúc sai** | Thiết kế không khả thi | **Không phải nợ** — mở `ADR` mới, đừng ghi ở đây |
+
+## 3. Sổ nợ
+
+| ID | Mô tả | Loại | Nguồn | Vì sao chấp nhận | **Lãi suất** | Chi phí trả | Mức | Chủ | Hạn xét lại | Trạng thái |
+|---|---|---|---|---|---|---|---|---|---|---|
+| `TD-01` | | 🎯 | `DREV-012` | | +2 ngày/tính năng chạm module | 5 ngày công | 🔴 | | | Mở |
+| `TD-02` | | 💥 | `FIT-01` đỏ, 12 vi phạm | | | | | | | |
+
+**Trạng thái:** Mở · Đang trả · Đã trả (kèm ngày) · Đã chuyển thành `ADR` · Chấp nhận vĩnh viễn
+
+🔴 Mục "sẽ sửa sau" không có **chủ** và **hạn** ⇒ không phải mục nợ hợp lệ, chặn AG3.
+
+## 4. Chi tiết mục mức cao
+
+### `TD-01` — <tên>
+
+| | |
+|---|---|
+| **Lệch so với** | `ADR-nnn` / `AGD` §… / `QAS-nnn` |
+| **Ở đâu trong code** | `<đường dẫn>` |
+| **Ai chấp nhận · ngày** | |
+| **Vì sao chấp nhận** | *(lý do thật: mốc nào, đánh đổi gì)* |
+| **Lãi suất** | *(con số)* |
+| **Rủi ro nếu để lâu** | |
+| **Cách trả** | *(các bước cụ thể)* |
+| **Chi phí trả** | … ngày công |
+| **Điều kiện phải trả ngay** | *(dấu hiệu nào thì không hoãn được nữa)* |
+| **Ngoại lệ trong `FIT`** | `FIT-nn` whitelist mục … · hạn … |
+
+🔴 **Whitelist trong `FIT` phải có hạn.** Whitelist không hạn là cách biến nợ tạm thời thành
+kiến trúc vĩnh viễn.
+
+## 5. Nợ đã trả
+
+| ID | Mô tả | Trả ngày | Chi phí thực tế | So với ước lượng | Bài học |
+|---|---|---|---|---|---|
+
+*Cột "so với ước lượng" giúp lần sau ước lượng đúng hơn. Nợ thường tốn hơn ước lượng ban đầu
+khoảng 1,5–2 lần.*
+
+## 6. Nợ chấp nhận vĩnh viễn
+
+*Nợ quyết định không trả. Ghi lại để người sau không mất thời gian điều tra "sao chỗ này lạ vậy".*
+
+| ID | Mô tả | Vì sao không trả | Ai quyết · ngày | Cần biết gì khi động vào chỗ này |
+|---|---|---|---|---|
+
+## 7. Trình bày cho PM / PO
+
+*Bảng này dùng để đưa nợ vào sprint. Dịch sang ngôn ngữ tiến độ và rủi ro.*
+
+| Nợ | Đang làm chậm cái gì | Chậm bao nhiêu | Trả mất | Hoà vốn sau |
+|---|---|---|---|---|
+| `TD-01` | mọi tính năng chạm module Order | +2 ngày/tính năng | 5 ngày | 3 tính năng |
+
+**Câu hỏi trình PM:** *"Quý tới có bao nhiêu tính năng chạm module Order?"* — nếu ≥ 3 thì trả
+nợ ngay là lựa chọn rẻ hơn, và PM tự thấy điều đó.
+
+## 8. Rà định kỳ
+
+| Việc | Tần suất | Ai | Lần gần nhất |
+|---|---|---|---|
+| Rà mục quá hạn xét lại | 2 tuần/lần | SA | |
+| Cập nhật lãi suất theo thực tế | hàng tháng | SA + Tech Lead | |
+| Rà whitelist `FIT` hết hạn | hàng tháng | SA | |
+| Trình bảng §7 cho PM | mỗi lần lập kế hoạch sprint/quý | SA | |