init git

.claude/skills/ba-lifecycle/references/domain-profiles.md

@@ -0,0 +1,192 @@
+# Project Profile — ba trục quyết định cách chạy pipeline
+
+Bộ skill này **không phụ thuộc ngành nghiệp vụ** (bán lẻ, y tế, logistics, ngân hàng, HR…
+đều dùng chung khung). Nhưng nó **phụ thuộc ba thứ khác**, và ba thứ đó phải được khai báo
+ngay ở Bước 0 của mọi skill:
+
+```
+PROFILE = PRODUCT × LIFECYCLE × RIGOR
+```
+
+Khai sai profile ⇒ skill đòi bạn điền những mục không tồn tại trong loại sản phẩm của bạn,
+hoặc bỏ qua những mục sống còn. Đây là thứ quyết định mọi guideline phía sau.
+
+---
+
+## 0. Cách khai báo
+
+Lần đầu chạy một project, `ba-lifecycle` tạo `00-index/PROFILE_<PROJECT>.md`:
+
+```markdown
+# PROFILE — <PROJECT>
+
+| | |
+|---|---|
+| **PRODUCT** | screen |
+| **LIFECYCLE** | brownfield |
+| **RIGOR** | standard |
+| **Ngành** | Bán lẻ / đối soát doanh thu |
+| **Người chốt profile** | <PO/BA Lead>, ngày… |
+| **Lý do chọn** | … |
+
+## Hệ quả đã áp dụng
+| Quyết định | Vì trục nào |
+|---|---|
+| Dùng biến thể SRS PART 2 = `screen` | PRODUCT |
+| Bắt buộc AS-IS đầy đủ + phân tích dữ liệu cũ | LIFECYCLE |
+| Gate ký bởi PO + Tech Lead + QA | RIGOR |
+```
+
+Mọi artifact khác thêm một dòng vào header: `| **Profile** | screen · brownfield · standard |`
+
+**Đổi profile giữa chừng** phải ghi `DEC-nn` và nêu artifact nào phải viết lại.
+
+---
+
+## 1. Trục PRODUCT — loại sản phẩm
+
+Trục quan trọng nhất. Nó quyết định **GĐ3 viết cái gì**.
+
+| Giá trị | Sản phẩm là gì | Biến thể SRS PART 2 |
+|---|---|---|
+| `screen` | Có giao diện người dùng — web admin, web app, app di động | `srs-part2/screen.md` |
+| `api-service` | Chỉ API/service, không giao diện; người tiêu thụ là hệ thống khác | `srs-part2/api-service.md` |
+| `data-pipeline` | Sản phẩm là **dữ liệu** — ETL, ingest, kho dữ liệu, báo cáo BI | `srs-part2/data-pipeline.md` |
+| `ml-model` | Sản phẩm là **mô hình dự đoán** — phân loại, xếp hạng, dự báo, sinh nội dung | `srs-part2/ml-model.md` |
+| `batch-job` | Job chạy theo lịch, không giao diện — đối soát đêm, sinh báo cáo, dọn dữ liệu | `srs-part2/batch-job.md` |
+| `process-only` | **Không phải phần mềm** — cải tiến quy trình, đổi cách làm việc | Không có PART 2 |
+
+### Hệ quả theo từng giai đoạn
+
+| | `screen` | `api-service` | `data-pipeline` | `ml-model` | `batch-job` | `process-only` |
+|---|---|---|---|---|---|---|
+| **GĐ1** Discovery | Đủ | Đủ; "người dùng" là **team tiêu thụ API** | Đủ; hỏi thêm về nguồn dữ liệu | Đủ; **bắt buộc** hỏi chi phí của dự đoán sai | Đủ | Đủ |
+| **GĐ2** `PROCESS` | Đủ | Đủ | Đủ | Đủ | Đủ | Đủ — **trọng tâm** |
+| **GĐ2** `RBAC` | Đủ | Theo client/scope thay vì vai trò người | Theo tập dữ liệu + độ nhạy cảm | Ai được xem điểm số/lý do | Ai được chạy tay | Đủ |
+| **GĐ3** PART 2 | Màn hình, field | Endpoint, schema | Luồng dữ liệu, data contract | Bài toán, metric, ngưỡng | Job, lịch, chạy lại | ❌ N/A |
+| **GĐ3** `AC` | 4 nhóm đầy đủ | 4 nhóm đầy đủ | 4 nhóm + **đối soát nguồn–đích** | 🔴 Chỉ áp cho hệ thống bao quanh; phần dự đoán dùng **ngưỡng metric** | 4 nhóm + **chạy lại** | Tiêu chí quy trình |
+| **GĐ3** text hiển thị | Bắt buộc | N/A | N/A | Chỉ phần hiển thị cho người | N/A | N/A |
+| **GĐ4** UAT | Người dùng thao tác | Team tiêu thụ tích hợp thử | Đối soát số liệu song song | 🔴 Đánh giá trên tập giữ lại + shadow mode | Chạy song song với cách cũ | Chạy thử quy trình |
+| **GĐ5** `MANUAL` | Cho người dùng cuối | **Tài liệu tích hợp** cho dev | Từ điển dữ liệu + hướng dẫn đọc số | Hướng dẫn diễn giải kết quả | Sổ tay vận hành | Quy trình mới |
+
+🔴 **`ml-model` là loại lệch nhiều nhất.** Yêu cầu mang tính xác suất, nên Given/When/Then
+không mô tả được — đọc kỹ phần đầu `srs-part2/ml-model.md` trước khi bắt đầu.
+
+### Loại chưa hỗ trợ
+
+`embedded` / IoT / firmware: NFR khác hẳn (điện năng, nhiệt độ, thời gian thực cứng, an
+toàn chức năng), và không có khái niệm "trạng thái rỗng". **Bộ skill này chưa có biến thể
+PART 2 cho nó.** Dùng khung GĐ1/GĐ2/GĐ4/GĐ5 vẫn được; PART 2 của GĐ3 phải tự viết. Nói rõ
+điều này với người dùng thay vì cố nhét vào biến thể gần đúng nhất.
+
+### Một project có nhiều loại
+
+Bình thường — một tính năng thường gồm `screen` + `api-service`, đôi khi + `batch-job`.
+Cách xử lý: **profile khai loại chính**, và GĐ3 nạp nhiều biến thể PART 2, mỗi biến thể một
+mục con. Không tách thành nhiều project.
+
+---
+
+## 2. Trục LIFECYCLE — nền cũ hay nền mới
+
+Quyết định **GĐ1 và GĐ2 nặng ở đâu**.
+
+| Giá trị | Nghĩa | AS-IS | Dữ liệu cũ | `IMPACT` |
+|---|---|---|---|---|
+| `greenfield` | Chưa có gì, không thay thế cái nào | Chỉ mô tả cách làm thủ công hiện tại (nếu có) | N/A — ghi rõ | Rút gọn: chỉ trục tích hợp |
+| `brownfield` | Thay thế/bổ sung hệ thống đang chạy | 🔴 **Bắt buộc đầy đủ** | 🔴 **Bắt buộc chọn 1 trong 3 phương án** | Đầy đủ 6 trục |
+| `enhancement` | Thêm/sửa trên module đã có | Chỉ phần bị đụng | Bắt buộc nếu đổi schema/rule | Đầy đủ 6 trục — **trọng tâm** |
+
+**Hệ quả cụ thể:**
+
+- `greenfield` ⇒ [process-model.md](../../ba-2-analysis/templates/process-model.md) PHẦN A rút
+  gọn còn A3 (điểm đau) + A4 (đường tắt) + A5 (ngoại lệ). Bỏ A1, A2, A6 và **ghi rõ lý do**,
+  đừng để trống.
+- `enhancement` ⇒ GĐ1 chạy chế độ rút gọn (`--mode enhancement`): chỉ `RQ` + rủi ro, bỏ
+  `BRIEF` đầy đủ. Nhưng `IMPACT` ở GĐ2 thì **nặng hơn** bình thường.
+- `brownfield` ⇒ mục "dữ liệu cũ xử lý thế nào" trong `IMPACT` §1.2 là blocker của G2.
+
+---
+
+## 3. Trục RIGOR — mức nghiêm ngặt
+
+Quyết định **gate chặt tới đâu và ai phải ký**. `standard` là baseline; `light` bớt đi,
+`strict` thêm vào.
+
+| Giá trị | Dùng khi | Ký gate |
+|---|---|---|
+| `light` | POC, thử nghiệm, công cụ nội bộ ≤ 2 tuần, không đụng tiền/dữ liệu cá nhân | Chỉ PO |
+| `standard` | Mặc định — sản phẩm thật, có người dùng thật | PO + Tech Lead + QA (theo từng gate) |
+| `strict` | Có tiền, dữ liệu cá nhân, yêu cầu pháp lý, chịu kiểm toán (tài chính, y tế, bảo hiểm) | Như standard **+ Bảo mật/Pháp chế ở G2 và G3** |
+
+Chi tiết tiêu chí bớt/thêm theo từng gate: [workflow.md §2.0](workflow.md).
+
+### Chọn `light` không phải là được phép làm ẩu
+
+`light` bỏ **thủ tục**, không bỏ **tư duy**. Bốn thứ không bao giờ được bỏ ở bất kỳ mức nào:
+
+1. Phát biểu bài toán (không có thì không biết đang giải gì)
+2. Ít nhất một `GOAL` có cách đo (không có thì không biết có thành công không)
+3. `OQ` cho mọi chỗ chưa rõ (bịa vẫn là bịa, kể cả trong POC)
+4. Ghi lại quyết định `DEC-nn` (POC hôm nay thành sản phẩm sáu tháng sau là chuyện thường)
+
+### Nâng mức giữa chừng
+
+POC `light` được duyệt thành sản phẩm ⇒ **nâng lên `standard` và chạy bù**: rà lại G1, G2,
+G3 theo checklist đầy đủ trước khi làm tiếp. Ghi `DEC-nn`. Không nâng bù là cách một POC
+mang theo mọi thiếu sót của nó vào sản phẩm thật.
+
+---
+
+## 4. Bảng tra nhanh — profile nào nạp gì
+
+| Profile | Template GĐ2 nạp | Biến thể PART 2 | Gate ký bởi |
+|---|---|---|---|
+| `screen · brownfield · standard` | Đủ 5 | `screen` | PO + TL + QA |
+| `screen · greenfield · light` | `BACKLOG`, `BR` | `screen` | PO |
+| `api-service · enhancement · standard` | `BACKLOG`, `BR`, `IMPACT` (nặng) | `api-service` | PO + TL + QA |
+| `data-pipeline · brownfield · strict` | Đủ 5 + đối soát | `data-pipeline` | PO + TL + QA + Bảo mật |
+| `ml-model · greenfield · standard` | `PROCESS`, `BACKLOG`, `BR` | `ml-model` | PO + TL + QA |
+| `batch-job · enhancement · strict` | `BACKLOG`, `BR`, `RBAC`, `IMPACT` | `batch-job` | PO + TL + QA + Bảo mật |
+| `process-only · brownfield · standard` | `PROCESS` (trọng tâm), `RBAC` | ❌ | PO |
+
+---
+
+## 5. Ba ví dụ profile thật
+
+**① Màn hình quản trị đối soát trong hệ thống bán lẻ đang chạy**
+```
+screen · brownfield · standard
+```
+Có giao diện, thay thế quy trình Excel đang dùng, đụng dữ liệu giao dịch có sẵn, không phải
+hệ thống chịu kiểm toán trực tiếp. → PART 2 `screen`, AS-IS bắt buộc, ký 3 bên.
+
+**② Luồng nạp dữ liệu POS hằng đêm vào kho dữ liệu, phục vụ báo cáo tài chính**
+```
+data-pipeline · greenfield · strict
+```
+Không giao diện, sản phẩm là dữ liệu, phục vụ báo cáo tài chính nên chịu kiểm toán. → PART 2
+`data-pipeline`, bắt buộc mục đối soát nguồn–đích và audit log, thêm chữ ký Bảo mật.
+
+**③ Thử nghiệm gợi ý sản phẩm cho app khách hàng, chạy 3 tuần xem có đáng đầu tư không**
+```
+ml-model · greenfield · light
+```
+POC, chưa có người dùng thật ngoài nhóm thử. → PART 2 `ml-model` nhưng chỉ mục 2.1–2.5,
+gate chỉ PO ký. Vẫn bắt buộc: bài toán, một metric có ngưỡng, `OQ`, `DEC`.
+
+---
+
+## 6. Chọn thế nào khi lưỡng lự
+
+| Lưỡng lự | Chọn | Vì |
+|---|---|---|
+| `screen` hay `api-service` | Theo **người tiêu thụ**: người → `screen`, hệ thống → `api-service` | Ai đọc AC quyết định AC viết thế nào |
+| `data-pipeline` hay `batch-job` | Sản phẩm là **dữ liệu để phân tích** → pipeline; là **việc được làm xong** → batch-job | Pipeline cần data contract, batch-job cần idempotency |
+| `ml-model` hay `screen` | Có thành phần dự đoán ⇒ **nạp cả hai biến thể** | Màn hình vẫn cần spec bình thường |
+| `brownfield` hay `enhancement` | Thay cả quy trình → brownfield; thêm một mẩu vào cái đang chạy → enhancement | Quyết AS-IS nặng hay nhẹ |
+| `standard` hay `strict` | Có tiền, dữ liệu cá nhân, hoặc ai đó có thể bị kiểm toán ⇒ `strict` | Nâng mức rẻ hơn nhiều so với sửa sau kiểm toán |
+| `light` hay `standard` | Kết quả sẽ được dùng thật bởi người ngoài nhóm ⇒ `standard` | "POC" mà có người dùng thật thì không còn là POC |
+
+**Không chắc ⇒ chọn mức cao hơn và hỏi người dùng.** Sai hướng "chặt quá" tốn thêm ít thủ
+tục; sai hướng "lỏng quá" mất thông tin không lấy lại được.